From nobody Thu Nov 3 17:14:37 2016 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 1C92C1299AF for ; Thu, 3 Nov 2016 17:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC27QPPAlhVU for ; Thu, 3 Nov 2016 17:14:34 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DBC1299AD for ; Thu, 3 Nov 2016 17:14:33 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id a684b2c3-a223-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 10:14:28 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 10:14:12 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> Date: Fri, 4 Nov 2016 11:14:29 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> To: IETF IDR WG X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, Susan Hares , "John G. Scudder" Subject: [RTG-DIR] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 00:14:36 -0000 I have reviewed this draft and have the following 9 suggestions. All of these fall into the category of minor suggestions. I do not believe that there is may major structural deficiency in this specification, and the document is largely ready, in my view. Here are my specific suggestions. 1. ---------------- Title: Large BGP Communities to be consistent with previous attribute specifications, how about "BGP Large Communities Attribute" i.e. switch the order of "Large BGP" to "BGP Large" to be consistent = with earlier BGP Extended Communities specification in RFC4360 2. ---------------- "Network operators=20 attach BGP communities to routes to identify intrinsic properties of these routes." I don't think community attributes are an intrinsic property of a route advertisement - they are more appropriately expressed as an attached = attribute=20 that expresses some desired property. how about: =20 "Network operators attach BGP communities to routes to associate particular properties with these routes." 3. ---------------- "and may apply to an individual route or to a group of routes." I am confused - surely the attributes in an Update BGP message apply to = the collection of routes contained in the Update. It cannot be applied to a=20= single route when the update itself contains multiple routes. Why not use the text: "and is applied to all routes contained in a BGP Update Message where the Communities Attribute is included." 4. ---------------- "[RFC1997] BGP Communities attributes are four-octet values split into two two-octet words." This is not the case - RFC1997 says: "Communities are treated as 32 bit = values" I think it would be more accurate to say: "BGP Communities attributes are four-octet values [RFC1997]. Common use = of this attribute type splits this single 32-bit value field into two = 16-bit values." 5. ---------------- "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as the protocol limit of six octets cannot accommodate both a four-octet Global Administrator value and a four-octet Local Administrator value, which precludes the common operational practice of encoding a target ASN in the Local Administrator field." Thats a very long sentence. Try: "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as the protocol limit of six octets for each community value cannot accommodate both a four-octet Global Administrator value and a = four-octet Local Administrator value. This limitation precludes the common operational practice of encoding a target ASN in the Local Administrator field." 6. ---------------- The aggregation section contains fewer constraints then either RFC1997 = or RFC4360. It also contains a confusing non-normative =E2=80=9Cshould". For reference, RFC4360 states: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Communities path attribute that contains the set union of all = the Extended Communities from all of the aggregated routes. The default behavior could be overridden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. =20 Why not use this formulation? i.e. "3. Aggregation If a set of routes is to be aggregated and the resulting aggregate = route's path attributes do not include the ATOMIC_AGGREGATE attribute, then the resulting aggregate route SHOULD have a Large Communities Attribute = formed from the set union of all the Large Community values from all of the aggregated set of routes. This behavior MAY be overridden via local configuration, in which case handling the Large Communities attribute in the presence of route aggregation is determined by the local policy of = the BGP speaker that performs the aggregation." 7. ---------------- 4. Canonical Representation I am confused here - this section used an example with TWO canonical representations: "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." =20 =20 Conventionally, it's better to use a single canonical representation, so = the authors should pick either a colon-delimited list, or a bracketed = comma+space separated object. =20 8. ---------------- =20 5. Reserved Large BGP Community values The text reads:=20 "the Global Administrator values specified above could be used if there is a future need for them." =20 This is entirely unclear. Is it referring to the values that the = previous paragraph specified as "SHOULD NOT use=E2=80=9D? Also "could be used" is = a poor choice of words for a normative specification. I suggest deleting completely the paragraph that contains this quote = from the document. 9. ---------------- The text reads:=20 "The error handling of Large BGP Communities is as follows: o A Large BGP Communities attribute SHALL be considered malformed if its length is not a non-zero multiple of 12." I think the author is trying to dayL "The error handling of Large BGP Communities is as follows: o A Large Communities attribute SHALL be considered malformed if the length of the Large Communities value, expressed in octets, is not = a non-zero multiple of 12." thanks, Geoff From nobody Thu Nov 3 17:17:32 2016 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 729DB1299B3 for ; Thu, 3 Nov 2016 17:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUnMA_-bDCkw for ; Thu, 3 Nov 2016 17:17:28 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C601299B2 for ; Thu, 3 Nov 2016 17:17:28 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 101901f0-a224-11e6-a41e-005056b6f213; Fri, 04 Nov 2016 10:17:25 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 10:17:24 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: Date: Fri, 4 Nov 2016 11:17:24 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <5A049C45-CD74-4B20-9C8A-357557E2EDEF@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> To: IETF IDR WG X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, Susan Hares , "John G. Scudder" Subject: Re: [RTG-DIR] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 00:17:30 -0000 I should=E2=80=99ve added: In terms of the quality of the document I think this is sorely needed and is a pivotal specification for the broad acceptance of four octet=20 AS numbers. I support its timely progress to publication as a standards track specification. Geoff > On 4 Nov. 2016, at 11:14 am, Geoff Huston wrote: >=20 > I have reviewed this draft and have the following 9 suggestions. All = of > these fall into the category of minor suggestions. I do not believe = that > there is may major structural deficiency in this specification, and = the > document is largely ready, in my view. >=20 > Here are my specific suggestions. >=20 >=20 > 1. ---------------- >=20 > Title: Large BGP Communities >=20 > to be consistent with previous attribute specifications, how about >=20 > "BGP Large Communities Attribute" >=20 > i.e. switch the order of "Large BGP" to "BGP Large" to be consistent = with > earlier BGP Extended Communities specification in RFC4360 >=20 > 2. ---------------- >=20 > "Network operators=20 > attach BGP communities to routes to identify intrinsic properties of > these routes." >=20 > I don't think community attributes are an intrinsic property of a = route > advertisement - they are more appropriately expressed as an attached = attribute=20 > that expresses some desired property. >=20 > how about: >=20 > "Network operators attach BGP communities to routes to associate > particular properties with these routes." >=20 > 3. ---------------- >=20 > "and may apply to an individual route or to a group of routes." >=20 > I am confused - surely the attributes in an Update BGP message apply = to the > collection of routes contained in the Update. It cannot be applied to = a=20 > single route when the update itself contains multiple routes. Why not > use the text: >=20 > "and is applied to all routes contained in a BGP Update Message where > the Communities Attribute is included." >=20 > 4. ---------------- >=20 > "[RFC1997] BGP Communities attributes are four-octet values split into > two two-octet words." >=20 > This is not the case - RFC1997 says: "Communities are treated as 32 = bit values" > I think it would be more accurate to say: >=20 > "BGP Communities attributes are four-octet values [RFC1997]. Common = use of > this attribute type splits this single 32-bit value field into two = 16-bit values." >=20 > 5. ---------------- >=20 > "The BGP Extended Communities > attribute [RFC4360] is also unsuitable, as the protocol limit of six > octets cannot accommodate both a four-octet Global Administrator > value and a four-octet Local Administrator value, which precludes the > common operational practice of encoding a target ASN in the Local > Administrator field." >=20 >=20 > Thats a very long sentence. Try: >=20 > "The BGP Extended Communities attribute [RFC4360] is also unsuitable, = as > the protocol limit of six octets for each community value cannot > accommodate both a four-octet Global Administrator value and a = four-octet > Local Administrator value. This limitation precludes the common > operational practice of encoding a target ASN in the Local = Administrator > field." >=20 > 6. ---------------- >=20 > The aggregation section contains fewer constraints then either RFC1997 = or > RFC4360. It also contains a confusing non-normative =E2=80=9Cshould". >=20 > For reference, RFC4360 states: By default if a range of routes is to = be > aggregated and the resultant aggregates path attributes do not carry = the > ATOMIC_AGGREGATE attribute, then the resulting aggregate should have = an > Extended Communities path attribute that contains the set union of all = the > Extended Communities from all of the aggregated routes. The default > behavior could be overridden via local configuration, in which case > handling the Extended Communities attribute in the presence of route > aggregation becomes a matter of the local policy of the BGP speaker = that > performs the aggregation. >=20 > Why not use this formulation? i.e. >=20 > "3. Aggregation >=20 > If a set of routes is to be aggregated and the resulting aggregate = route's > path attributes do not include the ATOMIC_AGGREGATE attribute, then = the > resulting aggregate route SHOULD have a Large Communities Attribute = formed > from the set union of all the Large Community values from all of the > aggregated set of routes. This behavior MAY be overridden via local > configuration, in which case handling the Large Communities attribute = in > the presence of route aggregation is determined by the local policy of = the > BGP speaker that performs the aggregation." >=20 > 7. ---------------- >=20 > 4. Canonical Representation >=20 > I am confused here - this section used an example with TWO canonical > representations: >=20 > "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." >=20 >=20 > Conventionally, it's better to use a single canonical representation, = so the > authors should pick either a colon-delimited list, or a bracketed = comma+space > separated object. >=20 >=20 > 8. ---------------- >=20 > 5. Reserved Large BGP Community values >=20 >=20 > The text reads:=20 >=20 > "the Global Administrator values specified above could be > used if there is a future need for them." >=20 > This is entirely unclear. Is it referring to the values that the = previous > paragraph specified as "SHOULD NOT use=E2=80=9D? Also "could be used" = is a poor > choice of words for a normative specification. >=20 > I suggest deleting completely the paragraph that contains this quote = from > the document. >=20 >=20 > 9. ---------------- >=20 > The text reads:=20 >=20 > "The error handling of Large BGP Communities is as follows: >=20 > o A Large BGP Communities attribute SHALL be considered malformed = if > its length is not a non-zero multiple of 12." >=20 >=20 > I think the author is trying to dayL >=20 > "The error handling of Large BGP Communities is as follows: >=20 > o A Large Communities attribute SHALL be considered malformed if = the > length of the Large Communities value, expressed in octets, is not = a > non-zero multiple of 12." >=20 >=20 > thanks, >=20 > Geoff >=20 From nobody Thu Nov 3 17:47:33 2016 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 46E6A129408; Thu, 3 Nov 2016 17:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQXE5aFW_4Np; Thu, 3 Nov 2016 17:47:30 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9661295BB; Thu, 3 Nov 2016 17:47:25 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 501F47C6CE; Fri, 4 Nov 2016 00:47:25 +0000 (UTC) Date: Fri, 4 Nov 2016 00:47:25 +0000 From: heasley To: Geoff Huston Message-ID: <20161104004725.GC17584@shrubbery.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 00:47:32 -0000 Fri, Nov 04, 2016 at 11:14:29AM +1100, Geoff Huston: > 2. ---------------- > > "Network operators > attach BGP communities to routes to identify intrinsic properties of > these routes." > > I don't think community attributes are an intrinsic property of a route > advertisement - they are more appropriately expressed as an attached attribute > that expresses some desired property. > > how about: > > "Network operators attach BGP communities to routes to associate > particular properties with these routes." is "particular" a useless word here? I think the original text is fine, but to consider your suggestion and follow the less-is-more mantra.... > 3. ---------------- > > "and may apply to an individual route or to a group of routes." > > I am confused - surely the attributes in an Update BGP message apply to the > collection of routes contained in the Update. It cannot be applied to a > single route when the update itself contains multiple routes. Why not > use the text: > > "and is applied to all routes contained in a BGP Update Message where > the Communities Attribute is included." You are correct about a BGP Update msg, obviously, but that text is not talking about an update, rather the utility of a community, which may apply to a single route or a group of routes - some of which may not be in a given BGP Update msg. Yes? > 7. ---------------- > > 4. Canonical Representation > > I am confused here - this section used an example with TWO canonical > representations: > > "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." > > > Conventionally, it's better to use a single canonical representation, so the > authors should pick either a colon-delimited list, or a bracketed comma+space > separated object. Are you sure; a separator is not defined in the text. I agree with the other suggestions; the authors may or not. From nobody Thu Nov 3 18:04:44 2016 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 2FF731295FA; Thu, 3 Nov 2016 18:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQxwVyn-8MPV; Thu, 3 Nov 2016 18:04:37 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A5A12941C; Thu, 3 Nov 2016 18:04:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.174.111; From: "Susan Hares" To: "'Geoff Huston'" , "'IETF IDR WG'" References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> In-Reply-To: Date: Thu, 3 Nov 2016 21:02:22 -0400 Message-ID: <004801d23637$19dcfd20$4d96f760$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7vYX/r5lvDTiDOvRZn6NWFj+MugIVEsE7AusR2FECKfMMF6A7okGQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, "'John G. Scudder'" Subject: Re: [RTG-DIR] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 01:04:39 -0000 Geoff:=20 Thank you for this amazing quick Review of the draft.=20 Sue=20 -----Original Message----- From: Geoff Huston [mailto:gih@apnic.net]=20 Sent: Thursday, November 3, 2016 8:14 PM To: IETF IDR WG Cc: rtg-dir@ietf.org; John G. Scudder; Susan Hares Subject: Review of draft-ietf-large-community-06.txt I have reviewed this draft and have the following 9 suggestions. All of = these fall into the category of minor suggestions. I do not believe that = there is may major structural deficiency in this specification, and the = document is largely ready, in my view. Here are my specific suggestions. 1. ---------------- Title: Large BGP Communities to be consistent with previous attribute specifications, how about "BGP Large Communities Attribute" i.e. switch the order of "Large BGP" to "BGP Large" to be consistent = with earlier BGP Extended Communities specification in RFC4360 2. ---------------- "Network operators attach BGP communities to routes to identify intrinsic properties of = these routes." I don't think community attributes are an intrinsic property of a route = advertisement - they are more appropriately expressed as an attached = attribute that expresses some desired property. how about: =20 "Network operators attach BGP communities to routes to associate = particular properties with these routes." 3. ---------------- "and may apply to an individual route or to a group of routes." I am confused - surely the attributes in an Update BGP message apply to = the collection of routes contained in the Update. It cannot be applied = to a single route when the update itself contains multiple routes. Why = not use the text: "and is applied to all routes contained in a BGP Update Message where = the Communities Attribute is included." 4. ---------------- "[RFC1997] BGP Communities attributes are four-octet values split into = two two-octet words." This is not the case - RFC1997 says: "Communities are treated as 32 bit = values" I think it would be more accurate to say: "BGP Communities attributes are four-octet values [RFC1997]. Common use = of this attribute type splits this single 32-bit value field into two = 16-bit values." 5. ---------------- "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as the protocol limit of six = octets cannot accommodate both a four-octet Global Administrator value = and a four-octet Local Administrator value, which precludes the common = operational practice of encoding a target ASN in the Local Administrator = field." Thats a very long sentence. Try: "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as = the protocol limit of six octets for each community value cannot = accommodate both a four-octet Global Administrator value and a = four-octet Local Administrator value. This limitation precludes the = common operational practice of encoding a target ASN in the Local = Administrator field." 6. ---------------- The aggregation section contains fewer constraints then either RFC1997 = or RFC4360. It also contains a confusing non-normative =E2=80=9Cshould". For reference, RFC4360 states: By default if a range of routes is to be = aggregated and the resultant aggregates path attributes do not carry the = ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an = Extended Communities path attribute that contains the set union of all = the Extended Communities from all of the aggregated routes. The default = behavior could be overridden via local configuration, in which case = handling the Extended Communities attribute in the presence of route = aggregation becomes a matter of the local policy of the BGP speaker that = performs the aggregation. =20 Why not use this formulation? i.e. "3. Aggregation If a set of routes is to be aggregated and the resulting aggregate = route's path attributes do not include the ATOMIC_AGGREGATE attribute, = then the resulting aggregate route SHOULD have a Large Communities = Attribute formed from the set union of all the Large Community values = from all of the aggregated set of routes. This behavior MAY be = overridden via local configuration, in which case handling the Large = Communities attribute in the presence of route aggregation is determined = by the local policy of the BGP speaker that performs the aggregation." 7. ---------------- 4. Canonical Representation I am confused here - this section used an example with TWO canonical representations: "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." =20 =20 Conventionally, it's better to use a single canonical representation, so = the authors should pick either a colon-delimited list, or a bracketed = comma+space separated object. =20 8. ---------------- =20 5. Reserved Large BGP Community values The text reads:=20 "the Global Administrator values specified above could be used if there = is a future need for them." =20 This is entirely unclear. Is it referring to the values that the = previous paragraph specified as "SHOULD NOT use=E2=80=9D? Also "could be = used" is a poor choice of words for a normative specification. I suggest deleting completely the paragraph that contains this quote = from the document. 9. ---------------- The text reads:=20 "The error handling of Large BGP Communities is as follows: o A Large BGP Communities attribute SHALL be considered malformed if its length is not a non-zero multiple of 12." I think the author is trying to dayL "The error handling of Large BGP Communities is as follows: o A Large Communities attribute SHALL be considered malformed if the length of the Large Communities value, expressed in octets, is not = a non-zero multiple of 12." thanks, Geoff From nobody Thu Nov 3 18:18:28 2016 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 1A0B6129629 for ; Thu, 3 Nov 2016 18:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wudNnTKjlHlx for ; Thu, 3 Nov 2016 18:18:25 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B1A1295AE for ; Thu, 3 Nov 2016 18:18:25 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 91ef3513-a22c-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 11:18:19 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 11:18:21 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104004725.GC17584@shrubbery.net> Date: Fri, 4 Nov 2016 12:18:20 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 01:18:27 -0000 > On 4 Nov. 2016, at 11:47 am, heasley wrote: >=20 > Fri, Nov 04, 2016 at 11:14:29AM +1100, Geoff Huston: >> 2. ---------------- >>=20 >> "Network operators=20 >> attach BGP communities to routes to identify intrinsic properties of >> these routes." >>=20 >> I don't think community attributes are an intrinsic property of a = route >> advertisement - they are more appropriately expressed as an attached = attribute=20 >> that expresses some desired property. >>=20 >> how about: >>=20 >> "Network operators attach BGP communities to routes to associate >> particular properties with these routes." >=20 > is "particular" a useless word here? I think the original text is = fine, but > to consider your suggestion and follow the less-is-more mantra=E2=80=A6.= >=20 I was taking exception to the word =E2=80=9Cintrinsic=E2=80=9D The route attributes attach properties to the route - they are not = expressing an =E2=80=9Cintrinsic=E2=80=9D property of the route. I suggested =E2=80=9Cparticular=E2=80=9D to propose that the properties = expressed with=20 communities are an association added by the BGP speaker. But less is more could just drop the adjective completely and I=E2=80=99d = be equally happy! Geoff From nobody Thu Nov 3 18:21:23 2016 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 563811295AE for ; Thu, 3 Nov 2016 18:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYj3q4c-4MvA for ; Thu, 3 Nov 2016 18:21:16 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541B7129629 for ; Thu, 3 Nov 2016 18:21:16 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id fa2470b0-a22c-11e6-a41e-005056b6f213; Fri, 04 Nov 2016 11:21:14 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 11:20:55 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104004725.GC17584@shrubbery.net> Date: Fri, 4 Nov 2016 12:21:12 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <3480266F-B03D-4623-A2FD-82F5A09110FD@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 01:21:19 -0000 > On 4 Nov. 2016, at 11:47 am, heasley wrote: >=20 > Fri, Nov 04, 2016 at 11:14:29AM +1100, Geoff Huston: >=20 >> 3. ---------------- >>=20 >> "and may apply to an individual route or to a group of routes." >>=20 >> I am confused - surely the attributes in an Update BGP message apply = to the >> collection of routes contained in the Update. It cannot be applied to = a=20 >> single route when the update itself contains multiple routes. Why not >> use the text: >>=20 >> "and is applied to all routes contained in a BGP Update Message where >> the Communities Attribute is included." >=20 > You are correct about a BGP Update msg, obviously, but that text is = not > talking about an update, rather the utility of a community, which may > apply to a single route or a group of routes - some of which may not = be > in a given BGP Update msg. Yes? So there is the mechanism of application (BGP) and the semantics of = application. It seemed to me that the text was implicitly referring to the mechanism of application and gave the impression that a community value could be = selectively applied to only some routes contained in a single BGP update. If the text is read as a semantic specification, then yes the same = community value can be applied to any number of routes. Either way, the text could do with some small clarification, imho. Geoff From nobody Thu Nov 3 18:25:16 2016 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 8029A129699 for ; Thu, 3 Nov 2016 18:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0dfSy14h8PO for ; Thu, 3 Nov 2016 18:25:14 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B9112969A for ; Thu, 3 Nov 2016 18:25:13 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 85a35a96-a22d-11e6-b8ce-005056b6ee6f; Fri, 04 Nov 2016 11:25:08 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 11:24:52 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104004725.GC17584@shrubbery.net> Date: Fri, 4 Nov 2016 12:25:08 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 01:25:15 -0000 > On 4 Nov. 2016, at 11:47 am, heasley wrote: >=20 >=20 >> 7. ---------------- >>=20 >> 4. Canonical Representation >>=20 >> I am confused here - this section used an example with TWO canonical >> representations: >>=20 >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." >>=20 >>=20 >> Conventionally, it's better to use a single canonical representation, = so the >> authors should pick either a colon-delimited list, or a bracketed = comma+space >> separated object. >=20 > Are you sure; a separator is not defined in the text. If the =E2=80=9CCanonical Representation=E2=80=9D is to represent the = Large Communities Attributes value=20 as a sequence of triplets, where the triplet is three unsigned decimal = values, but not to define the representation of the delimiter between the elements of the = triplet, nor the delineator between successive triplets, then I think that this is an incomplete = canonical representation. cheers, Geoff From nobody Thu Nov 3 20:54:04 2016 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 E92601296ED; Thu, 3 Nov 2016 20:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMSB9oG7A6gU; Thu, 3 Nov 2016 20:54:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7ABE1294DF; Thu, 3 Nov 2016 20:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1478231641; x=1479441241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A04UT/XEPWo7o3PZNRAVCeQ9DYRmeHU+T+jmBeYkGuU=; b=RH7nHxq8jlFrU4F1Aiv0TxwZolycnJfOMnkZDzPX5rAMTOS/asdsoO0y OjUbDJ4Ms2TlVerjTgQKaC8avuRwrZyCIrDkFW79oumGMTWS7niQevUVY DiXJHP+IMzwZni9wZyKKJnpsdZm4byMqA8GshrEBGARvVwpE2QrN3nfL7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQC8BRxY/4sNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR+BW40xq0eCCIYjAhqBcD8UAQIBAQEBAQEBYiiEYgEBBCM?= =?us-ascii?q?RRRACAQgODAImAgICMBUQAgQBDQ0MiESuX40NAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHIEJhTaEVYdLglwFlEKFXwGQNZARkSIBHjdrhR+HWoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,442,1473120000"; d="scan'208";a="167279388" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 03:54:01 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uA43s0W8011208 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 03:54:01 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 22:54:00 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 3 Nov 2016 22:54:00 -0500 From: "Jakob Heitz (jheitz)" To: Geoff Huston , IETF IDR WG Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIKelQ Date: Fri, 4 Nov 2016 03:54:00 +0000 Message-ID: <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.32.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , Susan Hares Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 03:54:03 -0000 VGhhbmtzIEdlb2ZmLCBJJ2xsIGZpeCB0aGVtLg0KDQpPbmUgdGhpbmcgYWJvdXQgdGhlIGFnZ3Jl Z2F0aW9uLg0KSSBmaXJzdCBoYWQgdGhlIGNvbmRpdGlvbiAiZG8gbm90IGluY2x1ZGUgdGhlIEFU T01JQ19BR0dSRUdBVEUiLg0KVGhlbiBzb21lb25lIGNvbW1lbnRlZCBvbiB0aGUgbGlzdCB0aGF0 IEFUT01JQ19BR0dSRUdBVEUgd2FzIGRlYWQuDQpJIHJldmlld2VkIHRoZSBmdW5jdGlvbiBvZiBB VE9NSUNfQUdHUkVHQVRFIGFuZCB3aGF0IG91ciBjb2RlIGRvZXMuDQpBVE9NSUNfQUdHUkVHQVRF IG1lYW5zIHRoYXQgaW5mb3JtYXRpb24gd2FzIGxvc3QgYnkgYWdncmVnYXRpb24uDQpJbiBvdXIg Y29kZSAoYW5kIG90aGVyIGNvZGUgdGhhdCBJIGhhdmUgd29ya2VkIG9uKSwgd2hlbiB3ZQ0KYWdn cmVnYXRlLCB3ZSBhbHdheXMgYWRkIHRoZSBBVE9NSUNfQUdHUkVHQVRFIGF0dHJpYnV0ZS4NClRo ZXJlIGlzIG5vIGNhc2Ugd2hlbiB3ZSBhZ2dyZWdhdGUgd2l0aG91dCBhZGRpbmcgdGhlIEFUT01J Q19BR0dSRUdBVEUNCmF0dHJpYnV0ZS4gQmVpbmcgb2Ygbm8gY29uc2VxdWVuY2UsIEkgcmVtb3Zl ZCB0aGF0IHBhcnQgb2YgdGhlIHRleHQuDQpJIG1lYW4sIHRoZSB0ZXh0IHRlbGxzIHlvdSBob3cg dG8gYWdncmVnYXRlIGlmIHRoZSBBVE9NSUNfQUdHUkVHQVRFDQppcyBhYnNlbnQsIGJ1dCBzYXlz IG5vdGhpbmcgYWJvdXQgaG93IHRvIGFnZ3JlZ2F0ZSBpZiBpdCdzIHByZXNlbnQuDQoNClBlcnNv bmFsbHksIEknbSBmaW5lIGVpdGhlciB3YXkuIEl0IHdpbGwgbm90IGNoYW5nZSBhbnkgY29kZSBJ IHdyaXRlLg0KDQoNCkpha29iLg0KDQoNCj4gIjMuIEFnZ3JlZ2F0aW9uDQo+IA0KPiBJZiBhIHNl dCBvZiByb3V0ZXMgaXMgdG8gYmUgYWdncmVnYXRlZCBhbmQgdGhlIHJlc3VsdGluZyBhZ2dyZWdh dGUgcm91dGUncw0KPiBwYXRoIGF0dHJpYnV0ZXMgZG8gbm90IGluY2x1ZGUgdGhlIEFUT01JQ19B R0dSRUdBVEUgYXR0cmlidXRlLCB0aGVuIHRoZQ0KPiByZXN1bHRpbmcgYWdncmVnYXRlIHJvdXRl IFNIT1VMRCBoYXZlIGEgTGFyZ2UgQ29tbXVuaXRpZXMgQXR0cmlidXRlIGZvcm1lZA0KPiBmcm9t IHRoZSBzZXQgdW5pb24gb2YgYWxsIHRoZSBMYXJnZSBDb21tdW5pdHkgdmFsdWVzIGZyb20gYWxs IG9mIHRoZQ0KPiBhZ2dyZWdhdGVkIHNldCBvZiByb3V0ZXMuICBUaGlzIGJlaGF2aW9yIE1BWSBi ZSBvdmVycmlkZGVuIHZpYSBsb2NhbA0KPiBjb25maWd1cmF0aW9uLCBpbiB3aGljaCBjYXNlIGhh bmRsaW5nIHRoZSBMYXJnZSBDb21tdW5pdGllcyBhdHRyaWJ1dGUgaW4NCj4gdGhlIHByZXNlbmNl IG9mIHJvdXRlIGFnZ3JlZ2F0aW9uIGlzIGRldGVybWluZWQgYnkgdGhlIGxvY2FsIHBvbGljeSBv ZiB0aGUNCj4gQkdQIHNwZWFrZXIgdGhhdCBwZXJmb3JtcyB0aGUgYWdncmVnYXRpb24uIg0K From nobody Thu Nov 3 21:06:06 2016 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 456D11296ED; Thu, 3 Nov 2016 21:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbdYJv4mC179; Thu, 3 Nov 2016 21:06:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D925F1297AA; Thu, 3 Nov 2016 21:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1478232354; x=1479441954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RQkWPVBMipKu2NUHQ39WhhJA1xTeR8TU4nP6BgJo8SM=; b=c+6rFzQ9JTi7/XYXrIt1Ma++iBgovuJ0/qHWEDfvzUr60EhgFhPPt0Zq vOZwFH4b3l9YJ4EoPOYyIQ2B3J3wTap+gkUGkXMt1ht5sFHY1HqFgUlmP Eko9aclCivZ60wwrBpNAH1VT7sV578xP3deCDlGiQWM/S3waK8crNs3kR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQAfCBxY/5xdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR+BW40xlwCUR4IIhiMCGoFwPxQBAgEBAQEBAQFiKIRhAQE?= =?us-ascii?q?BAwEjEUUFCwIBCA4MAiYCAgIwFRACBAENDQyIPAiuXY0NAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHIEJhTaEVYRegm2CXAEElEKFXwGQNZARkSIBHjdrhR+HWoEMAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.31,442,1473120000"; d="scan'208";a="169519625" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 04:05:53 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uA445sUl018422 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 04:05:54 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 23:05:53 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 3 Nov 2016 23:05:53 -0500 From: "Jakob Heitz (jheitz)" To: Geoff Huston , IETF IDR WG Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIMk6A Date: Fri, 4 Nov 2016 04:05:53 +0000 Message-ID: <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.32.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , Susan Hares Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 04:06:04 -0000 VG8gZXhwbGFpbiB0aGlzIG9uZSwgaXQgd2FzIG9yaWdpbmFsbHkgIlRleHR1YWwgUmVwcmVzZW50 YXRpb24iDQphbmQgaXQgd2FzIHdpdGggY29sb25zIG9ubHkuIFRoZW4gd2UgZGlzY292ZXJlZCB0 aGF0IEJpcmQgdXNlcw0KY29tbWFzIGFzIGEgc2VwYXJhdG9yLiBTaW5jZSB0aGF0IGRvZXMgbm90 IGRlZ3JhZGUgdGhlIHV0aWxpdHksDQp3ZSBhbGxvd2VkIGl0LiBUaGUgcmVhbCBwb2ludCBpcyB0 aGF0IGl0IGhhcyB0byBiZSBleGFjdGx5DQozIHBvc2l0aXZlIGRlY2ltYWwgaW50ZWdlcnMuIElm IHNvbWUgaW1wbGVtZW50YXRpb25zIG9ubHkgb2ZmZXJlZCBoZXhhZGVjaW1hbA0Kb3IgdXNlZCA2 IGludDE2J3MgdGhlbiBpdCB3b3VsZCBiZWNvbWUgdmVyeSBkaWZmaWN1bHQgZm9yIElTUHMNCnRv IGNvbW11bmljYXRlIGNvbW11bml0eSBzZXR0aW5ncyB0byBjdXN0b21lcnMuDQpJIGNhbiBjaGFu Z2UgaXQgdG8gYSBzaW5nbGUgcmVwcmVzZW50YXRpb24gYW5kIGRldGFpbCB0aGUgYWxsb3dlZA0K ZGV2aWF0aW9ucyBmcm9tIGl0Lg0KDQpKYWtvYi4NCg0KDQo+IDQuICBDYW5vbmljYWwgUmVwcmVz ZW50YXRpb24NCj4gDQo+IEkgYW0gY29uZnVzZWQgaGVyZSAtIHRoaXMgc2VjdGlvbiB1c2VkIGFu IGV4YW1wbGUgd2l0aCBUV08gY2Fub25pY2FsDQo+IHJlcHJlc2VudGF0aW9uczoNCj4gDQo+ICAg ICJGb3IgZXhhbXBsZTogNjQ0OTY6NDI5NDk2NzI5NToyLCA2NDQ5NjowOjAsIG9yICg2NDQ5Niwg MTExLCAyMjIpLiINCj4gDQo+IA0KPiBDb252ZW50aW9uYWxseSwgaXQncyBiZXR0ZXIgdG8gdXNl IGEgc2luZ2xlIGNhbm9uaWNhbCByZXByZXNlbnRhdGlvbiwgc28gdGhlDQo+IGF1dGhvcnMgc2hv dWxkIHBpY2sgZWl0aGVyIGEgY29sb24tZGVsaW1pdGVkIGxpc3QsIG9yIGEgYnJhY2tldGVkIGNv bW1hK3NwYWNlDQo+IHNlcGFyYXRlZCBvYmplY3QuDQo= From nobody Fri Nov 4 00:56:35 2016 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 38546129436; Fri, 4 Nov 2016 00:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXrkPpgyGzTk; Fri, 4 Nov 2016 00:56:27 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAA5129407; Fri, 4 Nov 2016 00:56:26 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2ZMK-0008p6-9B (job@us.ntt.net); Fri, 04 Nov 2016 07:56:21 +0000 Date: Fri, 4 Nov 2016 08:56:14 +0100 From: Job Snijders To: Geoff Huston Message-ID: <20161104075614.GU961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: heasley , IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 07:56:33 -0000 Dear Geoff, Thank you for your time and review. On Fri, Nov 04, 2016 at 12:25:08PM +1100, Geoff Huston wrote: > > On 4 Nov. 2016, at 11:47 am, heasley wrote: > > > >> 7. ---------------- > >> > >> 4. Canonical Representation > >> > >> I am confused here - this section used an example with TWO canonical > >> representations: > >> > >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." > >> > >> Conventionally, it's better to use a single canonical > >> representation, so the authors should pick either a colon-delimited > >> list, or a bracketed comma+space separated object. > > > > Are you sure; a separator is not defined in the text. > > If the “Canonical Representation” is to represent the Large > Communities Attributes value as a sequence of triplets, where the > triplet is three unsigned decimal values, but not to define the > representation of the delimiter between the elements of the triplet, > nor the delineator between successive triplets, then I think that this > is an incomplete canonical representation. The working group has debated long and furiously on this element of the text. In the end we ended up with the text without specifying a separator because the separator isn't what is important at all. The 'Canonical Representation' section came to be because we want to prevent a 'asdot vs asplain'-style time waste. It should be clear that each Large Community is composed of three fields, separated by something. If you read network documentation from another party and they reference "111:333:555" it should be clear it is a Large community; even if your router makes you type in "(111, 333, 555)". Or maybe your router solely consumes XML or JSON as configuration: [111, 333, 555]. It was a conscious choice to make the representation liberal enough that all implementors currently at the table felt comfortable with it, and that the operators at the table also have guidance on what the large community will look like in communication. Given the above context, do you have a suggestion other then "pick eiher a colon-delimited or bracketed"? My personal preference would be to keep the original text. Kind regards, Job From nobody Fri Nov 4 02:00:06 2016 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 045E712951B for ; Fri, 4 Nov 2016 02:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlf0dBAvOv9N for ; Fri, 4 Nov 2016 02:00:03 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF29129513 for ; Fri, 4 Nov 2016 02:00:02 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 0eec55a1-a26d-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 18:59:56 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 18:59:58 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> Date: Fri, 4 Nov 2016 19:59:57 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 09:00:05 -0000 > On 4 Nov. 2016, at 2:54 pm, Jakob Heitz (jheitz) = wrote: >=20 > Thanks Geoff, I'll fix them. >=20 > One thing about the aggregation. > I first had the condition "do not include the ATOMIC_AGGREGATE". > Then someone commented on the list that ATOMIC_AGGREGATE was dead. > I reviewed the function of ATOMIC_AGGREGATE and what our code does. > ATOMIC_AGGREGATE means that information was lost by aggregation. > In our code (and other code that I have worked on), when we > aggregate, we always add the ATOMIC_AGGREGATE attribute. > There is no case when we aggregate without adding the ATOMIC_AGGREGATE > attribute. Being of no consequence, I removed that part of the text. > I mean, the text tells you how to aggregate if the ATOMIC_AGGREGATE > is absent, but says nothing about how to aggregate if it's present. >=20 > Personally, I'm fine either way. It will not change any code I write. >=20 I just noted that RFC1997 and RFC4360 had these constraints. It seems strange to me that an implementation would handle aggregation = differently, treating communities and extended communities one way and = large communities in a subtly different manner. Frankly I would prefer to see a consistent treatment of communities in = the case of aggregation, and reproducxing the RFC4360 text kinda makes = that clear (at least to me) Omitting it invites different handling and that would be not good Geoff =20= From nobody Fri Nov 4 02:05:00 2016 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 BCF7F129417 for ; Fri, 4 Nov 2016 02:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E0aYxISkp3Y for ; Fri, 4 Nov 2016 02:04:53 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A273D129516 for ; Fri, 4 Nov 2016 02:04:52 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id bbdf8939-a26d-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 19:04:47 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 19:04:48 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> Date: Fri, 4 Nov 2016 20:04:47 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 09:04:55 -0000 >> 4. Canonical Representation >>=20 >> I am confused here - this section used an example with TWO canonical >> representations: >>=20 >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." >>=20 >>=20 >> Conventionally, it's better to use a single canonical representation, = so the >> authors should pick either a colon-delimited list, or a bracketed = comma+space >> separated object. > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) = wrote: >=20 > To explain this one, it was originally "Textual Representation" > and it was with colons only. Then we discovered that Bird uses > commas as a separator. Since that does not degrade the utility, > we allowed it. The real point is that it has to be exactly > 3 positive decimal integers. If some implementations only offered = hexadecimal > or used 6 int16's then it would become very difficult for ISPs > to communicate community settings to customers. > I can change it to a single representation and detail the allowed > deviations from it. >=20 if you make a canonical a SHOULD not a MUST then you can permit = variation without breaking the standard. So what you are saying is that the canonical representation of a single = Large Community value is three unsigned decimal integer values, separated by a =E2=80=98:=E2=80=99= (colon) character, representing=20 the value as a triplet of unsigned 32-bit integer values. = Implementations SHOULD accept this representation as a valid form of representation of the value of a Large = Community. From nobody Fri Nov 4 02:10:33 2016 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 26201129581 for ; Fri, 4 Nov 2016 02:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpBeRaRUr4Uy for ; Fri, 4 Nov 2016 02:10:29 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1F9129519 for ; Fri, 4 Nov 2016 02:10:29 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 85ae3b11-a26e-11e6-a41e-005056b6f213; Fri, 04 Nov 2016 19:10:25 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 19:10:06 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104075614.GU961@Vurt.local> Date: Fri, 4 Nov 2016 20:10:23 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <8F8E9266-DAD3-48A7-BFFE-7CE8C103C529@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> <20161104075614.GU961@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3251) Archived-At: Cc: heasley , IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 09:10:31 -0000 > On 4 Nov. 2016, at 6:56 pm, Job Snijders wrote: >=20 > Dear Geoff, >=20 > Thank you for your time and review. >=20 > On Fri, Nov 04, 2016 at 12:25:08PM +1100, Geoff Huston wrote: >>> On 4 Nov. 2016, at 11:47 am, heasley wrote: >>>=20 >>>> 7. ---------------- >>>>=20 >>>> 4. Canonical Representation >>>>=20 >>>> I am confused here - this section used an example with TWO = canonical >>>> representations: >>>>=20 >>>> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, = 222)." >>>>=20 >>>> Conventionally, it's better to use a single canonical >>>> representation, so the authors should pick either a colon-delimited >>>> list, or a bracketed comma+space separated object. >>>=20 >>> Are you sure; a separator is not defined in the text. >>=20 >> If the =E2=80=9CCanonical Representation=E2=80=9D is to represent the = Large >> Communities Attributes value as a sequence of triplets, where the >> triplet is three unsigned decimal values, but not to define the >> representation of the delimiter between the elements of the triplet, >> nor the delineator between successive triplets, then I think that = this >> is an incomplete canonical representation. >=20 > The working group has debated long and furiously on this element of = the > text. In the end we ended up with the text without specifying a > separator because the separator isn't what is important at all. >=20 > The 'Canonical Representation' section came to be because we want to > prevent a 'asdot vs asplain'-style time waste. It should be clear that > each Large Community is composed of three fields, separated by > something. If you read network documentation from another party and = they > reference "111:333:555" it should be clear it is a Large community; = even > if your router makes you type in "(111, 333, 555)". Or maybe your = router > solely consumes XML or JSON as configuration: [111, 333, 555]. >=20 > It was a conscious choice to make the representation liberal enough = that > all implementors currently at the table felt comfortable with it, and > that the operators at the table also have guidance on what the large > community will look like in communication. >=20 > Given the above context, do you have a suggestion other then "pick = eiher > a colon-delimited or bracketed"? My personal preference would be to > keep the original text. >=20 I think you make a clear SHOULD support for a particular representation = of the triplet, which makes other representations still ok, but there is a = clear preference for interoperability that says =E2=80=9Cclearly state a preferred format = for representating these values". My previous response to Jakob proposes some candidate text. regards, Geoff From nobody Fri Nov 4 03:31:50 2016 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 EA5E1129BDE; Fri, 4 Nov 2016 03:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDyHVB6NWaTq; Fri, 4 Nov 2016 03:31:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D64C212947D; Fri, 4 Nov 2016 03:31:43 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 0A4F01E369; Fri, 4 Nov 2016 06:34:18 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jeffrey Haas In-Reply-To: <8F8E9266-DAD3-48A7-BFFE-7CE8C103C529@apnic.net> Date: Fri, 4 Nov 2016 06:31:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50FBB9EC-F6C7-408E-A544-9D64E86E8293@pfrc.org> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> <20161104075614.GU961@Vurt.local> <8F8E9266-DAD3-48A7-BFFE-7CE8C103C529@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3251) Archived-At: Cc: heasley , IETF IDR WG , rtg-dir@ietf.org, Sue Hares , Job Snijders Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 10:31:45 -0000 > On Nov 4, 2016, at 5:10 AM, Geoff Huston wrote: >=20 >=20 >> On 4 Nov. 2016, at 6:56 pm, Job Snijders wrote: >> Given the above context, do you have a suggestion other then "pick = eiher >> a colon-delimited or bracketed"? My personal preference would be to >> keep the original text. >>=20 >=20 > I think you make a clear SHOULD support for a particular = representation of the > triplet, which makes other representations still ok, but there is a = clear preference > for interoperability that says =E2=80=9Cclearly state a preferred = format for representating > these values". I believe the intent of saying it's an ordered tuple of Global Admin, = Local Admin 1, Local Admin 2 is sufficient. If you want to define delimiters, go write a yang module. -- Jeff From nobody Fri Nov 4 03:34:36 2016 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 5E30612954D; Fri, 4 Nov 2016 03:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4s-8mdk7o6J; Fri, 4 Nov 2016 03:34:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9A12952F; Fri, 4 Nov 2016 03:34:28 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A96621E369; Fri, 4 Nov 2016 06:37:03 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jeffrey Haas In-Reply-To: <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> Date: Fri, 4 Nov 2016 06:34:27 -0400 Message-Id: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , "Jakob Heitz \(jheitz\)" , Sue Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 10:34:35 -0000 --Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 4, 2016, at 4:59 AM, Geoff Huston wrote: >=20 > I just noted that RFC1997 and RFC4360 had these constraints. >=20 > It seems strange to me that an implementation would handle aggregation = differently, treating communities and extended communities one way and = large communities in a subtly different manner. >=20 > Frankly I would prefer to see a consistent treatment of communities in = the case of aggregation, and reproducxing the RFC4360 text kinda makes = that clear (at least to me) >=20 > Omitting it invites different handling and that would be not good The relevant point from the thread is that the atomic-aggregate = attribute is largely protocol noise. It's a vestigial organ from the = BGP-3 to BGP-4 transition, and a poorly specified one at that. We = shouldn't include its use in specifications, particularly where = discussing aggregation. The only place its discussion would be relevant is as part of = *de-*aggregation of a prefix. -- Jeff --Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 4, 2016, at 4:59 AM, Geoff Huston <gih@apnic.net> = wrote:

I just noted that RFC1997 and RFC4360 had these = constraints.

It seems strange to = me that an implementation would handle aggregation differently, treating = communities and extended communities one way and large communities in a = subtly different manner.

Frankly I would prefer to see a consistent = treatment of communities in the case of aggregation, and reproducxing = the RFC4360 text kinda makes that clear (at least to me)

Omitting it invites different handling = and that would be not good

The relevant point from the thread is that = the atomic-aggregate attribute is largely protocol noise.  It's a = vestigial organ from the BGP-3 to BGP-4 transition, and a poorly = specified one at that.  We shouldn't include its use in = specifications, particularly where discussing aggregation.

The only place its = discussion would be relevant is as part of *de-*aggregation of a = prefix.

-- = Jeff

= --Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0-- From nobody Fri Nov 4 06:50:45 2016 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 30ACF129503; Fri, 4 Nov 2016 06:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfA5gPCSfnwY; Fri, 4 Nov 2016 06:50:35 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3D412946B; Fri, 4 Nov 2016 06:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8338; q=dns/txt; s=iport; t=1478267434; x=1479477034; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oH3lwZ6+BhMY66i9DyhgPplXOwpUfvmGVVxOXlrs3q8=; b=Z4yD/MOH+qzH4gxOThOf/wSSdf+4wMXUgXCAdQCl0KjmIRk4Ta063ErM Yx+O3Ixwsk/+g4mVwD/P/sOeUBDvzGjEyYP90ENm/7tFoB1/emy2TfCYB wjnv4INd5Y6jsnCW00e1XVyUJ7i8ojsxEmk91Yk5ENDczN0Try6BbB1iV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAQDvkBxY/4ENJK1dHAEBBAEBCgEBg?= =?us-ascii?q?nM7AQEBAQEfgVSNOKYuhRiCCIYjAoIWPxQBAgEBAQEBAQFiKIRiAQEEeRACAQg?= =?us-ascii?q?OMQcyFBECBA4FFIhEvCoBAQEBAQEBAQEBAQEBAQEBAQEBAQEchj+BfQiCUId4g?= =?us-ascii?q?i8FlESFXwGQPwKQCI0hhAMBHjdshSFyh3QBAQE?= X-IronPort-AV: E=Sophos;i="5.31,443,1473120000"; d="scan'208,217";a="344262040" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 13:50:33 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA4DoXwB013288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 13:50:33 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 08:50:32 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 4 Nov 2016 08:50:32 -0500 From: "Jakob Heitz (jheitz)" To: Jeffrey Haas Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIKelQgACxKYCAABpngP//4vhM Date: Fri, 4 Nov 2016 13:50:32 +0000 Message-ID: <98041685-2554-452C-B707-C1AF26BE1FA7@cisco.com> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_980416852554452CB707C1AF26BE1FA7ciscocom_" MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG , Geoff Huston , Sue Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 13:50:39 -0000 --_000_980416852554452CB707C1AF26BE1FA7ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text in RFCs 1997 and 4360 is not a constraint: If a range of routes is to be aggregated and the resultant aggregates attribute section does not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have a COMMUNITIES path attribute which contains all communities from all of the aggregated routes. It does not describe how to aggregate if ATOMIC_AGGREGATE is present. The t= ext is more constrained if ATOMIC_AGGREGATE is left out of it. Thanks, Jakob. On Nov 4, 2016, at 4:24 AM, Jeffrey Haas > wrote: On Nov 4, 2016, at 4:59 AM, Geoff Huston > wrote: I just noted that RFC1997 and RFC4360 had these constraints. It seems strange to me that an implementation would handle aggregation diff= erently, treating communities and extended communities one way and large co= mmunities in a subtly different manner. Frankly I would prefer to see a consistent treatment of communities in the = case of aggregation, and reproducxing the RFC4360 text kinda makes that cle= ar (at least to me) Omitting it invites different handling and that would be not good The relevant point from the thread is that the atomic-aggregate attribute i= s largely protocol noise. It's a vestigial organ from the BGP-3 to BGP-4 t= ransition, and a poorly specified one at that. We shouldn't include its us= e in specifications, particularly where discussing aggregation. The only place its discussion would be relevant is as part of *de-*aggregat= ion of a prefix. -- Jeff --_000_980416852554452CB707C1AF26BE1FA7ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The text in RFCs 1997 and 4360 is not a constraint:

If a ra=
nge of routes is to be aggregated and the resultant aggregates
   attribute section does not carry the ATOMIC_AGGREGATE attribute, then
   the resulting aggregate should have a COMMUNITIES path attribute
   which contains all communities from all of the aggregated routes.=

It does not describe how to aggregate if ATOMIC_AGGREGATE is present. = The text is more constrained if ATOMIC_AGGREGATE is left out of it.

Thanks,
Jakob.


On Nov 4, 2016, at 4:24 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:


On Nov 4, 2016, at 4:59 AM, Geoff Huston <gih@apnic.net> wrote:

I just noted that RFC1997 and RFC4360 had these constraints.

It seems strange to me that an implementation would handle aggregation differ= ently, treating communities and extended communities one way and large comm= unities in a subtly different manner.

Frankly I would prefer to see a consistent treatment of communities in the case of= aggregation, and reproducxing the RFC4360 text kinda makes that clear (at = least to me)

Omitting it invites different handling and that would be not good

The relevant point from the thread is that the atomic-aggre= gate attribute is largely protocol noise.  It's a vestigial organ from= the BGP-3 to BGP-4 transition, and a poorly specified one at that.  W= e shouldn't include its use in specifications, particularly where discussing aggregation.

The only place its discussion would be relevant is as part = of *de-*aggregation of a prefix.

-- Jeff

--_000_980416852554452CB707C1AF26BE1FA7ciscocom_-- From nobody Fri Nov 4 09:41:17 2016 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 55E8512950D; Fri, 4 Nov 2016 09:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImyfdF0j26P1; Fri, 4 Nov 2016 09:41:14 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BDC1295C1; Fri, 4 Nov 2016 09:41:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.175.1; From: "Susan Hares" To: "'Jeffrey Haas'" , "'Geoff Huston'" References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> In-Reply-To: Date: Fri, 4 Nov 2016 12:38:56 -0400 Message-ID: <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_043B_01D23698.695F7C40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7vYX/r5lvDTiDOvRZn6NWFj+MugIVEsE7AusR2FECKfMMFwHKxisSAhTYCDcBtVkRzqAQADnA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR WG' , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:41:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_043B_01D23698.695F7C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jeff: Should atomic-aggregate be deemed "historical" at this point? This can happen in parallel to this work. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, November 4, 2016 6:34 AM To: Geoff Huston Cc: IETF IDR WG; Sue Hares; rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt On Nov 4, 2016, at 4:59 AM, Geoff Huston wrote: I just noted that RFC1997 and RFC4360 had these constraints. It seems strange to me that an implementation would handle aggregation differently, treating communities and extended communities one way and large communities in a subtly different manner. Frankly I would prefer to see a consistent treatment of communities in the case of aggregation, and reproducxing the RFC4360 text kinda makes that clear (at least to me) Omitting it invites different handling and that would be not good The relevant point from the thread is that the atomic-aggregate attribute is largely protocol noise. It's a vestigial organ from the BGP-3 to BGP-4 transition, and a poorly specified one at that. We shouldn't include its use in specifications, particularly where discussing aggregation. The only place its discussion would be relevant is as part of *de-*aggregation of a prefix. -- Jeff ------=_NextPart_000_043B_01D23698.695F7C40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff:

 

Should atomic-aggregate be deemed “historical” at this = point?  This can happen in parallel to this work. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey = Haas
Sent: Friday, November 4, 2016 6:34 AM
To: = Geoff Huston
Cc: IETF IDR WG; Sue Hares; = rtg-dir@ietf.org
Subject: Re: [Idr] Review of = draft-ietf-large-community-06.txt

 

 

On Nov 4, 2016, at 4:59 AM, Geoff Huston <gih@apnic.net> = wrote:

 

I just = noted that RFC1997 and RFC4360 had these constraints.

It seems = strange to me that an implementation would handle aggregation = differently, treating communities and extended communities one way and = large communities in a subtly different manner.

Frankly I would = prefer to see a consistent treatment of communities in the case of = aggregation, and reproducxing the RFC4360 text kinda makes that clear = (at least to me)

Omitting it invites different handling and that = would be not good

 

The = relevant point from the thread is that the atomic-aggregate attribute is = largely protocol noise.  It's a vestigial organ from the BGP-3 to = BGP-4 transition, and a poorly specified one at that.  We shouldn't = include its use in specifications, particularly where discussing = aggregation.

 

The only place its discussion would be relevant is as = part of *de-*aggregation of a prefix.

 

-- Jeff

 

------=_NextPart_000_043B_01D23698.695F7C40-- From nobody Fri Nov 4 09:46:53 2016 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 C01031295B0; Fri, 4 Nov 2016 09:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzuRx-1hmRQM; Fri, 4 Nov 2016 09:46:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F18B1129469; Fri, 4 Nov 2016 09:46:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 01B001E377; Fri, 4 Nov 2016 12:49:23 -0400 (EDT) Date: Fri, 4 Nov 2016 12:49:23 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20161104164923.GA30743@pfrc.org> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: 'IETF IDR WG' , 'Geoff Huston' , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:46:49 -0000 Sue, On Fri, Nov 04, 2016 at 12:38:56PM -0400, Susan Hares wrote: > Should atomic-aggregate be deemed "historical" at this point? This can > happen in parallel to this work. I'd argue, yes. You might recall some of the reasoning as fallout to my introduction to IETF and the resultant churn in the 1771bis work as we tried to get the feature to make sense. :-) While I'm happy to write such a document at some point, it's something that's very low priority for the WG. In the meantime, I'll just keep pushing back on things that refer to it. -- Jeff From nobody Fri Nov 4 09:57:33 2016 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 72D171295D8; Fri, 4 Nov 2016 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRv3gw5lGZ7o; Fri, 4 Nov 2016 09:57:30 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1051295DB; Fri, 4 Nov 2016 09:57:30 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uA4GtDff024416; Fri, 4 Nov 2016 12:57:29 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 26gwe9v76b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Nov 2016 12:57:29 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA4GvSWr008831; Fri, 4 Nov 2016 12:57:29 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA4GvJUr008709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Nov 2016 12:57:22 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 4 Nov 2016 16:57:01 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA4Gv1tb016889; Fri, 4 Nov 2016 12:57:01 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA4Guowi016116; Fri, 4 Nov 2016 12:56:50 -0400 Received: by oz.mt.att.com (Postfix, from userid 1000) id BE1D2A410BC; Fri, 4 Nov 2016 12:56:49 -0400 (EDT) X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22556.48590.936986.153377@oz.mt.att.com> Date: Fri, 4 Nov 2016 12:56:46 -0400 From: Jay Borkenhagen To: Jeffrey Haas In-Reply-To: <20161104164923.GA30743@pfrc.org> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> <20161104164923.GA30743@pfrc.org> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-04_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1034 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611040317 Archived-At: Cc: 'IETF IDR WG' , Susan Hares , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Jay Borkenhagen List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:57:31 -0000 Jeffrey Haas writes: > Sue, > > On Fri, Nov 04, 2016 at 12:38:56PM -0400, Susan Hares wrote: > > Should atomic-aggregate be deemed "historical" at this point? This can > > happen in parallel to this work. > > I'd argue, yes. > > You might recall some of the reasoning as fallout to my introduction to IETF > and the resultant churn in the 1771bis work as we tried to get the feature > to make sense. :-) > > While I'm happy to write such a document at some point, it's something > that's very low priority for the WG. In the meantime, I'll just keep > pushing back on things that refer to it. > > -- Jeff > I agree with making atomic-aggregate 'historical'. In the meantime, the -large- work should not attempt to maintain parallels with atomic-aggregate specifications for rfc1997 communities. Thanks. Jay B. From nobody Fri Nov 4 10:18:46 2016 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 03865129505; Fri, 4 Nov 2016 10:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9LxivgBEwBu; Fri, 4 Nov 2016 10:18:43 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B391295B2; Fri, 4 Nov 2016 10:18:43 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2i8T-0000Xb-DY (job@us.ntt.net); Fri, 04 Nov 2016 17:18:38 +0000 Date: Fri, 4 Nov 2016 18:18:34 +0100 From: Job Snijders To: Geoff Huston Message-ID: <20161104171834.GE961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR WG , "Jakob Heitz \(jheitz\)" , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:18:45 -0000 On Fri, Nov 04, 2016 at 08:04:47PM +1100, Geoff Huston wrote: > >> 4. Canonical Representation > >> > >> I am confused here - this section used an example with TWO > >> canonical representations: > >> > >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." > >> Conventionally, it's better to use a single canonical > >> representation, so the authors should pick either a colon-delimited > >> list, or a bracketed comma+space separated object. > > > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) wrote: > > > > To explain this one, it was originally "Textual Representation" and > > it was with colons only. Then we discovered that Bird uses commas as > > a separator. Since that does not degrade the utility, we allowed it. > > The real point is that it has to be exactly 3 positive decimal > > integers. If some implementations only offered hexadecimal or used 6 > > int16's then it would become very difficult for ISPs to communicate > > community settings to customers. I can change it to a single > > representation and detail the allowed deviations from it. > > if you make a canonical a SHOULD not a MUST then you can permit > variation without breaking the standard. > > So what you are saying is that the canonical representation of a > single Large Community value is three unsigned decimal integer values, > separated by a ‘:’ (colon) character, representing the value as a > triplet of unsigned 32-bit integer values. Implementations SHOULD > accept this representation as a valid form of representation of the > value of a Large Community. It appears the word "canonical" is maybe triggering something. The key element is that its three separate values. Nobody cares whether it is a colon, comma or a hypen. Does removing the word "canonical" address the raised remark? """ 4. Representation Large BGP Communities MUST be represented as three separate unsigned integers in decimal notation in the following order: Global Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain leading zeros; a zero value MUST be represented with a single zero. For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). """ Kind regards, Job From nobody Fri Nov 4 10:30:14 2016 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 95DC5129467; Fri, 4 Nov 2016 10:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFIRrNbljGj4; Fri, 4 Nov 2016 10:30:11 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA481293F3; Fri, 4 Nov 2016 10:30:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.175.1; From: "Susan Hares" To: "'Jeffrey Haas'" References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> <20161104164923.GA30743@pfrc.org> In-Reply-To: <20161104164923.GA30743@pfrc.org> Date: Fri, 4 Nov 2016 13:27:54 -0400 Message-ID: <076001d236c0$c790c4e0$56b24ea0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7vYX/r5lvDTiDOvRZn6NWFj+MugIVEsE7AusR2FECKfMMFwHKxisSAhTYCDcBtVkRzgJ+o7uXAuC5phyf5RLOAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR WG' , 'Geoff Huston' , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:30:13 -0000 Jeff: My understanding of the process - is that you do not need to have an RFC to deem something historical. You simply do a WG LC on historical and then pass it to the IESG. Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Friday, November 4, 2016 12:49 PM To: Susan Hares Cc: 'Geoff Huston'; 'IETF IDR WG'; rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt Sue, On Fri, Nov 04, 2016 at 12:38:56PM -0400, Susan Hares wrote: > Should atomic-aggregate be deemed "historical" at this point? This > can happen in parallel to this work. I'd argue, yes. You might recall some of the reasoning as fallout to my introduction to IETF and the resultant churn in the 1771bis work as we tried to get the feature to make sense. :-) While I'm happy to write such a document at some point, it's something that's very low priority for the WG. In the meantime, I'll just keep pushing back on things that refer to it. -- Jeff From nobody Fri Nov 4 11:03:53 2016 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 DA84B1294C5 for ; Fri, 4 Nov 2016 11:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcHs9ZUPNOyW for ; Fri, 4 Nov 2016 11:03:46 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B7D129482 for ; Fri, 4 Nov 2016 11:03:45 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 036a44c9-a2b9-11e6-b23e-005056b685e3; Sat, 05 Nov 2016 04:03:39 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:03:23 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <50FBB9EC-F6C7-408E-A544-9D64E86E8293@pfrc.org> Date: Sat, 5 Nov 2016 05:03:40 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <8142B1B3-2911-47B5-8535-89C2D8EC9EBE@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> <20161104075614.GU961@Vurt.local> <8F8E9266-DAD3-48A7-BFFE-7CE8C103C529@apnic.net> <50FBB9EC-F6C7-408E-A544-9D64E86E8293@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3251) Archived-At: Cc: heasley , IETF IDR WG , rtg-dir@ietf.org, Sue Hares , Job Snijders Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:03:49 -0000 > On 4 Nov. 2016, at 9:31 pm, Jeffrey Haas wrote: >=20 >=20 >> On Nov 4, 2016, at 5:10 AM, Geoff Huston wrote: >>=20 >>=20 >>> On 4 Nov. 2016, at 6:56 pm, Job Snijders wrote: >>> Given the above context, do you have a suggestion other then "pick = eiher >>> a colon-delimited or bracketed"? My personal preference would be to >>> keep the original text. >>>=20 >>=20 >> I think you make a clear SHOULD support for a particular = representation of the >> triplet, which makes other representations still ok, but there is a = clear preference >> for interoperability that says =E2=80=9Cclearly state a preferred = format for representating >> these values". >=20 > I believe the intent of saying it's an ordered tuple of Global Admin, = Local Admin 1, Local Admin 2 is sufficient. >=20 > If you want to define delimiters, go write a yang module. >=20 > -- Jeff >=20 For me thats a bit like saying that an IPv5 address is represented as a = sequence of decimal values representing 8-bit values. Its not enough to = be useful without the delimiter. I like the way we are now spending time on the one part of the draft = that is truly of least relevant. So if all this generates too much angst then drop the entire canonical = representation part from the draft and let coders do what they want. = Like extended communities, no doubt there will be some canonical format = emerge from this process in time. From nobody Fri Nov 4 11:08:06 2016 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 C5646129604 for ; Fri, 4 Nov 2016 11:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5JZhnImSw5t for ; Fri, 4 Nov 2016 11:07:48 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D42A129482 for ; Fri, 4 Nov 2016 11:07:48 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 9441502b-a2b9-11e6-b8ce-005056b6ee6f; Sat, 05 Nov 2016 04:07:42 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:07:44 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: Date: Sat, 5 Nov 2016 05:07:42 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> To: Jeffrey Haas X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , "Jakob Heitz \(jheitz\)" , Sue Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:07:52 -0000 > On 4 Nov. 2016, at 9:34 pm, Jeffrey Haas wrote: >=20 >=20 >> On Nov 4, 2016, at 4:59 AM, Geoff Huston wrote: >>=20 >> I just noted that RFC1997 and RFC4360 had these constraints. >>=20 >> It seems strange to me that an implementation would handle = aggregation differently, treating communities and extended communities = one way and large communities in a subtly different manner. >>=20 >> Frankly I would prefer to see a consistent treatment of communities = in the case of aggregation, and reproducxing the RFC4360 text kinda = makes that clear (at least to me) >>=20 >> Omitting it invites different handling and that would be not good >=20 > The relevant point from the thread is that the atomic-aggregate = attribute is largely protocol noise. It's a vestigial organ from the = BGP-3 to BGP-4 transition, and a poorly specified one at that. We = shouldn't include its use in specifications, particularly where = discussing aggregation. >=20 > The only place its discussion would be relevant is as part of = *de-*aggregation of a prefix. >=20 I have to disagree with this position. I am more than happy if you want = to push out a spec that updates RFC1997 and RFC4360 and drops the = atomic-aggregation conditions and applies the same considerations to = this document as well. But having current specs that say =E2=80=9Cdo = with communities and extended communities and do with = large communities=E2=80=9D is bonkers! We should be consistent here and = not just deliberately generate inconsistencies here - that is not doing = anyone a favour. From nobody Fri Nov 4 11:11:11 2016 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 C170B1295ED for ; Fri, 4 Nov 2016 11:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryCDRCt2IoEm for ; Fri, 4 Nov 2016 11:11:09 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB7A1294E1 for ; Fri, 4 Nov 2016 11:11:09 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 0e6e8c3a-a2ba-11e6-a41e-005056b6f213; Sat, 05 Nov 2016 04:11:07 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:10:48 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <98041685-2554-452C-B707-C1AF26BE1FA7@cisco.com> Date: Sat, 5 Nov 2016 05:11:05 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <9C984D2D-F468-4E77-B693-09EA7FE569C4@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <98041685-2554-452C-B707-C1AF26BE1FA7@cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Jeffrey Haas , IETF IDR WG , Sue Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:11:11 -0000 > On 5 Nov. 2016, at 12:50 am, Jakob Heitz (jheitz) = wrote: >=20 > The text in RFCs 1997 and 4360 is not a constraint: >=20 > If a range of routes is to be aggregated and the resultant aggregates = attribute section does not carry the ATOMIC_AGGREGATE attribute, then = the resulting aggregate should have a COMMUNITIES path attribute which = contains all communities from all of the aggregated routes. >=20 > It does not describe how to aggregate if ATOMIC_AGGREGATE is present. = The text is more constrained if ATOMIC_AGGREGATE is left out of it. >=20 My suggestion was a cut and paste from RFC4360. My motivation to propose = this was along the grounds of consistent treatment of BGP communities = irrespective of the size of the community value. If you want to specify = a standard manner for BGP to treat ALL communities under aggregation and = deaggregation of routes then please do so. But trying to achieve this by = specifying inconsistent behaviours between the various community types = is not the way to achieve a good outcome here, imho. From nobody Fri Nov 4 11:14:01 2016 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 128B11295ED; Fri, 4 Nov 2016 11:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkwndW1H_5sf; Fri, 4 Nov 2016 11:13:57 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9B312961E; Fri, 4 Nov 2016 11:13:06 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2iz7-0006a9-Hy (job@us.ntt.net); Fri, 04 Nov 2016 18:13:02 +0000 Date: Fri, 4 Nov 2016 19:12:59 +0100 From: Job Snijders To: Geoff Huston Message-ID: <20161104181259.GH961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161104171834.GE961@Vurt.local> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:13:58 -0000 If we consider this as Option B: On Fri, Nov 04, 2016 at 06:18:34PM +0100, Job Snijders wrote: > Does removing the word "canonical" address the raised remark? > > """ > 4. Representation > > Large BGP Communities MUST be represented as three separate unsigned > integers in decimal notation in the following order: Global > Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain > leading zeros; a zero value MUST be represented with a single zero. > For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). > """ Option C: 4. Canonical Representation Large BGP Communities SHOULD be represented as three separate unsigned integers in decimal notation, separated by a colon, in the following order: Global Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain leading zeros; a zero value MUST be represented with a single zero. For example: 64496:4294967295:2 or 64496:0:0. Option D: remove the section and let the market figure it out. Some might argue "this is a minute detail" - however I do think that the proliferation of ways to notate extended communities have not really helped the extended communities effort. this is a good chance and a good place to shortcut some of that proces and provide guidance. Option C is basically as watered down as possible. Settle on that and move on? Kind regards, Job From nobody Fri Nov 4 11:23:07 2016 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 D121F12960D for ; Fri, 4 Nov 2016 11:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id finLo8dGT16k for ; Fri, 4 Nov 2016 11:23:04 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1015E129608 for ; Fri, 4 Nov 2016 11:23:03 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id b655b986-a2bb-11e6-b23e-005056b685e3; Sat, 05 Nov 2016 04:22:58 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:23:00 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104171834.GE961@Vurt.local> Date: Sat, 5 Nov 2016 05:22:59 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <4EAB2E28-E839-4007-9155-EE4B5AAD0997@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , "Jakob Heitz \(jheitz\)" , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:23:06 -0000 > On 5 Nov. 2016, at 4:18 am, Job Snijders wrote: >=20 > On Fri, Nov 04, 2016 at 08:04:47PM +1100, Geoff Huston wrote: >>>> 4. Canonical Representation >>>>=20 >>>> I am confused here - this section used an example with TWO >>>> canonical representations: >>>>=20 >>>> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, = 222)." >>>> Conventionally, it's better to use a single canonical >>>> representation, so the authors should pick either a colon-delimited >>>> list, or a bracketed comma+space separated object. >>=20 >>> On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) = wrote: >>>=20 >>> To explain this one, it was originally "Textual Representation" and >>> it was with colons only. Then we discovered that Bird uses commas as >>> a separator. Since that does not degrade the utility, we allowed it. >>> The real point is that it has to be exactly 3 positive decimal >>> integers. If some implementations only offered hexadecimal or used 6 >>> int16's then it would become very difficult for ISPs to communicate >>> community settings to customers. I can change it to a single >>> representation and detail the allowed deviations from it. >>=20 >> if you make a canonical a SHOULD not a MUST then you can permit >> variation without breaking the standard. >>=20 >> So what you are saying is that the canonical representation of a >> single Large Community value is three unsigned decimal integer = values, >> separated by a =E2=80=98:=E2=80=99 (colon) character, representing = the value as a >> triplet of unsigned 32-bit integer values. Implementations SHOULD >> accept this representation as a valid form of representation of the >> value of a Large Community. >=20 > It appears the word "canonical" is maybe triggering something. The key > element is that its three separate values. Nobody cares whether it is = a > colon, comma or a hypen. >=20 > Does removing the word "canonical" address the raised remark? >=20 > """ > 4. Representation >=20 > Large BGP Communities MUST be represented as three separate unsigned > integers in decimal notation in the following order: Global > Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain > leading zeros; a zero value MUST be represented with a single zero. > For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). > =E2=80=9C=E2=80=9D >=20 change the MUST to a SHOULD and drop the example that contains two = different delimiters (as the text is fully functional and the example = provides no further information, but adds confusion). I suspect that the second sentence is overly normative (!!) If you simply said that: =E2=80=9CThe decimal notation does not use = leading zeros, and a zero value is represented as a single =E2=80=980=E2=80= =99.=E2=80=9D then I suspect that you are consistent with a SHOULD, and = adequately convey the minimal intent you are aiming at here =20 regards, Geoff From nobody Fri Nov 4 11:26:27 2016 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 BBEB1129612 for ; Fri, 4 Nov 2016 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHdg2KjuoGkt for ; Fri, 4 Nov 2016 11:26:25 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3161F1295ED for ; Fri, 4 Nov 2016 11:26:25 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 2e7b6063-a2bc-11e6-b8ce-005056b6ee6f; Sat, 05 Nov 2016 04:26:20 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:26:21 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <076001d236c0$c790c4e0$56b24ea0$@ndzh.com> Date: Sat, 5 Nov 2016 05:26:20 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <56935F2E-B81D-4EAB-9737-FC76AD47579A@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> <20161104164923.GA30743@pfrc.org> <076001d236c0$c790c4e0$56b24ea0$@ndzh.com> To: Jeffrey Haas X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:26:27 -0000 Jeff,=20 I, for one, would encourage you do write this and get atomic-aggregate = declared historic. It would result in an update to RFC1997 and RFC4360 = and thereby make them consistent with the current text in the Large = Communities draft. Geoff > On 5 Nov. 2016, at 4:27 am, Susan Hares wrote: >=20 > Jeff:=20 >=20 > My understanding of the process - is that you do not need to have an = RFC to > deem something historical. You simply do a WG LC on historical and = then > pass it to the IESG. =20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 > Sent: Friday, November 4, 2016 12:49 PM > To: Susan Hares > Cc: 'Geoff Huston'; 'IETF IDR WG'; rtg-dir@ietf.org > Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt >=20 > Sue, >=20 > On Fri, Nov 04, 2016 at 12:38:56PM -0400, Susan Hares wrote: >> Should atomic-aggregate be deemed "historical" at this point? This=20= >> can happen in parallel to this work. >=20 > I'd argue, yes. >=20 > You might recall some of the reasoning as fallout to my introduction = to IETF > and the resultant churn in the 1771bis work as we tried to get the = feature > to make sense. :-) >=20 > While I'm happy to write such a document at some point, it's something > that's very low priority for the WG. In the meantime, I'll just keep > pushing back on things that refer to it. >=20 > -- Jeff >=20 From nobody Fri Nov 4 11:32:10 2016 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 BF0221295EF; Fri, 4 Nov 2016 11:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvpEUJjWImZo; Fri, 4 Nov 2016 11:32:03 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0127.outbound.protection.outlook.com [104.47.33.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108AC12962B; Fri, 4 Nov 2016 11:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0+UbjEReuViFfiYDt+EL9dNq2YDlv5oRmHy9kUfY5NQ=; b=heMUBpSsIiRMQhqXskYj8S3fuWIRnNCn91fS22iXJYqBadRaLRio2O6u5v0IwR1g8VuoSRJUOjMTYldd4Q2kHLCSYXfcllk0bz7pdSqc9y9QqtQMLQDYdBy28htgrPeiyD/FsGucWqsuYW/zN1ZBUJrLLjs7zuEq1V9HtbcAGnY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.33.22] (66.129.241.11) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Fri, 4 Nov 2016 18:32:00 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <4EAB2E28-E839-4007-9155-EE4B5AAD0997@apnic.net> Date: Fri, 4 Nov 2016 14:31:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <947C1BD7-5FC0-4737-8DA8-F831C78D7B9F@juniper.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> <4EAB2E28-E839-4007-9155-EE4B5AAD0997@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: CY1PR0801CA0033.namprd08.prod.outlook.com (10.163.136.171) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) X-MS-Office365-Filtering-Correlation-Id: 2f251d1f-a4de-48d1-c8cb-08d404e0de5e X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 2:MB4mfaluRwZyTtoieUoxNdgRygEVWxaPMweh20EJtnhm9nu/CYRyVLTAjphbQVD22CmwDrCF6EgAoDhnKdsHZ6eUiCNvwnBokOvaWClZY333Qtg5LQ/K7sZNzNOOK8QWBHGIGBelQUVIgg+ndK907BH/X6AL0jQ2oopC8+IgLOeWTwWpfriEJB8HVOoJTWiQCGo0292CBPsCjD2dPLRKXQ==; 3:AJkCP4Ohrh0vQSzkHwdFdhCFtvhYO9lxSeHAUPqj6AxKUFKPTWambeSiBQCZFNRsgB0j5yZi1mQ1MFACk7uZeviJmNsKKjiOSoqEEXln5AXU4i4UNJ7Ir0bL45Sdhb59lqnOKZcg2RL00ZZRKZKVyw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 25:QfvMTKCZW3S9/8WdnVCCwAtYc3qhB+Q6nh1tGnjDztl6j/l96daAwnqb1TTUCACcg6USek3xDSIRiLvXNmCp2vgfTKlAj06iFIl29ROiNCrOewao4PsxwkErb8CYe9O6cEE0aKXdlPt0Foc/SfBYI+btpDX26sPBaHFwAtXG9QXmEAp5D70DJA9KLPlvrXp2DvawUdiY/zYheqbVnj0ntJ0grwIR+M4fR3LeB5FPfQEMjmE2BZedvU+1qe6hlckg+++8QU57UxaqhOHV/z68r1k6wXKsGJ2OGiD8KFKzQ/HWWXO+/LMeoKgHWOzGBdUkwlStihQVRS8t2kDntjzBXRSRO6o6INTxnhY5FD4lATggJmv7q/4h+/SW8PaZQxryH/vN6HQ22NpDIXmV+Mt/jIRifX419JUtHmfgxiGumUbjMzbr8uQxD97FMv8kZ5Q7dfxfSn2Xhhyq97eL7nDM6WpYiHxaLPurUr80QYR/Jz1yCxv/KiBeKntHfvzyDj1/cTeasS2VRQpbi7OhDtj71feQEZ7OrSDxDYdibqfZu8NFkbigqklAZyr8HbQrYQ5UPHe8mJg+n5spaQ0EfYju5QLasAh0uAfxui0PTatOebVK87pImXVxh8eMGISPdjr95nPQXvoxjsGRw3hrxWPqwV9WR3h2dfxc9lM69oU/waL0qx2dj7P5TsAq+BLFHW8f1z8LRf4gvCbNhqqWuBBkgA== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 31:R3XcXQReQZBjuPwh/6C3MOOq2NfB/z0U4rXkmv8HszotlN17n/9skYWmNHWMb8w7r67j+J8ZSYu9KlBFwGWM4Tx3QwpP1aNLTI7pdKleUW6aR+T5rkGqixgZDA8RlmPZlHn9U9Jtda1xn9/XmGYBuJ36eaTye6QvOu21FUsk3ut7WtnzK1mquJPZbKfw2gNE8UymFC5TM3P3JYibGNggRWTPQ/Q5EF1hNs1NOY+OjSVbNpRaxm/UvxH2PavvEQet; 20:POlYoBziQjSXmrKe9CJaYzozjyU3v4cGhL0/ivoO6ccr8bV8qcMhHkCFazO3Y73MuoNEnxznQnFR5OsI8wqdeTlJcvBxZi5jZyRvtrh3OLMBh0Mx8MSM7PFO0ICdLBlhKZMurs9/wm1dEPx0n9FVErebet0F3rfyCxz/PzZY98scm7JfkZ0EIuLYtNV+RLxNrUIzo/10FW2YN8u5OjpfWdTR/RBP/B0YQvQC3XtG3yiQryYBEPvJVueZ6AV9MtsMQhxDMHhbLLd2Ds1JVvdMZReivSAkxPmK4lqB5pYbAAIISfnvT+8odaiSQUgXfI9VjCS5DodKgAAzmXpM+prV3NdxyF+rkYbY8S5IrzEvEvoprj//vQAoEi94mLXwprFQegvTtcBySgvqadHggTnLlE5u9EpAAS8e/i2HOanlYC5P9AiE6eyeUfIAfgrtNK0I8nwQ4f4ajPJL8bK9VAr7CVzHNN09RsDqMm1ueaPU3GZKCCUHUr5SufqlFDFoYrGtp0Z2LH4tb0Z/9G5U0NkA00Lwb/lFEDMLclyKiYQcbwxvDVoxL1PR2akWvWy6ClkdxCUjEGcupztWrJe2ILLl2PNIqZ2PeuEHwBJOFU6wJjA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 4:7gQYS5nRnGakuI2TC+oNBvvhtFAMMCxgeR4evV2ejTBwiR9RJZW15rYaiLLO3VhUZapfblPgamLnzrHkveJtoxRmaMjTy+71NXmS3OmkL9RPkDl2xQsWbsERiHj+rZGj/WjnVQpaP8ImTZcD3sgw83yzOKbmCdpsQZxsHsDkRYXMeDICG4TuWZncZ9n27STVXleiTnr239P5WYG4huYcs8u08PH9tSY+Yi+xPOEYqQ0DDfmC5mnqK5I/mKIyABJOmt5D8JHpOk8V0KeHePGbIqLxCEnTwEt5OdH+z+tucR/EPx/spgTFdZ+pCdAbYM6HugJs1KN+uvEEAZS+yLpoWjMzHV7DebwD4nsDgwGEbn+XfRcvET8PSfuAVqXQt3X6cAEeZdNElpJBzUoyi6Ail5I4JE2GXuoimJzUSsmhhXIaZAJx1eSl+RUF4THqZ/MoxrUIFyaS6qrUBS5EqwYVEQ== X-Forefront-PRVS: 01165471DB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(189002)(92566002)(66066001)(189998001)(8746002)(77096005)(82746002)(47776003)(6666003)(97736004)(36756003)(57306001)(83716003)(50226002)(586003)(230783001)(50466002)(42186005)(5660300001)(86362001)(105586002)(7736002)(7846002)(46406003)(4326007)(305945005)(68736007)(2906002)(97756001)(23726003)(110136003)(2950100002)(101416001)(106356001)(6916009)(3846002)(33656002)(6116002)(93886004)(81156014)(50986999)(76176999)(81166006)(8676002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:[172.29.33.22]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:UcJMjXP7nFcB6mKzCIxfWwJjzCWvkjTFlK9ss88Cw?= =?us-ascii?Q?2jAeSr+qjsp9RqGsuEjirKIkZfiQni4FUXq7bFTaeB1z90aq0dOd/q7s21rb?= =?us-ascii?Q?oyvnSVkAPC7sj661UQ6jEDbn4sgmQoB3Ohn1JIlA08zjfw0io9jv5tvMWihc?= =?us-ascii?Q?IlEx8WecEOQOqozFpgyVRUsOwTMvyLAqOSkbOADOXNmvUds1pdvg1ZhqMc/v?= =?us-ascii?Q?B2NRXegtnKr6DCPb/gg0Ju1NnFoDL62HacYbp4ikkjLPz6rHrWG7COEFbPsD?= =?us-ascii?Q?DEQu0JEx7BSd4Um3kQvRqt2kqNy5mEgyCbArQerJBM922zmzcDjCz9OAQKcf?= =?us-ascii?Q?2DfjFYLdqX9wW8tJjeEJSFeZ2bbN2ieaPj4fdMTxVCFtTXWgHZYX+HB63pqJ?= =?us-ascii?Q?32t9EqO68WfcvgAxtGtFKhLhj93Nwozd5KU7UoTjcfydT2UZM/B59ihIjkaT?= =?us-ascii?Q?/0cxWPjeTHsjs/OvhG3sFnjnCfoaissZ24+x3RF1HVLNbbZwC8S75wK8OJtR?= =?us-ascii?Q?fYjeazQULfPVU1caDBmXt2eJs/MRyqLz6Cvmaw4bVu3PdkIFY2kuuhPy43fx?= =?us-ascii?Q?TNvS1MHwBFxAqebuNiu/j8/GvXKT+mPvj1XsHiyHK+ltcsVmkpsy72rezWDH?= =?us-ascii?Q?oI5MfwYawfZQCIurtFtqcoO4UhRddgrUn9F4JUVy1Jr13Em0tPdGITg+hIKB?= =?us-ascii?Q?SoXVtn+GiuBfEK2KrLaV3DwI6bwLleKe+sr89DkPl+HyzO35ISnnA+pIxWI3?= =?us-ascii?Q?uDiBrHznWqUEO30FFnYFGlrHsUPr8eLDQVfNzMWUkGPgbKRPS4QK64nXilaR?= =?us-ascii?Q?jVLfdFQx3xgbjHLQqlqPHT/IdELH7v2BEw12fR8p3y1rwy+KrhX5fgxHq32F?= =?us-ascii?Q?fjxbw8sdbQ3dWGAtT3JSrODJ0r2xg7cpSflHtSeWJ8tIast57kdvl2GMKVxu?= =?us-ascii?Q?82YnQTqw8XThsjjs34fI2Q8gjlaEmRVGbbEietFGSTy1wCBDaX6otgaahr8a?= =?us-ascii?Q?kDgHfJHDPZImIAqQvmTnjJmsy1OvcrPSWMVQ0Ak7DYc7hv+tIbKYPbrUpN87?= =?us-ascii?Q?QeybPjJE0k0z6lzWm6K9IOscIITS8UYxAxqZV1eRqkTlBf49NloQ7SFcczXJ?= =?us-ascii?Q?AgR/uAp+B3+PsD+/+TTKyJzCGKARneHSXTQpDiL5RUpRPtny+22IzytZBeo4?= =?us-ascii?Q?4gZNtpeWSBGvfZNdVP3srN2tLcPADTJvv9e?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 6:jSn+jFpgZLElHN2xwEA+QvnAj3mNx5ITvdviz67YNPUttr0pN8ygrBBZwroGMPKBF8lhY5SxkQ8X2OTBC5s3csh0YquHdggxP6QdbG8t/k7UK7v7AdYe/yFAGmu9cTOqNbh9f4cEt1tjLg1K499voabyLh9sTsJ2EkHhuFBRjLRDBFbcVuih81R8A0hpsE2Ug9jcnW4eD6/QPSTWxOS1ACJv7iyElKIWWqHvGUECZwL6N4wf0oEEXT+B99kpBHlhbVODCQOigL0G3XjB6OEEQCcFGVCZl6W5w3MIyTXrHgIFky5Rzuzc6SxkRldUxwJJRybrqDVhnpa54Oh60JnXgfakgrZqR9x+2xtfqug1Bso=; 5:nniZM/kqPqyvIXVYkQuuiPU/VfJww2mL6sjOCSzBfGebYuq9peb3Dy85e+ObZuRjTPf8EFsqF7Pnj076bZpOBefwExNEij0ccDcqlZNKlfK/ZX0TI49x50cLOQgjukgO6O2faVfv4zSgQwOPYD+BxihUPhVGLe5Ek9m50nQGjYw=; 24:tRmDqQgPhZQYsvAjJrr9gTfAY/N/GXLPYR4bf96pC8ADPwWaTQQ/uikE2q/2hZyMth4jk/GehaNFQdi19INc5wdujRKSuh4A1pOi6h8RvnA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 7:PSU3zcB+As9/sNPhWD/hcZmklEakScgJfhKYb7shwHTshX4ON6NWUVt9+36TUzZiwdlMIpMQpgzMHf+7V1D/PH/HyNjJixOspQlmdnBy5Y1Xu/a4fOMTF5SG8Kw3JlY962hefjgLw5XzbZ6ySj/lzwT2W2teIvUzzkWdDthkJIMHyDRO9FmhQ7XGxPLrTFPcyNNI5JHd7qyjcbjKJBVK/LEq5XVeXw2LUDZFH9EqJcKN1sbx/h05tMl1TY6eXz3ElKfS4cnfbuYobba8y7caJxuO8Sq5XCYhcq9J6UBxVQunlJa5X/9rsO3FFvC7T5W73GS4HcqkDtGRE1NbvQiddLCfiUAGpr/+5dgSwONiJ0s= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2016 18:32:00.4902 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509 Archived-At: Cc: IETF IDR WG , "Jakob Heitz \(jheitz\)" , "rtg-dir@ietf.org" , Susan Hares , Job Snijders Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:32:05 -0000 Geoff and Job, I note that the WG already discussed this topic in some detail while the = document was being developed and the text as it stands represents a = consensus reached with knowledge of the tradeoffs. Certainly, if you can = improve the readability, that's great. Or if you've identified some = fundamental flaw, then we have to fix it. But short of that, I would = caution against making changes that go much past the editorial. (It does seem as though you are spiraling in to agreeing on some helpful = editorial changes that stop short of going against the previous = consensus, which is a relief to me.) Thanks! --John= From nobody Fri Nov 4 12:43:42 2016 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 C7ADF129452 for ; Fri, 4 Nov 2016 12:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLjwsd4Jo7ih for ; Fri, 4 Nov 2016 12:43:36 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDAD12957A for ; Fri, 4 Nov 2016 12:43:34 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id f59b4bb6-a2c6-11e6-b8ce-005056b6ee6f; Sat, 05 Nov 2016 05:43:29 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 05:43:28 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104181259.GH961@Vurt.local> Date: Sat, 5 Nov 2016 06:43:30 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> <20161104181259.GH961@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 19:43:37 -0000 > On 5 Nov. 2016, at 5:12 am, Job Snijders wrote: >=20 > If we consider this as Option B: >=20 > On Fri, Nov 04, 2016 at 06:18:34PM +0100, Job Snijders wrote: >> Does removing the word "canonical" address the raised remark? >>=20 >> """ >> 4. Representation >>=20 >> Large BGP Communities MUST be represented as three separate = unsigned >> integers in decimal notation in the following order: Global >> Administrator, Local Data 1, Local Data 2. Numbers MUST NOT = contain >> leading zeros; a zero value MUST be represented with a single zero. >> For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). >> """ >=20 > Option C: >=20 > 4. Canonical Representation >=20 > Large BGP Communities SHOULD be represented as three separate > unsigned integers in decimal notation, separated by a colon, in the > following order: Global Administrator, Local Data 1, Local Data 2. > Numbers MUST NOT contain leading zeros; a zero value MUST be > represented with a single zero. For example: 64496:4294967295:2 > or 64496:0:0. >=20 >=20 > Option D: >=20 > remove the section and let the market figure it out. >=20 > Some might argue "this is a minute detail" - however I do think that = the > proliferation of ways to notate extended communities have not really > helped the extended communities effort. this is a good chance and a = good > place to shortcut some of that proces and provide guidance. >=20 > Option C is basically as watered down as possible. Settle on that and > move on? >=20 I say =E2=80=9CYES=E2=80=9D - thanks Job Geoff From nobody Fri Nov 4 13:39:57 2016 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 8EDC1129546 for ; Fri, 4 Nov 2016 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXVGU0XbWvmM for ; Fri, 4 Nov 2016 13:39:53 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2B01295D6 for ; Fri, 4 Nov 2016 13:39:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 13CD2257 for ; Fri, 4 Nov 2016 20:39:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPuXLa_QSdWG for ; Fri, 4 Nov 2016 15:39:52 -0500 (CDT) Received: from mail-qk0-f200.google.com (mail-qk0-f200.google.com [209.85.220.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id C535C587 for ; Fri, 4 Nov 2016 15:39:52 -0500 (CDT) Received: by mail-qk0-f200.google.com with SMTP id x190so8984971qkb.5 for ; Fri, 04 Nov 2016 13:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g1BJG/G7Ur4Wvcce2dzsDypyupQiwihgl93eow69aaA=; b=Ksue/p9kEs0xA+kCR3E88hNpBIIdUgkSDQ0Mxi6ANJOhCJSpAHv75byPooc3dOpW1O wx+ZxUrDOh0edt0vvK8pgIFFflKKWSx0L1gxouQ64SdbJ+HQ9j3Vh1anrfAWr+3AMSOI XoLcC+5XHydmOpfqBTws5h0hbuG1XGuqHmOhLJ1y3wdWcN9Wb849MxaDAK36WVsKWs6t r70uHU5YOidusSOvXFkfj17/gNA72NAV4vm9SFRVsT12f+8Zv63Dc2cFTcMmhZ44y01H 783efYyphwUxZcEgqosvh03oxNb0TL9At13nJEmGZXqMkLJH3+VYs7PG8P5kAa85eJyz 7FoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g1BJG/G7Ur4Wvcce2dzsDypyupQiwihgl93eow69aaA=; b=mjFAod/4CWovMY3mMG3E7NXx28WGuOcNOR9/kVLjw4QiTWBI6wBjN1WQh98SZ+SNOB 0kiLvMsLTHhWORn/17xcnrv67QIkAaOHEUGX+rK0PYsGlBhXaxXG7m0KnDZSUrax7fWK 66QJbBKChkeYh5tygYtppJwjKLpooq9GPBT1nZZ0XyjpzTNwaJQEQFu4AMDEsDGniXf1 p2ZBsuWFogxLLkIZl2FqWc/C1+UC3PiC5FvQVvIOeTqrqdadreiblX50BZUZn37WQvra pbGr4wtcSz1K24img9KoIB2vYMBdF1mPVryOEDUjzB0AstCkIrAeW5eeCtGkTqRMItNm vq6g== X-Gm-Message-State: ABUngveaQEL3YkTYaCmxG02ybJGQ+9vbx4YMLe2ZWZukANuWp89VGDMdcgjYf+ckCXz3Vxi15a6tn0yu3Fx5GXB+xCLjKMa32nvJYNZ8KjhOaq7GQyGmFCOihu1NdZG7Ts5daBUKfr9VpwZEUlKGLkk= X-Received: by 10.55.91.193 with SMTP id p184mr6655972qkb.301.1478291992178; Fri, 04 Nov 2016 13:39:52 -0700 (PDT) X-Received: by 10.55.91.193 with SMTP id p184mr6655961qkb.301.1478291991988; Fri, 04 Nov 2016 13:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.50.253 with HTTP; Fri, 4 Nov 2016 13:39:51 -0700 (PDT) In-Reply-To: <20161104171834.GE961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> From: David Farmer Date: Fri, 4 Nov 2016 15:39:51 -0500 Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=001a114e2cf60ea45b05407fadfa Archived-At: Cc: IETF IDR WG , Geoff Huston , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 20:39:55 -0000 --001a114e2cf60ea45b05407fadfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 4, 2016 at 12:18 PM, Job Snijders wrote: > On Fri, Nov 04, 2016 at 08:04:47PM +1100, Geoff Huston wrote: > > >> 4. Canonical Representation > > >> > > >> I am confused here - this section used an example with TWO > > >> canonical representations: > > >> > > >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222).= " > > >> Conventionally, it's better to use a single canonical > > >> representation, so the authors should pick either a colon-delimited > > >> list, or a bracketed comma+space separated object. > > > > > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) > wrote: > > > > > > To explain this one, it was originally "Textual Representation" and > > > it was with colons only. Then we discovered that Bird uses commas as > > > a separator. Since that does not degrade the utility, we allowed it. > > > The real point is that it has to be exactly 3 positive decimal > > > integers. If some implementations only offered hexadecimal or used 6 > > > int16's then it would become very difficult for ISPs to communicate > > > community settings to customers. I can change it to a single > > > representation and detail the allowed deviations from it. > > > > if you make a canonical a SHOULD not a MUST then you can permit > > variation without breaking the standard. > > > > So what you are saying is that the canonical representation of a > > single Large Community value is three unsigned decimal integer values, > > separated by a =E2=80=98:=E2=80=99 (colon) character, representing the = value as a > > triplet of unsigned 32-bit integer values. Implementations SHOULD > > accept this representation as a valid form of representation of the > > value of a Large Community. > > It appears the word "canonical" is maybe triggering something. The key > element is that its three separate values. Nobody cares whether it is a > colon, comma or a hypen. > > Does removing the word "canonical" address the raised remark? > > """ > 4. Representation > > Large BGP Communities MUST be represented as three separate unsigned > integers in decimal notation in the following order: Global > Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain > leading zeros; a zero value MUST be represented with a single zero. > For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). > """ > I won't try to speak for Geoff, but it doesn't do it for me. I think we should just say what you've said previously as a summary of the intent, but use normative language. I'd propose something like the following. 4. Canonical Representation The canonical representation for Large BGP Communities is three separate unsigned integers in decimal notation separated by colons in the following order: Global Administrator, Local Data 1, Local Data 2. For example: 64496:4294967295:2, 64496:0:0, or 64496:111:222 Implementations SHOULD use the above canonical representation, especially when representing a Large BGP Community for output. Implementations MAY use other delimiters than colons, especially for compatibility with a configuration syntax. However, Large BGP Communities MUST be represented as three separate unsigned integers in decimal notation, regardless of the delimiters used. Further, the numbers MUST NOT contain leading zeros, and a zero value MUST be represented with a single zero. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114e2cf60ea45b05407fadfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 4, 2016 at 12:18 PM, Job Snijders <job@ntt.net> wr= ote:
On Fri, Nov 04, 2= 016 at 08:04:47PM +1100, Geoff Huston wrote:
> >> 4.=C2=A0 Canonical Representation
> >>
> >> I am confused here - this section used an example with TWO > >> canonical representations:
> >>
> >>=C2=A0 =C2=A0"For example: 64496:4294967295:2, 64496:0:0,= or (64496, 111, 222)."
> >> Conventionally, it's better to use a single canonical
> >> representation, so the authors should pick either a colon-del= imited
> >> list, or a bracketed comma+space separated object.
>
> > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> >
> > To explain this one, it was originally "Textual Representati= on" and
> > it was with colons only. Then we discovered that Bird uses commas= as
> > a separator. Since that does not degrade the utility, we allowed = it.
> > The real point is that it has to be exactly 3 positive decimal > > integers. If some implementations only offered hexadecimal or use= d 6
> > int16's then it would become very difficult for ISPs to commu= nicate
> > community settings to customers.=C2=A0 I can change it to a singl= e
> > representation and detail the allowed deviations from it.
>
> if you make a canonical a SHOULD not a MUST then you can permit
> variation without breaking the standard.
>
> So what you are saying is that the canonical representation of a
> single Large Community value is three unsigned decimal integer values,=
> separated by a =E2=80=98:=E2=80=99 (colon) character, representing the= value as a
> triplet of unsigned 32-bit integer values. Implementations SHOULD
> accept this representation as a valid form of representation of the > value of a Large Community.

It appears the word "canonical" is maybe triggering something. Th= e key
element is that its three separate values. Nobody cares whether it is a
colon, comma or a hypen.

Does removing the word "canonical" address the raised remark?

"""
4.=C2=A0 Representation

=C2=A0 =C2=A0Large BGP Communities MUST be represented as three separate un= signed
=C2=A0 =C2=A0integers in decimal notation in the following order: Global =C2=A0 =C2=A0Administrator, Local Data 1, Local Data 2.=C2=A0 Numbers MUST = NOT contain
=C2=A0 =C2=A0leading zeros; a zero value MUST be represented with a single = zero.
=C2=A0 =C2=A0For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 22= 2).
"""

I won't try to s= peak for Geoff, but it doesn't do it for me.=C2=A0

=
I think we should just say what you've said previously as a summar= y of the intent, but use normative language.

I'= ;d propose something like the following.

4.=C2=A0 Canonical Representation<= br>
=C2=A0 =C2=A0The canonical representation for Large BGP Communities = is three separate unsigned
=C2=A0 =C2=A0int= egers in decimal notation separated by colons in the following order: Globa= l
=C2=A0 =C2=A0Administrator, Local Data 1, Local Data 2.=C2=A0 For exam= ple: 64496:4294967295:2,=C2=A0
=C2=A0 =C2= =A064496:0:0, =C2=A0or 64496:111:222

=C2=A0 =C2=A0Implementations SHOULD use the = above canonical representation, especially when=C2=A0
=C2=A0 =C2=A0representing a Large BGP Community for output. =C2= =A0 Implementations MAY use other=C2=A0
=C2= =A0 =C2=A0delimiters than colons, especially for compatibility with a confi= guration syntax.=C2=A0 However,=C2=A0
=C2= =A0 =C2=A0Large BGP Communities MUST be represented as three separate unsig= ned integers=C2=A0
=C2=A0 =C2=A0in decimal = notation, regardless of the delimiters used. Further, the numbers MUST NOT = contain=C2=A0
=C2=A0 =C2=A0leading zeros, a= nd a zero value MUST be represented with a single zero.


=C2=A0=C2=A0




= --
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication = Services
Office of Information Technology
University of Minnesota=C2= =A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-= 626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a114e2cf60ea45b05407fadfa-- From nobody Mon Nov 14 06:46:55 2016 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 399AF12957B; Mon, 14 Nov 2016 06:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SayzopzARMSq; Mon, 14 Nov 2016 06:46:48 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.75]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07C212950B; Mon, 14 Nov 2016 06:46:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id 2E392BD; Mon, 14 Nov 2016 07:46:47 -0700 (MST) X-Virus-Scanned: Debian amavisd-new at mailnew.seatmates.net Received: from mail.tcb.net ([127.0.0.1]) by localhost (mail.chasingbugles.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb2rw9EOBh5J; Mon, 14 Nov 2016 07:46:45 -0700 (MST) Received: from mail.tcb.net (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 3C516BB; Mon, 14 Nov 2016 07:46:45 -0700 (MST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 14 Nov 2016 09:46:45 -0500 From: Danny McPherson To: idr@ietf.org, rtg-dir@ietf.org Message-ID: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.9.5 Archived-At: Subject: [RTG-DIR] RTG-DIR REVIEW: draft-ietf-idr-large-community-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 14:46:50 -0000 RTG-DIR REVIEW: draft-ietf-idr-large-community-08 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 (as is the case here). The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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-idr-large-community-08.txt Reviewer: Danny McPherson Review Date: November 14, 2016 Intended Status: Standards Track Summary: I have no major concerns with the content of this document and believe it is ready for publication. Some minor comments are provided below, although only with the intention to inform the authors, WG, and routing ADs during their deliberations with regard to the publication of this document. Comments: I believe the draft is technically sound and addresses an immediate operational need in a pragmatic manner. Major Issues: I have no “Major” issues with this I-D, I believe it is ready for publication as a Standards Track RFC. Minor Issues: S.2: Regarding the change in the -08 version to "MUST NOT" in "Duplicate BGP Large Community values MUST NOT be transmitted", I agree with John Scudder's November 14th email to the IDR WG on this topic, connecting it to RFC 2119 definitions and Postel's law. I believe MUST NOT is a good statement, particularly when considering implications of lazy implementations doing things such as including duplicates when creating aggregates such as outlined in S.3. Upon further consideration, to Peter Hessler's question on the same mailing list thread, perhaps RFC 1997 and 4360 communities SHOULD have such a restriction - for the sake of global routing system hygiene, at least! S.3: Regarding an aggregate inheriting all the BGP Large Communities from all of the aggregated routes, it would seem to me such an instruction may result in unintended operational impacts where regional or other intra-AS and routing policy functions based on community are promoted to the aggregate and trigger undesirable behavior. Operators should certainly be aware of the potential implications of this in their operational environments. S.7: I believe the reference to S.11 of RFC 7454 is appropriate, although upon rereading I am not sure I agree with the advice of that BCP. Specifically, suggesting that communities not be scrubbed on ingress (other than to enforce "high order bit" feasibility) leads to more unique path attributes that result in systemic effects (e.g., less efficient update packing, more memory consumption and unnecessary global routing system state, path churn resulting from community changes, etc..). Of course, that's well outside the scope of this document but this will certainly have implications related to those practices, as well as the default "scrubbing" practices by many operators. S.8: The editors call for the RFC Editor to remove section 8 "Implementation Status" before publication. I believe there is value in keeping this section in the document in order to memorialize the current implementation and operational status of the proposal, unless the intention is to create an external "Implementation Report" associated with Large Communities now or at a later time when progression along the Standards Track is desired. S.11: That's a solid list of acknowledgements there, it may be simpler to list who didn't contribute :-) Nits: None. From nobody Mon Nov 14 07:18:40 2016 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 2D77A12945F for ; Mon, 14 Nov 2016 07:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS4kNCyGqUrQ for ; Mon, 14 Nov 2016 07:18:35 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030A6129717 for ; Mon, 14 Nov 2016 07:18:34 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id d2so30203969pfd.0 for ; Mon, 14 Nov 2016 07:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=e3cCQ7Hr2GCEP2xRzzEWgeZADzhQCzKfumEobXHNnyM=; b=BDTnlowmyVubeEyKtWJIUXSqc66jDF0Joy0IOMz0y6qtYEIVB0FRBDgZK8qCwLpvOR x7PtDxiyPqrsIJw1FqzHPgEtqFTK5O+KNT6RLUWKXiYiU7/ZSyIOdd91kdLjHfBpGfaC iCLhu/KCSX2brlGWwQ8q4nw/XmQ7013NdIhJwRXe3GaJJERyrPmXAXdMlOTAEQL5dYqX Tt3g8zo64onZ/tdLL93Q6rdq4CxO0U9wGW20jj3QLtlh/Bidik2poVUFyNt5GQhAJpZy eXFoIGPe+sjHQ7GtP7M9DxASLIS9719g6myOHFI5rIQ+zJ3aUj4PoWElRkXmQAlt/Kv8 BI6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=e3cCQ7Hr2GCEP2xRzzEWgeZADzhQCzKfumEobXHNnyM=; b=PHSsQkiJvAtCVSAqys0wF9OP2bME3xSDCBxuWrtO+e+vfeyzP94PFjKXKj8O6uFK59 9lAwTVs+v24HZ62Ak7yquUKZlNy79gaHlAWfxTf+xtnpnU1sD5suIteRujQaNc8D9VBM nYqFaSAAK5HjjP5Jaj2gXCLIqg2hBn51mmlN7JUnk68IYWAIMZwXiZQYsiVQjAQLOKDD wRuQTXsOTIO51Q7pWvLVAUuX4/etzg6b0CLmXHcvWdM7KU1veWLfkvLrBriihE+4DhJe Bh6mqD72FmtvohNzuQUSwTZ1dpsZf0jY4pKZ+J8NtWgMUtRSje92FWRmXl/VEr47G6SF LjcQ== X-Gm-Message-State: ABUngvcn3SIjrMMFmG4oMuJdsgDnoo4dJnl1kNS4/tM+xRktLC7z9MFmJpBZj8FPGtFdLg== X-Received: by 10.98.74.18 with SMTP id x18mr36870085pfa.58.1479136714391; Mon, 14 Nov 2016 07:18:34 -0800 (PST) Received: from localhost ([2001:67c:370:144:61f5:85e9:4f01:aa8c]) by smtp.gmail.com with ESMTPSA id d15sm36053608pfl.46.2016.11.14.07.18.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 07:18:33 -0800 (PST) Date: Tue, 15 Nov 2016 00:18:29 +0900 From: Job Snijders To: Danny McPherson Message-ID: <20161114151829.GC67788@dhcp-9341.meeting.ietf.org> References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: idr@ietf.org, rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 15:18:37 -0000 Dear Danny, (snipped some text) On Mon, Nov 14, 2016 at 09:46:45AM -0500, Danny McPherson wrote: > RTG-DIR REVIEW: draft-ietf-idr-large-community-08 > Document: draft-ietf-idr-large-community-08.txt > Reviewer: Danny McPherson > Review Date: November 14, 2016 > Intended Status: Standards Track > > Summary: > > I have no major concerns with the content of this document and believe > it is ready for publication. > > Minor Issues: > > S.2: Regarding the change in the -08 version to "MUST NOT" in > "Duplicate BGP Large Community values MUST NOT be transmitted", I > agree with John Scudder's November 14th email to the IDR WG on this > topic, connecting it to RFC 2119 definitions and Postel's law. I > believe MUST NOT is a good statement, particularly when considering > implications of lazy implementations doing things such as including > duplicates when creating aggregates such as outlined in S.3. Upon > further consideration, to Peter Hessler's question on the same mailing > list thread, perhaps RFC 1997 and 4360 communities SHOULD have such a > restriction - for the sake of global routing system hygiene, at least! I agree rationale. I wish I had learned earlier on in this process more about some of the nuances between MUST and SHOULD. To put this in different words: if the paragraphs remains as it was (like in -07) with the words "SHOULD", implicitly we acknowledge that there _might_ be a semantic meaning in signalling duplicate communities. For instance, if community "1:2:3" means "prepend at location X", I'd never want an abomination implementation to exist in this multiverse where it would be legal routing policy construct to match "if community 1:2:3 is present _twice_ in the attribute, prepend twice". By changing the wording to MUST, it becomes clear that the presence of duplicate Large Community has no intrinsic meaning, and is just the artifact of a software bug on the sending side. This was the WGs intention all along because that is how we understand and treat RFC1997 comms too. The s/SHOULD/MUST/ change does not trigger any software updates for any of the currently known implementations. However it does (or should) put Q&A people on higher alert. > S.8: The editors call for the RFC Editor to remove section 8 > "Implementation Status" before publication. I believe there is value > in keeping this section in the document in order to memorialize the > current implementation and operational status of the proposal, unless > the intention is to create an external "Implementation Report" > associated with Large Communities now or at a later time when > progression along the Standards Track is desired. I'd rather scrub the document clean before publishing, and in doing so avoid creating any suggestion for the future readers, years from now, that the implementation is limited to a subset of software. Over time, software may start to support large communities or drop support for large communities. A more lively overview of implementations is available here: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations (inside ietf scope) and here http://largebgpcommunities.net/implementations/ (maintained outside ietf scope) > S.11: That's a solid list of acknowledgements there, it may be simpler > to list who didn't contribute :-) Attestation and acknowledgement are important. Kind regards, Job From nobody Mon Nov 14 08:24:18 2016 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 5D3AE128E19; Mon, 14 Nov 2016 08:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJCGj3jE0ivD; Mon, 14 Nov 2016 08:24:15 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FC0127735; Mon, 14 Nov 2016 08:24:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 3EBB53A; Mon, 14 Nov 2016 17:24:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1479140651; bh=szLWa2cVv8MicYwHr8hMHFdB0tbH 2yQuwyG4rkAVaq8=; b=BX8m3/SM8oA5NEIVV8qzyJFsacROUFTMDB5tJTprnkqC C3ZJqCKXcKBCZQ1FyIKRZaX8jRglL2RkJBtgx8MBjIgONoOhAEqSoal7e5r6z5ou zcdLLdYBEi9SvEr39UZAv0ulkMkMJGCwx9ApvtWV8TN7lxiU96D6RhSHo/LT1d0= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fppkl_O-IJOw; Mon, 14 Nov 2016 17:24:11 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:e144:6027:b4db:dee1] (unknown [IPv6:2a02:a213:a300:9300:e144:6027:b4db:dee1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 3463E38; Mon, 14 Nov 2016 17:24:11 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_0D266D3C-1512-4B38-9879-F45D375BAAA1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <20161114151829.GC67788@dhcp-9341.meeting.ietf.org> Date: Mon, 14 Nov 2016 17:24:10 +0100 Message-Id: <9E85C422-42DB-438B-98BC-DB678E403B12@steffann.nl> References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> <20161114151829.GC67788@dhcp-9341.meeting.ietf.org> To: Job Snijders X-Mailer: Apple Mail (2.3124) Archived-At: Cc: idr@ietf.org, rtg-dir@ietf.org, Danny McPherson Subject: Re: [RTG-DIR] [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 16:24:16 -0000 --Apple-Mail=_0D266D3C-1512-4B38-9879-F45D375BAAA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Job, Please see my previous email to John about SHOULD/MUST here. With that = in mind: > To put this in different words: if the paragraphs remains as it was > (like in -07) with the words "SHOULD", implicitly we acknowledge that > there _might_ be a semantic meaning in signalling duplicate = communities. I agree that there MUST NOT be semantic meaning in duplicate = communities. How about: """ Duplicate BGP Large Community values SHOULD NOT be transmitted. A receiving speaker SHOULD silently remove duplicate BGP Large Community values from a BGP Large Community attribute. If a community value is received multiple times this MUST NOT be treated differently than a community value that is received only once. """ as a middle ground? Cheers, Sander --Apple-Mail=_0D266D3C-1512-4B38-9879-F45D375BAAA1 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----- iQEcBAEBCAAGBQJYKeUqAAoJEKAtA7D+JBO5yOwH/jywpVZ0sbbn4TmzqLqVCpv9 E2MiuFSBL5ZjI+BC5/Zib3Npaf9hAUw54HMXwk+s5dTDT9HhckYtu64q6/vdfzvl TTUu15bOAoL1nSqFumaX4oALnjqKb//DhUvhsb9U3MN/JIRT6prxdujF9QswXwe0 HlzthB+BEvMZjX+k71rr1EzxyDj4cDz3Tytz2ah2Xpx/k0bBSitWuo50bN7TFXIc z1ZAIjfYbq0FQVQObN0YX9z6NzTBi+Clqe8q17F4LjJnT35gjm3X+MWcpjHkW8Xf YzH0824aTHTvZ7r9V18keISgtPOn9a+Irtep+5+vlL6AmCOHUDei0DrcBnzwRvU= =bV+d -----END PGP SIGNATURE----- --Apple-Mail=_0D266D3C-1512-4B38-9879-F45D375BAAA1-- From nobody Mon Nov 14 10:31:29 2016 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 C01A612997A; Mon, 14 Nov 2016 10:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69xlIiZ8LgCJ; Mon, 14 Nov 2016 10:31:23 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1329B129978; Mon, 14 Nov 2016 10:31:23 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.152.135; From: "Susan Hares" To: "'Danny McPherson'" , , References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> In-Reply-To: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> Date: Mon, 14 Nov 2016 13:28:55 -0500 Message-ID: <016a01d23ea4$f642b050$e2c810f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKoIgr88MYxeznhV/2V127EC8jvmp8tBcVQ X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [RTG-DIR] RTG-DIR REVIEW: draft-ietf-idr-large-community-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 18:31:25 -0000 Danny: Thank you for reviewing this document carefully! Sue=20 -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Danny = McPherson Sent: Monday, November 14, 2016 9:47 AM To: idr@ietf.org; rtg-dir@ietf.org Subject: [RTG-DIR] RTG-DIR REVIEW: draft-ietf-idr-large-community-08 RTG-DIR REVIEW: draft-ietf-idr-large-community-08 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 (as is the case here). The purpose of the = review is to provide assistance to the Routing ADs. For more information = about the Routing Directorate, please see = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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-idr-large-community-08.txt Reviewer: Danny McPherson Review Date: November 14, 2016 Intended Status: Standards Track Summary: I have no major concerns with the content of this document and believe = it is ready for publication. Some minor comments are provided below, = although only with the intention to inform the authors, WG, and routing = ADs during their deliberations with regard to the publication of this = document. Comments: I believe the draft is technically sound and addresses an immediate = operational need in a pragmatic manner. Major Issues: I have no =E2=80=9CMajor=E2=80=9D issues with this I-D, I believe it is = ready for=20 publication as a Standards Track RFC. Minor Issues: S.2: Regarding the change in the -08 version to "MUST NOT" in "Duplicate = BGP Large Community values MUST NOT be transmitted", I agree with John=20 Scudder's November 14th email to the IDR WG on this topic, connecting it = to RFC 2119 definitions and Postel's law. I believe MUST NOT is a good=20 statement, particularly when considering implications of lazy=20 implementations doing things such as including duplicates when creating=20 aggregates such as outlined in S.3. Upon further consideration, to=20 Peter Hessler's question on the same mailing list thread, perhaps RFC=20 1997 and 4360 communities SHOULD have such a restriction - for the sake=20 of global routing system hygiene, at least! S.3: Regarding an aggregate inheriting all the BGP Large Communities=20 from all of the aggregated routes, it would seem to me such an=20 instruction may result in unintended operational impacts where regional=20 or other intra-AS and routing policy functions based on community are=20 promoted to the aggregate and trigger undesirable behavior. Operators=20 should certainly be aware of the potential implications of this in their = operational environments. S.7: I believe the reference to S.11 of RFC 7454 is appropriate,=20 although upon rereading I am not sure I agree with the advice of that=20 BCP. Specifically, suggesting that communities not be scrubbed on=20 ingress (other than to enforce "high order bit" feasibility) leads to=20 more unique path attributes that result in systemic effects (e.g., less=20 efficient update packing, more memory consumption and unnecessary global = routing system state, path churn resulting from community changes,=20 etc..). Of course, that's well outside the scope of this document but=20 this will certainly have implications related to those practices, as=20 well as the default "scrubbing" practices by many operators. S.8: The editors call for the RFC Editor to remove section 8=20 "Implementation Status" before publication. I believe there is value in = keeping this section in the document in order to memorialize the current = implementation and operational status of the proposal, unless the=20 intention is to create an external "Implementation Report" associated=20 with Large Communities now or at a later time when progression along the = Standards Track is desired. S.11: That's a solid list of acknowledgements there, it may be simpler=20 to list who didn't contribute :-) Nits: None. From nobody Mon Nov 14 18:52:41 2016 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 365691299B6 for ; Mon, 14 Nov 2016 18:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUt-qjHK96Y5 for ; Mon, 14 Nov 2016 18:52:37 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A041294F7 for ; Mon, 14 Nov 2016 18:52:37 -0800 (PST) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 8fd5f403-aade-11e6-a41e-005056b6f213; Tue, 15 Nov 2016 12:52:35 +1000 (AEST) Received: from dhcp-868f.meeting.ietf.org (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Nov 2016 12:52:11 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <9E85C422-42DB-438B-98BC-DB678E403B12@steffann.nl> Date: Tue, 15 Nov 2016 13:52:27 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <34A7D25B-1B64-475A-8116-87BD9A651D75@apnic.net> References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> <20161114151829.GC67788@dhcp-9341.meeting.ietf.org> <9E85C422-42DB-438B-98BC-DB678E403B12@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Job Snijders , idr@ietf.org, Danny McPherson , rtg-dir@ietf.org Subject: Re: [RTG-DIR] [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:52:39 -0000 > On 15 Nov. 2016, at 3:24 am, Sander Steffann = wrote: > Please see my previous email to John about SHOULD/MUST here. With that = in mind: >=20 >> To put this in different words: if the paragraphs remains as it was >> (like in -07) with the words "SHOULD", implicitly we acknowledge that >> there _might_ be a semantic meaning in signalling duplicate = communities. >=20 > I agree that there MUST NOT be semantic meaning in duplicate = communities. How about: >=20 > """ > Duplicate BGP Large Community values SHOULD NOT be transmitted. A > receiving speaker SHOULD silently remove duplicate BGP Large > Community values from a BGP Large Community attribute. If a community > value is received multiple times this MUST NOT be treated differently > than a community value that is received only once. > """ >=20 > as a middle ground? >=20 I think this test is a good way forward. Geoff From nobody Tue Nov 15 15:17:45 2016 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 624931295C8; Tue, 15 Nov 2016 15:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATs93DKa0Ijz; Tue, 15 Nov 2016 15:17:41 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0107.outbound.protection.outlook.com [104.47.34.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F0B1295D1; Tue, 15 Nov 2016 15:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FgyIkOt7BRQdtH3bUZ1WsMD2t30OJJsyocN39Dqwb/w=; b=LGcbRKxH4ulrOZ7t9kgPPJUgnkxQMZ5K0gfJ6gzZ1KPvp+cSf8yCGcfxTb0AbiyBttt2d5YGCSv9SSEhL1kapd7jUd6D/vZoaOS6cfTqFfc+PHxJV05DQ+7F0sUxLVVlmP41q9IMPKIPVhN2svgEKl82cCtlPCUizGa4YjnQ3vY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.192.68] (116.197.188.11) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Tue, 15 Nov 2016 23:17:37 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <34A7D25B-1B64-475A-8116-87BD9A651D75@apnic.net> Date: Wed, 16 Nov 2016 08:17:15 +0900 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> <20161114151829.GC67788@dhcp-9341.meeting.ietf.org> <9E85C422-42DB-438B-98BC-DB678E403B12@steffann.nl> <34A7D25B-1B64-475A-8116-87BD9A651D75@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3124) X-Originating-IP: [116.197.188.11] X-ClientProxiedBy: HK2PR02CA0056.apcprd02.prod.outlook.com (10.165.70.24) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 2:8yjVGN3+3LMWV+GVhXbQawD4VYvWfU5kW5JAAxuxYCZg2EnJMGY/H+4dTN5HpIuoIDytlXegfrhfgsMRziH0I1e2H0vF++h5DVvFRc9eQWuqCOXVxUb+zLedKWMSleWpFHop6kmC/9tuKCj97q+IsLCjtG1VEP5K/D0NvRUIUCA=; 3:zDw0/X8uxDkZZlQfXbgVMwcZXhdimaot1nbrFDxEfqcnzoEYUD/SyTOkEqcL5PB4PvYVWzwdmdVwavuErTU5BZ04ydBGxbbEJ/uqkmik8u99GgxOS+laFEBBENoUyIEt/ElQUgQ5caFPgPc/3xRtJqXVQw/qJpm3uJ6jnIjOYGM=; 25:Q8V9H57QCLE4AcqI9K5cnzmtFCrZM9Ys2Jxutg3ePtG+x5qv+VYtQZG4E4MNU+rAaDOOqrx9lgJpBiH3mOdozF6zhiYqfUSCsv6nIqucMpxGi7KIDNw2eit0lQYlfWqmngmHj18hnJw4STygfBR1gG+zDESnI7vPWJeKw+iUj5Ql5XyYjpZk6MfvX6WSwzgN4eWwPWPCyW6iUNsYmn1AdRfbPA6sP1crSRLwC7KmBdsANRutA187rZIdsFXKt8Qqkc4Fz8faYTMWeJFsxlZ11/sd4i6zf/LDOJ+TXTGSy8BQFmNreH8xtonGuqF+i/L/LCtPgPYReQi/DxNBBO5B0AKsr6BWmbJGTobi0EsGV/IQW0eLD0dqFk6QYvzELv6Aw9h2Vduk8isulV2SKTgpma6CQ9SPQWZOoh/aLmvXaQEPrr1KHWamBWkvNztV6upuLrRhUZ2V+Q8rW2xbpAQYpQ== X-MS-Office365-Filtering-Correlation-Id: 213eb711-b29e-4283-1a8e-08d40dad9884 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:cXwjqb0qsfAHCus0J0hZAaqAh686KFJbwRQo7pTAf8bCClTHjXvfGizDyuowiR+4dfnkmg4WHwCZaE3mip21lIO43oWskDy4EEJ+ZwBkTBsn5C1U0i4Z1IhGC4LB79hzHyO5csNSdxkofGCWWa58yPhTZB2NU5SKUogcPb1ml0u2uEOd4mYZLmLO7A+Gq+xue74atW7eTZAC5e4ZjjscQwSTRyySg1kpUudRQiZbvrviqfBoRKvpusxJUmoYmxAiCsKRbw8mwKKUOzblTiUdJwRBhpINuT5CRouv2msSYL4=; 20:M2jKXF18j3WxoT4mIICvJP9WHzBraE0iaRtWiFf7s+Qsg/jjLCoNAjbRDPIaZfqD1woPyEm/UZAub67Dl8+RarXWRJ9jt4Lb7JHSJH3Ou7+ZzGRUYofcMD8cTOH5qkGh6XXZZQ9kE1rdtenRUJ/Uz/docWHn2JdhUWiWARxv417GB4NrNGJlPnziLVghJuvlAAmaJnS1I4Trf0Nor3TWloLVenrHJJDqJh90atM3/CuGJKafSPGvVwHsaHz21mvqESqaAlIn4iGKylkI5iEhPoXUpjUrWAbsjqZKSbiCWXU3HBZ0BRsVBxq32b3u8GdLUiwA+PFgmbAIkhfVtH64QbEh7evJiosu4F5cJSMeGDrtutZhQW/FNscXpEYa6saM79Xs6iTKx0YuFNEg3byUu/x5TSvtFZ9E2VM56b68il+dhuemNR4N5DfUhhTXHm43D1YWWkjFPE3HZKnouFNwFjyyb7spSZY+BLyPKxJaHdff3VTciGxTpSTEu5prtVfh X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061324); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:5JTpQ25tDjEUNvpoIr0IjYTUo2ea8E2szbyLi0BYF4xCpXjC7t+HfUrvuV1f8gz8nOBAOQQEBWM6KeE7ObX9UyhKcRvuuLoQvNVd4xBPn+WmhQUczdlAFTcUl1xZL5oWHu6sbqm15s4b+pWDuexdRJ3i3QmWUYRhnh+xGbu57yE8JWCoDxrd+GO/knzEvRjFvkogHomYrt3UQL8n0Ol7FNVYqS+1VcVJOeoSO/dpaa4ybJaHg4WyOWQ9VSJFEBlyvbT7R6t5OEXF5h3TcgY2xKmB+1E3BZsvaFdM6R+2hWBtFD3sbrQat6jFEib5E461f20FDM4aivaYaIw5q0BDrdQAOrA49lRXNCeQBTKWU4W2al7hAn8RsLdu76DhZ5FwNWL3JC1bEHTU6Ui9NFBEySCxzvMiFNBPddTgIpaI0DE2X+02SiQq9zqMJX9qilWy X-Forefront-PRVS: 012792EC17 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(189002)(199003)(24454002)(5660300001)(230783001)(4326007)(229853002)(110136003)(92566002)(93886004)(6666003)(305945005)(6916009)(2950100002)(7736002)(86362001)(82746002)(97756001)(83716003)(2906002)(189998001)(77096005)(68736007)(7846002)(76176999)(105586002)(50986999)(101416001)(42186005)(23726003)(50226002)(97736004)(47776003)(46406003)(6116002)(106356001)(3846002)(81156014)(8746002)(57306001)(66066001)(36756003)(33656002)(50466002)(561944003)(81166006)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:W5eyd/zrPEImqAgO3WKwj/oALdtEbpgXxir4dHWQ3?= =?us-ascii?Q?UoMB0Usj7Sxx4yHgY0OONfCmmpI2xOc2k+xcRNfBpqzw4dOMQgPKMl/KLxPY?= =?us-ascii?Q?eBQeDCQhNl2SsdUafQAFciB8c8vwETZoruIgmT05Vf8bknoGPv8U0BbE86Uo?= =?us-ascii?Q?AsaXWqFB1fHqUfJFAcRHpz3AX4hJ0hoAZiRWwQ33/7AFuWXBjig1OIfL6JvX?= =?us-ascii?Q?jMxVy2QucQm4M50MAAocrRPg4217JgNfh8f9yPFO/4lF012PZ+3EzFcTuEmB?= =?us-ascii?Q?zNaWXSecnSn2kfdpVpWUkaGoZawi6rtfQ6mzHaXURXOFyrmGdHYpIwuc8sfg?= =?us-ascii?Q?FPyjPIS0H5CUMG88yDaIsHsHjZVSpR1XPKGETXg+WDaWaEHN/17vn/mH5ump?= =?us-ascii?Q?sOakxRcBVoi/QSFtQ76i/jMXMGYyJYvW0acTVAAlEAH6OaFnkCLONs/msxZ7?= =?us-ascii?Q?d9kB1Rjxuu63MHZZ19IYXL79L+151YJ6DvAgnTpQl5nQxD1SYtEZQJ1oPIvp?= =?us-ascii?Q?WbLSN/e6beIB3fkfWX2JuSkZQseOqrGygFF/NZMUr17k4QP9FW4XckLRt9L6?= =?us-ascii?Q?4IaeQApDy3Ho5kPoVQR6hbf1tVLH6cAimFk/WExubry6QKIHv6LPBY3dLQmJ?= =?us-ascii?Q?XlDTQX2YZgPecrSn/mxJaVmhHCxj38SzVbty+1aQzW6aHdpNtNE0Gx2HuYvR?= =?us-ascii?Q?rLKjcvkKji0V5QzOKedT7NnHFehdTDGfJ5iNZZLzUs5KruVjyQtPwrd2Kc3P?= =?us-ascii?Q?do0G34E6UufrddCeyp7MnhxO0PnZcuKHLhnxmzJaDLguVrs7xT1aG95XqLcv?= =?us-ascii?Q?qDH+T7H2ltQ3YWe8zn077IhpkQG7q7W+M7yrOgju/pffd+JRuAEQsL6w2Rky?= =?us-ascii?Q?5z2E7s/PMLbteik6xSK4g8YSyufD7jeqfhCn8hQXf1cgRb3becXXBBMlqMvS?= =?us-ascii?Q?qvQdyOJJHGTHZRWY+SP4bZ9fEkAM46PYlaRfZ+oZRcu9PZEoh4vL+Z7N848c?= =?us-ascii?Q?Udm1+xkH0I54S8srGe3jWPFShFPnvTZa/NX6RsoVNPUeDh+RQSpZGUHXeBxG?= =?us-ascii?Q?BbYrRzISOMfPH5Y/coj7FivNZG9ezxHzxrPBhuCdHakOtaj3kTLOjSaLm7Q5?= =?us-ascii?Q?sZ5AcknaAK2RgVDammYHxrHdP8zb8CLGyzR9+MRXaLn0It0EdbIEKJmqNmBH?= =?us-ascii?Q?vlSrJ6s1urh9tD1AsZoaS9enMzmEOWgJnEDtTvE7eTH5A4b3SdGpMu6gmvYk?= =?us-ascii?Q?m9M7eI2LjEbIZMu3sA=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:E5iXsGkQu3P1w+VFJ6QjSrFrpHQwwlk6wzxs4OOsiyJoVW5Irf+gA5A/cacIz96gdlp+ueOWmTt2Pcm5cVIZSDoE4aEaUfDZ0pxJC3bngCg/bX6SKYJ/q/oVbonlxdCRnwqCeHfLIbr8MxAbaIL10abnLeeug1dVNFJQMMDHao1Rp0NTArBz+Jz62tKLH8kAyRLZiGpYsRA9lphSCPmYvdkfKsyt3qebIqr0mtm5+dWofyaqH5BE/ZDNOTAUa7yptDbOjaCr2fYY6e03UjLV/5dgRoQiMnkXpilini9r3DeWkQoSGgC7z2NUW8NjM2EH6qbU0xf4PeHnzyhMO3juJqRwWEouuVSWpgX+Cjimik4f8JeQGVuK5F2VrpKR87K1; 5:Zs7P40UzVgboGhypq1cdEBWoJXBPp7Eh+2zlt+VTTHlfyEhlr/XScavTbTaM8fejNkcyQ8CwWWgctwWdOqZdA+x0ttLf8tYzLnPFBIVaGeQhpOkQ8CnyvSousbgL/ysBPBXb4o8Ca599bFbkkk3JXw==; 24:Vwin15Q12vzkqgRoTZdOFhdQZVQdDV8RwsV9qc5IAVqDTV8daval0tkYlHTueqZsYuK+dG0LT5zhB/+EQS4rtygFihycqwgDzfrje5YKTH4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:py5hvWFYGiYZX7J9m/VyBZFIjPCwVWnhwDzbB2Rb34SIxn0GvnJmoTxQOlejqZxnhcnIMeq9j0/Uc3olZLlPhBuRa+WYTYDZFOX0YE4/26kpTp9RnDHp5ELaiDaqgHAN5qgYvvjBYgOS3CFsBGZ+tI8VWJvxhH2YQacUrl3aRJ89awJAJBTD77q6mg3TLQ+SPUUpCDPD/WTmscRl6d7okXBe3bqffkPWb5PuCXrL5iNgB6H+e4Dxv/gQQCqh/rBC4zJRlOSKa06RBNedIlogmHGmFKrUjFvKbC5LVwvoa/R/hTh3QtaEh3RJWvAEkGYSjxhd9DxeK0KEexIHosR0HG7qO0yTMO2v/9OasqVsz4A= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2016 23:17:37.5805 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506 Archived-At: Cc: Job Snijders , idr@ietf.org, Sander Steffann , rtg-dir@ietf.org, Danny McPherson Subject: Re: [RTG-DIR] [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 23:17:43 -0000 Geoff and Sander, > On Nov 15, 2016, at 11:52 AM, Geoff Huston wrote: >> On 15 Nov. 2016, at 3:24 am, Sander Steffann = wrote: >> Please see my previous email to John about SHOULD/MUST here. With = that in mind: >>=20 >>> To put this in different words: if the paragraphs remains as it was >>> (like in -07) with the words "SHOULD", implicitly we acknowledge = that >>> there _might_ be a semantic meaning in signalling duplicate = communities. >>=20 >> I agree that there MUST NOT be semantic meaning in duplicate = communities. How about: >>=20 >> """ >> Duplicate BGP Large Community values SHOULD NOT be transmitted. A >> receiving speaker SHOULD silently remove duplicate BGP Large >> Community values from a BGP Large Community attribute. If a community >> value is received multiple times this MUST NOT be treated differently >> than a community value that is received only once. >> """ >>=20 >> as a middle ground? >=20 > I think this test is a good way forward. I got a little confused because the conversation took place in two = threads. However, in looking at time stamps I think Sander's proposal = quoted above was overtaken by his later, in the other thread: On Nov 15, 2016, at 8:36 AM, Sander Steffann wrote: > Please count me as neutral on the issue. I'm fine with either wording,=20= and so on (this is in the thread "One week extension to WGLC for = draft-ietf-idr-large-community"). So, unless Sander says otherwise, I'll = suppose his concern from this thread has also been addressed without = need for "middle ground" text. I think the case for why the "SHOULD" = text is not needed and is (mildly) harmful has been made already, but to = summarize for convenience: Since we agree "there MUST NOT be semantic = meaning in duplicate communities", there seems no value in leaving the = door ajar (with a SHOULD) for such semantically meaningless dups to be = transmitted anyway. There also seems no practical value to leaving it = ajar for them to be stored on receipt, although as a practical matter = there's not going to be a way to detect this in a black-box test as long = as the MUST NOT transmit and MUST NOT have semantic meaning parts are = honored. The value of MUST discard duplicates is principally in telling = the implementor "you don't need to go to any trouble to store dups much = less affording them special semantics."=20 Geoff, if you feel there is a need for the "middle ground" text quoted = above, I would be interested in knowing why. (We could also chat f2f if = that's easier for you.) Or if your concerns have also been assuaged, if = you could confirm that to the list it would be helpful. Thanks, --John= From nobody Tue Nov 22 01:41:15 2016 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 96BDF129C7E; Tue, 22 Nov 2016 01:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDOWBxCiBwm4; Tue, 22 Nov 2016 01:41:10 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0139.outbound.protection.outlook.com [104.47.34.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4C8129C74; Tue, 22 Nov 2016 01:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IpuNb2BOJSdmXxpjjQTBf8PkmGjr6RuzLo14tJXlfpw=; b=paNc2IbDahI5Z/T7gfqoHJ68NAq5q/1+lSI535axSLKSf+qG0sJZNHZ4CYXTozKixMtIaFjY9FedbJHLDtsrIOTwBC49ZZlfbbZC+dFEPXM/SKIJe11xdcxiVHnJGnSC9N/JTy3IMMQsXhd8SaHReNZyynhq47TZu0lyH7SWzDI= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1912.namprd02.prod.outlook.com (10.163.75.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Tue, 22 Nov 2016 09:41:04 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0734.014; Tue, 22 Nov 2016 09:41:03 +0000 From: Jonathan Hardwick To: "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@ietf.org" Thread-Topic: Routing area draft minutes available Thread-Index: AdJEpD3JwLyqOOEPS/y8fh0hKkE6UA== Date: Tue, 22 Nov 2016 09:41:03 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.164.131.250] x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1912; 7:oIO3+h+49XVsmWe+U646v5YxEI2H3xpHKtNDDl96AaSffaIUYSOMqCQy4WL752kF+04y3NvyyNbcYN1fTGV+CvkSNOXrF60onl01/i9hfFahLIm9joysM879sjitVEOq6Fwr/paZisyqJgJ5rbXfsZflWUKufE5iNNYFWifcOd6VL07IT89/qIFb4XDqewBzS6dXbbHtBZdng3DVp+tyCuyQBogdURO6gMdjKgnwyFdyQbTu1kVBsy6P+ibPNBhiDeYuMd8MV+4O5p1OzfyOyVu7zmlIWE9oGRk1Ob0fkDe/F/BRTQXnTLx13isopd6Z4la17L7YhNKDufIAmltZjLiQgYHuC9oI/OGFPJDwfEY= x-ms-office365-filtering-correlation-id: 62167d61-e5e0-4826-8957-08d412bbacd1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0201MB1912; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045199)(6040307)(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6041248); SRVR:BY2PR0201MB1912; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1912; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(5660300001)(7846002)(2906002)(2501003)(101416001)(5001770100001)(3846002)(8676002)(66066001)(86362001)(2201001)(76576001)(450100001)(38730400001)(33656002)(2900100001)(74316002)(7736002)(92566002)(7906003)(7696004)(77096005)(122556002)(3280700002)(558084003)(54356999)(3660700001)(790700001)(6116002)(50986999)(106356001)(68736007)(102836003)(87936001)(8936002)(97736004)(81166006)(81156014)(99286002)(105586002)(9686002)(6506003)(606004)(189998001)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1912; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910CB53A77F1B81B250491484B40BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 09:41:03.0447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1912 Archived-At: Subject: [RTG-DIR] Routing area draft minutes available X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 09:41:13 -0000 --_000_BY2PR0201MB1910CB53A77F1B81B250491484B40BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft minutes for the RTGAREA meeting at IETF 97 are now available. Pl= ease let me know if you have any comments. https://www.ietf.org/proceedings/97/minutes/minutes-97-rtgarea-00.txt Best regards Jon --_000_BY2PR0201MB1910CB53A77F1B81B250491484B40BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft minutes for the RTGAREA meeting at IETF 97= are now available.  Please let me know if you have any comments.=

https://www.ietf.org/proceedings/97/minutes/m= inutes-97-rtgarea-00.txt

 

Best regards

Jon

 

--_000_BY2PR0201MB1910CB53A77F1B81B250491484B40BY2PR0201MB1910_-- From nobody Tue Nov 22 02:55:45 2016 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 79C23129D8B; Tue, 22 Nov 2016 02:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRRkjTSI92Uo; Tue, 22 Nov 2016 02:55:41 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB11129DAE; Tue, 22 Nov 2016 02:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5700; q=dns/txt; s=iport; t=1479811935; x=1481021535; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nH/kXiFGi9tzleZfsR7mwOr1gOT/3wv1ppsuFIUdQgY=; b=EJLCcOPgSeLSShcvTfvyl/yTNpiHHdKL5/J6oWCB/UF31QhVtjhlWKjo 7iwfZDN6VGGlT4efgH03hu3btYQfy+tg767X5ipiPXo4vTRFOU58vZSFG bkHbL84+7Y0FS2n2KO9a++Zb4TzFt/92M/8nUvSOKoTtLMk8TJcXrVe+8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAQCMIjRY/5RdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNFAQEBAQEfWIEBB405pmSFH4IGKIV5AhqBdz8UAQIBAQEBAQEBYii?= =?us-ascii?q?EaQEBBCNmAgEIPwMCAgIwFBEBAQQBEohtDq0YgikviywBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEXBYY+gX2CXYRggm0tgjAFlGaFaAGQfIFxhHeJQo1lhAsBHjeBEoV?= =?us-ascii?q?BcgGHbIENAQEB?= X-IronPort-AV: E=Sophos;i="5.31,680,1473120000"; d="scan'208,217";a="176476624" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Nov 2016 10:52:14 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uAMAqDhM008664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Nov 2016 10:52:13 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 22 Nov 2016 04:52:13 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 22 Nov 2016 04:52:12 -0600 From: "Alvaro Retana (aretana)" To: Jonathan Hardwick , "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@ietf.org" Thread-Topic: Routing area draft minutes available Thread-Index: AdJEpD3JwLyqOOEPS/y8fh0hKkE6UAAROimA Date: Tue, 22 Nov 2016 10:52:12 +0000 Message-ID: <8A3735D8-F00A-405B-86E2-C8A6590D7571@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.226.145] Content-Type: multipart/alternative; boundary="_000_8A3735D8F00A405B86E2C8A6590D7571ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [RTG-DIR] Routing area draft minutes available X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 10:55:43 -0000 --_000_8A3735D8F00A405B86E2C8A6590D7571ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEpvbiENCg0KSnVzdCBvbmUgY29ycmVjdGlvbjogdGhlIElBQiBzdGF0ZW1lbnQgaXMg b24gSVB2NiAobm90IElQdjQpLg0KDQpodHRwczovL3d3dy5pYWIub3JnLzIwMTYvMTEvMDcvaWFi LXN0YXRlbWVudC1vbi1pcHY2Lw0KDQpBbHZhcm8uDQoNCk9uIDExLzIyLzE2LCAxMDo0MSBBTSwg IkpvbmF0aGFuIEhhcmR3aWNrIiA8Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb208bWFp bHRvOkpvbmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0Y2guY29tPj4gd3JvdGU6DQoNClRoZSBkcmFm dCBtaW51dGVzIGZvciB0aGUgUlRHQVJFQSBtZWV0aW5nIGF0IElFVEYgOTcgYXJlIG5vdyBhdmFp bGFibGUuICBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1lbnRzLg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvbWludXRlcy9taW51dGVzLTk3LXJ0Z2Fy ZWEtMDAudHh0DQoNCkJlc3QgcmVnYXJkcw0KSm9uDQoNCg== --_000_8A3735D8F00A405B86E2C8A6590D7571ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1z dHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpD YWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQt c3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29s b3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IEpvbiE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBvbmUgY29ycmVjdGlvbjogdGhlIElB QiBzdGF0ZW1lbnQgaXMgb24gSVB2NiAobm90IElQdjQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJodHRwczovL3d3dy5pYWIub3JnLzIwMTYvMTEvMDcvaWFiLXN0YXRlbWVudC1v bi1pcHY2LyI+aHR0cHM6Ly93d3cuaWFiLm9yZy8yMDE2LzExLzA3L2lhYi1zdGF0ZW1lbnQtb24t aXB2Ni88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdmFyby48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPk9uIDExLzIyLzE2LCAxMDo0MSBBTSwg JnF1b3Q7Sm9uYXRoYW4gSGFyZHdpY2smcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpKb25hdGhh bi5IYXJkd2lja0BtZXRhc3dpdGNoLmNvbSI+Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBk cmFmdCBtaW51dGVzIGZvciB0aGUgUlRHQVJFQSBtZWV0aW5nIGF0IElFVEYgOTcgYXJlIG5vdyBh dmFpbGFibGUuJm5ic3A7IFBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVu dHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9taW51dGVzL21pbnV0ZXMtOTctcnRnYXJlYS0w MC50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L21pbnV0ZXMvbWludXRl cy05Ny1ydGdhcmVhLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdh cmRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb248bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8A3735D8F00A405B86E2C8A6590D7571ciscocom_-- From nobody Wed Nov 23 13:09:48 2016 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 7F4C81296D6; Wed, 23 Nov 2016 13:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3onRa1Sq-NZ; Wed, 23 Nov 2016 13:09:41 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EB612948A; Wed, 23 Nov 2016 13:09:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F3572247571; Wed, 23 Nov 2016 13:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479935378; bh=YyC0ggY/gelRqTbllYtt443brOZs4+9zW40ZiQFh7JQ=; h=To:Cc:From:Subject:Date:From; b=rHHZSUNMjyT+P/he9Hay3MHw4zR293H/wmkou540IwlhiXtI+GiORh+jOjTtjW7PF UplqlRQyHfsmuDDpJF6GkcpymS09k4BQUt6g4FUguNUUwQuZ5szR0N/e1qe57YZPUM WzuuAeyFLdT44kj75c0K0YRpWbSkYTs3OMgRRbyo= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 5D2A624B481; Wed, 23 Nov 2016 13:09:37 -0800 (PST) To: "rtg-ads@tools.ietf.org" From: "Joel M. Halpern" Message-ID: Date: Wed, 23 Nov 2016 16:10:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-dir@ietf.org" , draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org, "teas@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-teas-p2mp-loose-path-reopt-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 21:09:42 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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-teas-p2mp-loose-path-reopt-07.txt Reviewer: Joel M. Halpern Review Date: 23-November-2016 IETF LC End Date: N/A Intended Status: Standards Track Summary: I have some moderate concerns about this document that I think should be resolved before publication is approved. Comments: Major: The use of SHOULD and MAY in section 4.1 seems to lead to a device which ostensibly supports this document, but does the wrong things. First, with regard to the SHOULDs, in the absence of any indication as to why it would not do this, it appears that the SHOULD is really "MUST if the device supports this document" which is what MUST in a document actually means. Section 4.2 first bullet says that a mid-point LSR "SHOULD" check for a preferable P2MP-TE LSP Tree. But if it doesn't, it is not supporting this document. As written, it could decide to ignore the message, even though it claims to support this RFC. Looking at the handling when a preferable P2MP-TE LSP tree is found, according to the document, the LSR MAY send the PathErr response. My assumption is that if it does not send the PathErr, it MUST propagate the request. If it does not do either one, the protocol does not function. It seems likely that if this is really intended to be optional (MAY), the document would be improved my giving implementors some hint as to when it is desirable or undesirable to send the message. Then in the third bullet, it is only a SHOULD to pass on the request. Thus, a device which supports this mechanism, but chooses not to pass on the request, is compliant to this document while preventing other devices from properly supporting the mechanism. Minor: The abstract is much too long. Much of the content of the abstract belongs in the introduction. Even teh second paragraph has too much detail for an abstract. Editorial: In the last paragraph of the introduction, it says that this document "proposes" solutions. Given we are now in the position of evaluating publication as a Proposed Standard, I would say that this document "defines" solutions. From nobody Sun Nov 27 19:04:33 2016 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 C8EAE12956D for ; Sun, 27 Nov 2016 19:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rzSA6NK-BWM for ; Sun, 27 Nov 2016 19:04:28 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E30612949D for ; Sun, 27 Nov 2016 19:04:27 -0800 (PST) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 52a9e021-b517-11e6-b8ce-005056b6ee6f; Mon, 28 Nov 2016 13:04:06 +1000 (AEST) Received: from dhcp148.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Nov 2016 13:03:56 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: Date: Mon, 28 Nov 2016 14:04:13 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> References: To: "Zhangxian (Xian)" , X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, lisp@ietf.org, "db3546@att.com" , "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 03:04:32 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, 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 =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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-lisp-type-iana-03.txt=20 Reviewer: Geoff Huston Review Date: 28 November 2016=20 IETF LC End Date: not called=20 Intended Status: Standards Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors and the IANA. Comments: Draft quality and readability. The third paragraph of the Introduction is unclear. Given that LISP = itself is an experimental specification it is hard to understand the = distinction being made between the "experimentation purposes" and some other undescribed purpose which this reviewer can only conclude is also an experimentation purpose. I suggest re-thinking the intent of this paragraph and expressing it in simpler terms. In section 2, the use of the normative "MUST" seems to be inappropriate, particularly when a non-normative "must" ius used in section 4 in an identical context. Major Issues: It seems anomalous to me that a request to set up an IANA Registry for = an Experimental Protocol (RFC6830 is Experimental) is itself proposed to be = a Standards Track document. Furthermore, the document states that additional values be assigned via = a Standards Action. Again, it appears anomalous to me that a specification of a parameter value of an experimental protocol be described by a Standards Track action. If RFC6830 is revised and is re-published as a Standards Track specification then these points are of course not relevant, but until = such a publication takes place, specifying an IANA parameter registry as a Standards Track action for an experimental protocol seems to me to be anomalous and should not proceed unless the IESG specifically agrees = with this approach. Alternatively RFC5226 could be further revised to=20 explicitly describe the guidelines as they relate to Experimental Specifications (as distinct from experimental allocations within = Standards Track specifications), as this area appears to be unclear from my = reading of RFC5226. However it is not for me to resolve this issue, nor is it up to the = draft authors, or the LISP working group, as far as I can tell. It is up to = the IESG and IANA to clarify this situation and allow IANA to be given clear = directions as to how to maintain parameter registries for experimental = specifications while they remain experiments. From nobody Sun Nov 27 20:02:02 2016 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 20CC4129686; Sun, 27 Nov 2016 20:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN3-YHIUbRnk; Sun, 27 Nov 2016 20:01:59 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B29D129670; Sun, 27 Nov 2016 20:01:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 710041C03B7; Sun, 27 Nov 2016 20:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1480305719; bh=RsU4fcQVp513P6UDnwxc19FSoaV/Jb7qLGXkgAN+TDE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=DsUqEv6Hj0ZcKry0hVozwcfL4z8WMY0mZkGgqSvFW7cFft55SYJ6EMQ400GXdqHxm +tnSwCbxStG61qXksDG9NRhuL9MYTVeObPsLxs5fYX/1wIQeQuQ+fPkDkWDhnKDJ5b E4xU9aIHkGHuRJ9FE11LdqxnSCw//tM/XXrQN0mY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 147E31C0240; Sun, 27 Nov 2016 20:01:58 -0800 (PST) To: Geoff Huston , "Zhangxian (Xian)" , rtg-ads@ietf.org References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> From: "Joel M. Halpern" Message-ID: Date: Sun, 27 Nov 2016 23:01:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: rtg-dir@ietf.org, lisp@ietf.org, "db3546@att.com" , "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 04:02:01 -0000 You raise an interesting point Geoff. The documents are experimental. As such, it is reasoanble for this document to be experimental, and for it merely to require IETF RFC for assignment, without restricting it to Standards Track RFCs. And while we are in the process of moving the LISP documents to Standards Track, that will take time. However, I would like to be able to have the right status in the documents when we get the upgrade done. We can do a revision of this document as well, but that seems to be creating work. Any suggestions for how to thread this needly? Yours, Joel On 11/27/16 10:04 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > 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-lisp-type-iana-03.txt > Reviewer: Geoff Huston Review > Date: 28 November 2016 > IETF LC End Date: not called > Intended Status: Standards Track > > Summary: > > I have significant concerns about this document and recommend that the > Routing ADs discuss these issues further with the authors and the IANA. > > Comments: > > Draft quality and readability. > > The third paragraph of the Introduction is unclear. Given that LISP itself > is an experimental specification it is hard to understand the distinction > being made between the "experimentation purposes" and some other > undescribed purpose which this reviewer can only conclude is also an > experimentation purpose. I suggest re-thinking the intent of this > paragraph and expressing it in simpler terms. > > In section 2, the use of the normative "MUST" seems to be inappropriate, > particularly when a non-normative "must" ius used in section 4 in an > identical context. > > Major Issues: > > It seems anomalous to me that a request to set up an IANA Registry for an > Experimental Protocol (RFC6830 is Experimental) is itself proposed to be a > Standards Track document. > > Furthermore, the document states that additional values be assigned via a > Standards Action. Again, it appears anomalous to me that a specification > of a parameter value of an experimental protocol be described by a > Standards Track action. > > If RFC6830 is revised and is re-published as a Standards Track > specification then these points are of course not relevant, but until such > a publication takes place, specifying an IANA parameter registry as a > Standards Track action for an experimental protocol seems to me to be > anomalous and should not proceed unless the IESG specifically agrees with > this approach. Alternatively RFC5226 could be further revised to > explicitly describe the guidelines as they relate to Experimental > Specifications (as distinct from experimental allocations within Standards > Track specifications), as this area appears to be unclear from my reading > of RFC5226. > > However it is not for me to resolve this issue, nor is it up to the draft > authors, or the LISP working group, as far as I can tell. It is up to the IESG and > IANA to clarify this situation and allow IANA to be given clear directions > as to how to maintain parameter registries for experimental specifications > while they remain experiments. > > > From nobody Sun Nov 27 20:40:11 2016 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 43EDA1296B1 for ; Sun, 27 Nov 2016 20:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrXE-HmDwAvt for ; Sun, 27 Nov 2016 20:40:08 -0800 (PST) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [203.119.106.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634A8129448 for ; Sun, 27 Nov 2016 20:40:07 -0800 (PST) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id fbbece53-b523-11e6-b23e-005056b685e3; Mon, 28 Nov 2016 14:34:43 +1000 (AEST) Received: from dhcp148.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Nov 2016 14:35:01 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: Date: Mon, 28 Nov 2016 15:34:57 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" , lisp@ietf.org, "db3546@att.com" , rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 04:40:09 -0000 I am not fully aware of all the options here, but it strikes me that the = IESG could publish this document as EXPERIMENTAL, consistent with = RFC6830, and in the future whatever mechanism is used to update RFC6830 = to Standards Track, the same document could UPDATE this document and = place it on the standards track by virtue of the Update. There may be other approaches as well, as this is _not_ an area where I = would call myself an =E2=80=9Cexpert=E2=80=9D! regards, Geoff > On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern = wrote: >=20 > You raise an interesting point Geoff. >=20 > The documents are experimental. As such, it is reasoanble for this = document to be experimental, and for it merely to require IETF RFC for = assignment, without restricting it to Standards Track RFCs. >=20 > And while we are in the process of moving the LISP documents to = Standards Track, that will take time. >=20 > However, I would like to be able to have the right status in the = documents when we get the upgrade done. We can do a revision of this = document as well, but that seems to be creating work. >=20 > Any suggestions for how to thread this needly? >=20 > Yours, > Joel >=20 > On 11/27/16 10:04 PM, Geoff Huston wrote: >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. >>=20 >> 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 =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r >>=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-lisp-type-iana-03.txt >> Reviewer: Geoff Huston Review >> Date: 28 November 2016 >> IETF LC End Date: not called >> Intended Status: Standards Track >>=20 >> Summary: >>=20 >> I have significant concerns about this document and recommend that = the >> Routing ADs discuss these issues further with the authors and the = IANA. >>=20 >> Comments: >>=20 >> Draft quality and readability. >>=20 >> The third paragraph of the Introduction is unclear. Given that LISP = itself >> is an experimental specification it is hard to understand the = distinction >> being made between the "experimentation purposes" and some other >> undescribed purpose which this reviewer can only conclude is also an >> experimentation purpose. I suggest re-thinking the intent of this >> paragraph and expressing it in simpler terms. >>=20 >> In section 2, the use of the normative "MUST" seems to be = inappropriate, >> particularly when a non-normative "must" ius used in section 4 in an >> identical context. >>=20 >> Major Issues: >>=20 >> It seems anomalous to me that a request to set up an IANA Registry = for an >> Experimental Protocol (RFC6830 is Experimental) is itself proposed to = be a >> Standards Track document. >>=20 >> Furthermore, the document states that additional values be assigned = via a >> Standards Action. Again, it appears anomalous to me that a = specification >> of a parameter value of an experimental protocol be described by a >> Standards Track action. >>=20 >> If RFC6830 is revised and is re-published as a Standards Track >> specification then these points are of course not relevant, but until = such >> a publication takes place, specifying an IANA parameter registry as a >> Standards Track action for an experimental protocol seems to me to be >> anomalous and should not proceed unless the IESG specifically agrees = with >> this approach. Alternatively RFC5226 could be further revised to >> explicitly describe the guidelines as they relate to Experimental >> Specifications (as distinct from experimental allocations within = Standards >> Track specifications), as this area appears to be unclear from my = reading >> of RFC5226. >>=20 >> However it is not for me to resolve this issue, nor is it up to the = draft >> authors, or the LISP working group, as far as I can tell. It is up = to the IESG and >> IANA to clarify this situation and allow IANA to be given clear = directions >> as to how to maintain parameter registries for experimental = specifications >> while they remain experiments. >>=20 >>=20 >>=20 From nobody Sun Nov 27 22:11:04 2016 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 17E6512944D; Sun, 27 Nov 2016 22:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF4tqQiSdg-Z; Sun, 27 Nov 2016 22:11:01 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D60B128874; Sun, 27 Nov 2016 22:11:01 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 3so12170912pgd.0; Sun, 27 Nov 2016 22:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nROvU2+SgWFVRXCqwu2/hR+JVL5a/AtXnKnK+9W7whQ=; b=vapLZNj5Bnzxtia/P0lZf8WMM/qdeJHnsDh6CwiYzW9jSutfjVGBiacRysXT8cyxGJ vzkhiu+Bh37snNWV4kni8kah64wPsJ850qvxhFcBTtWbY7OkQ/ufEUb394W9Yww9xMuU /6gvhJe4+OsWeBj4RuXR89Z/oPvz/NRO4axN44P0SAAKqiaV+VOJFFBQlChJYcYRj82e eT1MeDfV54J32hi37GoZm+0vgVUZROHIdT0idCWLBZMCcZxszk66TQut0wqA+ziRfCNq xjB9h2VrxTShYDrAMyrpXPRFkiLdhmCZ5CwaVmrUsJM+RzTqfUF0kHjX1GTRHGGCw/FE zLpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nROvU2+SgWFVRXCqwu2/hR+JVL5a/AtXnKnK+9W7whQ=; b=M8l4CrcRbuXo1Y4DdMo8GajAVTkK3F1SMiRKaMo63CZzIiJr2+JchNfhcIKT1VHUBT t2RwE8OdPB0hNRAZZuEIbFpTEl062FtH2NV4W7Me6KIQWmyGCfppcW+e4ZrhqlwQf0Mq lrz6tj+HZRamp1MRMrYDJg7YUFGlRgt+uWu/6DaGx2Egcv/EOmizdtABNfP16LgguBMW tGAHp+rfWQ4JWVUt2FGeDsRyHGlsZ25ekcrMWvHI9koWgKXrlqYRVmduu7EdDLqqNODJ yBbS20/58SYMgvml1+CF/vpzkO0XhAQTpJBS1Z3naPuPdpNxJVGdPIn6y+0wrtVAnDqd UAoA== X-Gm-Message-State: AKaTC02U1+R4kGqEL6MBA7NH13ndUbLFRV7FZAt8IfgTC+fdru+v/dGygEsqvMBeoVM0pg== X-Received: by 10.98.97.7 with SMTP id v7mr19995428pfb.39.1480313460504; Sun, 27 Nov 2016 22:11:00 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:cd67:b6fd:d920:5965? ([2603:3024:151c:55f0:cd67:b6fd:d920:5965]) by smtp.gmail.com with ESMTPSA id v1sm66067892pgv.33.2016.11.27.22.10.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Nov 2016 22:10:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Sun, 27 Nov 2016 22:10:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <652FECD2-E034-4A21-86F8-DADA903A700B@gmail.com> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> To: Geoff Huston Archived-At: Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , "Joel M. Halpern" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 06:11:03 -0000 I think this is a good and expedient suggestion.=20 Dino > On Nov 27, 2016, at 8:34 PM, Geoff Huston wrote: >=20 > I am not fully aware of all the options here, but it strikes me that the I= ESG could publish this document as EXPERIMENTAL, consistent with RFC6830, an= d in the future whatever mechanism is used to update RFC6830 to Standards Tr= ack, the same document could UPDATE this document and place it on the standa= rds track by virtue of the Update. >=20 > There may be other approaches as well, as this is _not_ an area where I wo= uld call myself an =E2=80=9Cexpert=E2=80=9D! >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern wrote:= >>=20 >> You raise an interesting point Geoff. >>=20 >> The documents are experimental. As such, it is reasoanble for this docum= ent to be experimental, and for it merely to require IETF RFC for assignment= , without restricting it to Standards Track RFCs. >>=20 >> And while we are in the process of moving the LISP documents to Standards= Track, that will take time. >>=20 >> However, I would like to be able to have the right status in the document= s when we get the upgrade done. We can do a revision of this document as we= ll, but that seems to be creating work. >>=20 >> Any suggestions for how to thread this needly? >>=20 >> Yours, >> Joel >>=20 >>> On 11/27/16 10:04 PM, Geoff Huston wrote: >>> Hello, >>>=20 >>> I have been selected as the Routing Directorate reviewer for this draft.= >>>=20 >>> The Routing Directorate seeks to review all routing or routing-related >>> drafts as they pass through IETF last call and IESG review, and sometime= s >>> on special request. The purpose of the review is to provide assistance t= o >>> the Routing ADs. For more information about the Routing Directorate, >>> please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir= >>>=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 La= st >>> Call comments that you receive, and strive to resolve them through >>> discussion or by updating the draft. >>>=20 >>> Document: draft-ietf-lisp-type-iana-03.txt >>> Reviewer: Geoff Huston Review >>> Date: 28 November 2016 >>> IETF LC End Date: not called >>> Intended Status: Standards Track >>>=20 >>> Summary: >>>=20 >>> I have significant concerns about this document and recommend that the >>> Routing ADs discuss these issues further with the authors and the IANA. >>>=20 >>> Comments: >>>=20 >>> Draft quality and readability. >>>=20 >>> The third paragraph of the Introduction is unclear. Given that LISP itse= lf >>> is an experimental specification it is hard to understand the distinctio= n >>> being made between the "experimentation purposes" and some other >>> undescribed purpose which this reviewer can only conclude is also an >>> experimentation purpose. I suggest re-thinking the intent of this >>> paragraph and expressing it in simpler terms. >>>=20 >>> In section 2, the use of the normative "MUST" seems to be inappropriate,= >>> particularly when a non-normative "must" ius used in section 4 in an >>> identical context. >>>=20 >>> Major Issues: >>>=20 >>> It seems anomalous to me that a request to set up an IANA Registry for a= n >>> Experimental Protocol (RFC6830 is Experimental) is itself proposed to be= a >>> Standards Track document. >>>=20 >>> Furthermore, the document states that additional values be assigned via a= >>> Standards Action. Again, it appears anomalous to me that a specification= >>> of a parameter value of an experimental protocol be described by a >>> Standards Track action. >>>=20 >>> If RFC6830 is revised and is re-published as a Standards Track >>> specification then these points are of course not relevant, but until su= ch >>> a publication takes place, specifying an IANA parameter registry as a >>> Standards Track action for an experimental protocol seems to me to be >>> anomalous and should not proceed unless the IESG specifically agrees wit= h >>> this approach. Alternatively RFC5226 could be further revised to >>> explicitly describe the guidelines as they relate to Experimental >>> Specifications (as distinct from experimental allocations within Standar= ds >>> Track specifications), as this area appears to be unclear from my readin= g >>> of RFC5226. >>>=20 >>> However it is not for me to resolve this issue, nor is it up to the draf= t >>> authors, or the LISP working group, as far as I can tell. It is up to t= he IESG and >>> IANA to clarify this situation and allow IANA to be given clear directio= ns >>> as to how to maintain parameter registries for experimental specificatio= ns >>> while they remain experiments. >>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 28 01:13:01 2016 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 D95751296DF for ; Mon, 28 Nov 2016 01:12:59 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCtZe7sSnBuv for ; Mon, 28 Nov 2016 01:12:57 -0800 (PST) Received: from mail-wj0-x243.google.com (mail-wj0-x243.google.com [IPv6:2a00:1450:400c:c01::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2016E1296E0 for ; Mon, 28 Nov 2016 01:12:57 -0800 (PST) Received: by mail-wj0-x243.google.com with SMTP id jb2so13159648wjb.3 for ; Mon, 28 Nov 2016 01:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IexylFLX9eGuCG/tfR8OhaWpArGlaNdoYLT56G765fU=; b=rfhztQkgoxXkYHYLWiWmzJHznJhOGP3gwZdOHUDMeGtr4ZBCGUhRSmmi5N60nn5yCK 9bKVBQ/j/jbsT444+8DGv/lXNb5eRWuQFyZ0bMSHpqmaP0CLbTjdCDx1zYwBPkhl5tJ2 EEukmxWn/YlMYpK021W4faLY/FoT8uNomqvTMstuFUQFnp2jGX1V6A+l6veqVGL1M0BN hK578UskBK+h/Lt+PrZz37327Wy8jyaPO5daltdHMr+oFdFjuZva6cr6o1VVi4Zir/fG UK2C7guomuckwwp5zVyRcm0tGYWnYgVk5GhLWJRI1T84qqJC7iJOl5hva8V2nHc+dW5f xNWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IexylFLX9eGuCG/tfR8OhaWpArGlaNdoYLT56G765fU=; b=NMc+ptUjUul5Ci4ygytoKDjOdQb0WGLlcoFw8HhlQ1NG+I8lJaKXvu0gOSw4IICLjv 5LtWpkfVO6ZrP9ICdEnVFFnopVKStQbD+fBNQP6Rtnxl3wbH6X9t3l1mKd9HhP4vr/IJ jqdPNwyQn8do9ii3dktQj0a//XPRPhapNJZw1VYHa+akFQPUZLDDH/G5nt/wFnJ4Vdee wSiZ7Nc510kkcfzrIbWiH3B5Q8RnQWSF2RZeArzXDUMFQY8EHs6ldtIHMAioOOcHTYCc FtTPO4LJHDYwxGrO7rjF0p2Fh31BgKmRdFaC74bHKjr3bRG9tGYDVQeqa2WBRyMltWKP We6w== X-Gm-Message-State: AKaTC00ISpXQoD+714ApaIlKpqMRx6QZtFBsxq6YyGgdGbXZHZP+kb5aa8CIOM3GE8LbEQ== X-Received: by 10.194.60.195 with SMTP id j3mr18540833wjr.149.1480324375522; Mon, 28 Nov 2016 01:12:55 -0800 (PST) Received: from ?IPv6:2a01:e35:1381:3430:502b:7c76:76a7:6c22? ([2a01:e35:1381:3430:502b:7c76:76a7:6c22]) by smtp.gmail.com with ESMTPSA id ef10sm41845718wjd.22.2016.11.28.01.12.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 01:12:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Luigi Iannone In-Reply-To: Date: Mon, 28 Nov 2016 10:12:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94229B70-47C3-4FB5-8906-9CD4CC672D10@gigix.net> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , "Joel M. Halpern" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 09:13:00 -0000 Hi Geoff, > On 28 Nov 2016, at 05:34, Geoff Huston wrote: >=20 > I am not fully aware of all the options here, but it strikes me that = the IESG could publish this document as EXPERIMENTAL, consistent with = RFC6830, and in the future whatever mechanism is used to update RFC6830 = to Standards Track, the same document could UPDATE this document and = place it on the standards track by virtue of the Update. Just for clarity. You suggest We publish this document as experimental now. Then we merge the standard = track update in the same document that updates 6830 as standard track. Am I right? An alternative option (with less work to do) is to keep this document = on hold until there will be the standard track update of 6830. At that point, there will not be any issue in publishing the document as = well as standard track. In this way we do not need to work on merging the document with the 6830 = update and we still solve the issue you raised. Any thought ? ciao L. =20 >=20 > There may be other approaches as well, as this is _not_ an area where = I would call myself an =E2=80=9Cexpert=E2=80=9D! >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern = wrote: >>=20 >> You raise an interesting point Geoff. >>=20 >> The documents are experimental. As such, it is reasoanble for this = document to be experimental, and for it merely to require IETF RFC for = assignment, without restricting it to Standards Track RFCs. >>=20 >> And while we are in the process of moving the LISP documents to = Standards Track, that will take time. >>=20 >> However, I would like to be able to have the right status in the = documents when we get the upgrade done. We can do a revision of this = document as well, but that seems to be creating work. >>=20 >> Any suggestions for how to thread this needly? >>=20 >> Yours, >> Joel >>=20 >> On 11/27/16 10:04 PM, Geoff Huston wrote: >>> Hello, >>>=20 >>> I have been selected as the Routing Directorate reviewer for this = draft. >>>=20 >>> 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 =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgD= ir >>>=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-lisp-type-iana-03.txt >>> Reviewer: Geoff Huston Review >>> Date: 28 November 2016 >>> IETF LC End Date: not called >>> Intended Status: Standards Track >>>=20 >>> Summary: >>>=20 >>> I have significant concerns about this document and recommend that = the >>> Routing ADs discuss these issues further with the authors and the = IANA. >>>=20 >>> Comments: >>>=20 >>> Draft quality and readability. >>>=20 >>> The third paragraph of the Introduction is unclear. Given that LISP = itself >>> is an experimental specification it is hard to understand the = distinction >>> being made between the "experimentation purposes" and some other >>> undescribed purpose which this reviewer can only conclude is also an >>> experimentation purpose. I suggest re-thinking the intent of this >>> paragraph and expressing it in simpler terms. >>>=20 >>> In section 2, the use of the normative "MUST" seems to be = inappropriate, >>> particularly when a non-normative "must" ius used in section 4 in an >>> identical context. >>>=20 >>> Major Issues: >>>=20 >>> It seems anomalous to me that a request to set up an IANA Registry = for an >>> Experimental Protocol (RFC6830 is Experimental) is itself proposed = to be a >>> Standards Track document. >>>=20 >>> Furthermore, the document states that additional values be assigned = via a >>> Standards Action. Again, it appears anomalous to me that a = specification >>> of a parameter value of an experimental protocol be described by a >>> Standards Track action. >>>=20 >>> If RFC6830 is revised and is re-published as a Standards Track >>> specification then these points are of course not relevant, but = until such >>> a publication takes place, specifying an IANA parameter registry as = a >>> Standards Track action for an experimental protocol seems to me to = be >>> anomalous and should not proceed unless the IESG specifically agrees = with >>> this approach. Alternatively RFC5226 could be further revised to >>> explicitly describe the guidelines as they relate to Experimental >>> Specifications (as distinct from experimental allocations within = Standards >>> Track specifications), as this area appears to be unclear from my = reading >>> of RFC5226. >>>=20 >>> However it is not for me to resolve this issue, nor is it up to the = draft >>> authors, or the LISP working group, as far as I can tell. It is up = to the IESG and >>> IANA to clarify this situation and allow IANA to be given clear = directions >>> as to how to maintain parameter registries for experimental = specifications >>> while they remain experiments. >>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 28 02:11:26 2016 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 0B6A3129ABE for ; Mon, 28 Nov 2016 02:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEZWY70PPgbN for ; Mon, 28 Nov 2016 02:11:22 -0800 (PST) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [203.119.106.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F54129AC0 for ; Mon, 28 Nov 2016 02:03:25 -0800 (PST) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 269d3f95-b551-11e6-b23e-005056b685e3; Mon, 28 Nov 2016 19:58:03 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Nov 2016 19:58:20 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <94229B70-47C3-4FB5-8906-9CD4CC672D10@gigix.net> Date: Mon, 28 Nov 2016 20:58:15 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <94229B70-47C3-4FB5-8906-9CD4CC672D10@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , "Joel M. Halpern" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 10:11:24 -0000 Hi Luigi, If you think that it would be useful to open up an IANA registry now, = then I would not wait i.e. I=E2=80=99d publish the document as = EXPERIMENTAL and update it into the standards track when you update = RFC6830. On the other hand, if the IANA registry is not needed at once then it = could all wait.=20 Personally, I find deferral options difficult to remember and pick up = the threads - so I normally do things on the day and then adjust as = required down the track - but that's more about my preferred way to = work! kind regards, Geoff > On 28 Nov. 2016, at 8:12 pm, Luigi Iannone wrote: >=20 > Hi Geoff, >> On 28 Nov 2016, at 05:34, Geoff Huston wrote: >>=20 >> I am not fully aware of all the options here, but it strikes me that = the IESG could publish this document as EXPERIMENTAL, consistent with = RFC6830, and in the future whatever mechanism is used to update RFC6830 = to Standards Track, the same document could UPDATE this document and = place it on the standards track by virtue of the Update. >=20 > Just for clarity. >=20 > You suggest >=20 > We publish this document as experimental now. Then we merge the = standard track update in the same document that updates 6830 as standard = track. >=20 > Am I right? >=20 > An alternative option (with less work to do) is to keep this = document on hold until there will be the standard track update of 6830. > At that point, there will not be any issue in publishing the document = as well as standard track. >=20 > In this way we do not need to work on merging the document with the = 6830 update and we still solve the issue you raised. >=20 > Any thought ? >=20 > ciao >=20 > L. >=20 >=20 >=20 >>=20 >> There may be other approaches as well, as this is _not_ an area where = I would call myself an =E2=80=9Cexpert=E2=80=9D! >>=20 >> regards, >>=20 >> Geoff >>=20 >>=20 >>=20 >>> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern = wrote: >>>=20 >>> You raise an interesting point Geoff. >>>=20 >>> The documents are experimental. As such, it is reasoanble for this = document to be experimental, and for it merely to require IETF RFC for = assignment, without restricting it to Standards Track RFCs. >>>=20 >>> And while we are in the process of moving the LISP documents to = Standards Track, that will take time. >>>=20 >>> However, I would like to be able to have the right status in the = documents when we get the upgrade done. We can do a revision of this = document as well, but that seems to be creating work. >>>=20 >>> Any suggestions for how to thread this needly? >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 11/27/16 10:04 PM, Geoff Huston wrote: >>>> Hello, >>>>=20 >>>> I have been selected as the Routing Directorate reviewer for this = draft. >>>>=20 >>>> 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 =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/Rtg= Dir >>>>=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-lisp-type-iana-03.txt >>>> Reviewer: Geoff Huston Review >>>> Date: 28 November 2016 >>>> IETF LC End Date: not called >>>> Intended Status: Standards Track >>>>=20 >>>> Summary: >>>>=20 >>>> I have significant concerns about this document and recommend that = the >>>> Routing ADs discuss these issues further with the authors and the = IANA. >>>>=20 >>>> Comments: >>>>=20 >>>> Draft quality and readability. >>>>=20 >>>> The third paragraph of the Introduction is unclear. Given that LISP = itself >>>> is an experimental specification it is hard to understand the = distinction >>>> being made between the "experimentation purposes" and some other >>>> undescribed purpose which this reviewer can only conclude is also = an >>>> experimentation purpose. I suggest re-thinking the intent of this >>>> paragraph and expressing it in simpler terms. >>>>=20 >>>> In section 2, the use of the normative "MUST" seems to be = inappropriate, >>>> particularly when a non-normative "must" ius used in section 4 in = an >>>> identical context. >>>>=20 >>>> Major Issues: >>>>=20 >>>> It seems anomalous to me that a request to set up an IANA Registry = for an >>>> Experimental Protocol (RFC6830 is Experimental) is itself proposed = to be a >>>> Standards Track document. >>>>=20 >>>> Furthermore, the document states that additional values be assigned = via a >>>> Standards Action. Again, it appears anomalous to me that a = specification >>>> of a parameter value of an experimental protocol be described by a >>>> Standards Track action. >>>>=20 >>>> If RFC6830 is revised and is re-published as a Standards Track >>>> specification then these points are of course not relevant, but = until such >>>> a publication takes place, specifying an IANA parameter registry as = a >>>> Standards Track action for an experimental protocol seems to me to = be >>>> anomalous and should not proceed unless the IESG specifically = agrees with >>>> this approach. Alternatively RFC5226 could be further revised to >>>> explicitly describe the guidelines as they relate to Experimental >>>> Specifications (as distinct from experimental allocations within = Standards >>>> Track specifications), as this area appears to be unclear from my = reading >>>> of RFC5226. >>>>=20 >>>> However it is not for me to resolve this issue, nor is it up to the = draft >>>> authors, or the LISP working group, as far as I can tell. It is up = to the IESG and >>>> IANA to clarify this situation and allow IANA to be given clear = directions >>>> as to how to maintain parameter registries for experimental = specifications >>>> while they remain experiments. >>>>=20 >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Mon Nov 28 05:14:55 2016 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 F24EB129F21; Mon, 28 Nov 2016 05:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFSLI5o6lg-0; Mon, 28 Nov 2016 05:14:48 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF14129F1B; Mon, 28 Nov 2016 05:14:48 -0800 (PST) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6DE244757B; Mon, 28 Nov 2016 08:14:47 -0500 (EST) From: "Marc Blanchet" To: "Geoff Huston" Date: Mon, 28 Nov 2016 08:14:48 -0500 Message-ID: <291FCB7C-AC8A-40C4-8602-3731CB02751A@viagenie.ca> In-Reply-To: References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <94229B70-47C3-4FB5-8906-9CD4CC672D10@gigix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5307) Archived-At: Cc: rtg-dir@ietf.org, Zhangxian , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , Luigi Iannone , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:14:54 -0000 On 28 Nov 2016, at 4:58, Geoff Huston wrote: > Hi Luigi, > > If you think that it would be useful to open up an IANA registry now, > then I would not wait i.e. I’d publish the document as EXPERIMENTAL > and update it into the standards track when you update RFC6830. FYI, dtnrg had his specs as experimental. After some good experimentation with wg managed registries, we end up creating an RFC to register all the parameters. That RFC (6255) was Informational. Marc. > > On the other hand, if the IANA registry is not needed at once then it > could all wait. > > Personally, I find deferral options difficult to remember and pick up > the threads - so I normally do things on the day and then adjust as > required down the track - but that's more about my preferred way to > work! > > kind regards, > > Geoff > > > > >> On 28 Nov. 2016, at 8:12 pm, Luigi Iannone wrote: >> >> Hi Geoff, >>> On 28 Nov 2016, at 05:34, Geoff Huston wrote: >>> >>> I am not fully aware of all the options here, but it strikes me that >>> the IESG could publish this document as EXPERIMENTAL, consistent >>> with RFC6830, and in the future whatever mechanism is used to update >>> RFC6830 to Standards Track, the same document could UPDATE this >>> document and place it on the standards track by virtue of the >>> Update. >> >> Just for clarity. >> >> You suggest >> >> We publish this document as experimental now. Then we merge the >> standard track update in the same document that updates 6830 as >> standard track. >> >> Am I right? >> >> An alternative option (with less work to do) is to keep this >> document on hold until there will be the standard track update of >> 6830. >> At that point, there will not be any issue in publishing the document >> as well as standard track. >> >> In this way we do not need to work on merging the document with the >> 6830 update and we still solve the issue you raised. >> >> Any thought ? >> >> ciao >> >> L. >> >> >> >>> >>> There may be other approaches as well, as this is _not_ an area >>> where I would call myself an “expert”! >>> >>> regards, >>> >>> Geoff >>> >>> >>> >>>> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern >>>> wrote: >>>> >>>> You raise an interesting point Geoff. >>>> >>>> The documents are experimental. As such, it is reasoanble for this >>>> document to be experimental, and for it merely to require IETF RFC >>>> for assignment, without restricting it to Standards Track RFCs. >>>> >>>> And while we are in the process of moving the LISP documents to >>>> Standards Track, that will take time. >>>> >>>> However, I would like to be able to have the right status in the >>>> documents when we get the upgrade done. We can do a revision of >>>> this document as well, but that seems to be creating work. >>>> >>>> Any suggestions for how to thread this needly? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/27/16 10:04 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>>>> >>>>> 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-lisp-type-iana-03.txt >>>>> Reviewer: Geoff Huston Review >>>>> Date: 28 November 2016 >>>>> IETF LC End Date: not called >>>>> Intended Status: Standards Track >>>>> >>>>> Summary: >>>>> >>>>> I have significant concerns about this document and recommend that >>>>> the >>>>> Routing ADs discuss these issues further with the authors and the >>>>> IANA. >>>>> >>>>> Comments: >>>>> >>>>> Draft quality and readability. >>>>> >>>>> The third paragraph of the Introduction is unclear. Given that >>>>> LISP itself >>>>> is an experimental specification it is hard to understand the >>>>> distinction >>>>> being made between the "experimentation purposes" and some other >>>>> undescribed purpose which this reviewer can only conclude is also >>>>> an >>>>> experimentation purpose. I suggest re-thinking the intent of this >>>>> paragraph and expressing it in simpler terms. >>>>> >>>>> In section 2, the use of the normative "MUST" seems to be >>>>> inappropriate, >>>>> particularly when a non-normative "must" ius used in section 4 in >>>>> an >>>>> identical context. >>>>> >>>>> Major Issues: >>>>> >>>>> It seems anomalous to me that a request to set up an IANA Registry >>>>> for an >>>>> Experimental Protocol (RFC6830 is Experimental) is itself proposed >>>>> to be a >>>>> Standards Track document. >>>>> >>>>> Furthermore, the document states that additional values be >>>>> assigned via a >>>>> Standards Action. Again, it appears anomalous to me that a >>>>> specification >>>>> of a parameter value of an experimental protocol be described by a >>>>> Standards Track action. >>>>> >>>>> If RFC6830 is revised and is re-published as a Standards Track >>>>> specification then these points are of course not relevant, but >>>>> until such >>>>> a publication takes place, specifying an IANA parameter registry >>>>> as a >>>>> Standards Track action for an experimental protocol seems to me to >>>>> be >>>>> anomalous and should not proceed unless the IESG specifically >>>>> agrees with >>>>> this approach. Alternatively RFC5226 could be further revised to >>>>> explicitly describe the guidelines as they relate to Experimental >>>>> Specifications (as distinct from experimental allocations within >>>>> Standards >>>>> Track specifications), as this area appears to be unclear from my >>>>> reading >>>>> of RFC5226. >>>>> >>>>> However it is not for me to resolve this issue, nor is it up to >>>>> the draft >>>>> authors, or the LISP working group, as far as I can tell. It is >>>>> up to the IESG and >>>>> IANA to clarify this situation and allow IANA to be given clear >>>>> directions >>>>> as to how to maintain parameter registries for experimental >>>>> specifications >>>>> while they remain experiments. >>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 28 05:47:57 2016 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 DC15A129417; Mon, 28 Nov 2016 05:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC4P7ebjtHhB; Mon, 28 Nov 2016 05:47:50 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AE012952F; Mon, 28 Nov 2016 05:43:32 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 47EF0602E2; Mon, 28 Nov 2016 14:43:30 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 1EA90C009B; Mon, 28 Nov 2016 14:43:30 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 14:43:29 +0100 From: To: Geoff Huston , "Zhangxian (Xian)" , "rtg-ads@ietf.org" Thread-Topic: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt Thread-Index: AQHSSSTZkTJXs+jI90y9VfbdmaPmWaDuYMHA Date: Mon, 28 Nov 2016 13:43:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DB9254@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> In-Reply-To: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "jonathan.hardwick@metaswitch.com" , "rtg-dir@ietf.org" , "draft-ietf-lisp-type-iana.all@ietf.org" , "lisp@ietf.org" , Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:47:52 -0000 SGkgR29lZmYsIA0KDQpJIGhhdmUgb25lIGNvbW1lbnQgYWJvdXQgdGhpcyBwYXJ0IG9mIHlvdXIg cmV2aWV3OiANCg0KPiBJdCBzZWVtcyBhbm9tYWxvdXMgdG8gbWUgdGhhdCBhIHJlcXVlc3QgdG8g c2V0IHVwIGFuIElBTkEgUmVnaXN0cnkgZm9yIGFuDQo+IEV4cGVyaW1lbnRhbCBQcm90b2NvbCAo UkZDNjgzMCBpcyBFeHBlcmltZW50YWwpIGlzIGl0c2VsZiBwcm9wb3NlZCB0byBiZSBhDQo+IFN0 YW5kYXJkcyBUcmFjayBkb2N1bWVudC4NCg0KRldJVywgSSdtIGF3YXJlIG9mIGFuIElBTkEgcmVn aXN0cnkgZm9yIGFuIGV4cGVyaW1lbnRhbCBwcm90b2NvbCB0aGF0IHlvdSBjYW4gY2hlY2sgaGVy ZTogDQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3RjcC1wYXJhbWV0ZXJzL3RjcC1w YXJhbWV0ZXJzLnhodG1sI21wdGNwLW9wdGlvbi1zdWJ0eXBlcyANCg0KQ2hlZXJzLA0KTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGxpc3AgW21haWx0bzpsaXNw LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgR2VvZmYgSHVzdG9uDQo+IEVudm95w6nC oDogbHVuZGkgMjggbm92ZW1icmUgMjAxNiAwNDowNA0KPiDDgMKgOiBaaGFuZ3hpYW4gKFhpYW4p OyBydGctYWRzQGlldGYub3JnDQo+IENjwqA6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5v cmc7IGpvbmF0aGFuLmhhcmR3aWNrQG1ldGFzd2l0Y2guY29tOw0KPiBkcmFmdC1pZXRmLWxpc3At dHlwZS1pYW5hLmFsbEBpZXRmLm9yZzsgSm9uIEh1ZHNvbg0KPiBPYmpldMKgOiBbbGlzcF0gUnRn RGlyIHJldmlldzogZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wMy50eHQNCj4gDQo+IEhlbGxv LA0KPiANCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuDQo+IA0KPiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBz ZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+IGRyYWZ0cyBh cyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBz b21ldGltZXMNCj4gb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3 IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0bw0KPiB0aGUgUm91dGluZyBBRHMuIEZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLA0KPiBwbGVhc2Ugc2Vl IOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIN Cj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIFJvdXRpbmcgQURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBj b25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdA0KPiBDYWxsIGNvbW1l bnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gN Cj4gZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1bWVudDog ZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wMy50eHQNCj4gUmV2aWV3ZXI6IEdlb2ZmIEh1c3Rv biBSZXZpZXcNCj4gRGF0ZTogMjggTm92ZW1iZXIgMjAxNg0KPiBJRVRGIExDIEVuZCBEYXRlOiBu b3QgY2FsbGVkDQo+IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQo+IA0KPiBTdW1t YXJ5Og0KPiANCj4gSSBoYXZlIHNpZ25pZmljYW50IGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1l bnQgYW5kIHJlY29tbWVuZCB0aGF0IHRoZQ0KPiBSb3V0aW5nIEFEcyBkaXNjdXNzIHRoZXNlIGlz c3VlcyBmdXJ0aGVyIHdpdGggdGhlIGF1dGhvcnMgYW5kIHRoZSBJQU5BLg0KPiANCj4gQ29tbWVu dHM6DQo+IA0KPiBEcmFmdCBxdWFsaXR5IGFuZCByZWFkYWJpbGl0eS4NCj4gDQo+IFRoZSB0aGly ZCBwYXJhZ3JhcGggb2YgdGhlIEludHJvZHVjdGlvbiBpcyB1bmNsZWFyLiBHaXZlbiB0aGF0IExJ U1AgaXRzZWxmDQo+IGlzIGFuIGV4cGVyaW1lbnRhbCBzcGVjaWZpY2F0aW9uIGl0IGlzIGhhcmQg dG8gdW5kZXJzdGFuZCB0aGUgZGlzdGluY3Rpb24NCj4gYmVpbmcgbWFkZSBiZXR3ZWVuIHRoZSAi ZXhwZXJpbWVudGF0aW9uIHB1cnBvc2VzIiBhbmQgc29tZSBvdGhlcg0KPiB1bmRlc2NyaWJlZCBw dXJwb3NlIHdoaWNoIHRoaXMgcmV2aWV3ZXIgY2FuIG9ubHkgY29uY2x1ZGUgaXMgYWxzbyBhbg0K PiBleHBlcmltZW50YXRpb24gcHVycG9zZS4gSSBzdWdnZXN0IHJlLXRoaW5raW5nIHRoZSBpbnRl bnQgb2YgdGhpcw0KPiBwYXJhZ3JhcGggYW5kIGV4cHJlc3NpbmcgaXQgaW4gc2ltcGxlciB0ZXJt cy4NCj4gDQo+IEluIHNlY3Rpb24gMiwgdGhlIHVzZSBvZiB0aGUgbm9ybWF0aXZlICJNVVNUIiBz ZWVtcyB0byBiZSBpbmFwcHJvcHJpYXRlLA0KPiBwYXJ0aWN1bGFybHkgd2hlbiBhIG5vbi1ub3Jt YXRpdmUgIm11c3QiIGl1cyB1c2VkIGluIHNlY3Rpb24gNCBpbiBhbg0KPiBpZGVudGljYWwgY29u dGV4dC4NCj4gDQo+IE1ham9yIElzc3VlczoNCj4gDQo+IEl0IHNlZW1zIGFub21hbG91cyB0byBt ZSB0aGF0IGEgcmVxdWVzdCB0byBzZXQgdXAgYW4gSUFOQSBSZWdpc3RyeSBmb3IgYW4NCj4gRXhw ZXJpbWVudGFsIFByb3RvY29sIChSRkM2ODMwIGlzIEV4cGVyaW1lbnRhbCkgaXMgaXRzZWxmIHBy b3Bvc2VkIHRvIGJlIGENCj4gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50Lg0KPiANCj4gRnVydGhl cm1vcmUsIHRoZSBkb2N1bWVudCBzdGF0ZXMgdGhhdCBhZGRpdGlvbmFsIHZhbHVlcyBiZSBhc3Np Z25lZCB2aWEgYQ0KPiBTdGFuZGFyZHMgQWN0aW9uLiBBZ2FpbiwgaXQgYXBwZWFycyBhbm9tYWxv dXMgdG8gbWUgdGhhdCBhIHNwZWNpZmljYXRpb24NCj4gb2YgYSBwYXJhbWV0ZXIgdmFsdWUgb2Yg YW4gZXhwZXJpbWVudGFsIHByb3RvY29sIGJlIGRlc2NyaWJlZCBieSBhDQo+IFN0YW5kYXJkcyBU cmFjayBhY3Rpb24uDQo+IA0KPiBJZiBSRkM2ODMwIGlzIHJldmlzZWQgYW5kIGlzIHJlLXB1Ymxp c2hlZCBhcyBhIFN0YW5kYXJkcyBUcmFjaw0KPiBzcGVjaWZpY2F0aW9uIHRoZW4gdGhlc2UgcG9p bnRzIGFyZSBvZiBjb3Vyc2Ugbm90IHJlbGV2YW50LCBidXQgdW50aWwgc3VjaA0KPiBhIHB1Ymxp Y2F0aW9uIHRha2VzIHBsYWNlLCBzcGVjaWZ5aW5nIGFuIElBTkEgcGFyYW1ldGVyIHJlZ2lzdHJ5 IGFzIGENCj4gU3RhbmRhcmRzIFRyYWNrIGFjdGlvbiBmb3IgYW4gZXhwZXJpbWVudGFsIHByb3Rv Y29sIHNlZW1zIHRvIG1lIHRvIGJlDQo+IGFub21hbG91cyBhbmQgc2hvdWxkIG5vdCBwcm9jZWVk IHVubGVzcyB0aGUgSUVTRyBzcGVjaWZpY2FsbHkgYWdyZWVzIHdpdGgNCj4gdGhpcyBhcHByb2Fj aC4gQWx0ZXJuYXRpdmVseSBSRkM1MjI2IGNvdWxkIGJlIGZ1cnRoZXIgcmV2aXNlZCB0bw0KPiBl eHBsaWNpdGx5IGRlc2NyaWJlIHRoZSBndWlkZWxpbmVzIGFzIHRoZXkgcmVsYXRlIHRvIEV4cGVy aW1lbnRhbA0KPiBTcGVjaWZpY2F0aW9ucyAoYXMgZGlzdGluY3QgZnJvbSBleHBlcmltZW50YWwg YWxsb2NhdGlvbnMgd2l0aGluIFN0YW5kYXJkcw0KPiBUcmFjayBzcGVjaWZpY2F0aW9ucyksIGFz IHRoaXMgYXJlYSBhcHBlYXJzIHRvIGJlIHVuY2xlYXIgZnJvbSBteSByZWFkaW5nDQo+IG9mIFJG QzUyMjYuDQo+IA0KPiBIb3dldmVyIGl0IGlzIG5vdCBmb3IgbWUgdG8gcmVzb2x2ZSB0aGlzIGlz c3VlLCBub3IgaXMgaXQgdXAgdG8gdGhlIGRyYWZ0DQo+IGF1dGhvcnMsIG9yIHRoZSBMSVNQIHdv cmtpbmcgZ3JvdXAsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLiAgSXQgaXMgdXAgdG8gdGhlDQo+IElF U0cgYW5kDQo+IElBTkEgdG8gY2xhcmlmeSB0aGlzIHNpdHVhdGlvbiBhbmQgYWxsb3cgSUFOQSB0 byBiZSBnaXZlbiBjbGVhciBkaXJlY3Rpb25zDQo+IGFzIHRvIGhvdyB0byBtYWludGFpbiBwYXJh bWV0ZXIgcmVnaXN0cmllcyBmb3IgZXhwZXJpbWVudGFsIHNwZWNpZmljYXRpb25zDQo+IHdoaWxl IHRoZXkgcmVtYWluIGV4cGVyaW1lbnRzLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxpc3AgbWFpbGluZyBsaXN0DQo+IGxpc3BA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQo= From nobody Mon Nov 28 05:59:36 2016 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 AAC361295AE; Mon, 28 Nov 2016 05:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R0qgjIKVCJC; Mon, 28 Nov 2016 05:59:28 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9A41294C5; Mon, 28 Nov 2016 05:59:28 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id EE7BE60235; Mon, 28 Nov 2016 14:59:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id A260318006E; Mon, 28 Nov 2016 14:59:26 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 14:59:26 +0100 From: To: Dino Farinacci , Geoff Huston Thread-Topic: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt Thread-Index: AQHSSSwvSGQwvHveDkym5s43SC04mqDtvm+AgAAa1YCAAJNP8A== Date: Mon, 28 Nov 2016 13:59:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DB9287@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <652FECD2-E034-4A21-86F8-DADA903A700B@gmail.com> In-Reply-To: <652FECD2-E034-4A21-86F8-DADA903A700B@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , "Joel M. Halpern" , "draft-ietf-lisp-type-iana.all@ietf.org" , Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:59:31 -0000 UmUtLA0KDQpXb3JrcyBmb3IgbWUsIHRvby4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZhcmlu YWNjaUBnbWFpbC5jb21dDQo+IEVudm95w6nCoDogbHVuZGkgMjggbm92ZW1icmUgMjAxNiAwNzox MQ0KPiDDgMKgOiBHZW9mZiBIdXN0b24NCj4gQ2PCoDogSm9lbCBNLiBIYWxwZXJuOyBydGctZGly QGlldGYub3JnOyBaaGFuZ3hpYW4gKFhpYW4pOyBsaXNwQGlldGYub3JnOw0KPiBydGctYWRzQGll dGYub3JnOyBqb25hdGhhbi5oYXJkd2lja0BtZXRhc3dpdGNoLmNvbTsgZHJhZnQtaWV0Zi1saXNw LXR5cGUtDQo+IGlhbmEuYWxsQGlldGYub3JnOyBKb24gSHVkc29uDQo+IE9iamV0wqA6IFJlOiBb bGlzcF0gW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmEt DQo+IDAzLnR4dA0KPiANCj4gSSB0aGluayB0aGlzIGlzIGEgZ29vZCBhbmQgZXhwZWRpZW50IHN1 Z2dlc3Rpb24uDQo+IA0KPiBEaW5vDQo+IA0KPiA+IE9uIE5vdiAyNywgMjAxNiwgYXQgODozNCBQ TSwgR2VvZmYgSHVzdG9uIDxnaWhAYXBuaWMubmV0PiB3cm90ZToNCj4gPg0KPiA+IEkgYW0gbm90 IGZ1bGx5IGF3YXJlIG9mIGFsbCB0aGUgb3B0aW9ucyBoZXJlLCBidXQgaXQgc3RyaWtlcyBtZSB0 aGF0IHRoZQ0KPiBJRVNHIGNvdWxkIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBFWFBFUklNRU5U QUwsIGNvbnNpc3RlbnQgd2l0aCBSRkM2ODMwLA0KPiBhbmQgaW4gdGhlIGZ1dHVyZSB3aGF0ZXZl ciBtZWNoYW5pc20gaXMgdXNlZCB0byB1cGRhdGUgUkZDNjgzMCB0bw0KPiBTdGFuZGFyZHMgVHJh Y2ssIHRoZSBzYW1lIGRvY3VtZW50IGNvdWxkIFVQREFURSB0aGlzIGRvY3VtZW50IGFuZCBwbGFj ZSBpdA0KPiBvbiB0aGUgc3RhbmRhcmRzIHRyYWNrIGJ5IHZpcnR1ZSBvZiB0aGUgVXBkYXRlLg0K PiA+DQo+ID4gVGhlcmUgbWF5IGJlIG90aGVyIGFwcHJvYWNoZXMgYXMgd2VsbCwgYXMgdGhpcyBp cyBfbm90XyBhbiBhcmVhIHdoZXJlIEkNCj4gd291bGQgY2FsbCBteXNlbGYgYW4g4oCcZXhwZXJ0 4oCdIQ0KPiA+DQo+ID4gcmVnYXJkcywNCj4gPg0KPiA+ICBHZW9mZg0KPiA+DQo+ID4NCj4gPg0K PiA+PiBPbiAyOCBOb3YuIDIwMTYsIGF0IDM6MDEgcG0sIEpvZWwgTS4gSGFscGVybiA8am1oQGpv ZWxoYWxwZXJuLmNvbT4NCj4gd3JvdGU6DQo+ID4+DQo+ID4+IFlvdSByYWlzZSBhbiBpbnRlcmVz dGluZyBwb2ludCBHZW9mZi4NCj4gPj4NCj4gPj4gVGhlIGRvY3VtZW50cyBhcmUgZXhwZXJpbWVu dGFsLiAgQXMgc3VjaCwgaXQgaXMgcmVhc29hbmJsZSBmb3IgdGhpcw0KPiBkb2N1bWVudCB0byBi ZSBleHBlcmltZW50YWwsIGFuZCBmb3IgaXQgbWVyZWx5IHRvIHJlcXVpcmUgSUVURiBSRkMgZm9y DQo+IGFzc2lnbm1lbnQsIHdpdGhvdXQgcmVzdHJpY3RpbmcgaXQgdG8gU3RhbmRhcmRzIFRyYWNr IFJGQ3MuDQo+ID4+DQo+ID4+IEFuZCB3aGlsZSB3ZSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YgbW92 aW5nIHRoZSBMSVNQIGRvY3VtZW50cyB0bw0KPiBTdGFuZGFyZHMgVHJhY2ssIHRoYXQgd2lsbCB0 YWtlIHRpbWUuDQo+ID4+DQo+ID4+IEhvd2V2ZXIsIEkgd291bGQgbGlrZSB0byBiZSBhYmxlIHRv IGhhdmUgdGhlIHJpZ2h0IHN0YXR1cyBpbiB0aGUNCj4gZG9jdW1lbnRzIHdoZW4gd2UgZ2V0IHRo ZSB1cGdyYWRlIGRvbmUuICBXZSBjYW4gZG8gYSByZXZpc2lvbiBvZiB0aGlzDQo+IGRvY3VtZW50 IGFzIHdlbGwsIGJ1dCB0aGF0IHNlZW1zIHRvIGJlIGNyZWF0aW5nIHdvcmsuDQo+ID4+DQo+ID4+ IEFueSBzdWdnZXN0aW9ucyBmb3IgaG93IHRvIHRocmVhZCB0aGlzIG5lZWRseT8NCj4gPj4NCj4g Pj4gWW91cnMsDQo+ID4+IEpvZWwNCj4gPj4NCj4gPj4+IE9uIDExLzI3LzE2IDEwOjA0IFBNLCBH ZW9mZiBIdXN0b24gd3JvdGU6DQo+ID4+PiBIZWxsbywNCj4gPj4+DQo+ID4+PiBJIGhhdmUgYmVl biBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcw0K PiBkcmFmdC4NCj4gPj4+DQo+ID4+PiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+ID4+PiBkcmFmdHMgYXMgdGhl eSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQNCj4gc29t ZXRpbWVzDQo+ID4+PiBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZp ZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlDQo+IHRvDQo+ID4+PiB0aGUgUm91dGluZyBBRHMu IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLA0KPiA+ Pj4gcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFj L3dpa2kvUnRnRGlyDQo+ID4+Pg0KPiA+Pj4gQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHBy aW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsDQo+IGl0DQo+ID4+PiB3b3Vs ZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90 aGVyIElFVEYNCj4gTGFzdA0KPiA+Pj4gQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBh bmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoDQo+ID4+PiBkaXNjdXNzaW9uIG9yIGJ5 IHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4gPj4+DQo+ID4+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1s aXNwLXR5cGUtaWFuYS0wMy50eHQNCj4gPj4+IFJldmlld2VyOiBHZW9mZiBIdXN0b24gUmV2aWV3 DQo+ID4+PiBEYXRlOiAyOCBOb3ZlbWJlciAyMDE2DQo+ID4+PiBJRVRGIExDIEVuZCBEYXRlOiBu b3QgY2FsbGVkDQo+ID4+PiBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPiA+Pj4N Cj4gPj4+IFN1bW1hcnk6DQo+ID4+Pg0KPiA+Pj4gSSBoYXZlIHNpZ25pZmljYW50IGNvbmNlcm5z IGFib3V0IHRoaXMgZG9jdW1lbnQgYW5kIHJlY29tbWVuZCB0aGF0IHRoZQ0KPiA+Pj4gUm91dGlu ZyBBRHMgZGlzY3VzcyB0aGVzZSBpc3N1ZXMgZnVydGhlciB3aXRoIHRoZSBhdXRob3JzIGFuZCB0 aGUNCj4gSUFOQS4NCj4gPj4+DQo+ID4+PiBDb21tZW50czoNCj4gPj4+DQo+ID4+PiBEcmFmdCBx dWFsaXR5IGFuZCByZWFkYWJpbGl0eS4NCj4gPj4+DQo+ID4+PiBUaGUgdGhpcmQgcGFyYWdyYXBo IG9mIHRoZSBJbnRyb2R1Y3Rpb24gaXMgdW5jbGVhci4gR2l2ZW4gdGhhdCBMSVNQDQo+IGl0c2Vs Zg0KPiA+Pj4gaXMgYW4gZXhwZXJpbWVudGFsIHNwZWNpZmljYXRpb24gaXQgaXMgaGFyZCB0byB1 bmRlcnN0YW5kIHRoZQ0KPiBkaXN0aW5jdGlvbg0KPiA+Pj4gYmVpbmcgbWFkZSBiZXR3ZWVuIHRo ZSAiZXhwZXJpbWVudGF0aW9uIHB1cnBvc2VzIiBhbmQgc29tZSBvdGhlcg0KPiA+Pj4gdW5kZXNj cmliZWQgcHVycG9zZSB3aGljaCB0aGlzIHJldmlld2VyIGNhbiBvbmx5IGNvbmNsdWRlIGlzIGFs c28gYW4NCj4gPj4+IGV4cGVyaW1lbnRhdGlvbiBwdXJwb3NlLiBJIHN1Z2dlc3QgcmUtdGhpbmtp bmcgdGhlIGludGVudCBvZiB0aGlzDQo+ID4+PiBwYXJhZ3JhcGggYW5kIGV4cHJlc3NpbmcgaXQg aW4gc2ltcGxlciB0ZXJtcy4NCj4gPj4+DQo+ID4+PiBJbiBzZWN0aW9uIDIsIHRoZSB1c2Ugb2Yg dGhlIG5vcm1hdGl2ZSAiTVVTVCIgc2VlbXMgdG8gYmUNCj4gaW5hcHByb3ByaWF0ZSwNCj4gPj4+ IHBhcnRpY3VsYXJseSB3aGVuIGEgbm9uLW5vcm1hdGl2ZSAibXVzdCIgaXVzIHVzZWQgaW4gc2Vj dGlvbiA0IGluIGFuDQo+ID4+PiBpZGVudGljYWwgY29udGV4dC4NCj4gPj4+DQo+ID4+PiBNYWpv ciBJc3N1ZXM6DQo+ID4+Pg0KPiA+Pj4gSXQgc2VlbXMgYW5vbWFsb3VzIHRvIG1lIHRoYXQgYSBy ZXF1ZXN0IHRvIHNldCB1cCBhbiBJQU5BIFJlZ2lzdHJ5IGZvcg0KPiBhbg0KPiA+Pj4gRXhwZXJp bWVudGFsIFByb3RvY29sIChSRkM2ODMwIGlzIEV4cGVyaW1lbnRhbCkgaXMgaXRzZWxmIHByb3Bv c2VkIHRvDQo+IGJlIGENCj4gPj4+IFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudC4NCj4gPj4+DQo+ ID4+PiBGdXJ0aGVybW9yZSwgdGhlIGRvY3VtZW50IHN0YXRlcyB0aGF0IGFkZGl0aW9uYWwgdmFs dWVzIGJlIGFzc2lnbmVkDQo+IHZpYSBhDQo+ID4+PiBTdGFuZGFyZHMgQWN0aW9uLiBBZ2Fpbiwg aXQgYXBwZWFycyBhbm9tYWxvdXMgdG8gbWUgdGhhdCBhDQo+IHNwZWNpZmljYXRpb24NCj4gPj4+ IG9mIGEgcGFyYW1ldGVyIHZhbHVlIG9mIGFuIGV4cGVyaW1lbnRhbCBwcm90b2NvbCBiZSBkZXNj cmliZWQgYnkgYQ0KPiA+Pj4gU3RhbmRhcmRzIFRyYWNrIGFjdGlvbi4NCj4gPj4+DQo+ID4+PiBJ ZiBSRkM2ODMwIGlzIHJldmlzZWQgYW5kIGlzIHJlLXB1Ymxpc2hlZCBhcyBhIFN0YW5kYXJkcyBU cmFjaw0KPiA+Pj4gc3BlY2lmaWNhdGlvbiB0aGVuIHRoZXNlIHBvaW50cyBhcmUgb2YgY291cnNl IG5vdCByZWxldmFudCwgYnV0IHVudGlsDQo+IHN1Y2gNCj4gPj4+IGEgcHVibGljYXRpb24gdGFr ZXMgcGxhY2UsIHNwZWNpZnlpbmcgYW4gSUFOQSBwYXJhbWV0ZXIgcmVnaXN0cnkgYXMgYQ0KPiA+ Pj4gU3RhbmRhcmRzIFRyYWNrIGFjdGlvbiBmb3IgYW4gZXhwZXJpbWVudGFsIHByb3RvY29sIHNl ZW1zIHRvIG1lIHRvIGJlDQo+ID4+PiBhbm9tYWxvdXMgYW5kIHNob3VsZCBub3QgcHJvY2VlZCB1 bmxlc3MgdGhlIElFU0cgc3BlY2lmaWNhbGx5IGFncmVlcw0KPiB3aXRoDQo+ID4+PiB0aGlzIGFw cHJvYWNoLiBBbHRlcm5hdGl2ZWx5IFJGQzUyMjYgY291bGQgYmUgZnVydGhlciByZXZpc2VkIHRv DQo+ID4+PiBleHBsaWNpdGx5IGRlc2NyaWJlIHRoZSBndWlkZWxpbmVzIGFzIHRoZXkgcmVsYXRl IHRvIEV4cGVyaW1lbnRhbA0KPiA+Pj4gU3BlY2lmaWNhdGlvbnMgKGFzIGRpc3RpbmN0IGZyb20g ZXhwZXJpbWVudGFsIGFsbG9jYXRpb25zIHdpdGhpbg0KPiBTdGFuZGFyZHMNCj4gPj4+IFRyYWNr IHNwZWNpZmljYXRpb25zKSwgYXMgdGhpcyBhcmVhIGFwcGVhcnMgdG8gYmUgdW5jbGVhciBmcm9t IG15DQo+IHJlYWRpbmcNCj4gPj4+IG9mIFJGQzUyMjYuDQo+ID4+Pg0KPiA+Pj4gSG93ZXZlciBp dCBpcyBub3QgZm9yIG1lIHRvIHJlc29sdmUgdGhpcyBpc3N1ZSwgbm9yIGlzIGl0IHVwIHRvIHRo ZQ0KPiBkcmFmdA0KPiA+Pj4gYXV0aG9ycywgb3IgdGhlIExJU1Agd29ya2luZyBncm91cCwgYXMg ZmFyIGFzIEkgY2FuIHRlbGwuICBJdCBpcyB1cCB0bw0KPiB0aGUgSUVTRyBhbmQNCj4gPj4+IElB TkEgdG8gY2xhcmlmeSB0aGlzIHNpdHVhdGlvbiBhbmQgYWxsb3cgSUFOQSB0byBiZSBnaXZlbiBj bGVhcg0KPiBkaXJlY3Rpb25zDQo+ID4+PiBhcyB0byBob3cgdG8gbWFpbnRhaW4gcGFyYW1ldGVy IHJlZ2lzdHJpZXMgZm9yIGV4cGVyaW1lbnRhbA0KPiBzcGVjaWZpY2F0aW9ucw0KPiA+Pj4gd2hp bGUgdGhleSByZW1haW4gZXhwZXJpbWVudHMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGxp c3AgbWFpbGluZyBsaXN0DQo+ID4gbGlzcEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0K From nobody Mon Nov 28 06:05:14 2016 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 8888A1295A3; Mon, 28 Nov 2016 06:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYz2JM79jqyX; Mon, 28 Nov 2016 06:05:08 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E64129483; Mon, 28 Nov 2016 06:05:07 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 80D2860324; Mon, 28 Nov 2016 15:05:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 30EBF8006A; Mon, 28 Nov 2016 15:05:06 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 15:05:00 +0100 From: To: BOUCADAIR Mohamed IMT/OLN , Dino Farinacci , Geoff Huston Thread-Topic: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt Thread-Index: AQHSSSwvUUj9ILWswkWoprVxl0cx6KDtvm+AgAAa1YCAAILhgIAAEh8Q Date: Mon, 28 Nov 2016 14:04:56 +0000 Message-ID: <17824_1480341906_583C3992_17824_11501_1_118c2c10-9fa0-45c2-a15a-5819f01a3972@OPEXCLILM6C.corporate.adroot.infra.ftgroup> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <652FECD2-E034-4A21-86F8-DADA903A700B@gmail.com> <787AE7BB302AE849A7480A190F8B933009DB9287@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DB9287@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , "Joel M. Halpern" , "draft-ietf-lisp-type-iana.all@ietf.org" , Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 14:05:09 -0000 SGksDQoNCkdlb2ZmJ3MgcHJvcG9zYWwgaXMgYWxzbyBmaW5lIGJ5IG1lLg0KDQpDaGVlcnMsDQoN CkNocmlzdGlhbi4NCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bV0gDQpFbnZvecOpwqA6IGx1bmRpIDI4IG5vdmVtYnJlIDIwMTYgMTQ6NTkNCsOAwqA6IERpbm8g RmFyaW5hY2NpOyBHZW9mZiBIdXN0b24NCkNjwqA6IEpvZWwgTS4gSGFscGVybjsgcnRnLWRpckBp ZXRmLm9yZzsgWmhhbmd4aWFuIChYaWFuKTsgbGlzcEBpZXRmLm9yZzsgcnRnLWFkc0BpZXRmLm9y Zzsgam9uYXRoYW4uaGFyZHdpY2tAbWV0YXN3aXRjaC5jb207IGRyYWZ0LWlldGYtbGlzcC10eXBl LWlhbmEuYWxsQGlldGYub3JnOyBKb24gSHVkc29uDQpPYmpldMKgOiBSRTogW2xpc3BdIFtSVEct RElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5hLTAzLnR4dA0KDQpS ZS0sDQoNCldvcmtzIGZvciBtZSwgdG9vLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERpbm8gRmFyaW5hY2NpIFttYWlsdG86ZmFyaW5h Y2NpQGdtYWlsLmNvbV0gRW52b3nDqcKgOiBsdW5kaSAyOCANCj4gbm92ZW1icmUgMjAxNiAwNzox MSDDgMKgOiBHZW9mZiBIdXN0b24gQ2PCoDogSm9lbCBNLiBIYWxwZXJuOyANCj4gcnRnLWRpckBp ZXRmLm9yZzsgWmhhbmd4aWFuIChYaWFuKTsgbGlzcEBpZXRmLm9yZzsgcnRnLWFkc0BpZXRmLm9y ZzsgDQo+IGpvbmF0aGFuLmhhcmR3aWNrQG1ldGFzd2l0Y2guY29tOyBkcmFmdC1pZXRmLWxpc3At dHlwZS0gDQo+IGlhbmEuYWxsQGlldGYub3JnOyBKb24gSHVkc29uIE9iamV0wqA6IFJlOiBbbGlz cF0gW1JURy1ESVJdIFJ0Z0RpciANCj4gcmV2aWV3OiBkcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5h LSAwMy50eHQNCj4gDQo+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgYW5kIGV4cGVkaWVudCBzdWdn ZXN0aW9uLg0KPiANCj4gRGlubw0KPiANCj4gPiBPbiBOb3YgMjcsIDIwMTYsIGF0IDg6MzQgUE0s IEdlb2ZmIEh1c3RvbiA8Z2loQGFwbmljLm5ldD4gd3JvdGU6DQo+ID4NCj4gPiBJIGFtIG5vdCBm dWxseSBhd2FyZSBvZiBhbGwgdGhlIG9wdGlvbnMgaGVyZSwgYnV0IGl0IHN0cmlrZXMgbWUgdGhh dCANCj4gPiB0aGUNCj4gSUVTRyBjb3VsZCBwdWJsaXNoIHRoaXMgZG9jdW1lbnQgYXMgRVhQRVJJ TUVOVEFMLCBjb25zaXN0ZW50IHdpdGggDQo+IFJGQzY4MzAsIGFuZCBpbiB0aGUgZnV0dXJlIHdo YXRldmVyIG1lY2hhbmlzbSBpcyB1c2VkIHRvIHVwZGF0ZSANCj4gUkZDNjgzMCB0byBTdGFuZGFy ZHMgVHJhY2ssIHRoZSBzYW1lIGRvY3VtZW50IGNvdWxkIFVQREFURSB0aGlzIA0KPiBkb2N1bWVu dCBhbmQgcGxhY2UgaXQgb24gdGhlIHN0YW5kYXJkcyB0cmFjayBieSB2aXJ0dWUgb2YgdGhlIFVw ZGF0ZS4NCj4gPg0KPiA+IFRoZXJlIG1heSBiZSBvdGhlciBhcHByb2FjaGVzIGFzIHdlbGwsIGFz IHRoaXMgaXMgX25vdF8gYW4gYXJlYSANCj4gPiB3aGVyZSBJDQo+IHdvdWxkIGNhbGwgbXlzZWxm IGFuIOKAnGV4cGVydOKAnSENCj4gPg0KPiA+IHJlZ2FyZHMsDQo+ID4NCj4gPiAgR2VvZmYNCj4g Pg0KPiA+DQo+ID4NCj4gPj4gT24gMjggTm92LiAyMDE2LCBhdCAzOjAxIHBtLCBKb2VsIE0uIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+PiBZb3UgcmFp c2UgYW4gaW50ZXJlc3RpbmcgcG9pbnQgR2VvZmYuDQo+ID4+DQo+ID4+IFRoZSBkb2N1bWVudHMg YXJlIGV4cGVyaW1lbnRhbC4gIEFzIHN1Y2gsIGl0IGlzIHJlYXNvYW5ibGUgZm9yIHRoaXMNCj4g ZG9jdW1lbnQgdG8gYmUgZXhwZXJpbWVudGFsLCBhbmQgZm9yIGl0IG1lcmVseSB0byByZXF1aXJl IElFVEYgUkZDIGZvciANCj4gYXNzaWdubWVudCwgd2l0aG91dCByZXN0cmljdGluZyBpdCB0byBT dGFuZGFyZHMgVHJhY2sgUkZDcy4NCj4gPj4NCj4gPj4gQW5kIHdoaWxlIHdlIGFyZSBpbiB0aGUg cHJvY2VzcyBvZiBtb3ZpbmcgdGhlIExJU1AgZG9jdW1lbnRzIHRvDQo+IFN0YW5kYXJkcyBUcmFj aywgdGhhdCB3aWxsIHRha2UgdGltZS4NCj4gPj4NCj4gPj4gSG93ZXZlciwgSSB3b3VsZCBsaWtl IHRvIGJlIGFibGUgdG8gaGF2ZSB0aGUgcmlnaHQgc3RhdHVzIGluIHRoZQ0KPiBkb2N1bWVudHMg d2hlbiB3ZSBnZXQgdGhlIHVwZ3JhZGUgZG9uZS4gIFdlIGNhbiBkbyBhIHJldmlzaW9uIG9mIHRo aXMgDQo+IGRvY3VtZW50IGFzIHdlbGwsIGJ1dCB0aGF0IHNlZW1zIHRvIGJlIGNyZWF0aW5nIHdv cmsuDQo+ID4+DQo+ID4+IEFueSBzdWdnZXN0aW9ucyBmb3IgaG93IHRvIHRocmVhZCB0aGlzIG5l ZWRseT8NCj4gPj4NCj4gPj4gWW91cnMsDQo+ID4+IEpvZWwNCj4gPj4NCj4gPj4+IE9uIDExLzI3 LzE2IDEwOjA0IFBNLCBHZW9mZiBIdXN0b24gd3JvdGU6DQo+ID4+PiBIZWxsbywNCj4gPj4+DQo+ ID4+PiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZp ZXdlciBmb3IgdGhpcw0KPiBkcmFmdC4NCj4gPj4+DQo+ID4+PiBUaGUgUm91dGluZyBEaXJlY3Rv cmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3IgDQo+ID4+PiByb3V0aW5nLXJlbGF0 ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCANCj4gPj4+ IElFU0cgcmV2aWV3LCBhbmQNCj4gc29tZXRpbWVzDQo+ID4+PiBvbiBzcGVjaWFsIHJlcXVlc3Qu IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSANCj4gPj4+IGFzc2lzdGFu Y2UNCj4gdG8NCj4gPj4+IHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgdGhlIFJvdXRpbmcgDQo+ID4+PiBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSANCj4gPj4+IOKA i2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4g Pj4+DQo+ID4+PiBBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUg dXNlIG9mIHRoZSBSb3V0aW5nIA0KPiA+Pj4gQURzLA0KPiBpdA0KPiA+Pj4gd291bGQgYmUgaGVs cGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciANCj4g Pj4+IElFVEYNCj4gTGFzdA0KPiA+Pj4gQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBh bmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIA0KPiA+Pj4gZGlzY3Vzc2lvbiBvciBi eSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYt bGlzcC10eXBlLWlhbmEtMDMudHh0DQo+ID4+PiBSZXZpZXdlcjogR2VvZmYgSHVzdG9uIFJldmll dw0KPiA+Pj4gRGF0ZTogMjggTm92ZW1iZXIgMjAxNg0KPiA+Pj4gSUVURiBMQyBFbmQgRGF0ZTog bm90IGNhbGxlZA0KPiA+Pj4gSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCj4gPj4+ DQo+ID4+PiBTdW1tYXJ5Og0KPiA+Pj4NCj4gPj4+IEkgaGF2ZSBzaWduaWZpY2FudCBjb25jZXJu cyBhYm91dCB0aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQgdGhhdCANCj4gPj4+IHRoZSBSb3V0 aW5nIEFEcyBkaXNjdXNzIHRoZXNlIGlzc3VlcyBmdXJ0aGVyIHdpdGggdGhlIGF1dGhvcnMgYW5k IA0KPiA+Pj4gdGhlDQo+IElBTkEuDQo+ID4+Pg0KPiA+Pj4gQ29tbWVudHM6DQo+ID4+Pg0KPiA+ Pj4gRHJhZnQgcXVhbGl0eSBhbmQgcmVhZGFiaWxpdHkuDQo+ID4+Pg0KPiA+Pj4gVGhlIHRoaXJk IHBhcmFncmFwaCBvZiB0aGUgSW50cm9kdWN0aW9uIGlzIHVuY2xlYXIuIEdpdmVuIHRoYXQgDQo+ ID4+PiBMSVNQDQo+IGl0c2VsZg0KPiA+Pj4gaXMgYW4gZXhwZXJpbWVudGFsIHNwZWNpZmljYXRp b24gaXQgaXMgaGFyZCB0byB1bmRlcnN0YW5kIHRoZQ0KPiBkaXN0aW5jdGlvbg0KPiA+Pj4gYmVp bmcgbWFkZSBiZXR3ZWVuIHRoZSAiZXhwZXJpbWVudGF0aW9uIHB1cnBvc2VzIiBhbmQgc29tZSBv dGhlciANCj4gPj4+IHVuZGVzY3JpYmVkIHB1cnBvc2Ugd2hpY2ggdGhpcyByZXZpZXdlciBjYW4g b25seSBjb25jbHVkZSBpcyBhbHNvIA0KPiA+Pj4gYW4gZXhwZXJpbWVudGF0aW9uIHB1cnBvc2Uu IEkgc3VnZ2VzdCByZS10aGlua2luZyB0aGUgaW50ZW50IG9mIA0KPiA+Pj4gdGhpcyBwYXJhZ3Jh cGggYW5kIGV4cHJlc3NpbmcgaXQgaW4gc2ltcGxlciB0ZXJtcy4NCj4gPj4+DQo+ID4+PiBJbiBz ZWN0aW9uIDIsIHRoZSB1c2Ugb2YgdGhlIG5vcm1hdGl2ZSAiTVVTVCIgc2VlbXMgdG8gYmUNCj4g aW5hcHByb3ByaWF0ZSwNCj4gPj4+IHBhcnRpY3VsYXJseSB3aGVuIGEgbm9uLW5vcm1hdGl2ZSAi bXVzdCIgaXVzIHVzZWQgaW4gc2VjdGlvbiA0IGluIA0KPiA+Pj4gYW4gaWRlbnRpY2FsIGNvbnRl eHQuDQo+ID4+Pg0KPiA+Pj4gTWFqb3IgSXNzdWVzOg0KPiA+Pj4NCj4gPj4+IEl0IHNlZW1zIGFu b21hbG91cyB0byBtZSB0aGF0IGEgcmVxdWVzdCB0byBzZXQgdXAgYW4gSUFOQSBSZWdpc3RyeSAN Cj4gPj4+IGZvcg0KPiBhbg0KPiA+Pj4gRXhwZXJpbWVudGFsIFByb3RvY29sIChSRkM2ODMwIGlz IEV4cGVyaW1lbnRhbCkgaXMgaXRzZWxmIHByb3Bvc2VkIA0KPiA+Pj4gdG8NCj4gYmUgYQ0KPiA+ Pj4gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50Lg0KPiA+Pj4NCj4gPj4+IEZ1cnRoZXJtb3JlLCB0 aGUgZG9jdW1lbnQgc3RhdGVzIHRoYXQgYWRkaXRpb25hbCB2YWx1ZXMgYmUgDQo+ID4+PiBhc3Np Z25lZA0KPiB2aWEgYQ0KPiA+Pj4gU3RhbmRhcmRzIEFjdGlvbi4gQWdhaW4sIGl0IGFwcGVhcnMg YW5vbWFsb3VzIHRvIG1lIHRoYXQgYQ0KPiBzcGVjaWZpY2F0aW9uDQo+ID4+PiBvZiBhIHBhcmFt ZXRlciB2YWx1ZSBvZiBhbiBleHBlcmltZW50YWwgcHJvdG9jb2wgYmUgZGVzY3JpYmVkIGJ5IGEg DQo+ID4+PiBTdGFuZGFyZHMgVHJhY2sgYWN0aW9uLg0KPiA+Pj4NCj4gPj4+IElmIFJGQzY4MzAg aXMgcmV2aXNlZCBhbmQgaXMgcmUtcHVibGlzaGVkIGFzIGEgU3RhbmRhcmRzIFRyYWNrIA0KPiA+ Pj4gc3BlY2lmaWNhdGlvbiB0aGVuIHRoZXNlIHBvaW50cyBhcmUgb2YgY291cnNlIG5vdCByZWxl dmFudCwgYnV0IA0KPiA+Pj4gdW50aWwNCj4gc3VjaA0KPiA+Pj4gYSBwdWJsaWNhdGlvbiB0YWtl cyBwbGFjZSwgc3BlY2lmeWluZyBhbiBJQU5BIHBhcmFtZXRlciByZWdpc3RyeSANCj4gPj4+IGFz IGEgU3RhbmRhcmRzIFRyYWNrIGFjdGlvbiBmb3IgYW4gZXhwZXJpbWVudGFsIHByb3RvY29sIHNl ZW1zIHRvIA0KPiA+Pj4gbWUgdG8gYmUgYW5vbWFsb3VzIGFuZCBzaG91bGQgbm90IHByb2NlZWQg dW5sZXNzIHRoZSBJRVNHIA0KPiA+Pj4gc3BlY2lmaWNhbGx5IGFncmVlcw0KPiB3aXRoDQo+ID4+ PiB0aGlzIGFwcHJvYWNoLiBBbHRlcm5hdGl2ZWx5IFJGQzUyMjYgY291bGQgYmUgZnVydGhlciBy ZXZpc2VkIHRvIA0KPiA+Pj4gZXhwbGljaXRseSBkZXNjcmliZSB0aGUgZ3VpZGVsaW5lcyBhcyB0 aGV5IHJlbGF0ZSB0byBFeHBlcmltZW50YWwgDQo+ID4+PiBTcGVjaWZpY2F0aW9ucyAoYXMgZGlz dGluY3QgZnJvbSBleHBlcmltZW50YWwgYWxsb2NhdGlvbnMgd2l0aGluDQo+IFN0YW5kYXJkcw0K PiA+Pj4gVHJhY2sgc3BlY2lmaWNhdGlvbnMpLCBhcyB0aGlzIGFyZWEgYXBwZWFycyB0byBiZSB1 bmNsZWFyIGZyb20gbXkNCj4gcmVhZGluZw0KPiA+Pj4gb2YgUkZDNTIyNi4NCj4gPj4+DQo+ID4+ PiBIb3dldmVyIGl0IGlzIG5vdCBmb3IgbWUgdG8gcmVzb2x2ZSB0aGlzIGlzc3VlLCBub3IgaXMg aXQgdXAgdG8gDQo+ID4+PiB0aGUNCj4gZHJhZnQNCj4gPj4+IGF1dGhvcnMsIG9yIHRoZSBMSVNQ IHdvcmtpbmcgZ3JvdXAsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLiAgSXQgaXMgDQo+ID4+PiB1cCB0 bw0KPiB0aGUgSUVTRyBhbmQNCj4gPj4+IElBTkEgdG8gY2xhcmlmeSB0aGlzIHNpdHVhdGlvbiBh bmQgYWxsb3cgSUFOQSB0byBiZSBnaXZlbiBjbGVhcg0KPiBkaXJlY3Rpb25zDQo+ID4+PiBhcyB0 byBob3cgdG8gbWFpbnRhaW4gcGFyYW1ldGVyIHJlZ2lzdHJpZXMgZm9yIGV4cGVyaW1lbnRhbA0K PiBzcGVjaWZpY2F0aW9ucw0KPiA+Pj4gd2hpbGUgdGhleSByZW1haW4gZXhwZXJpbWVudHMuDQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IGxpc3AgbWFpbGluZyBsaXN0DQo+ID4gbGlzcEBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Nov 28 10:59:42 2016 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 3ACDA129F95 for ; Mon, 28 Nov 2016 10:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtjqXXQsN69r for ; Mon, 28 Nov 2016 10:59:39 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [203.119.102.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98535129F9D for ; Mon, 28 Nov 2016 10:59:39 -0800 (PST) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 10fcd6d5-b59c-11e6-b8ce-005056b6ee6f; Tue, 29 Nov 2016 04:54:19 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Nov 2016 04:54:28 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DB9254@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 29 Nov 2016 05:54:25 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <46143E39-F8EF-4E41-8893-C166FF5F8C5E@apnic.net> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <787AE7BB302AE849A7480A190F8B933009DB9254@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , "draft-ietf-lisp-type-iana.all@ietf.org" , Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 18:59:41 -0000 You appear to have misunderstood me - its _not_ that this draft seeks to = create an IANA registry for an experimental specification that I found to be = anomalous. What=20 I found anomalous was that the document proposing such an action was = itself proposed=20 to be a Standards Track document.=20 Clear now? thanks, Geoff > On 29 Nov. 2016, at 12:43 am, = wrote: >=20 > Hi Goeff,=20 >=20 > I have one comment about this part of your review:=20 >=20 >> It seems anomalous to me that a request to set up an IANA Registry = for an >> Experimental Protocol (RFC6830 is Experimental) is itself proposed to = be a >> Standards Track document. >=20 > FWIW, I'm aware of an IANA registry for an experimental protocol that = you can check here:=20 > = http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#mptcp-= option-subtypes=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : lisp [mailto:lisp-bounces@ietf.org] De la part de Geoff Huston >> Envoy=C3=A9 : lundi 28 novembre 2016 04:04 >> =C3=80 : Zhangxian (Xian); rtg-ads@ietf.org >> Cc : rtg-dir@ietf.org; lisp@ietf.org; = jonathan.hardwick@metaswitch.com; >> draft-ietf-lisp-type-iana.all@ietf.org; Jon Hudson >> Objet : [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. >>=20 >> 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 =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r >>=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-lisp-type-iana-03.txt >> Reviewer: Geoff Huston Review >> Date: 28 November 2016 >> IETF LC End Date: not called >> Intended Status: Standards Track >>=20 >> Summary: >>=20 >> I have significant concerns about this document and recommend that = the >> Routing ADs discuss these issues further with the authors and the = IANA. >>=20 >> Comments: >>=20 >> Draft quality and readability. >>=20 >> The third paragraph of the Introduction is unclear. Given that LISP = itself >> is an experimental specification it is hard to understand the = distinction >> being made between the "experimentation purposes" and some other >> undescribed purpose which this reviewer can only conclude is also an >> experimentation purpose. I suggest re-thinking the intent of this >> paragraph and expressing it in simpler terms. >>=20 >> In section 2, the use of the normative "MUST" seems to be = inappropriate, >> particularly when a non-normative "must" ius used in section 4 in an >> identical context. >>=20 >> Major Issues: >>=20 >> It seems anomalous to me that a request to set up an IANA Registry = for an >> Experimental Protocol (RFC6830 is Experimental) is itself proposed to = be a >> Standards Track document. >>=20 >> Furthermore, the document states that additional values be assigned = via a >> Standards Action. Again, it appears anomalous to me that a = specification >> of a parameter value of an experimental protocol be described by a >> Standards Track action. >>=20 >> If RFC6830 is revised and is re-published as a Standards Track >> specification then these points are of course not relevant, but until = such >> a publication takes place, specifying an IANA parameter registry as a >> Standards Track action for an experimental protocol seems to me to be >> anomalous and should not proceed unless the IESG specifically agrees = with >> this approach. Alternatively RFC5226 could be further revised to >> explicitly describe the guidelines as they relate to Experimental >> Specifications (as distinct from experimental allocations within = Standards >> Track specifications), as this area appears to be unclear from my = reading >> of RFC5226. >>=20 >> However it is not for me to resolve this issue, nor is it up to the = draft >> authors, or the LISP working group, as far as I can tell. It is up = to the >> IESG and >> IANA to clarify this situation and allow IANA to be given clear = directions >> as to how to maintain parameter registries for experimental = specifications >> while they remain experiments. >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 28 22:23:41 2016 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 9A854127735; Mon, 28 Nov 2016 22:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLV7UUQc_J3t; Mon, 28 Nov 2016 22:23:37 -0800 (PST) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B59129563; Mon, 28 Nov 2016 22:23:36 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id E3E7440671; Tue, 29 Nov 2016 07:23:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 7F7841A006E; Tue, 29 Nov 2016 07:23:34 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0319.002; Tue, 29 Nov 2016 07:23:33 +0100 From: To: Geoff Huston Thread-Topic: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt Thread-Index: AQHSSajh01bAeatvw0+OeG+VNv4OX6DvfISg Date: Tue, 29 Nov 2016 06:23:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DB9827@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <787AE7BB302AE849A7480A190F8B933009DB9254@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <46143E39-F8EF-4E41-8893-C166FF5F8C5E@apnic.net> In-Reply-To: <46143E39-F8EF-4E41-8893-C166FF5F8C5E@apnic.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , "draft-ietf-lisp-type-iana.all@ietf.org" , Jon Hudson Subject: Re: [RTG-DIR] [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 06:23:40 -0000 SGkgR2VvZmYsDQoNCkFjdHVhbGx5LCB0aGUgcHJvcG9zZWQgc3RhdHVzIG9mIHRoaXMgZG9jdW1l bnQgd2FzIG5vdCB0cmlnZ2VyZWQgYnkgdGhlIGFjdGlvbiB0byBjcmVhdGUgdGhlIElBTkEgcmVn aXN0ZXIgKHRoYXQgY2FuIGJlIGRvbmUgdmlhIGFuIEluZm9ybWF0aW9uYWwgRG9jdW1lbnQpIGJ1 dCB3aXRoIHRoZSBhY3Rpb24gdG8gc3BlY2lmeSBhIHNoYXJlZCBMSVNQIGV4dGVuc2lvbiBtZXNz YWdlIGZvcm1hdCBhbmQgYXNzaWduIGEgY29kZXBvaW50ICgxNSkgZm9yIHRoYXQgcHVycG9zZS4g DQoNCkZXSVcsIHRoaXMgcG9pbnQgd2FzIG1lbnRpb25lZCBpbiB0aGUgd3JpdGUtdXA6DQoNCj09 DQogICAgICBUaGlzIGRvY3VtZW50IHRhcmdldHMgdG8gZm9sbG93IHN0YW5kYXJkIHRyYWNrLCBo ZW5jZSBhaW1pbmcgYXQgdGhlDQogICAgICBpbml0aWFsIGxldmVsIG9mICJQcm9wb3NlZCBTdGFu ZGFyZCIuDQogICAgICBJIHBlcnNvbmFsbHkgYXJndWVkIHdpdGggdGhlIGF1dGhvcnMgdGhhdCB1 c3VhbGx5IGRvY3VtZW50cw0KICAgICAgYWltaW5nIGF0IGNyZWF0aW5nIElBTkEgcmVnaXN0cmll cyBhcmUgImluZm9ybWF0aW9uYWwiLg0KICAgICAgWWV0LCBhcyB0aGUgYXV0aG9ycyByaWdodGZ1 bGx5IHBvaW50ZWQgb3V0LCB0aGUgZG9jdW1lbnQgYWxzbw0KICAgICAgcHJvcG9zZXMgdGhlIGV4 cGVyaW1lbnRhbCBwYWNrZXQgZm9ybWF0LCBmb3Igd2hpY2ggc3RhbmRhcmQNCiAgICAgIHRyYWNr IGxvb2tzIG1vcmUgYXBwcm9wcmlhdGUuDQogICAgICBBcyBhIHNoZXBoZXJkIG9mIHRoZSBkb2N1 bWVudCBJIGFtIGZpbmUga2VlcGluZyB0aGlzDQogICAgICBpbnRlbmRlZCBzdGF0dXMuIFRvIGJl IG5vdGVkIHRoYXQgdGhlIGRvY3VtZW50IHBhc3NlZCB0aGUNCiAgICAgIFdHTEMgd2l0aCB0aGUg c3VjaCBpbnRlbmRlZCBzdGF0dXMuIE5vIGNvbmNlcm4gd2FzIHJhaXNlZCBieSB0aGUNCiAgICAg IFdHIG1lbWJlcnMuIEFzIGZvciB0aGUgSUVURiBwcm9jZXNzLCBpdCBpcyB1cCB0byB0aGUNCiAg ICAgIElFU0cgdG8gYXNzaWduIHRoZSBtb3N0IGFwcHJvcHJpYXRlIHN0YXR1cyB0byB0aGlzIGRv Y3VtZW50Lg0KPT0NCg0KVGhhdCdzIHNhaWQsIEknbSBPSyB0byBjaGFuZ2UgdGhlIHN0YXR1cyB0 byBFWFAgaWYgdGhhdCBpcyBtb3JlIGFwcHJvcHJpYXRlLg0KDQpUaGFuayB5b3UuDQoNCkNoZWVy cywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBHZW9mZiBI dXN0b24gW21haWx0bzpnaWhAYXBuaWMubmV0XQ0KPiBFbnZvecOpwqA6IGx1bmRpIDI4IG5vdmVt YnJlIDIwMTYgMTk6NTQNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPiBDY8Kg OiBaaGFuZ3hpYW4gKFhpYW4pOyBydGctYWRzQGlldGYub3JnOyBydGctZGlyQGlldGYub3JnOyBs aXNwQGlldGYub3JnOw0KPiBqb25hdGhhbi5oYXJkd2lja0BtZXRhc3dpdGNoLmNvbTsgZHJhZnQt aWV0Zi1saXNwLXR5cGUtaWFuYS5hbGxAaWV0Zi5vcmc7DQo+IEpvbiBIdWRzb24NCj4gT2JqZXTC oDogUmU6IFtsaXNwXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5hLTAz LnR4dA0KPiANCj4gWW91IGFwcGVhciB0byBoYXZlIG1pc3VuZGVyc3Rvb2QgbWUgLSBpdHMgX25v dF8gdGhhdCB0aGlzIGRyYWZ0IHNlZWtzIHRvDQo+IGNyZWF0ZSBhbg0KPiBJQU5BIHJlZ2lzdHJ5 IGZvciBhbiBleHBlcmltZW50YWwgc3BlY2lmaWNhdGlvbiB0aGF0IEkgZm91bmQgdG8gYmUNCj4g YW5vbWFsb3VzLiBXaGF0DQo+IEkgZm91bmQgYW5vbWFsb3VzIHdhcyB0aGF0IHRoZSBkb2N1bWVu dCBwcm9wb3Npbmcgc3VjaCBhbiBhY3Rpb24gd2FzDQo+IGl0c2VsZiBwcm9wb3NlZA0KPiB0byBi ZSBhIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudC4NCj4gDQo+IENsZWFyIG5vdz8NCj4gDQo+IHRo YW5rcywNCj4gDQo+ICAgR2VvZmYNCj4gDQo+IA0KPiANCj4gPiBPbiAyOSBOb3YuIDIwMTYsIGF0 IDEyOjQzIGFtLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgR29lZmYsDQo+ID4NCj4gPiBJ IGhhdmUgb25lIGNvbW1lbnQgYWJvdXQgdGhpcyBwYXJ0IG9mIHlvdXIgcmV2aWV3Og0KPiA+DQo+ ID4+IEl0IHNlZW1zIGFub21hbG91cyB0byBtZSB0aGF0IGEgcmVxdWVzdCB0byBzZXQgdXAgYW4g SUFOQSBSZWdpc3RyeSBmb3INCj4gYW4NCj4gPj4gRXhwZXJpbWVudGFsIFByb3RvY29sIChSRkM2 ODMwIGlzIEV4cGVyaW1lbnRhbCkgaXMgaXRzZWxmIHByb3Bvc2VkIHRvDQo+IGJlIGENCj4gPj4g U3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50Lg0KPiA+DQo+ID4gRldJVywgSSdtIGF3YXJlIG9mIGFu IElBTkEgcmVnaXN0cnkgZm9yIGFuIGV4cGVyaW1lbnRhbCBwcm90b2NvbCB0aGF0DQo+IHlvdSBj YW4gY2hlY2sgaGVyZToNCj4gPiBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3RjcC1w YXJhbWV0ZXJzL3RjcC0NCj4gcGFyYW1ldGVycy54aHRtbCNtcHRjcC1vcHRpb24tc3VidHlwZXMN Cj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gPj4gRGUgOiBsaXNwIFttYWlsdG86bGlzcC1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIEdlb2ZmIEh1c3Rvbg0KPiA+PiBFbnZvecOpIDogbHVuZGkgMjggbm92ZW1i cmUgMjAxNiAwNDowNA0KPiA+PiDDgCA6IFpoYW5neGlhbiAoWGlhbik7IHJ0Zy1hZHNAaWV0Zi5v cmcNCj4gPj4gQ2MgOiBydGctZGlyQGlldGYub3JnOyBsaXNwQGlldGYub3JnOyBqb25hdGhhbi5o YXJkd2lja0BtZXRhc3dpdGNoLmNvbTsNCj4gPj4gZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS5h bGxAaWV0Zi5vcmc7IEpvbiBIdWRzb24NCj4gPj4gT2JqZXQgOiBbbGlzcF0gUnRnRGlyIHJldmll dzogZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wMy50eHQNCj4gPj4NCj4gPj4gSGVsbG8sDQo+ ID4+DQo+ID4+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzDQo+IGRyYWZ0Lg0KPiA+Pg0KPiA+PiBUaGUgUm91dGluZyBEaXJl Y3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+ ID4+IGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyBy ZXZpZXcsIGFuZA0KPiBzb21ldGltZXMNCj4gPj4gb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVy cG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZQ0KPiB0bw0KPiA+PiB0 aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERp cmVjdG9yYXRlLA0KPiA+PiBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4gPj4NCj4gPj4gQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsDQo+IGl0 DQo+ID4+IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcg d2l0aCBhbnkgb3RoZXIgSUVURg0KPiBMYXN0DQo+ID4+IENhbGwgY29tbWVudHMgdGhhdCB5b3Ug cmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaA0KPiA+PiBkaXNjdXNz aW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4gPj4NCj4gPj4gRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtbGlzcC10eXBlLWlhbmEtMDMudHh0DQo+ID4+IFJldmlld2VyOiBHZW9mZiBIdXN0b24g UmV2aWV3DQo+ID4+IERhdGU6IDI4IE5vdmVtYmVyIDIwMTYNCj4gPj4gSUVURiBMQyBFbmQgRGF0 ZTogbm90IGNhbGxlZA0KPiA+PiBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPiA+ Pg0KPiA+PiBTdW1tYXJ5Og0KPiA+Pg0KPiA+PiBJIGhhdmUgc2lnbmlmaWNhbnQgY29uY2VybnMg YWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVjb21tZW5kIHRoYXQgdGhlDQo+ID4+IFJvdXRpbmcg QURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycyBhbmQgdGhl IElBTkEuDQo+ID4+DQo+ID4+IENvbW1lbnRzOg0KPiA+Pg0KPiA+PiBEcmFmdCBxdWFsaXR5IGFu ZCByZWFkYWJpbGl0eS4NCj4gPj4NCj4gPj4gVGhlIHRoaXJkIHBhcmFncmFwaCBvZiB0aGUgSW50 cm9kdWN0aW9uIGlzIHVuY2xlYXIuIEdpdmVuIHRoYXQgTElTUA0KPiBpdHNlbGYNCj4gPj4gaXMg YW4gZXhwZXJpbWVudGFsIHNwZWNpZmljYXRpb24gaXQgaXMgaGFyZCB0byB1bmRlcnN0YW5kIHRo ZQ0KPiBkaXN0aW5jdGlvbg0KPiA+PiBiZWluZyBtYWRlIGJldHdlZW4gdGhlICJleHBlcmltZW50 YXRpb24gcHVycG9zZXMiIGFuZCBzb21lIG90aGVyDQo+ID4+IHVuZGVzY3JpYmVkIHB1cnBvc2Ug d2hpY2ggdGhpcyByZXZpZXdlciBjYW4gb25seSBjb25jbHVkZSBpcyBhbHNvIGFuDQo+ID4+IGV4 cGVyaW1lbnRhdGlvbiBwdXJwb3NlLiBJIHN1Z2dlc3QgcmUtdGhpbmtpbmcgdGhlIGludGVudCBv ZiB0aGlzDQo+ID4+IHBhcmFncmFwaCBhbmQgZXhwcmVzc2luZyBpdCBpbiBzaW1wbGVyIHRlcm1z Lg0KPiA+Pg0KPiA+PiBJbiBzZWN0aW9uIDIsIHRoZSB1c2Ugb2YgdGhlIG5vcm1hdGl2ZSAiTVVT VCIgc2VlbXMgdG8gYmUNCj4gaW5hcHByb3ByaWF0ZSwNCj4gPj4gcGFydGljdWxhcmx5IHdoZW4g YSBub24tbm9ybWF0aXZlICJtdXN0IiBpdXMgdXNlZCBpbiBzZWN0aW9uIDQgaW4gYW4NCj4gPj4g aWRlbnRpY2FsIGNvbnRleHQuDQo+ID4+DQo+ID4+IE1ham9yIElzc3VlczoNCj4gPj4NCj4gPj4g SXQgc2VlbXMgYW5vbWFsb3VzIHRvIG1lIHRoYXQgYSByZXF1ZXN0IHRvIHNldCB1cCBhbiBJQU5B IFJlZ2lzdHJ5IGZvcg0KPiBhbg0KPiA+PiBFeHBlcmltZW50YWwgUHJvdG9jb2wgKFJGQzY4MzAg aXMgRXhwZXJpbWVudGFsKSBpcyBpdHNlbGYgcHJvcG9zZWQgdG8NCj4gYmUgYQ0KPiA+PiBTdGFu ZGFyZHMgVHJhY2sgZG9jdW1lbnQuDQo+ID4+DQo+ID4+IEZ1cnRoZXJtb3JlLCB0aGUgZG9jdW1l bnQgc3RhdGVzIHRoYXQgYWRkaXRpb25hbCB2YWx1ZXMgYmUgYXNzaWduZWQgdmlhDQo+IGENCj4g Pj4gU3RhbmRhcmRzIEFjdGlvbi4gQWdhaW4sIGl0IGFwcGVhcnMgYW5vbWFsb3VzIHRvIG1lIHRo YXQgYQ0KPiBzcGVjaWZpY2F0aW9uDQo+ID4+IG9mIGEgcGFyYW1ldGVyIHZhbHVlIG9mIGFuIGV4 cGVyaW1lbnRhbCBwcm90b2NvbCBiZSBkZXNjcmliZWQgYnkgYQ0KPiA+PiBTdGFuZGFyZHMgVHJh Y2sgYWN0aW9uLg0KPiA+Pg0KPiA+PiBJZiBSRkM2ODMwIGlzIHJldmlzZWQgYW5kIGlzIHJlLXB1 Ymxpc2hlZCBhcyBhIFN0YW5kYXJkcyBUcmFjaw0KPiA+PiBzcGVjaWZpY2F0aW9uIHRoZW4gdGhl c2UgcG9pbnRzIGFyZSBvZiBjb3Vyc2Ugbm90IHJlbGV2YW50LCBidXQgdW50aWwNCj4gc3VjaA0K PiA+PiBhIHB1YmxpY2F0aW9uIHRha2VzIHBsYWNlLCBzcGVjaWZ5aW5nIGFuIElBTkEgcGFyYW1l dGVyIHJlZ2lzdHJ5IGFzIGENCj4gPj4gU3RhbmRhcmRzIFRyYWNrIGFjdGlvbiBmb3IgYW4gZXhw ZXJpbWVudGFsIHByb3RvY29sIHNlZW1zIHRvIG1lIHRvIGJlDQo+ID4+IGFub21hbG91cyBhbmQg c2hvdWxkIG5vdCBwcm9jZWVkIHVubGVzcyB0aGUgSUVTRyBzcGVjaWZpY2FsbHkgYWdyZWVzDQo+ IHdpdGgNCj4gPj4gdGhpcyBhcHByb2FjaC4gQWx0ZXJuYXRpdmVseSBSRkM1MjI2IGNvdWxkIGJl IGZ1cnRoZXIgcmV2aXNlZCB0bw0KPiA+PiBleHBsaWNpdGx5IGRlc2NyaWJlIHRoZSBndWlkZWxp bmVzIGFzIHRoZXkgcmVsYXRlIHRvIEV4cGVyaW1lbnRhbA0KPiA+PiBTcGVjaWZpY2F0aW9ucyAo YXMgZGlzdGluY3QgZnJvbSBleHBlcmltZW50YWwgYWxsb2NhdGlvbnMgd2l0aGluDQo+IFN0YW5k YXJkcw0KPiA+PiBUcmFjayBzcGVjaWZpY2F0aW9ucyksIGFzIHRoaXMgYXJlYSBhcHBlYXJzIHRv IGJlIHVuY2xlYXIgZnJvbSBteQ0KPiByZWFkaW5nDQo+ID4+IG9mIFJGQzUyMjYuDQo+ID4+DQo+ ID4+IEhvd2V2ZXIgaXQgaXMgbm90IGZvciBtZSB0byByZXNvbHZlIHRoaXMgaXNzdWUsIG5vciBp cyBpdCB1cCB0byB0aGUNCj4gZHJhZnQNCj4gPj4gYXV0aG9ycywgb3IgdGhlIExJU1Agd29ya2lu ZyBncm91cCwgYXMgZmFyIGFzIEkgY2FuIHRlbGwuICBJdCBpcyB1cCB0bw0KPiB0aGUNCj4gPj4g SUVTRyBhbmQNCj4gPj4gSUFOQSB0byBjbGFyaWZ5IHRoaXMgc2l0dWF0aW9uIGFuZCBhbGxvdyBJ QU5BIHRvIGJlIGdpdmVuIGNsZWFyDQo+IGRpcmVjdGlvbnMNCj4gPj4gYXMgdG8gaG93IHRvIG1h aW50YWluIHBhcmFtZXRlciByZWdpc3RyaWVzIGZvciBleHBlcmltZW50YWwNCj4gc3BlY2lmaWNh dGlvbnMNCj4gPj4gd2hpbGUgdGhleSByZW1haW4gZXhwZXJpbWVudHMuDQo+ID4+DQo+ID4+DQo+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ IGxpc3AgbWFpbGluZyBsaXN0DQo+ID4+IGxpc3BAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQoNCg== From nobody Wed Nov 30 03:54:43 2016 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 BA0D51296AE; Wed, 30 Nov 2016 03:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-tW9t-VIclA; Wed, 30 Nov 2016 03:54:38 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34223129B19; Wed, 30 Nov 2016 03:53:33 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B30E0C0242; Wed, 30 Nov 2016 12:53:31 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 84B6E12006B; Wed, 30 Nov 2016 12:53:31 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 12:53:31 +0100 From: To: Geoff Huston Thread-Topic: I-D Action: draft-ietf-lisp-type-iana-04.txt Thread-Index: AQHSSv76g7DUggpH9EuwZacnNO/QKaDxaIQQ Date: Wed, 30 Nov 2016 11:53:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> In-Reply-To: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , Jon Hudson Subject: Re: [RTG-DIR] I-D Action: draft-ietf-lisp-type-iana-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 11:54:43 -0000 Hi Goeff,=20 A new version of the draft is available online. The main changes are: * Change the status to Experimental * Rename the new message and relevant text in the draft to avoid the confus= ion that you raised in your review (LISP is itself is an experimental specification) We didn't change the normative "MUST" in Section 2 because that use is appr= opriate. The "must" you referred to in Section 4 will be removed from the t= ext once the IANA actions are completed.=20 A diff is provided below, fwiw.=20 Let's now if you are OK with this revision. Thank you for the review. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mercredi 30 novembre 2016 12:43 > =C0=A0: i-d-announce@ietf.org > Cc=A0: lisp@ietf.org > Objet=A0: I-D Action: draft-ietf-lisp-type-iana-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol of the > IETF. >=20 > Title : LISP Shared Extension Message & IANA Registry > for LISP Packet Type Allocations > Authors : Mohamed Boucadair > Christian Jacquenet > Filename : draft-ietf-lisp-type-iana-04.txt > Pages : 5 > Date : 2016-11-30 >=20 > Abstract: > This document defines a registry for LISP Packet Type allocations. > It also specifies a LISP shared message type for defining future > extensions and conducting experiments without consuming a LISP packet > type codepoint for each extension. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lisp-type-iana-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-type-iana-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 30 09:46:40 2016 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 CDBBE1295BD; Wed, 30 Nov 2016 09:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZgh6TrNsLCQ; Wed, 30 Nov 2016 09:46:33 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5533212950D; Wed, 30 Nov 2016 09:46:33 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 3so1935355pgd.0; Wed, 30 Nov 2016 09:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kQpU5J22I+WXWtKPkWtzOsNV0lGO6pFGSOIZ2PCDjLg=; b=ljv2kIOd8HGcMENX7nVZwgSff3rUinZVQx7zjYkOjkVGU0gTe4w1OngXb58pJkGLGE zi9mjQPmnN/WwKpRO1j/FdUIf05WY2H6C/MkU6vx3XWi6tBjv43DFGrhA00HiE81qUc2 x8ipdfY+UqxTffZgbX2ykys96kPvTK1svxyfCg/fcvVaIR/Gi7ifr1dtEoTHEcLwUaYW 14bCoKxZPfuYxARxM5k57hCYdUx0d9fZVmJwihPxv83qZUjCukli2D3bYvTxBww3qUx7 BIa6AocOf6t7DQ7hukUN44zvyH1sY4aKH+oxZZnm5o8E6TXpZ2yX5wQI/5DVNLvJt8wF /yOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kQpU5J22I+WXWtKPkWtzOsNV0lGO6pFGSOIZ2PCDjLg=; b=ck0g2G53A17Kxf99tS7eOoYzbpvleuYtd0I45waGxTftO+n0ZXmVQ7QJXJks2uoWnh OThrxjdscZX1oxQtE3q6zVn1xmmsxb/2yqN4k5awpul+x5uSVD8ovqbCSQNPMp0YN8lE lE4PwsX9pr0be5hjWoSuZTSaHkcLqJ/q7yY3EQz8Om2qVGRgQl3mZ87GZ5bzuFChblJN Y/ILkIpJbzeCpia36+A2MNupkagBBKRHeNRqnGalruSwMVvzLXzGDuh7NcmcQh1hdJYq F3z/KwttdeoJ0+PIEafa5r2kAeSMEczqrPI77aiDKsQxlWschRyXG8mVBr+OtWxDKf/D lzGg== X-Gm-Message-State: AKaTC01T0nAwp2P8DPoOC3qO1dV8sxkuKAaP3kPY9y5GnQxI1QRJ8yL96itl4k+ZXDu57g== X-Received: by 10.98.214.20 with SMTP id r20mr34708673pfg.59.1480527992806; Wed, 30 Nov 2016 09:46:32 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id b29sm86701605pgn.48.2016.11.30.09.46.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 09:46:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 30 Nov 2016 09:46:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , Geoff Huston , Jon Hudson Subject: Re: [RTG-DIR] [lisp] I-D Action: draft-ietf-lisp-type-iana-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 17:46:35 -0000 > We didn't change the normative "MUST" in Section 2 because that use is = appropriate. The "must" you referred to in Section 4 will be removed = from the text once the IANA actions are completed.=20 You may want to reference 6830bis and 6833bis documents that will be = standards track. They are individual submissions right now. But the = deadline for objections of making these drafts working group drafts is = this week I think. The draft names will be: draft-ietf-lisp-rfc6830bis-00 draft-ietf-lisp-rfc6833bis-00 Dino From nobody Wed Nov 30 10:28:04 2016 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 69507129698 for ; Wed, 30 Nov 2016 10:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.897 X-Spam-Level: X-Spam-Status: No, score=-107.897 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnuKMGGzQCKP for ; Wed, 30 Nov 2016 10:27:55 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6025129951 for ; Wed, 30 Nov 2016 10:27:53 -0800 (PST) Received: from NXMDA2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id b2b065ef-b72a-11e6-8fe1-005056b6f213; Thu, 01 Dec 2016 04:27:50 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Dec 2016 04:27:23 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 1 Dec 2016 05:27:47 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , Jon Hudson Subject: Re: [RTG-DIR] I-D Action: draft-ietf-lisp-type-iana-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 18:27:59 -0000 Thank you for this revision - this 04 draft appropriately addresses all = of the concerns raised in my review. kind regards, Geoff > On 30 Nov. 2016, at 10:53 pm, = wrote: >=20 > Hi Goeff,=20 >=20 > A new version of the draft is available online. The main changes are: > * Change the status to Experimental > * Rename the new message and relevant text in the draft to avoid the = confusion that you raised in your review (LISP is itself > is an experimental specification) >=20 > We didn't change the normative "MUST" in Section 2 because that use is = appropriate. The "must" you referred to in Section 4 will be removed = from the text once the IANA actions are completed.=20 >=20 > A diff is provided below, fwiw.=20 >=20 > Let's now if you are OK with this revision. >=20 > Thank you for the review. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part = de >> internet-drafts@ietf.org >> Envoy=C3=A9 : mercredi 30 novembre 2016 12:43 >> =C3=80 : i-d-announce@ietf.org >> Cc : lisp@ietf.org >> Objet : I-D Action: draft-ietf-lisp-type-iana-04.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Locator/ID Separation Protocol of = the >> IETF. >>=20 >> Title : LISP Shared Extension Message & IANA = Registry >> for LISP Packet Type Allocations >> Authors : Mohamed Boucadair >> Christian Jacquenet >> Filename : draft-ietf-lisp-type-iana-04.txt >> Pages : 5 >> Date : 2016-11-30 >>=20 >> Abstract: >> This document defines a registry for LISP Packet Type allocations. >> It also specifies a LISP shared message type for defining future >> extensions and conducting experiments without consuming a LISP = packet >> type codepoint for each extension. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-lisp-type-iana-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-type-iana-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 30 12:46:51 2016 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 589E3129A25; Wed, 30 Nov 2016 12:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoFOZRFqcM3Z; Wed, 30 Nov 2016 12:46:47 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1790612960F; Wed, 30 Nov 2016 12:43:55 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uAUKZ4Yf042586; Wed, 30 Nov 2016 15:43:47 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 272541auva-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Nov 2016 15:43:47 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAUKhirG020506; Wed, 30 Nov 2016 15:43:46 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAUKhTE2020282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Nov 2016 15:43:34 -0500 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 30 Nov 2016 20:43:10 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.222]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 15:43:10 -0500 From: "BRUNGARD, DEBORAH A" To: Geoff Huston , "mohamed.boucadair@orange.com" Thread-Topic: [lisp] I-D Action: draft-ietf-lisp-type-iana-04.txt Thread-Index: AQHSSv77YcVFjXVZdEm3sXNpU9RsUKDxvpAAgABuKYD//9G5IA== Date: Wed, 30 Nov 2016 20:43:09 +0000 Message-ID: References: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.205.208] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-30_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611300330 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "jonathan.hardwick@metaswitch.com" , Jon Hudson Subject: Re: [RTG-DIR] [lisp] I-D Action: draft-ietf-lisp-type-iana-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 20:46:50 -0000 VGhhbmtzIEdlb2ZmIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3IQ0KRGVib3JhaA0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGlzcCBbbWFpbHRvOmxpc3AtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdlb2ZmIEh1c3Rvbg0KPiBTZW50OiBXZWRuZXNkYXks IE5vdmVtYmVyIDMwLCAyMDE2IDE6MjggUE0NCj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IFpoYW5neGlhbiAoWGlhbikgPHpoYW5nLnhp YW5AaHVhd2VpLmNvbT47DQo+IGxpc3BAaWV0Zi5vcmc7IHJ0Zy1hZHNAaWV0Zi5vcmc7IGpvbmF0 aGFuLmhhcmR3aWNrQG1ldGFzd2l0Y2guY29tOyBKb24NCj4gSHVkc29uIDxqb24uaHVkc29uQGdt YWlsLmNvbT4NCj4gU3ViamVjdDogUmU6IFtsaXNwXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxp c3AtdHlwZS1pYW5hLTA0LnR4dA0KPiANCj4gVGhhbmsgeW91IGZvciB0aGlzIHJldmlzaW9uIC0g dGhpcyAwNCBkcmFmdCBhcHByb3ByaWF0ZWx5IGFkZHJlc3NlcyBhbGwgb2YgdGhlDQo+IGNvbmNl cm5zIHJhaXNlZCBpbiBteSByZXZpZXcuDQo+IA0KPiBraW5kIHJlZ2FyZHMsDQo+IA0KPiAgICAg R2VvZmYNCj4gDQo+IA0KPiANCj4gPiBPbiAzMCBOb3YuIDIwMTYsIGF0IDEwOjUzIHBtLCA8bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgR29lZmYsDQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9m IHRoZSBkcmFmdCBpcyBhdmFpbGFibGUgb25saW5lLiBUaGUgbWFpbiBjaGFuZ2VzIGFyZToNCj4g PiAqIENoYW5nZSB0aGUgc3RhdHVzIHRvIEV4cGVyaW1lbnRhbA0KPiA+ICogUmVuYW1lIHRoZSBu ZXcgbWVzc2FnZSBhbmQgcmVsZXZhbnQgdGV4dCBpbiB0aGUgZHJhZnQgdG8gYXZvaWQgdGhlDQo+ IGNvbmZ1c2lvbiB0aGF0IHlvdSByYWlzZWQgaW4geW91ciByZXZpZXcgKExJU1AgaXMgaXRzZWxm DQo+ID4gaXMgYW4gZXhwZXJpbWVudGFsIHNwZWNpZmljYXRpb24pDQo+ID4NCj4gPiBXZSBkaWRu J3QgY2hhbmdlIHRoZSBub3JtYXRpdmUgIk1VU1QiIGluIFNlY3Rpb24gMiBiZWNhdXNlIHRoYXQg dXNlIGlzDQo+IGFwcHJvcHJpYXRlLiBUaGUgIm11c3QiIHlvdSByZWZlcnJlZCB0byBpbiBTZWN0 aW9uIDQgd2lsbCBiZSByZW1vdmVkIGZyb20gdGhlDQo+IHRleHQgb25jZSB0aGUgSUFOQSBhY3Rp b25zIGFyZSBjb21wbGV0ZWQuDQo+ID4NCj4gPiBBIGRpZmYgaXMgcHJvdmlkZWQgYmVsb3csIGZ3 aXcuDQo+ID4NCj4gPiBMZXQncyBub3cgaWYgeW91IGFyZSBPSyB3aXRoIHRoaXMgcmV2aXNpb24u DQo+ID4NCj4gPiBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERlIDog SS1ELUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUNCj4gPj4gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+IEVudm95w6kgOiBt ZXJjcmVkaSAzMCBub3ZlbWJyZSAyMDE2IDEyOjQzDQo+ID4+IMOAIDogaS1kLWFubm91bmNlQGll dGYub3JnDQo+ID4+IENjIDogbGlzcEBpZXRmLm9yZw0KPiA+PiBPYmpldCA6IEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmEtMDQudHh0DQo+ID4+DQo+ID4+DQo+ID4+IEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cw0KPiA+PiBkaXJlY3Rvcmllcy4NCj4gPj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIG9mIHRoZQ0KPiA+PiBJRVRGLg0K PiA+Pg0KPiA+PiAgICAgICAgVGl0bGUgICAgICAgICAgIDogTElTUCBTaGFyZWQgRXh0ZW5zaW9u IE1lc3NhZ2UgJiBJQU5BIFJlZ2lzdHJ5DQo+ID4+IGZvciBMSVNQIFBhY2tldCBUeXBlIEFsbG9j YXRpb25zDQo+ID4+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0K PiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KPiA+PiAJ RmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wNC50eHQNCj4gPj4g CVBhZ2VzICAgICAgICAgICA6IDUNCj4gPj4gCURhdGUgICAgICAgICAgICA6IDIwMTYtMTEtMzAN Cj4gPj4NCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgcmVn aXN0cnkgZm9yIExJU1AgUGFja2V0IFR5cGUgYWxsb2NhdGlvbnMuDQo+ID4+ICAgSXQgYWxzbyBz cGVjaWZpZXMgYSBMSVNQIHNoYXJlZCBtZXNzYWdlIHR5cGUgZm9yIGRlZmluaW5nIGZ1dHVyZQ0K PiA+PiAgIGV4dGVuc2lvbnMgYW5kIGNvbmR1Y3RpbmcgZXhwZXJpbWVudHMgd2l0aG91dCBjb25z dW1pbmcgYSBMSVNQIHBhY2tldA0KPiA+PiAgIHR5cGUgY29kZXBvaW50IGZvciBlYWNoIGV4dGVu c2lvbi4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmEvDQo+ID4+DQo+ID4+IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiA+PiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wNA0KPiA+Pg0KPiA+PiBBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5hLTA0 DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+IHN1Ym1pc3Npb24NCj4gPj4gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4gPj4NCj4gPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KPiA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+ID4+IEktRC1Bbm5vdW5jZUBp ZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1h bm5vdW5jZQ0KPiA+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbA0KPiA+PiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93 LXNpdGVzLnR4dA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbGlzcCBtYWlsaW5nIGxpc3QNCj4gbGlzcEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCg== From nobody Wed Nov 30 15:45:39 2016 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 44EFE129BCF for ; Wed, 30 Nov 2016 15:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WImDOeQWyuop for ; Wed, 30 Nov 2016 15:45:34 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7CA212945F for ; Wed, 30 Nov 2016 15:45:34 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id n6so204899059qtd.1 for ; Wed, 30 Nov 2016 15:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cTmrwXLAignZbBF5YxcbL0AkajWmQBQtP5ROizk5MVM=; b=h5EozvAuSZuLbEJzEoMtYb7zpBdqRZxfhw6l7QKDet4oU9IJDKGmJWnvh5UsYzagsc 7QMFep1lsOACQE0xyayyXRNoL0XTRMnTOv+IB2WgxKee5gkhlALikY4ri5HdTYFDOMYP Eoie56QxS/8ATrl8er6kVvJAKzI784LPtZRnBWx/wlOqy+/7Cb6jmGqK0UZXxWWvgRw4 bc4Thp3Pep5CyFfmPTwLk5r83N+ONhrEP8LtvqTRlkSfL7OsOwke4nb0HhCfPVVUE+ow QJ92OcOrymMIVs9uwzAIz1ePUk7lQPpvua7Fz/hDGKYmb7hQgFsF6yMOR3al5KxGgM62 LPKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=cTmrwXLAignZbBF5YxcbL0AkajWmQBQtP5ROizk5MVM=; b=VK14oe870W8GoxADGlvNufzk0WdfmpWk+APM/1i9hIBCvW1D1+Z5hekDxOEAzq1WM3 g4v1uE1tCHwkdCDawaxYf4Vx2syrEwwbQX1LGm/k6+mB/e2GqsCZhX+PYPrA/9Bmu8qi kpAE0/AQfiQho+YaxBKNrQN3QLBvX92U0CQzGCRy5zltl5dLUqZGdfLkJLfp4njWm1rG Ev/djVqBVDdO7n+LFvye0u/4bM24H9F1hekKzmG+uSGmFetA43cynJUXmgZMFurjoV3S l9b8HgAFF5F4D8SRqyHNwl2Akc1ZhHfOKSqOGO3wDq2h5w9/fUhT9AG+pRamlNzt1uAY a3kA== X-Gm-Message-State: AKaTC000kO7xAyWugbYUtHPc3t9v9o++GQkcqnBjzSIFxln7LrXevzGh9c+xbA3uxfJ9004or+/bKWuHKU2eCQ== X-Received: by 10.237.35.181 with SMTP id j50mr34886070qtc.138.1480549533510; Wed, 30 Nov 2016 15:45:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.45.14 with HTTP; Wed, 30 Nov 2016 15:45:32 -0800 (PST) In-Reply-To: References: From: Alia Atlas Date: Wed, 30 Nov 2016 18:45:32 -0500 Message-ID: To: "rtg-dir@ietf.org" Content-Type: multipart/alternative; boundary=001a11396f2e046f8c05428d4d5a Archived-At: Subject: [RTG-DIR] Fwd: Review tracking in the datatracker X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 23:45:37 -0000 --001a11396f2e046f8c05428d4d5a Content-Type: text/plain; charset=UTF-8 FYI ---------- Forwarded message ---------- From: Robert Sparks Date: Wed, Nov 30, 2016 at 6:43 PM Subject: Re: Review tracking in the datatracker To: wgchairs@ietf.org Oh - I meant to add - Jean Mahoney put together a page for genart reviewers that may be useful for everyone at RjS On 11/30/16 5:41 PM, Robert Sparks wrote: > Chairs - > > Today's datatracker release added directorate review tracking to the > datatracker (as described in RFC7735). > > You'll see some new buttons show up. In particular, there is a "request > review" button that will show up on your working group documents. Use it to > request Early reviews from different directorates. You do not need to (and > should not) use it to ask for last call or telechat reviews - the > directorate secretaries will see those automatically. > > You'll also see review results linked directly from a document's main page > now. Note that many older reviews will present a "cannot read file" error - > we're working on fixing that - for now, follow the "Posted At" link that > will appear on the review document's main page. > > You'll see more as the directorate secretaries use this tool to assign > reviews. > > If you have any questions, please don't hesitate to ask. > > RjS > > --001a11396f2e046f8c05428d4d5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI


---------- Forwarded message ----------
From: Robert Sparks <rjsparks@nostrum.com>
Date: Wed, Nov 30, 2016 a= t 6:43 PM
Subject: Re: Review tracking in the datatracker
To: wgchairs@ietf.org


Oh - I meant= to add - Jean Mahoney put together a page for genart reviewers that may be= useful for everyone at

<https://trac.ietf.org/trac/ge= n/wiki/DatatrackerReviewToolHowto>

RjS



On 11/30/16 5:41 PM, Robert Sparks wrote:
Chairs -

Today's datatracker release added directorate review tracking to the da= tatracker (as described in RFC7735).

You'll see some new buttons show up. In particular, there is a "re= quest review" button that will show up on your working group documents= . Use it to request Early reviews from different directorates. You do not n= eed to (and should not) use it to ask for last call or telechat reviews - t= he directorate secretaries will see those automatically.

You'll also see review results linked directly from a document's ma= in page now. Note that many older reviews will present a "cannot read = file" error - we're working on fixing that - for now, follow the &= quot;Posted At" link that will appear on the review document's mai= n page.

You'll see more as the directorate secretaries use this tool to assign = reviews.

If you have any questions, please don't hesitate to ask.

RjS



--001a11396f2e046f8c05428d4d5a--