From adrian@olddog.co.uk Wed Feb 22 01:09:42 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707A721F8798 for ; Wed, 22 Feb 2012 01:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWyhrYkvo+3p for ; Wed, 22 Feb 2012 01:09:40 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2405321F8794 for ; Wed, 22 Feb 2012 01:09:35 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q1M99Yv2011858 for ; Wed, 22 Feb 2012 09:09:34 GMT Received: from 950129200 (42-177.79-83.cust.bluewin.ch [83.79.177.42]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q1M98b1U011143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 22 Feb 2012 09:09:31 GMT From: "Adrian Farrel" To: Date: Wed, 22 Feb 2012 09:08:29 -0000 Message-ID: <001a01ccf141$b12f7f30$138e7d90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczwwCd31SXyNhIWSUyBZ1t8C7qZ7A== Content-Language: en-gb Subject: [RTG-DIR] Your help with Routing Area Meeting in Paris X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 09:09:43 -0000 Hi Directorate, In Paris Stewart and I are thinking about spending some time looking at the routing work that is happening in other Areas. This is not necessarily routing packets in the way we are used to, but is often using a lot of the same paradigms and maybe reinventing some of the same wheels. We don't think that we should be muscling in on the work in other Areas (except maybe where the work really belongs in the Routing Area), but we suspect that there is quite a bit of advice that could be given. And at the least there is some two-way information exchange that can happen. We are aware of a number of I-Ds that involve "routing" concepts. Examples include draft-ietf-p2psip-base and draft-mrw-abfab-trust-router, but there are plenty of others. This is a call for you to flag up any IETF "routing-type" work that you are aware of so we can try to put together a session of lightning talks on the work in Paris. Thanks for any suggestions. Cheers, Adrian From ginsberg@cisco.com Sun Feb 26 23:21:46 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4526C21F851C for ; Sun, 26 Feb 2012 23:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXHyyAa91rgN for ; Sun, 26 Feb 2012 23:21:41 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED8421F8512 for ; Sun, 26 Feb 2012 23:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=2260; q=dns/txt; s=iport; t=1330327301; x=1331536901; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=P4KFoqA0Ro5PiEKc/se9zVfMtWx3uZQMeTcfBzAkIrk=; b=KoAWrYtCE/6+kPq7ajmnO/1dhXmOraSs3DTW6MwsxqI+UNLQLKXta/yV YmXpIamtRJXcQqptXKkl5YVWKx4DnJnaRP1UhqJL360ZdHo1kdTRlWGUV NBic8V+R8onIfyqvHWgCasm4lacJxTDN0i6PE7zwXiuIqCot2MSdwGo7W I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL8tS0+rRDoI/2dsb2JhbABDs1qBB4F1AQQSAR0KPxIBHA4GGAdXAQQbARmHYwELoFcBljeNFgcHAgELAQEKAwJEEQkChEEFfQ4HBAYaDoI7YwSIT599 X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="30604652" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 27 Feb 2012 07:21:40 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1R7Leof019848; Mon, 27 Feb 2012 07:21:40 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Feb 2012 23:21:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Feb 2012 23:21:38 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-netext-pmip-lr-08.txt Thread-Index: Acz1IHG1hUuhpJ7bSE66fe92hHq8QA== From: "Les Ginsberg (ginsberg)" To: X-OriginalArrivalTime: 27 Feb 2012 07:21:40.0411 (UTC) FILETIME=[730110B0:01CCF520] Cc: rtg-dir@ietf.org, draft-ietf-netext-pmip-lr-08.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-netext-pmip-lr-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 07:21:46 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-netext-pmip-lr-08 Reviewer: Les Ginsberg Review Date: 26 February 2012 IETF LC End Date: ??? Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document is clearly written and easy to understand. This is the first PMIP document I have reviewed, so I went back and read some of the previous RFCs. Despite that it may mean that some of my comments/questions are naive. Please indulge me. Major Issues: No major issues found. Minor Issues: Why are you not using the "MN-CN" terminology from RFC 6279? The fact that you use "MN-MN" makes me think that you are only addressing cases where both endpoints are MNs. Is this the case? If so, this should be explicitly stated. If not, it would seem to be better to use the RFC 6279 terminology. Section 5 I assume the lack of requirement for synchronization works because the LMA will always forward packets regardless of whether it has sent an LRI/received an LRA? This implies that MNs and MAGs may receive duplicate packets at times - which presumably should be no problem. I am wondering if it would be useful to discuss these points? Similarly, in Section 6.1 it is assumed that LMAs always forward inter-MN packets regardless of the state of LR? Nits: A number of acronyms are used without definition. For example, in Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not represent a complete list. Can you please scrub the document for all such occurences? From ginsberg@cisco.com Sun Feb 26 23:29:00 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E0F21F8526 for ; Sun, 26 Feb 2012 23:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.266 X-Spam-Level: X-Spam-Status: No, score=-9.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDZyengY0KT3 for ; Sun, 26 Feb 2012 23:28:59 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF421F851D for ; Sun, 26 Feb 2012 23:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=2301; q=dns/txt; s=iport; t=1330327739; x=1331537339; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=g62ZMPmnSU+wRDvauIx+uPnqFemMmJ9O2E1Sush9lY4=; b=i3ILEhUHZHBP1ZdPKh/KocE44BZNUtCbWkrlcpv25CN1ELfP5f9g+E05 Og9w0Yc/p/v5llP7t4GtX0szHQXZKPvMtOGJbLJrUf1g29KWMcG5ydaFj c6TVG08OMOw1bAV7hzxFY24ZKyQSn0GNv4WQS0zXLwCspami6H/RALqTX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABcwS0+rRDoI/2dsb2JhbABDs1qBB4F1AQQSAR0KPxIBHA4GGAdXAQQbARmHYwELoFoBlj2NFgcHAgELAQEKAwJEEQkChEEFfQ4HBAYaDoI7YwSIT599 X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="32571177" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 27 Feb 2012 07:28:58 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1R7Sw3V023222; Mon, 27 Feb 2012 07:28:58 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Feb 2012 23:28:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Feb 2012 23:28:56 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-netext-pmip-lr-08.txt Thread-Index: Acz1IHG1hUuhpJ7bSE66fe92hHq8QA== From: "Les Ginsberg (ginsberg)" To: X-OriginalArrivalTime: 27 Feb 2012 07:28:58.0421 (UTC) FILETIME=[78141650:01CCF521] Cc: rtg-dir@ietf.org, draft-ietf-netext-pmip-lr.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-netext-pmip-lr-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 07:29:00 -0000 (Resending w corrected draft address) Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-netext-pmip-lr-08 Reviewer: Les Ginsberg Review Date: 26 February 2012 IETF LC End Date: ??? Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document is clearly written and easy to understand. This is the first PMIP document I have reviewed, so I went back and read some of the previous RFCs. Despite that it may mean that some of my comments/questions are naive. Please indulge me. Major Issues: No major issues found. Minor Issues: Why are you not using the "MN-CN" terminology from RFC 6279? The fact that you use "MN-MN" makes me think that you are only addressing cases where both endpoints are MNs. Is this the case? If so, this should be explicitly stated. If not, it would seem to be better to use the RFC 6279 terminology. Section 5 I assume the lack of requirement for synchronization works because the LMA will always forward packets regardless of whether it has sent an LRI/received an LRA? This implies that MNs and MAGs may receive duplicate packets at times - which presumably should be no problem. I am wondering if it would be useful to discuss these points? Similarly, in Section 6.1 it is assumed that LMAs always forward inter-MN packets regardless of the state of LR? Nits: A number of acronyms are used without definition. For example, in Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not represent a complete list. Can you please scrub the document for all such occurences? From ginsberg@cisco.com Wed Feb 29 20:32:33 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4621E801E for ; Wed, 29 Feb 2012 20:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5B3jEeIo7er7 for ; Wed, 29 Feb 2012 20:32:33 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0C75921E8021 for ; Wed, 29 Feb 2012 20:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=5542; q=dns/txt; s=iport; t=1330576353; x=1331785953; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Qvq1Hqe5utatrOM6G7k8jbrqdvOaBW8rEPhlFzPCluM=; b=GccHGhQ2HeAAY5n6Gmf7GJf269piR1YxDVWgSOg6+AbHlTKel00aDil6 y/U8j7S5ExarQFyI0kItKBwk4Joav6d59IRqhBTneimXPF9zeHHOL7lku TI/I/LG7z5u0XR4p5Ya3n2FaVDUixTRiEaHDs+k5OU2Muo+arMKYuNobP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK77Tk+rRDoI/2dsb2JhbABDtAiBB4F6AQEBAwESAR0KPwwEAgEIEQMBAQEBCgYXAQYBRQkIAQEEEwgBEgeHYgQBC6BFAZcgjHoFAwcJAQkBAgsDAkQRhEwFfQ4HBAYBGAGCSWMEiE+gAg X-IronPort-AV: E=Sophos;i="4.73,507,1325462400"; d="scan'208";a="33580210" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 01 Mar 2012 04:32:20 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q214WK7Z018532; Thu, 1 Mar 2012 04:32:20 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 20:32:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 20:32:18 -0800 Message-ID: In-Reply-To: <4F4D83A1.8040103@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-netext-pmip-lr-08.txt Thread-Index: Acz2hBTs7nP0lYbhT+iPqIKKQe8t9wA3dFIw References: <4F4D83A1.8040103@ericsson.com> From: "Les Ginsberg (ginsberg)" To: "Suresh Krishnan" X-OriginalArrivalTime: 01 Mar 2012 04:32:20.0571 (UTC) FILETIME=[4A81C2B0:01CCF764] Cc: rtg-dir@ietf.org, draft-ietf-netext-pmip-lr.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netext-pmip-lr-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 04:32:34 -0000 Suresh - Replies inline. > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Tuesday, February 28, 2012 5:47 PM > To: Les Ginsberg (ginsberg) > Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-netext-pmip- > lr.all@tools.ietf.org > Subject: Re: RtgDir review: draft-ietf-netext-pmip-lr-08.txt >=20 > Hi Les, > Thanks for the review. Please find responses inline. >=20 > On 02/27/2012 02:28 AM, Les Ginsberg (ginsberg) wrote: > > (Resending w corrected draft address) > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this > draft. > > The Routing Directorate seeks to review all routing or routing- > related > > drafts as they pass through IETF last call and IESG review. The > purpose > > of the review is to provide assistance to the Routing ADs. For more > > information about the Routing Directorate, please see > > http://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the Routing ADs, > it > > would be helpful if you could consider them along with any other IETF > > Last Call comments that you receive, and strive to resolve them > through > > discussion or by updating the draft. > > > > Document: draft-ietf-netext-pmip-lr-08 > > Reviewer: Les Ginsberg > > Review Date: 26 February 2012 > > IETF LC End Date: ??? > > Intended Status: Standards Track > > > > Summary: > > I have some minor concerns about this document that I think should be > > resolved before publication. > > > > Comments: > > This document is clearly written and easy to understand. > > This is the first PMIP document I have reviewed, so I went back and > read > > some of the previous RFCs. Despite that it may mean that some of my > > comments/questions are naive. Please indulge me. > > > > Major Issues: > > No major issues found. > > > > Minor Issues: > > > > Why are you not using the "MN-CN" terminology from RFC 6279? The fact > > that you use "MN-MN" makes me think that you are only addressing > cases > > where both endpoints are MNs. Is this the case? If so, this should be > > explicitly stated. If not, it would seem to be better to use the RFC > > 6279 terminology. >=20 > Your understanding is correct. I will add a statement to that effect. Could you also explain why the solutions defined do not work unless both nodes are Mobile? And, since you say that MN-CN is not addressed, is this something which is planned for a future document? RFC 6279 seems to clearly include both MN-MN and MN-nonMN (my terminology invention :-)) in the problem space to be solved. >=20 > > > > Section 5 > > > > I assume the lack of requirement for synchronization works because > the > > LMA will always forward packets regardless of whether it has sent an > > LRI/received an LRA? This implies that MNs and MAGs may receive > > duplicate packets at times - which presumably should be no problem. I > am > > wondering if it would be useful to discuss these points? >=20 > In the handover case, the MAG2 will continue sending packets to MAG1 > until the LMA establishes new LR state towards nMAG1, and these packets > will be lost. I will add text to this section to make this clear. This is not what I was commenting on - though additional clarity in this case would be helpful as well. I was commenting on the initial setup of LR. I was commenting on the statement " The protocol does not require any synchronization between the MAGs before local forwarding begins." This occurs at the end of Section 5 BEFORE the discussion of handoff in Section 5.1. Please respond to this comment. >=20 > > > > Similarly, in Section 6.1 it is assumed that LMAs always forward > > inter-MN packets regardless of the state of LR? >=20 > There will be no inter-LMA forwarding in this case during handover. The > wg decided not to handle this case (A22) because there is no defined > inter-LMA communication mechanism in PMIPv6. I am not commenting on A22 - which is discussed in Section 7. My comment is regarding what happens during the handover discussed in Section 6.1. My concern is regarding what prevents packets from being lost during the handover. I assume that no packets are lost because the LMA will always forward packets to an MN registered with it even if it currently believes that LR is active/enabled - but wanted to confirm and also suggest that mention of that point (if correct) might be clarifying. I understand that the scenario morphs into A22 and you are not trying to enable LR in that scenario. I also understand that there will not be LMA1-LMA2 communication. Hope this helps clarify my original comment. >=20 > > > > Nits: > > A number of acronyms are used without definition. For example, in > > Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not > > represent a complete list. Can you please scrub the document for all > > such occurences? >=20 > These are inherited from the base PMIP RFC (RFC5213). Would you still > like me to add the expansions here? I have been advised in the past on drafts I have co-authored that defining all acronyms is necessary - even if they are defined in a reference. I think this is motivated by trying to make the reader experience more friendly. They should not have to open another document just to find the definition of an acronym. Les =20 >=20 > Thanks > Suresh >=20