From stig@venaas.com Tue May 1 12:01:19 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 D915A21F89A2 for ; Tue, 1 May 2012 12:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 B6ghRdDBbrSL for ; Tue, 1 May 2012 12:01:19 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id B694A21F89A6 for ; Tue, 1 May 2012 12:01:08 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D6AFF7FD8; Tue, 1 May 2012 21:01:01 +0200 (CEST) Message-ID: <4FA032E6.9020508@venaas.com> Date: Tue, 01 May 2012 12:00:54 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Geoff Huston References: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> In-Reply-To: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-mcaddrdoc-03.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: Tue, 01 May 2012 19:01:20 -0000 Thanks Geoff, one comment below. On 4/30/2012 2:00 PM, Geoff Huston wrote: > 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, and sometimes on special request. 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-mboned-mcaddrdoc-03.txt > Reviewer: Geoff Huston > Review Date: 2 May 2012 > IETF LC End Date: not known > Intended Status: Informational > > Summary: > > I have some minor concerns about this document that I think should be resolved before publication. > > Comments: > > The draft is clear and readily understandably - quality is good and no changes are suggested here. > > Major Issues: > No major issues found. > > Minor Issues: > > 1. Section 2, First paragraph reads: > > "For Any-Source Multicast (ASM), the IPv4 multicast addresses > allocated for documentation purposes are 233.252.0.0 - 233.252.0.255 > (233.252.0.0/24)." > > But the IANA Multicast registry (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml) says: > > AD-HOC Block III (233.252.0.0-233.255.255.255 (233.252/14)) > > 233.252.0.0-233.252.0.255 MCAST-TEST-NET [IANA] 2010-01-20 2010-01-20 > > i.e. the IANA registry does NOT say that this address block has been allocated for documentation. Indeed, it appears (by virtue of its name MCAST-TEST-NET) to be already assigned for test purposes. > > In IPv4 and IPv6 unicast we have deliberately split documentation and test addresses. It would be useful to either understand why this split is not appropriate here, or why this draft does not request a block for IPv4 ASM in the say way that it is already requesting a block for IPv6. This reviewer is of the personal view that a separate assignment would be appropriate here, in a comparable fashion to that being proposed for IPv6 ASM. Good point. I don't remember the history, but I was told that we already had these addresses we could use for IPv4, and then I confess I did not think much more about it. Having separate addresses for test and configuration is a good point though! I'm trying to check with IANA what the original request actually was. I'll hopefully get some feedback soon. Does anyone reading this know? If they indeed are for testing (which the name clearly indicates), then I'm in favor of requesting a separate documentation block as well. I think whatever we decide here is something I need to take back to mboned as well, to make sure we're all in agreement. Stig > > 2. IANA Considerations > > Obviously the reviewr is anticipating that the 2 TBD IANA assignments will be nade prior to publication. > > > Nits: > > none found (but this reviewer is the first to admit that he is not a good proof reader!) > > -- > > Geoff Huston From stig@venaas.com Wed May 2 11:27:35 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 75A6621F8541 for ; Wed, 2 May 2012 11:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 c-jZAGMO8R1n for ; Wed, 2 May 2012 11:27:34 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 504EA21F8540 for ; Wed, 2 May 2012 11:27:34 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id B68807FD6; Wed, 2 May 2012 20:27:30 +0200 (CEST) Message-ID: <4FA17C8D.1090709@venaas.com> Date: Wed, 02 May 2012 11:27:25 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tim Chown References: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> <4FA032E6.9020508@venaas.com> <7B1BD856-69F2-4D19-9E76-6C0BBD8D8D94@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , "draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org" , Geoff Huston , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-mcaddrdoc-03.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: Wed, 02 May 2012 18:27:35 -0000 On 5/2/2012 7:57 AM, Tim Chown wrote: > Interesting. > > Out of curiosity I looked at RFC5737 on IPv4 unicast documentation prefixes and it says > > "The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and > 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation" > > which suggests TEST-NET is used elsewhere for documentation purposes. > > Means you can also use 234.192.0.2 for documentation too, presumbly ;) > > Anyway, let's see what response Stig gets. They pointed me to RFC 5771, I should have thought of that. Section 9 says: The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- TEST-NET" for use in documentation and example code. 233.252.0.0/24 SHOULD be used in conjunction with the [RFC2606] domain names example.com or example.net in vendor and protocol documentation. Addresses within 233.252.0.0/24 MUST NOT appear on the public Internet. Hence it looks like these are exactly what we want. The name MCAST-TEST-NET is confusing, but since it is in line with unicast as you write above, it seems we should not make any changes regarding this in the draft. Stig > > Tim > > > On 1 May 2012, at 20:00, Stig Venaas wrote: > >> Thanks Geoff, one comment below. >> >> On 4/30/2012 2:00 PM, Geoff Huston wrote: >>> 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, and sometimes on special request. 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-mboned-mcaddrdoc-03.txt >>> Reviewer: Geoff Huston >>> Review Date: 2 May 2012 >>> IETF LC End Date: not known >>> Intended Status: Informational >>> >>> Summary: >>> >>> I have some minor concerns about this document that I think should be resolved before publication. >>> >>> Comments: >>> >>> The draft is clear and readily understandably - quality is good and no changes are suggested here. >>> >>> Major Issues: >>> No major issues found. >>> >>> Minor Issues: >>> >>> 1. Section 2, First paragraph reads: >>> >>> "For Any-Source Multicast (ASM), the IPv4 multicast addresses >>> allocated for documentation purposes are 233.252.0.0 - 233.252.0.255 >>> (233.252.0.0/24)." >>> >>> But the IANA Multicast registry (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml) says: >>> >>> AD-HOC Block III (233.252.0.0-233.255.255.255 (233.252/14)) >>> >>> 233.252.0.0-233.252.0.255 MCAST-TEST-NET [IANA] 2010-01-20 2010-01-20 >>> >>> i.e. the IANA registry does NOT say that this address block has been allocated for documentation. Indeed, it appears (by virtue of its name MCAST-TEST-NET) to be already assigned for test purposes. >>> >>> In IPv4 and IPv6 unicast we have deliberately split documentation and test addresses. It would be useful to either understand why this split is not appropriate here, or why this draft does not request a block for IPv4 ASM in the say way that it is already requesting a block for IPv6. This reviewer is of the personal view that a separate assignment would be appropriate here, in a comparable fashion to that being proposed for IPv6 ASM. >> >> Good point. I don't remember the history, but I was told that we >> already had these addresses we could use for IPv4, and then I >> confess I did not think much more about it. Having separate >> addresses for test and configuration is a good point though! >> >> I'm trying to check with IANA what the original request actually >> was. I'll hopefully get some feedback soon. Does anyone reading >> this know? >> >> If they indeed are for testing (which the name clearly >> indicates), then I'm in favor of requesting a separate >> documentation block as well. >> >> I think whatever we decide here is something I need to take back >> to mboned as well, to make sure we're all in agreement. >> >> Stig >> >>> >>> 2. IANA Considerations >>> >>> Obviously the reviewr is anticipating that the 2 TBD IANA assignments will be nade prior to publication. >>> >>> >>> Nits: >>> >>> none found (but this reviewer is the first to admit that he is not a good proof reader!) >>> >>> -- >>> >>> Geoff Huston >> From gih@apnic.net Wed May 2 11:44:48 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 7E5EF11E8097 for ; Wed, 2 May 2012 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] 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 u+xVbAgyppe8 for ; Wed, 2 May 2012 11:44:47 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA1E11E808F for ; Wed, 2 May 2012 11:44:46 -0700 (PDT) Received: from dhcp140.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A69D1B67DA; Thu, 3 May 2012 04:44:44 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 3 May 2012 04:44:43 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <906947BC-88F1-48A0-B21E-63A2E929FF56@apnic.net> References: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> <4FA032E6.9020508@venaas.com> <7B1BD856-69F2-4D19-9E76-6C0BBD8D8D94@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1257) Cc: Stig Venaas , "draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-mcaddrdoc-03.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: Wed, 02 May 2012 18:44:48 -0000 IANA's naming conventions are not clear to me. Don't forget there is = RFC2544 which explicitly assigns 198.15.0.0/15 as a test block as = distinct from a documentation block. Geoff On 03/05/2012, at 12:57 AM, Tim Chown wrote: > Interesting. >=20 > Out of curiosity I looked at RFC5737 on IPv4 unicast documentation = prefixes and it says >=20 > "The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), = and=20 > 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation" >=20 > which suggests TEST-NET is used elsewhere for documentation purposes. >=20 > Means you can also use 234.192.0.2 for documentation too, presumbly ;) >=20 > Anyway, let's see what response Stig gets. >=20 > Tim >=20 >=20 > On 1 May 2012, at 20:00, Stig Venaas wrote: >=20 >> Thanks Geoff, one comment below. >>=20 >> On 4/30/2012 2:00 PM, Geoff Huston wrote: >>> Hello, >>>=20 >>> 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, and sometimes on special request. 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 >>>=20 >>> 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. >>>=20 >>> Document: draft-ietf-mboned-mcaddrdoc-03.txt >>> Reviewer: Geoff Huston >>> Review Date: 2 May 2012 >>> IETF LC End Date: not known >>> Intended Status: Informational >>>=20 >>> Summary: >>>=20 >>> I have some minor concerns about this document that I think should = be resolved before publication. >>>=20 >>> Comments: >>>=20 >>> The draft is clear and readily understandably - quality is good = and no changes are suggested here. >>>=20 >>> Major Issues: >>> No major issues found. >>>=20 >>> Minor Issues: >>>=20 >>> 1. Section 2, First paragraph reads: >>>=20 >>> "For Any-Source Multicast (ASM), the IPv4 multicast addresses >>> allocated for documentation purposes are 233.252.0.0 - = 233.252.0.255 >>> (233.252.0.0/24)." >>>=20 >>> But the IANA Multicast registry = (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.x= ml) says: >>>=20 >>> AD-HOC Block III (233.252.0.0-233.255.255.255 (233.252/14)) >>>=20 >>> 233.252.0.0-233.252.0.255 MCAST-TEST-NET [IANA] = 2010-01-20 2010-01-20 >>>=20 >>> i.e. the IANA registry does NOT say that this address block has = been allocated for documentation. Indeed, it appears (by virtue of its = name MCAST-TEST-NET) to be already assigned for test purposes. >>>=20 >>> In IPv4 and IPv6 unicast we have deliberately split documentation = and test addresses. It would be useful to either understand why this = split is not appropriate here, or why this draft does not request a = block for IPv4 ASM in the say way that it is already requesting a block = for IPv6. This reviewer is of the personal view that a separate = assignment would be appropriate here, in a comparable fashion to that = being proposed for IPv6 ASM. >>=20 >> Good point. I don't remember the history, but I was told that we >> already had these addresses we could use for IPv4, and then I >> confess I did not think much more about it. Having separate >> addresses for test and configuration is a good point though! >>=20 >> I'm trying to check with IANA what the original request actually >> was. I'll hopefully get some feedback soon. Does anyone reading >> this know? >>=20 >> If they indeed are for testing (which the name clearly >> indicates), then I'm in favor of requesting a separate >> documentation block as well. >>=20 >> I think whatever we decide here is something I need to take back >> to mboned as well, to make sure we're all in agreement. >>=20 >> Stig >>=20 >>>=20 >>> 2. IANA Considerations >>>=20 >>> Obviously the reviewr is anticipating that the 2 TBD IANA = assignments will be nade prior to publication. >>>=20 >>>=20 >>> Nits: >>>=20 >>> none found (but this reviewer is the first to admit that he is not = a good proof reader!) >>>=20 >>> -- >>>=20 >>> Geoff Huston >>=20 -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From gih@apnic.net Wed May 2 11:56:36 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 851CD21F84DA for ; Wed, 2 May 2012 11:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] 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 QYebEACpukvI for ; Wed, 2 May 2012 11:56:36 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id A737E21F84D6 for ; Wed, 2 May 2012 11:56:35 -0700 (PDT) Received: from dhcp140.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 76AB2B67DA; Thu, 3 May 2012 04:56:34 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Geoff Huston In-Reply-To: <4FA17C8D.1090709@venaas.com> Date: Thu, 3 May 2012 04:56:33 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <68504C91-43A5-414C-B568-DB2D2C0BC341@apnic.net> References: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> <4FA032E6.9020508@venaas.com> <7B1BD856-69F2-4D19-9E76-6C0BBD8D8D94@ecs.soton.ac.uk> <4FA17C8D.1090709@venaas.com> To: Stig Venaas X-Mailer: Apple Mail (2.1257) Cc: "rtg-dir@ietf.org" , Tim Chown , "draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-mcaddrdoc-03.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: Wed, 02 May 2012 18:56:36 -0000 On 03/05/2012, at 4:27 AM, Stig Venaas wrote: > On 5/2/2012 7:57 AM, Tim Chown wrote: >> Interesting. >>=20 >> Out of curiosity I looked at RFC5737 on IPv4 unicast documentation = prefixes and it says >>=20 >> "The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), = and >> 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation" >>=20 >> which suggests TEST-NET is used elsewhere for documentation purposes. >>=20 >> Means you can also use 234.192.0.2 for documentation too, presumbly = ;) >>=20 >> Anyway, let's see what response Stig gets. >=20 > They pointed me to RFC 5771, I should have thought of that. Section 9 = says: >=20 > The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- > TEST-NET" for use in documentation and example code. 233.252.0.0/24 > SHOULD be used in conjunction with the [RFC2606] domain names > example.com or example.net in vendor and protocol documentation. > Addresses within 233.252.0.0/24 MUST NOT appear on the public > Internet. >=20 > Hence it looks like these are exactly what we want. The name > MCAST-TEST-NET is confusing, but since it is in line with unicast > as you write above, it seems we should not make any changes regarding > this in the draft. >=20 > Stig I agree with your assessment It would've been helpful if the references section in the IANA registry = http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xm= l for this address block referenced RFC5771 rather than as it is today, = namely [IANA]. You might want to consider adding to your IANA considerations section = that the entry for 233.252.0.0-233.252.0.255 MCAST-TEST-NET reference = this RFC-to-be, as should all the other IANA registry entries for the = documentation address assignments made in this document, so that all the = documentation prefixes are clearly identified in the IANA multicast = address registries as such cheers, Geoff From stig@venaas.com Wed May 2 12:04:40 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 3BAD611E808D for ; Wed, 2 May 2012 12:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3KBXDz9I3jPF for ; Wed, 2 May 2012 12:04:39 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 54FA011E8074 for ; Wed, 2 May 2012 12:04:39 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6C2E07FE7; Wed, 2 May 2012 21:04:37 +0200 (CEST) Message-ID: <4FA18544.6050601@venaas.com> Date: Wed, 02 May 2012 12:04:36 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Geoff Huston References: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> <4FA032E6.9020508@venaas.com> <7B1BD856-69F2-4D19-9E76-6C0BBD8D8D94@ecs.soton.ac.uk> <4FA17C8D.1090709@venaas.com> <68504C91-43A5-414C-B568-DB2D2C0BC341@apnic.net> In-Reply-To: <68504C91-43A5-414C-B568-DB2D2C0BC341@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , Tim Chown , "draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-mcaddrdoc-03.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: Wed, 02 May 2012 19:04:40 -0000 On 5/2/2012 11:56 AM, Geoff Huston wrote: > > On 03/05/2012, at 4:27 AM, Stig Venaas wrote: > >> On 5/2/2012 7:57 AM, Tim Chown wrote: >>> Interesting. >>> >>> Out of curiosity I looked at RFC5737 on IPv4 unicast documentation prefixes and it says >>> >>> "The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and >>> 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation" >>> >>> which suggests TEST-NET is used elsewhere for documentation purposes. >>> >>> Means you can also use 234.192.0.2 for documentation too, presumbly ;) >>> >>> Anyway, let's see what response Stig gets. >> >> They pointed me to RFC 5771, I should have thought of that. Section 9 says: >> >> The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- >> TEST-NET" for use in documentation and example code. 233.252.0.0/24 >> SHOULD be used in conjunction with the [RFC2606] domain names >> example.com or example.net in vendor and protocol documentation. >> Addresses within 233.252.0.0/24 MUST NOT appear on the public >> Internet. >> >> Hence it looks like these are exactly what we want. The name >> MCAST-TEST-NET is confusing, but since it is in line with unicast >> as you write above, it seems we should not make any changes regarding >> this in the draft. >> >> Stig > > > I agree with your assessment First of all, I find the naming confusing, but guess best to stick to it now. > It would've been helpful if the references section in the IANA registry http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml for this address block referenced RFC5771 rather than as it is today, namely [IANA]. Yes, I just suggested that to IANA as well. > You might want to consider adding to your IANA considerations section that the entry for 233.252.0.0-233.252.0.255 MCAST-TEST-NET reference this RFC-to-be, as should all the other IANA registry entries for the documentation address assignments made in this document, so that all the documentation prefixes are clearly identified in the IANA multicast address registries as such Thanks, I'll do that. You may also have seen an email from IANA regarding the IANA actions for this document, which I responded to just now. The current IANA considerations need to be improved. Thanks Geoff, Stig > cheers, > > Geoff > > > > From tjc@ecs.soton.ac.uk Wed May 2 07:56:19 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 DD43121F8594 for ; Wed, 2 May 2012 07:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 Y6uoukmSI8pK for ; Wed, 2 May 2012 07:56:17 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 41B4321F8566 for ; Wed, 2 May 2012 07:56:17 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q42Eu0e4004907; Wed, 2 May 2012 15:56:00 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q42Eu0e4004907 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1335970561; bh=8kQI2s/XHIHxeaX1ZNpaZIIzSrY=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=BS7ApMs+VGXjjhIP/cL98zfmN0HO++iMBMlV/LZ9d0ay2BliWwGtlZ8uUh3Gi6z+o 4G/l2RZYJvUKheiqdjcaJr5oHsmobSOejJc+vv/DH81zEvN/GrqOBvnsHXMfHvDZeI Rw6DjsDtxGZD8jvOSlHpVfOtA0fVmI+UU2qg3XUw= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o41Fu00543729886WF ret-id none; Wed, 02 May 2012 15:56:00 +0100 Received: from [152.78.162.74] (ip-162-074.eduroam.soton.ac.uk [152.78.162.74]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q42Etu6m022510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 May 2012 15:55:56 +0100 References: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> <4FA032E6.9020508@venaas.com> <7B1BD856-69F2-4D19-9E76-6C0BBD8D8D94@ecs.soton.ac.uk> In-Reply-To: <4FA032E6.9020508@venaas.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-ID: X-Mailer: iPad Mail (9B176) From: Tim Chown Date: Wed, 2 May 2012 15:57:09 +0100 To: Stig Venaas X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o41Fu0054372988600; tid=o41Fu00543729886WF; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q42Eu0e4004907 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Wed, 02 May 2012 13:06:28 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org" , Geoff Huston , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-mcaddrdoc-03.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: Wed, 02 May 2012 14:56:20 -0000 Interesting. Out of curiosity I looked at RFC5737 on IPv4 unicast documentation prefixes a= nd it says "The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and=20 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation" which suggests TEST-NET is used elsewhere for documentation purposes. Means you can also use 234.192.0.2 for documentation too, presumbly ;) Anyway, let's see what response Stig gets. Tim On 1 May 2012, at 20:00, Stig Venaas wrote: > Thanks Geoff, one comment below. >=20 > On 4/30/2012 2:00 PM, Geoff Huston wrote: >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this draft. T= he Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on speci= al request. The purpose of the review is to provide assistance to the Routin= g ADs. For more information about the Routing Directorate, please see http:/= /www.ietf.org/iesg/directorate/routing.html >>=20 >> Although these comments are primarily for the use of the Routing ADs, it w= ould be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion o= r by updating the draft. >>=20 >> Document: draft-ietf-mboned-mcaddrdoc-03.txt >> Reviewer: Geoff Huston >> Review Date: 2 May 2012 >> IETF LC End Date: not known >> Intended Status: Informational >>=20 >> Summary: >>=20 >> I have some minor concerns about this document that I think should be r= esolved before publication. >>=20 >> Comments: >>=20 >> The draft is clear and readily understandably - quality is good and no= changes are suggested here. >>=20 >> Major Issues: >> No major issues found. >>=20 >> Minor Issues: >>=20 >> 1. Section 2, First paragraph reads: >>=20 >> "For Any-Source Multicast (ASM), the IPv4 multicast addresses >> allocated for documentation purposes are 233.252.0.0 - 233.252.0.255 >> (233.252.0.0/24)." >>=20 >> But the IANA Multicast registry (http://www.iana.org/assignments/multi= cast-addresses/multicast-addresses.xml) says: >>=20 >> AD-HOC Block III (233.252.0.0-233.255.255.255 (233.252/14)) >>=20 >> 233.252.0.0-233.252.0.255 MCAST-TEST-NET [IANA] 2010-01-20 = 2010-01-20 >>=20 >> i.e. the IANA registry does NOT say that this address block has been al= located for documentation. Indeed, it appears (by virtue of its name MCAST-T= EST-NET) to be already assigned for test purposes. >>=20 >> In IPv4 and IPv6 unicast we have deliberately split documentation and t= est addresses. It would be useful to either understand why this split is not= appropriate here, or why this draft does not request a block for IPv4 ASM i= n the say way that it is already requesting a block for IPv6. This reviewer i= s of the personal view that a separate assignment would be appropriate here,= in a comparable fashion to that being proposed for IPv6 ASM. >=20 > Good point. I don't remember the history, but I was told that we > already had these addresses we could use for IPv4, and then I > confess I did not think much more about it. Having separate > addresses for test and configuration is a good point though! >=20 > I'm trying to check with IANA what the original request actually > was. I'll hopefully get some feedback soon. Does anyone reading > this know? >=20 > If they indeed are for testing (which the name clearly > indicates), then I'm in favor of requesting a separate > documentation block as well. >=20 > I think whatever we decide here is something I need to take back > to mboned as well, to make sure we're all in agreement. >=20 > Stig >=20 >>=20 >> 2. IANA Considerations >>=20 >> Obviously the reviewr is anticipating that the 2 TBD IANA assignments w= ill be nade prior to publication. >>=20 >>=20 >> Nits: >>=20 >> none found (but this reviewer is the first to admit that he is not a go= od proof reader!) >>=20 >> -- >>=20 >> Geoff Huston >=20 From tjc@ecs.soton.ac.uk Wed May 2 13:20:13 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 5CA8321E8101 for ; Wed, 2 May 2012 13:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.501, 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 TOjKtf7LgvDt for ; Wed, 2 May 2012 13:20:12 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D121E80E7 for ; Wed, 2 May 2012 13:20:12 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q42KK0sc016882; Wed, 2 May 2012 21:20:00 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q42KK0sc016882 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1335990001; bh=AsRvXnIipFDActILK/TOIbEjXwg=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=cv4j1z28keADGSx070LdFMn+c0Lkbezmr+YlofMTe22C3l20WcHquytC9jTYM9s6U QxsOOvW/TW/ZHOTKmbeqH1KHvjxzGrESwwvrTJAEx6POI3mfMUR35kXbCeV/uxKWAf b4yWrbdVwyQTKWkuixNY81u//JcfdYkVJSPi1ADE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o41LK00543732447yZ ret-id none; Wed, 02 May 2012 21:20:01 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q42KJsM4004869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 May 2012 21:19:55 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Tim Chown In-Reply-To: <4FA18544.6050601@venaas.com> Date: Wed, 2 May 2012 21:19:53 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6EDB6C6A-A8C5-45EE-9FD3-D92D2AD9282D@apnic.net> <4FA032E6.9020508@venaas.com> <7B1BD856-69F2-4D19-9E76-6C0BBD8D8D94@ecs.soton.ac.uk> <4FA17C8D.1090709@venaas.com> <68504C91-43A5-414C-B568-DB2D2C0BC341@apnic.net> <4FA18544.6050601@venaas.com> To: Stig Venaas X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o41LK0054373244700; tid=o41LK00543732447yZ; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q42KK0sc016882 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Thu, 03 May 2012 03:18:39 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mboned-mcaddrdoc.all@tools.ietf.org" , Geoff Huston , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-mcaddrdoc-03.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: Wed, 02 May 2012 20:20:13 -0000 Sounds goo, thanks Geoff. Tim On 2 May 2012, at 20:04, Stig Venaas wrote: > On 5/2/2012 11:56 AM, Geoff Huston wrote: >>=20 >> On 03/05/2012, at 4:27 AM, Stig Venaas wrote: >>=20 >>> On 5/2/2012 7:57 AM, Tim Chown wrote: >>>> Interesting. >>>>=20 >>>> Out of curiosity I looked at RFC5737 on IPv4 unicast documentation = prefixes and it says >>>>=20 >>>> "The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 = (TEST-NET-2), and >>>> 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation" >>>>=20 >>>> which suggests TEST-NET is used elsewhere for documentation = purposes. >>>>=20 >>>> Means you can also use 234.192.0.2 for documentation too, presumbly = ;) >>>>=20 >>>> Anyway, let's see what response Stig gets. >>>=20 >>> They pointed me to RFC 5771, I should have thought of that. Section = 9 says: >>>=20 >>> The first /24 in this range, 233.252.0.0/24, is assigned as = "MCAST- >>> TEST-NET" for use in documentation and example code. = 233.252.0.0/24 >>> SHOULD be used in conjunction with the [RFC2606] domain names >>> example.com or example.net in vendor and protocol documentation. >>> Addresses within 233.252.0.0/24 MUST NOT appear on the public >>> Internet. >>>=20 >>> Hence it looks like these are exactly what we want. The name >>> MCAST-TEST-NET is confusing, but since it is in line with unicast >>> as you write above, it seems we should not make any changes = regarding >>> this in the draft. >>>=20 >>> Stig >>=20 >>=20 >> I agree with your assessment >=20 > First of all, I find the naming confusing, but guess best to stick > to it now. >=20 >> It would've been helpful if the references section in the IANA = registry = http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xm= l for this address block referenced RFC5771 rather than as it is today, = namely [IANA]. >=20 > Yes, I just suggested that to IANA as well. >=20 >> You might want to consider adding to your IANA considerations section = that the entry for 233.252.0.0-233.252.0.255 MCAST-TEST-NET reference = this RFC-to-be, as should all the other IANA registry entries for the = documentation address assignments made in this document, so that all the = documentation prefixes are clearly identified in the IANA multicast = address registries as such >=20 > Thanks, I'll do that. >=20 > You may also have seen an email from IANA regarding the IANA actions = for > this document, which I responded to just now. The current IANA > considerations need to be improved. >=20 > Thanks Geoff, >=20 > Stig >=20 >> cheers, >>=20 >> Geoff >>=20 >>=20 >>=20 >>=20 >=20 From jdrake@juniper.net Mon May 14 07:14:47 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 511E821F8771 for ; Mon, 14 May 2012 07:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NscH9SIraipk for ; Mon, 14 May 2012 07:14:46 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A021F85F6 for ; Mon, 14 May 2012 07:14:45 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT7ETRyySHh2tnZFmdIbH5sPy8bQDBR7Q@postini.com; Mon, 14 May 2012 07:14:46 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 14 May 2012 07:13:26 -0700 From: John E Drake To: "rtg-ads@tools.ietf.org" Date: Mon, 14 May 2012 07:13:25 -0700 Thread-Topic: RtgDir review:draft-ietf-ccamp-assoc-info-03.txt Thread-Index: Ac0x27njzESdP6MQQuWMyHV3lH3G1A== Message-ID: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-ccamp-assoc-info.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review:draft-ietf-ccamp-assoc-info-03.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, 14 May 2012 14:14:47 -0000 Hello,=20 I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html=20 Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.=20 Document: draft-ietf-ccamp-assoc-info-03.txt=20 Reviewer: John Drake=20 Review Date: 14-May-2012=20 Intended Status: Informational=20 Summary:=20 No issues found. This document is ready for publication. Comments:=20 This document is clearly written and easy to understand, albeit geared towa= rds the lay reader. Major Issues:=20 No major issues found. Minor Issues:=20 No minor issues found. Sent from my iPhone From eric.gray@ericsson.com Fri May 25 11:17:52 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 3163121F86A6 for ; Fri, 25 May 2012 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9VERQYwhiZmt for ; Fri, 25 May 2012 11:17:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8060B21F86A7 for ; Fri, 25 May 2012 11:17:48 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4PIHiZN021451; Fri, 25 May 2012 13:17:46 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 25 May 2012 14:17:40 -0400 From: Eric Gray To: "rtg-ads@tools.ietf.org" , "BRUNGARD, DEBORAH A" Date: Fri, 25 May 2012 14:17:38 -0400 Thread-Topic: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt Thread-Index: Ac0x27njzESdP6MQQuWMyHV3lH3G1AIvbl0w Message-ID: References: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" Subject: [RTG-DIR] RtgDir review:draft-ietf-mpls-ldp-gtsm-06.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: Fri, 25 May 2012 18:17:52 -0000 =20 Hello,=20 I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html=20 Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.=20 Document: draft-ietf-mpls-ldp-gtsm-06.txt=20 Reviewer: Eric Gray Review Date: 25-May-2012=20 Intended Status: Standard=20 Summary:=20 No major issues found. This document is essentially ready for publication. Comments:=20 This document is mostly clearly written and easily understood. Major Issues:=20 No major issues found. Minor Issues:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Because this draft defines only a new bit assignment as an update to RFC 50= 36, it=20 would have been cleaner to have only included the flags field as shown here= : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To maintain readability, the draft should still say where this field is (th= at it is part of the Common Hello Parameter TLV). =20 In addition, since the definitions of T and R are exactly as given in RFC 5= 036, the text that currently repeats the definitions for T and R could better ha= ve=20 been written as: "T and R As specified in [RFC5036]." This way of representing the changes makes it clearer what the actual chang= es are. However, this is a very minor issue. ___________________________________________________________________________= ______ I am curious why the text under Figure 1 explicitly includes the possibilit= y that=20 an LSR might implement GTSM capability negotiation but not implement GTSM. = But,=20 again, this is a very minor issue. ___________________________________________________________________________= ______ NITs: =3D=3D=3D=3D In the abstract, "packets" should be "packet's." First sentence, first paragraph under Figure 1 - "meaingful" should be "mea= ningful." Second sentence, second paragraph under Figure 1 - "but that it does not" s= hould be "but that does not." -- Eric Gray From eric.gray@ericsson.com Fri May 25 13:05:01 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 53F8021F85AF for ; Fri, 25 May 2012 13:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 sgIB+hcZqKBS for ; Fri, 25 May 2012 13:05:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EB38F21F853C for ; Fri, 25 May 2012 13:04:59 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4PK4sff010342; Fri, 25 May 2012 15:04:57 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 25 May 2012 16:04:56 -0400 From: Eric Gray To: Carlos Pignataro Date: Fri, 25 May 2012 16:04:54 -0400 Thread-Topic: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt Thread-Index: Ac06prTsvXQARGmdQ1CRBt+4laZzEgAB+EcQ Message-ID: References: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C0AC8FAB6849AB4FADACCC70A949E2F123BAF520E6EUSAACMS0701e_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" , "BRUNGARD, DEBORAH A" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-mpls-ldp-gtsm-06.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: Fri, 25 May 2012 20:05:01 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F123BAF520E6EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When I said it would be "cleaner", it was because your draft doesn't modify the rest of the TLV. As a general rule, it is "cleaner" not to include anything that you are not modifying (beyond whatever you believe is minimal acceptable context). If some later draft were to come along and modify - or extend - some other part of the TLV, the issue would then be - does this later document update this one, or RFC 5036? That could lead to a mess. Which is pretty much what it means not to be "clean." However, it doesn't seem terribly likely that someone else is going to alte= r another part of this TLV, so this is largely theoretical, and a minor issue= . As a secondary factor, the fact that you repeated the entire TLV meant that there were just that many other bits I had to make sure you didn't "typo" in some way, or make other (un)intended changes to. >From a point of view of readability, it should be relatively clear to anyon= e implementing these changes to their LDP implementation, where the flags field is in the modified TLV. In fact, I suspect that - if you just showed= the flags field, this would make the meaning clearer and easier to implement to many readers. And this too is a minor issue. For one thing, it is a matter of opinion. = As I mentioned in my other reply, it's okay with me if you don't want to adopt any of the changes implied in my comments. On your paraphrasing the quote about a picture being worth a thousand words, the jury's still out on just how true that is. Different people thi= nk and comprehend in different ways. For me, a picture is worthless unless the words are there to explain it. -- Eric ________________________________ From: Carlos Pignataro [mailto:cpignata@cisco.com] Sent: Friday, May 25, 2012 2:46 PM To: Eric Gray Cc: rtg-ads@tools.ietf.org; BRUNGARD, DEBORAH A; rtg-dir@ietf.org; draft-ie= tf-mpls-ldp-gtsm@tools.ietf.org Subject: Re: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt Importance: High Eric, Thanks much for your review! Please see inline. On May 25, 2012, at 2:17 PM, Eric Gray wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-mpls-ldp-gtsm-06.txt Reviewer: Eric Gray Review Date: 25-May-2012 Intended Status: Standard Summary: No major issues found. This document is essentially ready for publication. Sounds good. Comments: This document is mostly clearly written and easily understood. Thanks. Is the "mostly" qualifying clearly written, easily understood, or b= oth? :-) Where is specifically not? It seems the nits you bring up below ar= e not clarifying meaning. Major Issues: No major issues found. Minor Issues: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Because this draft defines only a new bit assignment as an update to RFC 50= 36, it would have been cleaner to have only included the flags field as shown here= : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thank you for this suggestion. I feel however that furthering the packet co= ntext in which the bits reside adds much more to the clarity and removes am= biguity than this proposal. That is, the whole TLV in a figure is more clea= r than just 3 bits and a reserved without insertion point, and the figure e= xactly as from the RFC it is updating (RFC 5036) module the updated bit is = more unambiguous and easier to find. To maintain readability, the draft should still say where this field is (th= at it is part of the Common Hello Parameter TLV). A figure is worth how many words? :-) In addition, since the definitions of T and R are exactly as given in RFC 5= 036, the text that currently repeats the definitions for T and R could better ha= ve been written as: "T and R As specified in [RFC5036]." Sure we could take the common denominator out, but the current form of the = definition has more symmetry and rhyme while not wasting too many extra lin= es... T, Targeted Hello As specified in [RFC5036]. R, Request Send Targeted Hellos As specified in [RFC5036]. G, GTSM ... This way of representing the changes makes it clearer what the actual chang= es are. However, this is a very minor issue. Perhaps clarity is relative. I feel that including the contextual fields gr= aphically is more clear than describing it with words, and keeping a per-fi= eld list element seems more clear. In any case I appreciate you taking the time to comment on this and proposi= ng an alternate representation of those few lines. ___________________________________________________________________________= ______ I am curious why the text under Figure 1 explicitly includes the possibilit= y that an LSR might implement GTSM capability negotiation but not implement GTSM. = But, again, this is a very minor issue. Do you mean the text immediately underneath Figure 1, or the last paragraph= of Section 2.1? If the latter, this is based on an mpls wg review (Adrian'= s IIRC), which separates the support for GTSM from the understanding of the= G bit. While I agree with you, I think the current text is OK because it i= s unambiguous and complete. Thanks also for pointing this out. I do not expect this will be the case bu= t covering the base. ___________________________________________________________________________= ______ NITs: =3D=3D=3D=3D In the abstract, "packets" should be "packet's." Agreed. Changed in my working copy. First sentence, first paragraph under Figure 1 - "meaingful" should be "mea= ningful." Wow, great catch! I thought I'd run idspell on this... Second sentence, second paragraph under Figure 1 - "but that it does not" s= hould be "but that does not." Yes. Done in my working copy. Thanks again for this review! -- Carlos. -- Eric Gray --_000_C0AC8FAB6849AB4FADACCC70A949E2F123BAF520E6EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
When I said it would be "cleaner", it was because = your=20 draft doesn't modify
the rest of the TLV.
 
As a general rule, it is "cleaner" not to include = anything=20 that you are not
modifying (beyond whatever you believe is minimal= =20 acceptable context).
 
If some later draft were to come along and modify = - or=20 extend - some
other part of the TLV, the i= ssue would=20 then be - does this later document
update this one, or RFC= =20 5036?
 
That could lead to a mess.  Which is pretty m= uch what=20 it means not to
be "clean."
 
However, it doesn't seem terribly likely that some= one else=20 is going to alter
another part of this TLV, so this is largely=20 theoretical, and a minor issue.
 
As a secondary factor, the fact that you repeated = the=20 entire TLV meant
that there were just that many other bits I had to= make=20 sure you didn't
"typo" in some way, or make other (un)intended cha= nges=20 to.
 
From a point of view of readability, it should be= =20 relatively clear to anyone
implementing these changes to their LDP implementa= tion,=20 where the flags
field is in the modified TLV.  In fact, I sus= pect that=20 - if you just showed the
flags field, this would make the meaning clearer a= nd easier=20 to implement
to many readers.
 
And this too is a minor issue.  For one thing= , it is a=20 matter of opinion.  As
I mentioned in my other reply, it's okay with= =20 me if you don't want to adopt 
any of the changes implied in my=20 comments.
 
On your paraphrasing the quote about a picture bei= ng worth=20 a thousand
words, the jury's still out = on just how=20 true that is.  Different people think
and comprehend in diff= erent=20 ways.  For me, a picture is worthless unless
the words are = there=20 to explain it.
 
--
Eric

From: Carlos Pignataro=20 [mailto:cpignata@cisco.com]
Sent: Friday, May 25, 2012 2:46=20 PM
To: Eric Gray
Cc: rtg-ads@tools.ietf.org; BRUNGARD,= =20 DEBORAH A; rtg-dir@ietf.org;=20 draft-ietf-mpls-ldp-gtsm@tools.ietf.org
Subject: Re: RtgDir=20 review:draft-ietf-mpls-ldp-gtsm-06.txt
Importance:=20 High

Eric,

Thanks much for your review! Please see inline.

On May 25, 2012, at 2:17 PM, Eric Gray wrote:


Hello,

I have been selected as the Routing Directora= te=20 reviewer for this draft. The Routing Directorate seeks to review all rout= ing=20 or routing-related drafts as they pass through IETF last call and IESG re= view,=20 and sometimes on special request. The purpose of the review is to provide= =20 assistance to the Routing ADs. For more information about the Routing=20 Directorate, please see http://www.iet= f.org/iesg/directorate/routing.html=20

Although these comments are primarily for the use of the Routing = ADs,=20 it would be helpful if you could consider them along with any other IETF = Last=20 Call comments that you receive, and strive to resolve them through discus= sion=20 or by updating the draft.

Document: draft-ietf-mpls-ldp-gtsm-06.t= xt=20
Reviewer: Eric Gray
Review Date: 25-May-2012
Intended Status:= =20 Standard

Summary:

No major issues found. This document is= =20 essentially ready for publication.

Sounds good.


Comments:

This document is mostly clearly written and ea= sily=20 understood.

Thanks. Is the "mostly" qualifying clearly written, easily understood,= or=20 both? :-) Where is specifically not? It seems the nits you bring up below a= re=20 not clarifying meaning.


Major Issues:

No major issues found.

Minor Issues= :=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Because this draft define= s only a new bit assignment=20 as an update to RFC 5036, it
would have been cleaner to have only inc= luded=20 the flags field as shown=20 here:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R|G|   Res= erved=20             &= nbsp;|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thank you for this suggestion. I feel however that furthering the pack= et=20 context in which the bits reside adds much more to the clarity and removes= =20 ambiguity than this proposal. That is, the whole TLV in a figure is more cl= ear=20 than just 3 bits and a reserved without insertion point, and the figure exa= ctly=20 as from the RFC it is updating (RFC 5036) module the updated bit is more=20 unambiguous and easier to find.


To maintain readability, the draft should still say where this f= ield=20 is (that it
is part of the Common Hello Parameter TLV).=20  

A figure is worth how many words? :-)


In addition, since the definitions of T and R are exactly as giv= en in=20 RFC 5036,
the text that currently repeats the definitions for T and R = could=20 better have
been written as:

"T and R
  As specif= ied=20 in [RFC5036]."

Sure we could take the common denominator out, but the current form of= the=20 definition has more symmetry and rhyme while not wasting too many extra=20 lines...

    T, Targeted Hello
       As specified in [RFC5036].

    R, Request Send Targeted Hellos
       As specified in [RFC5036].

    G, GTSM
...


This way of representing the changes makes it clearer what the a= ctual=20 changes
are.  However, this is a very minor=20 issue.

Perhaps clarity is relative. I feel that including the contextual fiel= ds=20 graphically is more clear than describing it with words, and keeping a per-= field=20 list element seems more clear.

In any case I appreciate you taking the time to comment on this and=20 proposing an alternate representation of those few lines.

____________________________________________________________________= _____________

I=20 am curious why the text under Figure 1 explicitly includes the possibilit= y=20 that
an LSR might implement GTSM capability negotiation but not imple= ment=20 GTSM.  But,
again, this is a very minor issue.

Do you mean the text immediately underneath Figure 1, or the last para= graph=20 of Section 2.1? If the latter, this is based on an mpls wg review (Adrian's= =20 IIRC), which separates the support for GTSM from the understanding of the G= bit.=20 While I agree with you, I think the current text is OK because it is unambi= guous=20 and complete. 

Thanks also for pointing this out. I do not expect this will be the ca= se=20 but covering the base.

____________________________________________________________________= _____________

NITs:
=3D=3D=3D=3D

In=20 the abstract, "packets" should be "packet's."

Agreed. Changed in my working copy.


First sentence, first paragraph under Figure 1 - "meaingful" sho= uld=20 be "meaningful."

Wow, great catch! I thought I'd run idspell on this...


Second sentence, second paragraph under Figure 1 - "but that it = does=20 not" should be
"but that does not."

Yes. Done in my working copy.

Thanks again for this review!

-- Carlos.


--
Eric=20 Gray




--_000_C0AC8FAB6849AB4FADACCC70A949E2F123BAF520E6EUSAACMS0701e_-- From eric.gray@ericsson.com Fri May 25 13:05:02 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 D082821F853C for ; Fri, 25 May 2012 13:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bQh8bXW+HvBN for ; Fri, 25 May 2012 13:05:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7A96521F855A for ; Fri, 25 May 2012 13:05:00 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4PK4vD4010359; Fri, 25 May 2012 15:04:59 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 25 May 2012 16:04:52 -0400 From: Eric Gray To: "Rajiv Asati (rajiva)" , "rtg-ads@tools.ietf.org" , "BRUNGARD, DEBORAH A" Date: Fri, 25 May 2012 16:04:50 -0400 Thread-Topic: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt Thread-Index: Ac0x27njzESdP6MQQuWMyHV3lH3G1AIvbl0wAALGHQAAAgsSIA== Message-ID: References: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-mpls-ldp-gtsm-06.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: Fri, 25 May 2012 20:05:02 -0000 It was the second sentence of the second paragraph under Figure 1: " Similarly, an LSR that does recognize the G flag but that it does not support GTSM (either because it is not implemented, or because it is so configured), would clear the G flag (i.e.,g G=3D0) on send and would effectively ignore the G flag on receipt." One of the cases for "not support" of GTSM - explicitly included - is the case where an implementation recognizes the G flag (implements at least this much of the negotiation), but does not implement GTSM. It struck me as odd, because GTSM does not seem to be hard to do, and we're talking about control plain activities for both the negotiation and the subsequent message processing. It's a very minor issue, because this case could have been implicitly included without begging this question, if worded differently. The thing that triggered this for me was the choice of the words "not supported" (to me, if you have to configure an LSR to _not_ do some function, the LSR supports that function, but it is disabled). I am fine (as is implicit in my saying that the draft is ready to be published) with not making any changes. The NITs can be added to the instructions to the RFC Editor by the IESG. My other comments are to deal with or not deal with at the discretion of the IESG and authors. -- Eric -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Friday, May 25, 2012 2:46 PM To: Eric Gray; rtg-ads@tools.ietf.org; BRUNGARD, DEBORAH A Cc: rtg-dir@ietf.org; draft-ietf-mpls-ldp-gtsm@tools.ietf.org Subject: RE: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt Importance: High Hi Eric, Thank you so much for your review. I agree to the nits and > I am curious why the text under Figure 1 explicitly includes the possibility > that an LSR might implement GTSM capability negotiation but not > implement GTSM. But, again, this is a very minor issue. Could you paste the para that you are referring to? I see the following text under Figure 1: The G flag is meaingful only if the T flag is set to 0 (which must be the case for Basic Discovery), otherwise, the value of G flag SHOULD be ignored on receipt. But I don't think that this is the text you refer to. Any way, Does the note below (PS:) help? > To maintain readability, the draft should still say where this field is (that it is > part of the Common Hello Parameter TLV). > This way of representing the changes makes it clearer what the actual > changes are. However, this is a very minor issue. I am divided on this one. I like having the complete TLV illustrated, otherwise, I would no longer get the complete picture of the TLV itself. Cheers, Rajiv PS: Perhaps, we could update the 2nd last para of the Section 1 introduction as shown below to clarify the rationale: "Since" GTSM [RFC5082] specifies that "it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol" (see Section 3 of [RFC5082]), this document maintains the backward compatibility by including a dynamic GTSM negotiation for LDP to suggest the use of GTSM=20 (without relying on LDP Capabilities [RFCxxxx]). This means that GTSM will be used as specified in this document provided both peers on an LDP session can detect each others' support for GTSM procedures and agree to use it. That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default. =20 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Friday, May 25, 2012 2:18 PM > To: rtg-ads@tools.ietf.org; BRUNGARD, DEBORAH A > Cc: rtg-dir@ietf.org; draft-ietf-mpls-ldp-gtsm@tools.ietf.org > Subject: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt >=20 >=20 > Hello, >=20 > 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, and sometimes on special > request. 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 >=20 > 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. >=20 > Document: draft-ietf-mpls-ldp-gtsm-06.txt > Reviewer: Eric Gray > Review Date: 25-May-2012 > Intended Status: Standard >=20 > Summary: >=20 > No major issues found. This document is essentially ready for publication. >=20 > Comments: >=20 > This document is mostly clearly written and easily understood. >=20 > Major Issues: >=20 > No major issues found. >=20 > Minor Issues: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Because this draft defines only a new bit assignment as an update to RFC > 5036, it would have been cleaner to have only included the flags field as > shown here: >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |T|R|G| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > To maintain readability, the draft should still say where this field is (that it is > part of the Common Hello Parameter TLV). >=20 > In addition, since the definitions of T and R are exactly as given in RFC 5036, > the text that currently repeats the definitions for T and R could better have > been written as: >=20 > "T and R > As specified in [RFC5036]." >=20 > This way of representing the changes makes it clearer what the actual > changes are. However, this is a very minor issue. > ___________________________________________________________________ > ______________ >=20 > I am curious why the text under Figure 1 explicitly includes the possibility > that an LSR might implement GTSM capability negotiation but not > implement GTSM. But, again, this is a very minor issue. > ___________________________________________________________________ > ______________ >=20 > NITs: > =3D=3D=3D=3D >=20 > In the abstract, "packets" should be "packet's." >=20 > First sentence, first paragraph under Figure 1 - "meaingful" should be > "meaningful." >=20 > Second sentence, second paragraph under Figure 1 - "but that it does not" > should be "but that does not." >=20 > -- > Eric Gray >=20 From rajiva@cisco.com Fri May 25 11:45:35 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 E140E21F873B for ; Fri, 25 May 2012 11:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 W3Q3otBTGEva for ; Fri, 25 May 2012 11:45:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C8D9F21F8736 for ; Fri, 25 May 2012 11:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4892; q=dns/txt; s=iport; t=1337971535; x=1339181135; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qCCHGNVl92EqAT1dSNG92cPf9xDPIDJpXt2POgkEU4Y=; b=OFNjgKy5WWSRuqeDumUDZqhW+utaafemSBAAwWRRBv3ZjYgMuDyrl5gK RcxxxhFeh6nv2cOMS/T19zzFMtslVkACOD+1V4S9FE3vG95c1BLsubbxq E55ilXyBuJ8D14Moe7aOHdiTFspu/m1+zQIiyBQmmkVp5zDRPHzphigT2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANrSv0+tJXG9/2dsb2JhbABEtRaBB4IVAQEBAwESAR0KPwUHBAIBCBEDAQEBCwYXAQYBRQkIAQEEARIIARmHZgULmG+fVYsBhGZgA4g/mmWBZIJ+ X-IronPort-AV: E=Sophos;i="4.75,657,1330905600"; d="scan'208";a="86798198" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 25 May 2012 18:45:33 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4PIjXud016266; Fri, 25 May 2012 18:45:33 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 13:45:33 -0500 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: Fri, 25 May 2012 13:45:32 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt Thread-Index: Ac0x27njzESdP6MQQuWMyHV3lH3G1AIvbl0wAALGHQA= References: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> From: "Rajiv Asati (rajiva)" To: "Eric Gray" , , "BRUNGARD, DEBORAH A" X-OriginalArrivalTime: 25 May 2012 18:45:33.0391 (UTC) FILETIME=[90EAEDF0:01CD3AA6] X-Mailman-Approved-At: Sat, 26 May 2012 02:43:24 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-ldp-gtsm@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-mpls-ldp-gtsm-06.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: Fri, 25 May 2012 18:45:36 -0000 Hi Eric, Thank you so much for your review. I agree to the nits and > I am curious why the text under Figure 1 explicitly includes the possibility > that an LSR might implement GTSM capability negotiation but not > implement GTSM. But, again, this is a very minor issue. Could you paste the para that you are referring to? I see the following text under Figure 1: The G flag is meaingful only if the T flag is set to 0 (which must be the case for Basic Discovery), otherwise, the value of G flag SHOULD be ignored on receipt. But I don't think that this is the text you refer to. Any way, Does the note below (PS:) help? > To maintain readability, the draft should still say where this field is (that it is > part of the Common Hello Parameter TLV). > This way of representing the changes makes it clearer what the actual > changes are. However, this is a very minor issue. I am divided on this one. I like having the complete TLV illustrated, otherwise, I would no longer get the complete picture of the TLV itself. Cheers, Rajiv PS: Perhaps, we could update the 2nd last para of the Section 1 introduction as shown below to clarify the rationale: "Since" GTSM [RFC5082] specifies that "it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol" (see Section 3 of [RFC5082]), this document maintains the backward compatibility by including a dynamic GTSM negotiation for LDP to suggest the use of GTSM=20 (without relying on LDP Capabilities [RFCxxxx]). This means that GTSM will be used as specified in this document provided both peers on an LDP session can detect each others' support for GTSM procedures and agree to use it. That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default. =20 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Friday, May 25, 2012 2:18 PM > To: rtg-ads@tools.ietf.org; BRUNGARD, DEBORAH A > Cc: rtg-dir@ietf.org; draft-ietf-mpls-ldp-gtsm@tools.ietf.org > Subject: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt >=20 >=20 > Hello, >=20 > 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, and sometimes on special > request. 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 >=20 > 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. >=20 > Document: draft-ietf-mpls-ldp-gtsm-06.txt > Reviewer: Eric Gray > Review Date: 25-May-2012 > Intended Status: Standard >=20 > Summary: >=20 > No major issues found. This document is essentially ready for publication. >=20 > Comments: >=20 > This document is mostly clearly written and easily understood. >=20 > Major Issues: >=20 > No major issues found. >=20 > Minor Issues: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Because this draft defines only a new bit assignment as an update to RFC > 5036, it would have been cleaner to have only included the flags field as > shown here: >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |T|R|G| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > To maintain readability, the draft should still say where this field is (that it is > part of the Common Hello Parameter TLV). >=20 > In addition, since the definitions of T and R are exactly as given in RFC 5036, > the text that currently repeats the definitions for T and R could better have > been written as: >=20 > "T and R > As specified in [RFC5036]." >=20 > This way of representing the changes makes it clearer what the actual > changes are. However, this is a very minor issue. > ___________________________________________________________________ > ______________ >=20 > I am curious why the text under Figure 1 explicitly includes the possibility > that an LSR might implement GTSM capability negotiation but not > implement GTSM. But, again, this is a very minor issue. > ___________________________________________________________________ > ______________ >=20 > NITs: > =3D=3D=3D=3D >=20 > In the abstract, "packets" should be "packet's." >=20 > First sentence, first paragraph under Figure 1 - "meaingful" should be > "meaningful." >=20 > Second sentence, second paragraph under Figure 1 - "but that it does not" > should be "but that does not." >=20 > -- > Eric Gray >=20 From cpignata@cisco.com Fri May 25 11:46:13 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 0D80221F8780 for ; Fri, 25 May 2012 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 iKzbkTDPYzvm for ; Fri, 25 May 2012 11:46:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DC27921F8736 for ; Fri, 25 May 2012 11:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=12820; q=dns/txt; s=iport; t=1337971572; x=1339181172; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=KYJT0Qv9rZj7qktfQOS6qPMYoMLKRoPY7Eoex8meZ/k=; b=k9w+qEs+SqNc/FkMlYhhiXtGN8hXUVdtJwQAOJq8rNCTcs42fLXEQpo8 cdiJHWTXU0RXifDRYP3n0mZpYcRoFK4+cbMPbcwIFrWIBUmXoLLOn1S90 t0XiOdFUJzR1CKphgb9lNMc0EAXGWJy00WxCKDfQ+6X7CxU3n7abM4/u/ w=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFACXSv0+tJV2Z/2dsb2JhbABEiBSjRgGJO4EHghUBAQEDARIBZgULCxQyVwYcGYdmBQuYb59ViwGEZmADjjWGY4EPjH2BZIEtgU8 X-IronPort-AV: E=Sophos;i="4.75,657,1330905600"; d="asc'?scan'208,217";a="86791527" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 25 May 2012 18:46:11 +0000 Received: from rtp-cpignata-8914.cisco.com (rtp-cpignata-8914.cisco.com [10.117.115.53]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4PIkA89010878; Fri, 25 May 2012 18:46:10 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_EE4DF9BD-0D59-4082-B77F-243D40E831BE"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Carlos Pignataro In-Reply-To: Date: Fri, 25 May 2012 14:46:09 -0400 Message-Id: References: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> To: Eric Gray X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Sat, 26 May 2012 02:43:24 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" , "BRUNGARD, DEBORAH A" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-mpls-ldp-gtsm-06.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: Fri, 25 May 2012 18:46:13 -0000 --Apple-Mail=_EE4DF9BD-0D59-4082-B77F-243D40E831BE Content-Type: multipart/alternative; boundary="Apple-Mail=_41B2C2C7-27D5-49CA-9932-50B174179F12" --Apple-Mail=_41B2C2C7-27D5-49CA-9932-50B174179F12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric, Thanks much for your review! Please see inline. On May 25, 2012, at 2:17 PM, Eric Gray wrote: >=20 >=20 > Hello,=20 >=20 > 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, and sometimes on special request. 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=20 >=20 > 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.=20 >=20 > Document: draft-ietf-mpls-ldp-gtsm-06.txt=20 > Reviewer: Eric Gray > Review Date: 25-May-2012=20 > Intended Status: Standard=20 >=20 > Summary:=20 >=20 > No major issues found. This document is essentially ready for = publication. Sounds good. >=20 > Comments:=20 >=20 > This document is mostly clearly written and easily understood. Thanks. Is the "mostly" qualifying clearly written, easily understood, = or both? :-) Where is specifically not? It seems the nits you bring up = below are not clarifying meaning. >=20 > Major Issues:=20 >=20 > No major issues found. >=20 > Minor Issues:=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Because this draft defines only a new bit assignment as an update to = RFC 5036, it=20 > would have been cleaner to have only included the flags field as shown = here: >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |T|R|G| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thank you for this suggestion. I feel however that furthering the packet = context in which the bits reside adds much more to the clarity and = removes ambiguity than this proposal. That is, the whole TLV in a figure = is more clear than just 3 bits and a reserved without insertion point, = and the figure exactly as from the RFC it is updating (RFC 5036) module = the updated bit is more unambiguous and easier to find. >=20 > To maintain readability, the draft should still say where this field = is (that it > is part of the Common Hello Parameter TLV). =20 A figure is worth how many words? :-) >=20 > In addition, since the definitions of T and R are exactly as given in = RFC 5036, > the text that currently repeats the definitions for T and R could = better have=20 > been written as: >=20 > "T and R > As specified in [RFC5036]." Sure we could take the common denominator out, but the current form of = the definition has more symmetry and rhyme while not wasting too many = extra lines... T, Targeted Hello As specified in [RFC5036]. R, Request Send Targeted Hellos As specified in [RFC5036]. G, GTSM ... >=20 > This way of representing the changes makes it clearer what the actual = changes > are. However, this is a very minor issue. Perhaps clarity is relative. I feel that including the contextual fields = graphically is more clear than describing it with words, and keeping a = per-field list element seems more clear. In any case I appreciate you taking the time to comment on this and = proposing an alternate representation of those few lines. > = __________________________________________________________________________= _______ >=20 > I am curious why the text under Figure 1 explicitly includes the = possibility that=20 > an LSR might implement GTSM capability negotiation but not implement = GTSM. But,=20 > again, this is a very minor issue. Do you mean the text immediately underneath Figure 1, or the last = paragraph of Section 2.1? If the latter, this is based on an mpls wg = review (Adrian's IIRC), which separates the support for GTSM from the = understanding of the G bit. While I agree with you, I think the current = text is OK because it is unambiguous and complete.=20 Thanks also for pointing this out. I do not expect this will be the case = but covering the base. > = __________________________________________________________________________= _______ >=20 > NITs: > =3D=3D=3D=3D >=20 > In the abstract, "packets" should be "packet's." Agreed. Changed in my working copy. >=20 > First sentence, first paragraph under Figure 1 - "meaingful" should be = "meaningful." Wow, great catch! I thought I'd run idspell on this... >=20 > Second sentence, second paragraph under Figure 1 - "but that it does = not" should be > "but that does not." Yes. Done in my working copy. Thanks again for this review! -- Carlos. >=20 > -- > Eric Gray >=20 >=20 >=20 --Apple-Mail=_41B2C2C7-27D5-49CA-9932-50B174179F12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


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, and sometimes on special = request. 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-mpls-ldp-gtsm-06.txt =
Reviewer: Eric Gray
Review Date: 25-May-2012
Intended Status: = Standard

Summary:

No major issues found. This document = is essentially ready for = publication.

Sounds = good.


Comments:

This = document is mostly clearly written and easily = understood.

Thanks. Is the = "mostly" qualifying clearly written, easily understood, or both? :-) = Where is specifically not? It seems the nits you bring up below are not = clarifying meaning.


Major Issues:

No major issues = found.

Minor Issues:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Because this draft defines only a new bit assignment as an update to = RFC 5036, it
would have been cleaner to have only included the flags = field as shown here:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R|G| =   Reserved =             &n= bsp;|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=
Thank you for this suggestion. I feel however that furthering = the packet context in which the bits reside adds much more to the = clarity and removes ambiguity than this proposal. That is, the whole TLV = in a figure is more clear than just 3 bits and a reserved without = insertion point, and the figure exactly as from the RFC it is updating = (RFC 5036) module the updated bit is more unambiguous and easier to = find.


To maintain = readability, the draft should still say where this field is (that = it
is part of the Common Hello Parameter TLV). =  

A figure is worth how = many words? :-)


In addition, = since the definitions of T and R are exactly as given in RFC = 5036,
the text that currently repeats the definitions for T and R = could better have
been written as:

"T and R
=   As specified in = [RFC5036]."

Sure we could take = the common denominator out, but the current form of the definition has = more symmetry and rhyme while not wasting too many extra = lines...

    T, =
Targeted Hello
       As specified in [RFC5036].

    R, Request Send Targeted Hellos
       As specified in [RFC5036].

    G, GTSM
...


This way of representing the changes makes it = clearer what the actual changes
are.  However, this is a very = minor issue.

Perhaps clarity = is relative. I feel that including the contextual fields graphically is = more clear than describing it with words, and keeping a per-field list = element seems more clear.

In any case I = appreciate you taking the time to comment on this and proposing an = alternate representation of those few lines.

_______________________________________________________= __________________________

I am curious why the text under Figure = 1 explicitly includes the possibility that
an LSR might implement = GTSM capability negotiation but not implement GTSM.  But, =
again, this is a very minor = issue.

Do you mean the text = immediately underneath Figure 1, or the last paragraph of Section 2.1? = If the latter, this is based on an mpls wg review (Adrian's IIRC), which = separates the support for GTSM from the understanding of the G bit. = While I agree with you, I think the current text is OK because it is = unambiguous and complete. 

Thanks also for = pointing this out. I do not expect this will be the case but covering = the base.

_______________________________________________________= __________________________

NITs:
=3D=3D=3D=3D

In the = abstract, "packets" should be = "packet's."

Agreed. Changed in = my working copy.


First = sentence, first paragraph under Figure 1 - "meaingful" should be = "meaningful."

Wow, great = catch! I thought I'd run idspell on this...


Second sentence, second paragraph under Figure 1 = - "but that it does not" should be
"but that does = not."

Yes. Done in my working = copy.

Thanks again for this = review!

-- Carlos.


--
Eric = Gray




= --Apple-Mail=_41B2C2C7-27D5-49CA-9932-50B174179F12-- --Apple-Mail=_EE4DF9BD-0D59-4082-B77F-243D40E831BE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk+/03IACgkQtfDPGTp3USwdowCeIocrrDTn+hmyBBek7DVMXz5H hh8AmQGaMqmisSH6Iu1sctdaGlRyTfb8 =Rdp9 -----END PGP SIGNATURE----- --Apple-Mail=_EE4DF9BD-0D59-4082-B77F-243D40E831BE-- From cpignata@cisco.com Fri May 25 13:27:47 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 2E08A21F87DE for ; Fri, 25 May 2012 13:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.135 X-Spam-Level: X-Spam-Status: No, score=-107.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] 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 Z9NCqrpxzEzZ for ; Fri, 25 May 2012 13:27:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 78F6321F87DD for ; Fri, 25 May 2012 13:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=23380; q=dns/txt; s=iport; t=1337977665; x=1339187265; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=d8FzdEP8HOiNU1JiUVlY+etMySdT39vrBBoyTIbSrTs=; b=TMlyyP2RgkvxoXZJo8U/7anFb6f5xfY0p2WhbrCalEhfy2KFCvm9kgwl cH4qA6KJHoKiXYnEQD7LyxOkig+YZggSDjppbChwkcf3QRe/KUI1R1FPP GZn95N/dcH4siWUfK4JaoQw6lgrog411W2eFNp3oILzX2H8T3WzkzggYK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4HAPrqv0+tJV2Z/2dsb2JhbABEhTSvYAKBB4IVAQEBAwESARBWBQsCAQgRAwEBAQEgBwMCAkYJCAEBBBMJGYdmBQuYdI0UkkKLAYQ0MmADiAyNDIEPjH2BZIJ8 X-IronPort-AV: E=Sophos;i="4.75,658,1330905600"; d="scan'208,217";a="86815698" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 25 May 2012 20:27:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4PKRib5013386; Fri, 25 May 2012 20:27:44 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 15:27:44 -0500 Received: from 72.163.62.213 ([72.163.62.213]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 May 2012 20:27:44 +0000 References: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> Content-Transfer-Encoding: 7bit thread-topic: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt thread-index: Ac06tNceryMJgt3OTLCpiRzpnKnxPA== From: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary="Apple-Mail-25FAA9CE-2369-4E62-93D5-B3A98C38CE6A"; charset="iso-8859-1" In-Reply-To: Message-ID: Date: Fri, 25 May 2012 16:27:39 -0400 To: "Eric Gray" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 25 May 2012 20:27:44.0470 (UTC) FILETIME=[D7535760:01CD3AB4] X-Mailman-Approved-At: Sat, 26 May 2012 02:43:24 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-ldp-gtsm@tools.ietf.org, "BRUNGARD, DEBORAH A" , rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-mpls-ldp-gtsm-06.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: Fri, 25 May 2012 20:27:47 -0000 --Apple-Mail-25FAA9CE-2369-4E62-93D5-B3A98C38CE6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks again for your review.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 25, 2012, at 4:05 PM, "Eric Gray" wrote: > When I said it would be "cleaner", it was because your draft doesn't modif= y > the rest of the TLV. > =20 > As a general rule, it is "cleaner" not to include anything that you are no= t > modifying (beyond whatever you believe is minimal acceptable context). > =20 > If some later draft were to come along and modify - or extend - some > other part of the TLV, the issue would then be - does this later document > update this one, or RFC 5036? > =20 > That could lead to a mess. Which is pretty much what it means not to > be "clean." > =20 > However, it doesn't seem terribly likely that someone else is going to alt= er > another part of this TLV, so this is largely theoretical, and a minor issu= e. > =20 > As a secondary factor, the fact that you repeated the entire TLV meant > that there were just that many other bits I had to make sure you didn't > "typo" in some way, or make other (un)intended changes to. > =20 > =46rom a point of view of readability, it should be relatively clear to an= yone > implementing these changes to their LDP implementation, where the flags > field is in the modified TLV. In fact, I suspect that - if you just showe= d the > flags field, this would make the meaning clearer and easier to implement > to many readers. > =20 > And this too is a minor issue. For one thing, it is a matter of opinion. = As > I mentioned in my other reply, it's okay with me if you don't want to adop= t=20 > any of the changes implied in my comments. > =20 > On your paraphrasing the quote about a picture being worth a thousand > words, the jury's still out on just how true that is. Different people th= ink > and comprehend in different ways. For me, a picture is worthless unless > the words are there to explain it. > =20 > -- > Eric >=20 > From: Carlos Pignataro [mailto:cpignata@cisco.com]=20 > Sent: Friday, May 25, 2012 2:46 PM > To: Eric Gray > Cc: rtg-ads@tools.ietf.org; BRUNGARD, DEBORAH A; rtg-dir@ietf.org; draft-i= etf-mpls-ldp-gtsm@tools.ietf.org > Subject: Re: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt > Importance: High >=20 > Eric, >=20 > Thanks much for your review! Please see inline. >=20 > On May 25, 2012, at 2:17 PM, Eric Gray wrote: >=20 >>=20 >>=20 >> Hello,=20 >>=20 >> I have been selected as the Routing Directorate reviewer for this draft. T= he Routing Directorate seeks to review all routing or routing-related dra= fts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Rou= ting ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html=20 >>=20 >> Although these comments are primarily for the use of the Routing ADs, it w= ould be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion = or by updating the draft.=20 >>=20 >> Document: draft-ietf-mpls-ldp-gtsm-06.txt=20 >> Reviewer: Eric Gray >> Review Date: 25-May-2012=20 >> Intended Status: Standard=20 >>=20 >> Summary:=20 >>=20 >> No major issues found. This document is essentially ready for publication= . >=20 > Sounds good. >=20 >>=20 >> Comments:=20 >>=20 >> This document is mostly clearly written and easily understood. >=20 > Thanks. Is the "mostly" qualifying clearly written, easily understood, or b= oth? :-) Where is specifically not? It seems the nits you bring up below are= not clarifying meaning. >=20 >>=20 >> Major Issues:=20 >>=20 >> No major issues found. >>=20 >> Minor Issues:=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Because this draft defines only a new bit assignment as an update to RFC 5= 036, it=20 >> would have been cleaner to have only included the flags field as shown he= re: >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |T|R|G| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Thank you for this suggestion. I feel however that furthering the packet c= ontext in which the bits reside adds much more to the clarity and removes am= biguity than this proposal. That is, the whole TLV in a figure is more clear= than just 3 bits and a reserved without insertion point, and the figure exa= ctly as from the RFC it is updating (RFC 5036) module the updated bit is mor= e unambiguous and easier to find. >=20 >>=20 >> To maintain readability, the draft should still say where this field is (= that it >> is part of the Common Hello Parameter TLV). =20 >=20 > A figure is worth how many words? :-) >=20 >>=20 >> In addition, since the definitions of T and R are exactly as given in RFC= 5036, >> the text that currently repeats the definitions for T and R could better h= ave=20 >> been written as: >>=20 >> "T and R >> As specified in [RFC5036]." >=20 > Sure we could take the common denominator out, but the current form of the= definition has more symmetry and rhyme while not wasting too many extra lin= es... >=20 > T, Targeted Hello > As specified in [RFC5036]. >=20 > R, Request Send Targeted Hellos > As specified in [RFC5036]. >=20 > G, GTSM > ... >=20 >>=20 >> This way of representing the changes makes it clearer what the actual cha= nges >> are. However, this is a very minor issue. >=20 > Perhaps clarity is relative. I feel that including the contextual fields g= raphically is more clear than describing it with words, and keeping a per-fi= eld list element seems more clear. >=20 > In any case I appreciate you taking the time to comment on this and propos= ing an alternate representation of those few lines. >=20 >> _________________________________________________________________________= ________ >>=20 >> I am curious why the text under Figure 1 explicitly includes the possibil= ity that=20 >> an LSR might implement GTSM capability negotiation but not implement GTSM= . But,=20 >> again, this is a very minor issue. >=20 > Do you mean the text immediately underneath Figure 1, or the last paragrap= h of Section 2.1? If the latter, this is based on an mpls wg review (Adrian'= s IIRC), which separates the support for GTSM from the understanding of the G= bit. While I agree with you, I think the current text is OK because it is u= nambiguous and complete.=20 >=20 > Thanks also for pointing this out. I do not expect this will be the case b= ut covering the base. >=20 >> _________________________________________________________________________= ________ >>=20 >> NITs: >> =3D=3D=3D=3D >>=20 >> In the abstract, "packets" should be "packet's." >=20 > Agreed. Changed in my working copy. >=20 >>=20 >> First sentence, first paragraph under Figure 1 - "meaingful" should be "m= eaningful." >=20 > Wow, great catch! I thought I'd run idspell on this... >=20 >>=20 >> Second sentence, second paragraph under Figure 1 - "but that it does not"= should be >> "but that does not." >=20 > Yes. Done in my working copy. >=20 > Thanks again for this review! >=20 > -- Carlos. >=20 >>=20 >> -- >> Eric Gray >>=20 >>=20 >>=20 >=20 --Apple-Mail-25FAA9CE-2369-4E62-93D5-B3A98C38CE6A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Thanks again for your review. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On May 25, 2012, at 4:05 PM, "Eric Gray" <eric.gray@ericsson.com> wrote:

When I said it would be "cleaner", it was because your draft doesn't modify
the rest of the TLV.
 
As a general rule, it is "cleaner" not to include anything that you are not
modifying (beyond whatever you believe is minimal acceptable context).
 
If some later draft were to come along and modify - or extend - some
other part of the TLV, the issue would then be - does this later document
update this one, or RFC 5036?
 
That could lead to a mess.  Which is pretty much what it means not to
be "clean."
 
However, it doesn't seem terribly likely that someone else is going to alter
another part of this TLV, so this is largely theoretical, and a minor issue.
 
As a secondary factor, the fact that you repeated the entire TLV meant
that there were just that many other bits I had to make sure you didn't
"typo" in some way, or make other (un)intended changes to.
 
From a point of view of readability, it should be relatively clear to anyone
implementing these changes to their LDP implementation, where the flags
field is in the modified TLV.  In fact, I suspect that - if you just showed the
flags field, this would make the meaning clearer and easier to implement
to many readers.
 
And this too is a minor issue.  For one thing, it is a matter of opinion.  As
I mentioned in my other reply, it's okay with me if you don't want to adopt 
any of the changes implied in my comments.
 
On your paraphrasing the quote about a picture being worth a thousand
words, the jury's still out on just how true that is.  Different people think
and comprehend in different ways.  For me, a picture is worthless unless
the words are there to explain it.
 
--
Eric

From: Carlos Pignataro [mailto:cpignata@cisco.com]
Sent: Friday, May 25, 2012 2:46 PM
To: Eric Gray
Cc: rtg-ads@tools.ietf.org; BRUNGARD, DEBORAH A; rtg-dir@ietf.org; draft-ietf-mpls-ldp-gtsm@tools.ietf.org
Subject: Re: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt
Importance: High

Eric,

Thanks much for your review! Please see inline.

On May 25, 2012, at 2:17 PM, Eric Gray wrote:



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, and sometimes on special request. 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-mpls-ldp-gtsm-06.txt
Reviewer: Eric Gray
Review Date: 25-May-2012
Intended Status: Standard

Summary:

No major issues found. This document is essentially ready for publication.

Sounds good.


Comments:

This document is mostly clearly written and easily understood.

Thanks. Is the "mostly" qualifying clearly written, easily understood, or both? :-) Where is specifically not? It seems the nits you bring up below are not clarifying meaning.


Major Issues:

No major issues found.

Minor Issues:
============

Because this draft defines only a new bit assignment as an update to RFC 5036, it
would have been cleaner to have only included the flags field as shown here:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R|G|   Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thank you for this suggestion. I feel however that furthering the packet context in which the bits reside adds much more to the clarity and removes ambiguity than this proposal. That is, the whole TLV in a figure is more clear than just 3 bits and a reserved without insertion point, and the figure exactly as from the RFC it is updating (RFC 5036) module the updated bit is more unambiguous and easier to find.


To maintain readability, the draft should still say where this field is (that it
is part of the Common Hello Parameter TLV).  

A figure is worth how many words? :-)


In addition, since the definitions of T and R are exactly as given in RFC 5036,
the text that currently repeats the definitions for T and R could better have
been written as:

"T and R
  As specified in [RFC5036]."

Sure we could take the common denominator out, but the current form of the definition has more symmetry and rhyme while not wasting too many extra lines...

    T, Targeted Hello
       As specified in [RFC5036].

    R, Request Send Targeted Hellos
       As specified in [RFC5036].

    G, GTSM
...


This way of representing the changes makes it clearer what the actual changes
are.  However, this is a very minor issue.

Perhaps clarity is relative. I feel that including the contextual fields graphically is more clear than describing it with words, and keeping a per-field list element seems more clear.

In any case I appreciate you taking the time to comment on this and proposing an alternate representation of those few lines.

_________________________________________________________________________________

I am curious why the text under Figure 1 explicitly includes the possibility that
an LSR might implement GTSM capability negotiation but not implement GTSM.  But,
again, this is a very minor issue.

Do you mean the text immediately underneath Figure 1, or the last paragraph of Section 2.1? If the latter, this is based on an mpls wg review (Adrian's IIRC), which separates the support for GTSM from the understanding of the G bit. While I agree with you, I think the current text is OK because it is unambiguous and complete. 

Thanks also for pointing this out. I do not expect this will be the case but covering the base.

_________________________________________________________________________________

NITs:
====

In the abstract, "packets" should be "packet's."

Agreed. Changed in my working copy.


First sentence, first paragraph under Figure 1 - "meaingful" should be "meaningful."

Wow, great catch! I thought I'd run idspell on this...


Second sentence, second paragraph under Figure 1 - "but that it does not" should be
"but that does not."

Yes. Done in my working copy.

Thanks again for this review!

-- Carlos.


--
Eric Gray




--Apple-Mail-25FAA9CE-2369-4E62-93D5-B3A98C38CE6A-- From cpignata@cisco.com Mon May 28 08:28:58 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 AD9DE21F8627 for ; Mon, 28 May 2012 08:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 RMXxB8jG6wQP for ; Mon, 28 May 2012 08:28:56 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9D21F8623 for ; Mon, 28 May 2012 08:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=39514; q=dns/txt; s=iport; t=1338218936; x=1339428536; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=WcZWU5ymz7sGNPIbbGLsbdhRr9XyG+s15XTPdhRxQXk=; b=FVNXIxijSYKAggQzFYMwcDLvngezFlRN8Am2LL0Tdi7HDdrNfBVIu3x+ fi/2EylFMbvUJAqQUEZ6Pvn09v69R4l5fwukw5O2lJBgeJAiuBkTj5szl C12ITPIfL7oBSkT1DhE9N9Zvke09Lv3963xPgmttj/sz3fRHc8wcxV1GF s=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYFAG2Zw0+tJV2Y/2dsb2JhbABFiBKjcQGJW4EHghcBAQEDARIBB1IKAwULCxEDAQEBASABBgdGCQgGEwkLBwQDh2QFC5hCnzKLA4RfYAOONIZjgQ+MfYFlgS2BTw X-IronPort-AV: E=Sophos;i="4.75,671,1330905600"; d="asc'?scan'208,217";a="87288763" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 28 May 2012 15:28:55 +0000 Received: from rtp-cpignata-8914.cisco.com (rtp-cpignata-8914.cisco.com [10.117.115.53]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4SFSs5J016459; Mon, 28 May 2012 15:28:54 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_F0015F48-72AD-417B-B414-453FE5ABCB98"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Carlos Pignataro In-Reply-To: Date: Mon, 28 May 2012 11:28:53 -0400 Message-Id: <0C0765F2-3507-4C14-8976-6E992EF8D806@cisco.com> References: <5E893DB832F57341992548CDBB333163A577E0C9D2@EMBX01-HQ.jnpr.net> To: Eric Gray X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Mon, 28 May 2012 08:45:07 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" , "BRUNGARD, DEBORAH A" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-mpls-ldp-gtsm-06.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, 28 May 2012 15:28:58 -0000 --Apple-Mail=_F0015F48-72AD-417B-B414-453FE5ABCB98 Content-Type: multipart/alternative; boundary="Apple-Mail=_F4C91E52-CD35-4285-92C5-CF59AE04CB56" --Apple-Mail=_F4C91E52-CD35-4285-92C5-CF59AE04CB56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric, You are bringing up a real problem that we have not solved. Perhaps = mostly theoretical, in theory, but real nonetheless -- though, in = practice, I have seen this become an issue in other protocols. Thank = you. I have first-hand appreciation for the problem space you are describing, = so I wanted to close the loop and follow-up with this response. Hopefully this response is helpful and useful -- perhaps we can even = take an action or two from it. There are two dimensions: one generic and one specific to the I-D you = are reviewing. And I believe that your proposed solution is wrong, both = in the generic and specific cases. Generic: Clearly there is a potential race condition on a set of bits marked as = "Reserved" / MBZ, that do not have an assignment strategy/rule -- = agreed. Like you say (or imply), using RFC metadata like "Updates", etc = is not a solution, it is a patch. However, I strongly believe that narrowcasting and constraining the = context of a figure is not the solution either. RFC definitions should = be "as simple as possible, but NOT simpler", and removing relevant and = useful context is not substitute for lack of bit governance. I believe that the real solution is to have a central single source of = truth for the definitions, appropriate pointers, and explicit and well = defined allocation strategies. All of these requirements are already = solved with IANA providing that service. To me, the real problem is that = these Reserved bits are not managed by IANA. The issue is not trivial, however, because (as Adrian had pointed out), = those consecutive bits are not typedef'ed (i.e., they could be a = bit-field, or a 16-bit unsigned integer field and some extra bits, 3 = independent fields, or...) To be honest, the same can happen with any field already assigned and = not only Reserved -- which is I believe part of the point you are = making. It has happened already (having a "Type" field, and then = "borrowing" the most-significant bit to use it as "Mandatory" vs. = "Optional" TLV) -- but it is even less likely than a collision on an = unassigned set of bits. The "Reserved" is more "problematic" than = existing fields. Because unless we only copy the field itself alone, there will always be = context, and it is rather arbitrary to set the context on a 16-bit short = -- so the natural context (i.e., the context from the place being = updated) is most useful. I believe (although I could argue either way of this, and I do not think = it could be "won" since both sides of the argument can hold) that the = right approach is to reserve and manage via IANA -- existing fields, = values, bitfields, but also Reserved bits. In fact, we had started down this road -- doing "community service" with = this I-D http://tools.ietf.org/html/draft-ietf-mpls-ldp-iana-01 but = there was discussion around whether it was the right thing to manage = Reserved fields (as a set of bits) because they could be assigned with a = different field type (bitfield, integer of different sizes, etc), and = "typecasting" a IANA definition was considered odd. In retrospect, perhaps it is not off to Reserve the Reserved field in = IANA and centralize the definition. Specific to draft-ietf-mpls-ldp-gtsm: In the specific case of this bit being assigned from Reserved in this = particular TLV, draft-ietf-mpls-ldp-gtsm uses: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Common Hello Parms(0x0400)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time |T|R|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And I believe this is the best choice because it is the closest to the = Figure from the RFC that it is updating -- it is the natural boundary. = Basically this is the same figure used in RFC 5036, so it maximizes the = graphical correlation and context. = http://tools.ietf.org/html/rfc5036#section-3.5.2 =46rom this, "0|0" is unlikely to change unless there is a major LDP = ginormous change, the type 0x0400 won't change because it is the Type, = the Length won't change (as the field that it is, and also as the = value), then we have "Hold Time" (most unlikely to change again). Conversely, you propose we use: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And I believe this is wrong on quite a number of reasons. First, because = it shifts alignment in the 32-bit word, basically defeating the = Principle of Least Astonishment removing the graphical anchor. Second, = because the fields that it is not including are the ones that (in = practice) will not change!, Third, because an implementor will have much = more trouble correlating this to where it is coming from in RFC 5036, = especially a visual one :-) And fourth and last, because it still includes the "Reserved" which is = the one that could most likely be assigned (in other RFC in parallel, in = the future, etc... Even when a reviewer needs to "check I did not typo bits" -- thank you = for that :-) My perspective is that we would not gain anything and we would loose at = least those 3 points. In fact, that it would be a lot "messier" and much = "less clean" to over-trim the figure from what's in RFC 5036. And the alternative, which is where the logic you present is leading me, = is to define the bit as in RFC 3514 :-) = http://tools.ietf.org/html/rfc3514#section-2 The G-bit is laid out as follows: 0 +-+ |G| +-+ Moreover, we started this trying to do what we considered was the right = thing http://tools.ietf.org/html/draft-ietf-mpls-ldp-iana-01#section-2.3 = but abandoned this approach. Thanks, -- Carlos. On May 25, 2012, at 4:04 PM, Eric Gray wrote: > When I said it would be "cleaner", it was because your draft doesn't = modify > the rest of the TLV. > =20 > As a general rule, it is "cleaner" not to include anything that you = are not > modifying (beyond whatever you believe is minimal acceptable context). > =20 > If some later draft were to come along and modify - or extend - some > other part of the TLV, the issue would then be - does this later = document > update this one, or RFC 5036? > =20 > That could lead to a mess. Which is pretty much what it means not to > be "clean." > =20 > However, it doesn't seem terribly likely that someone else is going to = alter > another part of this TLV, so this is largely theoretical, and a minor = issue. > =20 > As a secondary factor, the fact that you repeated the entire TLV meant > that there were just that many other bits I had to make sure you = didn't > "typo" in some way, or make other (un)intended changes to. > =20 > =46rom a point of view of readability, it should be relatively clear = to anyone > implementing these changes to their LDP implementation, where the = flags > field is in the modified TLV. In fact, I suspect that - if you just = showed the > flags field, this would make the meaning clearer and easier to = implement > to many readers. > =20 > And this too is a minor issue. For one thing, it is a matter of = opinion. As > I mentioned in my other reply, it's okay with me if you don't want to = adopt=20 > any of the changes implied in my comments. > =20 > On your paraphrasing the quote about a picture being worth a thousand > words, the jury's still out on just how true that is. Different = people think > and comprehend in different ways. For me, a picture is worthless = unless > the words are there to explain it. > =20 > -- > Eric >=20 > From: Carlos Pignataro [mailto:cpignata@cisco.com]=20 > Sent: Friday, May 25, 2012 2:46 PM > To: Eric Gray > Cc: rtg-ads@tools.ietf.org; BRUNGARD, DEBORAH A; rtg-dir@ietf.org; = draft-ietf-mpls-ldp-gtsm@tools.ietf.org > Subject: Re: RtgDir review:draft-ietf-mpls-ldp-gtsm-06.txt > Importance: High >=20 > Eric, >=20 > Thanks much for your review! Please see inline. >=20 > On May 25, 2012, at 2:17 PM, Eric Gray wrote: >=20 >>=20 >>=20 >> Hello,=20 >>=20 >> 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, and sometimes on special request. 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=20 >>=20 >> 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.=20 >>=20 >> Document: draft-ietf-mpls-ldp-gtsm-06.txt=20 >> Reviewer: Eric Gray >> Review Date: 25-May-2012=20 >> Intended Status: Standard=20 >>=20 >> Summary:=20 >>=20 >> No major issues found. This document is essentially ready for = publication. >=20 > Sounds good. >=20 >>=20 >> Comments:=20 >>=20 >> This document is mostly clearly written and easily understood. >=20 > Thanks. Is the "mostly" qualifying clearly written, easily understood, = or both? :-) Where is specifically not? It seems the nits you bring up = below are not clarifying meaning. >=20 >>=20 >> Major Issues:=20 >>=20 >> No major issues found. >>=20 >> Minor Issues:=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Because this draft defines only a new bit assignment as an update to = RFC 5036, it=20 >> would have been cleaner to have only included the flags field as = shown here: >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |T|R|G| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Thank you for this suggestion. I feel however that furthering the = packet context in which the bits reside adds much more to the clarity = and removes ambiguity than this proposal. That is, the whole TLV in a = figure is more clear than just 3 bits and a reserved without insertion = point, and the figure exactly as from the RFC it is updating (RFC 5036) = module the updated bit is more unambiguous and easier to find. >=20 >>=20 >> To maintain readability, the draft should still say where this field = is (that it >> is part of the Common Hello Parameter TLV). =20 >=20 > A figure is worth how many words? :-) >=20 >>=20 >> In addition, since the definitions of T and R are exactly as given in = RFC 5036, >> the text that currently repeats the definitions for T and R could = better have=20 >> been written as: >>=20 >> "T and R >> As specified in [RFC5036]." >=20 > Sure we could take the common denominator out, but the current form of = the definition has more symmetry and rhyme while not wasting too many = extra lines... >=20 > T, Targeted Hello > As specified in [RFC5036]. >=20 > R, Request Send Targeted Hellos > As specified in [RFC5036]. >=20 > G, GTSM > ... >=20 >>=20 >> This way of representing the changes makes it clearer what the actual = changes >> are. However, this is a very minor issue. >=20 > Perhaps clarity is relative. I feel that including the contextual = fields graphically is more clear than describing it with words, and = keeping a per-field list element seems more clear. >=20 > In any case I appreciate you taking the time to comment on this and = proposing an alternate representation of those few lines. >=20 >> = __________________________________________________________________________= _______ >>=20 >> I am curious why the text under Figure 1 explicitly includes the = possibility that=20 >> an LSR might implement GTSM capability negotiation but not implement = GTSM. But,=20 >> again, this is a very minor issue. >=20 > Do you mean the text immediately underneath Figure 1, or the last = paragraph of Section 2.1? If the latter, this is based on an mpls wg = review (Adrian's IIRC), which separates the support for GTSM from the = understanding of the G bit. While I agree with you, I think the current = text is OK because it is unambiguous and complete.=20 >=20 > Thanks also for pointing this out. I do not expect this will be the = case but covering the base. >=20 >> = __________________________________________________________________________= _______ >>=20 >> NITs: >> =3D=3D=3D=3D >>=20 >> In the abstract, "packets" should be "packet's." >=20 > Agreed. Changed in my working copy. >=20 >>=20 >> First sentence, first paragraph under Figure 1 - "meaingful" should = be "meaningful." >=20 > Wow, great catch! I thought I'd run idspell on this... >=20 >>=20 >> Second sentence, second paragraph under Figure 1 - "but that it does = not" should be >> "but that does not." >=20 > Yes. Done in my working copy. >=20 > Thanks again for this review! >=20 > -- Carlos. >=20 >>=20 >> -- >> Eric Gray >>=20 >>=20 >>=20 >=20 --Apple-Mail=_F4C91E52-CD35-4285-92C5-CF59AE04CB56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

However, = I strongly believe that narrowcasting and constraining the context of a = figure is not the solution either. RFC definitions should be "as simple = as possible, but NOT simpler", and removing relevant and useful context = is not substitute for lack of bit governance.

I = believe that the real solution is to have a central single source of = truth for the definitions, appropriate pointers, and explicit and well = defined allocation strategies. All of these requirements are already = solved with IANA providing that service. To me, the real problem is that = these Reserved bits are not managed by = IANA.

The issue is not trivial, however, = because (as Adrian had pointed out), those consecutive bits are not = typedef'ed (i.e., they could be a bit-field, or a 16-bit unsigned = integer field and some extra bits, 3 independent fields, = or...)

To be honest, the same can happen with = any field already assigned and not only Reserved -- which is I believe = part of the point you are making. It has happened already (having a = "Type" field, and then "borrowing" the most-significant bit to use it as = "Mandatory" vs. "Optional" TLV) -- but it is even less likely than a = collision on an unassigned set of bits. The "Reserved" is more = "problematic" than existing fields.

Because = unless we only copy the field itself alone, there will always be = context, and it is rather arbitrary to set the context on a 16-bit short = -- so the natural context (i.e., the context from the place being = updated) is most useful.

I believe (although I = could argue either way of this, and I do not think it could be "won" = since both sides of the argument can hold) that the right approach is to = reserve and manage via IANA -- existing fields, values, bitfields, but = also Reserved bits.

In fact, we had = started down this road -- doing "community service" with this = I-D http://too= ls.ietf.org/html/draft-ietf-mpls-ldp-iana-01 but there was = discussion around whether it was the right thing to manage Reserved = fields (as a set of bits) because they could be assigned with a = different field type (bitfield, integer of different sizes, etc), and = "typecasting" a IANA definition was considered = odd.

In retrospect, perhaps it is not off to = Reserve the Reserved field in IANA and centralize the = definition.

Specific = to draft-ietf-mpls-ldp-gtsm:

In = the specific case of this bit being assigned from Reserved in this = particular TLV, draft-ietf-mpls-ldp-gtsm = uses:

     0                   1             =
      2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|0| Common Hello Parms(0x0400)|      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Hold Time                |T|R|G|   Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And I believe this is the best choice = because it is the closest to the Figure from the RFC that it is updating = -- it is the natural boundary. Basically this is the same figure used in = RFC 5036, so it maximizes the graphical correlation and context. http://tools.iet= f.org/html/rfc5036#section-3.5.2

=46rom = this, "0|0" is unlikely to change unless there is a major LDP ginormous = change, the type 0x0400 won't change because it is the Type, the Length = won't change (as the field that it is, and also as the value), then we = have "Hold Time" (most unlikely to change = again).

Conversely, you propose we = use:

    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |T|R|G|   Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And I believe this is wrong on = quite a number of reasons. First, because it shifts alignment in the = 32-bit word, basically defeating the Principle of Least Astonishment = removing the graphical anchor. Second, because the fields that it is not = including are the ones that (in practice) will not change!, Third, = because an implementor will have much more trouble correlating this to = where it is coming from in RFC 5036, especially a visual one = :-)

And fourth and last, because it still = includes the "Reserved" which is the one that could most likely be = assigned (in other RFC in parallel, in the future, = etc...

Even when a reviewer needs to "check I = did not typo bits" -- thank you for that :-)

My = perspective is that we would not gain anything and we would loose at = least those 3 points. In fact, that it would be a lot "messier" and much = "less clean" to over-trim the figure from what's in RFC = 5036.

And the alternative, which is where the = logic you present is leading me, is to define the bit as in RFC 3514 = :-) http://tools.ietf.or= g/html/rfc3514#section-2

   The G-bit is laid out as follows:

             0
            +-+
            |G|
            +-+

Moreover, we started this trying to do = what we considered was the right thing http://tools.ietf.org/html/draft-ietf-mpls-ldp-iana-01#section-2.3&n= bsp;but abandoned this = approach.

Thanks,

-- = Carlos.


On May 25, 2012, at 4:04 = PM, Eric Gray wrote:

When I said it would be = "cleaner", it was because your=20 draft doesn't modify
the rest of the = TLV.
 
As a general rule, it is = "cleaner" not to include anything=20 that you are not
modifying (beyond whatever = you believe is minimal=20 acceptable context).
 
If some later draft were to = come along and modify - or=20 extend - some
other part of the TLV, = the issue would=20 then be - does this later document
update this one, or = RFC=20 5036?
 
That could lead to a = mess.  Which is pretty much what=20 it means not to
be = "clean."
 
However, it doesn't seem = terribly likely that someone else=20 is going to alter
another part of this TLV, so = this is largely=20 theoretical, and a minor issue.
 
As a secondary factor, the = fact that you repeated the=20 entire TLV meant
that there were just that = many other bits I had to make=20 sure you didn't
"typo" in some way, or make = other (un)intended changes=20 to.
 
=46rom a point of view of = readability, it should be=20 relatively clear to anyone
implementing these changes = to their LDP implementation,=20 where the flags
field is in the modified = TLV.  In fact, I suspect that=20 - if you just showed the
flags field, this would make = the meaning clearer and easier=20 to implement
to many = readers.
 
And this too is a minor = issue.  For one thing, it is a=20 matter of opinion.  As
I mentioned in my other = reply, it's okay with=20 me if you don't want to adopt 
any of the changes implied in my=20 comments.
 
On your paraphrasing the = quote about a picture being worth=20 a thousand
words, the jury's still = out on just how=20 true that is.  Different people think
and comprehend in = different=20 ways.  For me, a picture is worthless unless =
the words = are there=20 to explain it.
 
--
Eric

From: Carlos Pignataro=20 [mailto:cpignata@cisco.com]
Sent: Friday, May 25, 2012 2:46=20= PM
To: Eric Gray
Cc: rtg-ads@tools.ietf.org; = BRUNGARD,=20 DEBORAH A; rtg-dir@ietf.org;=20 draft-ietf-mpls-ld= p-gtsm@tools.ietf.org
Subject: Re: RtgDir=20 review:draft-ietf-mpls-ldp-gtsm-06.txt
Importance:=20 High

Eric,

Thanks much for your review! Please see inline.

On May 25, 2012, at 2:17 PM, Eric Gray wrote:



Hello,

I have been selected as the Routing = Directorate=20 reviewer for this draft. The Routing Directorate seeks to review all = routing=20 or routing-related drafts as they pass through IETF last call and IESG = review,=20 and sometimes on special request. The purpose of the review is to = provide=20 assistance to the Routing ADs. For more information about the Routing=20= Directorate, please see http://www.ietf= .org/iesg/directorate/routing.html=20

Although these comments are primarily for the use of the = Routing ADs,=20 it would be helpful if you could consider them along with any other = IETF Last=20 Call comments that you receive, and strive to resolve them through = discussion=20 or by updating the draft.

Document: = draft-ietf-mpls-ldp-gtsm-06.txt=20
Reviewer: Eric Gray
Review Date: 25-May-2012
Intended = Status:=20 Standard

Summary:

No major issues found. This document = is=20 essentially ready for publication.

Sounds good.


Comments:

This document is mostly clearly written and = easily=20 understood.

Thanks. Is the "mostly" qualifying clearly written, easily = understood, or=20 both? :-) Where is specifically not? It seems the nits you bring up = below are=20 not clarifying meaning.


Major Issues:

No major issues found.

Minor = Issues:=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Because this draft = defines only a new bit assignment=20 as an update to RFC 5036, it
would have been cleaner to have only = included=20 the flags field as shown=20 here:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R|G| =   Reserved=20 =             &n= bsp;|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thank you for this suggestion. I feel however that furthering the = packet=20 context in which the bits reside adds much more to the clarity and = removes=20 ambiguity than this proposal. That is, the whole TLV in a figure is more = clear=20 than just 3 bits and a reserved without insertion point, and the figure = exactly=20 as from the RFC it is updating (RFC 5036) module the updated bit is more=20= unambiguous and easier to find.


To maintain readability, the draft should still say where = this field=20 is (that it
is part of the Common Hello Parameter TLV).=20  

A figure is worth how many words? :-)


In addition, since the definitions of T and R are exactly as = given in=20 RFC 5036,
the text that currently repeats the definitions for T and = R could=20 better have
been written as:

"T and R
  As = specified=20 in [RFC5036]."

Sure we could take the common denominator out, but the current form = of the=20 definition has more symmetry and rhyme while not wasting too many extra=20= lines...

    T, Targeted Hello
       As specified in [RFC5036].

    R, Request Send Targeted Hellos
       As specified in [RFC5036].

    G, GTSM
...


This way of representing the changes makes it clearer what = the actual=20 changes
are.  However, this is a very minor=20 issue.

Perhaps clarity is relative. I feel that including the contextual = fields=20 graphically is more clear than describing it with words, and keeping a = per-field=20 list element seems more clear.

In any case I appreciate you taking the time to comment on this and=20= proposing an alternate representation of those few lines.

=
_____________________________________________________________________= ____________

I=20 am curious why the text under Figure 1 explicitly includes the = possibility=20 that
an LSR might implement GTSM capability negotiation but not = implement=20 GTSM.  But,
again, this is a very minor = issue.

Do you mean the text immediately underneath Figure 1, or the last = paragraph=20 of Section 2.1? If the latter, this is based on an mpls wg review = (Adrian's=20 IIRC), which separates the support for GTSM from the understanding of = the G bit.=20 While I agree with you, I think the current text is OK because it is = unambiguous=20 and complete. 

Thanks also for pointing this out. I do not expect this will be the = case=20 but covering the base.

=
_____________________________________________________________________= ____________

NITs:
=3D=3D=3D=3D

In=20 the abstract, "packets" should be "packet's."

Agreed. Changed in my working copy.


First sentence, first paragraph under Figure 1 - "meaingful" = should=20 be "meaningful."

Wow, great catch! I thought I'd run idspell on this...


Second sentence, second paragraph under Figure 1 - "but that = it does=20 not" should be
"but that does not."

Yes. Done in my working copy.

Thanks again for this review!

-- Carlos.


--
Eric=20 Gray





= --Apple-Mail=_F4C91E52-CD35-4285-92C5-CF59AE04CB56-- --Apple-Mail=_F0015F48-72AD-417B-B414-453FE5ABCB98 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk/DmbYACgkQtfDPGTp3USw8dwCfcxsAu4LLmEhIkJf/qsoIlJr1 ujIAn2Bdu3YHs7COIawK7hMQwKY+k6p7 =wsFv -----END PGP SIGNATURE----- --Apple-Mail=_F0015F48-72AD-417B-B414-453FE5ABCB98--