From rps-admin@ietf.org Wed Sep 10 12:42:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07297 for ; Wed, 10 Sep 2003 12:42:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x82b-0003Dv-LW; Wed, 10 Sep 2003 12:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x207-0007e3-CB for rps@optimus.ietf.org; Wed, 10 Sep 2003 06:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24480; Wed, 10 Sep 2003 06:14:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x203-0002Uu-00; Wed, 10 Sep 2003 06:14:59 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19x202-0002UT-00; Wed, 10 Sep 2003 06:14:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8AAESq31328; Wed, 10 Sep 2003 13:14:28 +0300 From: Pekka Savola To: iesg@ietf.org cc: rpslng@ripe.net, In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 13:14:27 +0300 (EEST) On Tue, 26 Aug 2003, The IESG wrote: > The IESG has received a request from an individual submitter to consider > 'RPSLng' as a Proposed Standard. This document > has been reviewed in the IETF but is not the product of an IETF Working > Group. [...] > File(s) can be obtained via > http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt If I'd use the "sirs (or airs)" classification of this document review, I'd say: * This draft is on the right track but has open issues, described in the review. Below are my comments to the draft. Overall, I think the document is pretty good, and a very relevant piece of work; it's needed by IPv6 ops folks. However, there seem to be a number of (more or less) textual inaccuracies and confusion in the document, which should be settled prior to publication. I think there are the three most important issues here are: * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what? * issue 3) -- whether ipvX should imply only unicast or both unicast and multicast? * issue 5) and others-- whether the document needs to specify all the relevant modifications explicitly, or not. IMHO, Stds Track document should describe every change, not just say something like "other attributes are modified in a similar fashion" (or something to that effect) substantial ----------- 1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", or something like that -- if for no other reason than to have a forward references in the RFC index to this document? 2) one important aspect to consider is interaction with old specification, that is: Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below. ==> so, should one get information from both the RPSLng multiprotocol attributes and the old ones? What if they conflict? Maybe some words would be useful on how to effectively transition/co-exist with both RPSL and RPSLng? 3) I note that there is no way to specify "these attributes affect both multicast and unicast", you have to always include the both, in: The possible values for are: ipv4 ipv4.unicast (equivalent to ipv4) ipv4.multicast ipv6 ipv6.unicast (equivalent to ipv6) ipv6.multicast ==> is this intended? Is there a particular reason why we couldn't just assume that "ipv4" includes both unicast and multicast? Where multicast is deployed, it's typically mostly congruent with unicast infrastructure, and where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" implication? Or should there be a separate value which would imply the both? 4) it seems that ipv6_address dictionary attribute (though trivial) has not been defined: In order to support IPv6 addresses specified with the next-hop rp-attribute, a new predefined dictionary type entitled ipv6_address is added to the RPSL dictionary. ==> this should probably be something like: An IPv6 address is represented as [blah blah blah] 5) As the document is Standards Track (and not e.g. Informational, which would also be a possibility), I'm not sure whether it's appropriate to wave away some, possibly important, pieces of the specification, with like: 2.3.2 The expression is an extension of the RPSL expression [section 5.4 of RFC 2622 [1]], with the inclusion of the ability to specify IPv6 address prefixes in Address-Prefix sets. For the sake of brevity, we do not include the full definition of here and refer the reader to RFC 2622 [1]. and: 4.5 inet-rtr Class The "mp-peer:" attribute is defined below. The difference between this attribute and the "peer:" attribute is the inclusion of support for IPv6 addresses. 6) there seem to be a case or two where it is not clear whether including the discussion in this specification is appropriate (and just not implementation-specific issues, or issues relating to the user's RPSL user interface); in below, the last sentence seems a bit dubious: The evaluation of an is done by evaluating all of its components. Evaluation of peering-sets and filter-sets is constrained by the address family. Such constraints may result in a {NOT ANY} or invalid depending on implicit or explicit definitions of the address family in the set. In the latter case an error is returned. {NOT ANY} may issue a warning. 7) related to point 4), it may not be apparent what's the intent of the specification, unless done explicitly; for example: Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy: aut-num: AS2 mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} the mp-filter should be evaluated as {NOT ANY}. ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? Note that that's very valid for IPv6 too, except perhaps due to the way it's written (should be {::/0}). I.e., I think it's very important to specify the grammar for properly so that the IPv4 and IPv6 addresses can be distinguished properly in all cases. 8) related to point 5), it is not clear whether the document is intended to be include conclusive lists of class attributes or just modified ones; for example: 3. New route6 Class member-of list of optional, multi-valued aggr-bndry optional, single-valued aggr-mtd inbound or outbound optional, single-valued [] mnt-lower list of optional, multi-valued ==> note that there are multiple attributes which do not seem to be referred to in this document. Is the list in the document intended as a conclusive list of attributes or just examples? Based on that, one may have to decide whether to remove non-modified ones, or whether to ensure that everything is always present [where's route-set-name or as-expression, for example?] (and possibly separate new and classic attributes). ==> similar in section 5, at least. 9) there seem to be some mismatches or missing specification; for example, in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the like, but the only similar thing in the document so far as been "": mp-members list of ( optional, multi-valued or or or ) and: In RPSLng, these attributes are extended to the route6 and inet6num (described below) classes. Further, the syntax of the existing mnt-routes attribute is modified to allow the optional specification of IPv6 prefix range lists when present in inet6num, route6, and aut-num class objects. ==> it seems the document may be trying to take too many shortcuts by leaving the values undefined and to be intuitively filled in by the implementors. 10) remote-endpoint-address specifies some some encapsulations: indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. denotes the encapsulation used in the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing policies for these routers should be described in the appropriate classes (eg. aut-num). ==> I believe DVMRP is probably very much obsolete in this interdomain, RPSLng context and could be removed. ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already cover that, *assuming* that one looks at the and to figure out what it is. Including both in here seems redundant to me; but if that's the path, also include IPv6inIPv6 and IPv4inIPv6, please! 11) split the references to normative and informative; the first two are probably normative, and the last one informative. editorial --------- ==> the document requires Table of Contents, as it's more than 15 pages long. RPSLng draft-blunk-rpslng-01.txt ==> spell out RPSLng in the title. Abstract This memo presents a new set of simple extensions to the RPSL language enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. ==> similarly, spell out RPSL here. Blunk, et al. Expires January 23, 2004 [Page 1] Internet-Draft RPSLng July 2003 ==> I note that the document does not have page breaks (^L) , so it's more difficult to read and does not print correctly. This document proposes to extend RPSL according to the following goals and requirements: Provide RPSL extensibility in the dimension of address families. Specifically, to allow users to document routing policy for IPv6 and multicast. ==> add bullets, dashes, or whatever to the list of four goals/requirements. Clarity and non-ambiguity: RPSL information is used by humans in addition to software tools. ==> s/Clarity/Maintain clarity/ Address Family Identifier, , is a RPSL list of address families ==> s/a RPSL/an RPSL/ (everywhere where applicable) ? mp-import ::= [protocol ] [into ] ==> these should probably be protocol-1 and protocol-2, to be in line with the rest of the document conventions? The expression is an extension of the RPSL expression [section 5.4 of RFC 2622 [1]] s/[section 5.4 of RFC 2622 [1]]/(section 5.4 of RFC 2622 [1])/ (similar in a few other places) mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo except { afi ipv6.unicast,ipv4 from AS2 action pref = 2; accept AS226 except { afi ipv6.unicast from AS3 action pref = 3; accept {3FFE:FFFF::/35} } } ==> should probably use a some more bogus AS number in the example ==> should probably use the /32 prefix length in the example, the same in some exampler later on. Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy: ==> s/evaluation/the evaluation/ ==> s/that is/that is,/ to a particular address family using the traditional filtering mechanism in use in IRR systems today. ==> spell out IRR. mp-peer or optional, or multi-valued ==> in here, and many other places, one uses "ipv4_address" and the like. Note tha lower dash, not dash in the middle; in many other places it's "ipv4-address" and the like. Pick one approach and stick to it, please :-) In the aut-num class, the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. They keyword "ANY" is also allowed which means all more specifics. The default when no additional set items are specified is "ANY". ==> s/They/The/. ==> s/all more specifics/any route/? (why would keyword "ANY" refer to more specifics only? that would be highly confusing) The must be a valid two-letter ISO 3166 country code identifier. is a symbolic name for the specified IPv6 address space. ==> the country code specification is, at least, outside of the scope of this document, I guess :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Wed Sep 10 12:42:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07312 for ; Wed, 10 Sep 2003 12:42:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x82v-0003GC-8h for rps-archive@odin.ietf.org; Wed, 10 Sep 2003 12:42:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8AGgLaN012528 for rps-archive@odin.ietf.org; Wed, 10 Sep 2003 12:42:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x82v-0003Fz-2K for rps-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 12:42:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07269 for ; Wed, 10 Sep 2003 12:42:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x82t-0005Wn-00 for rps-web-archive@ietf.org; Wed, 10 Sep 2003 12:42:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x82t-0005Wj-00 for rps-web-archive@ietf.org; Wed, 10 Sep 2003 12:42:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x82b-0003Dv-LW; Wed, 10 Sep 2003 12:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x207-0007e3-CB for rps@optimus.ietf.org; Wed, 10 Sep 2003 06:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24480; Wed, 10 Sep 2003 06:14:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x203-0002Uu-00; Wed, 10 Sep 2003 06:14:59 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19x202-0002UT-00; Wed, 10 Sep 2003 06:14:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8AAESq31328; Wed, 10 Sep 2003 13:14:28 +0300 From: Pekka Savola To: iesg@ietf.org cc: rpslng@ripe.net, In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 13:14:27 +0300 (EEST) On Tue, 26 Aug 2003, The IESG wrote: > The IESG has received a request from an individual submitter to consider > 'RPSLng' as a Proposed Standard. This document > has been reviewed in the IETF but is not the product of an IETF Working > Group. [...] > File(s) can be obtained via > http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt If I'd use the "sirs (or airs)" classification of this document review, I'd say: * This draft is on the right track but has open issues, described in the review. Below are my comments to the draft. Overall, I think the document is pretty good, and a very relevant piece of work; it's needed by IPv6 ops folks. However, there seem to be a number of (more or less) textual inaccuracies and confusion in the document, which should be settled prior to publication. I think there are the three most important issues here are: * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what? * issue 3) -- whether ipvX should imply only unicast or both unicast and multicast? * issue 5) and others-- whether the document needs to specify all the relevant modifications explicitly, or not. IMHO, Stds Track document should describe every change, not just say something like "other attributes are modified in a similar fashion" (or something to that effect) substantial ----------- 1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", or something like that -- if for no other reason than to have a forward references in the RFC index to this document? 2) one important aspect to consider is interaction with old specification, that is: Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below. ==> so, should one get information from both the RPSLng multiprotocol attributes and the old ones? What if they conflict? Maybe some words would be useful on how to effectively transition/co-exist with both RPSL and RPSLng? 3) I note that there is no way to specify "these attributes affect both multicast and unicast", you have to always include the both, in: The possible values for are: ipv4 ipv4.unicast (equivalent to ipv4) ipv4.multicast ipv6 ipv6.unicast (equivalent to ipv6) ipv6.multicast ==> is this intended? Is there a particular reason why we couldn't just assume that "ipv4" includes both unicast and multicast? Where multicast is deployed, it's typically mostly congruent with unicast infrastructure, and where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" implication? Or should there be a separate value which would imply the both? 4) it seems that ipv6_address dictionary attribute (though trivial) has not been defined: In order to support IPv6 addresses specified with the next-hop rp-attribute, a new predefined dictionary type entitled ipv6_address is added to the RPSL dictionary. ==> this should probably be something like: An IPv6 address is represented as [blah blah blah] 5) As the document is Standards Track (and not e.g. Informational, which would also be a possibility), I'm not sure whether it's appropriate to wave away some, possibly important, pieces of the specification, with like: 2.3.2 The expression is an extension of the RPSL expression [section 5.4 of RFC 2622 [1]], with the inclusion of the ability to specify IPv6 address prefixes in Address-Prefix sets. For the sake of brevity, we do not include the full definition of here and refer the reader to RFC 2622 [1]. and: 4.5 inet-rtr Class The "mp-peer:" attribute is defined below. The difference between this attribute and the "peer:" attribute is the inclusion of support for IPv6 addresses. 6) there seem to be a case or two where it is not clear whether including the discussion in this specification is appropriate (and just not implementation-specific issues, or issues relating to the user's RPSL user interface); in below, the last sentence seems a bit dubious: The evaluation of an is done by evaluating all of its components. Evaluation of peering-sets and filter-sets is constrained by the address family. Such constraints may result in a {NOT ANY} or invalid depending on implicit or explicit definitions of the address family in the set. In the latter case an error is returned. {NOT ANY} may issue a warning. 7) related to point 4), it may not be apparent what's the intent of the specification, unless done explicitly; for example: Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy: aut-num: AS2 mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} the mp-filter should be evaluated as {NOT ANY}. ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? Note that that's very valid for IPv6 too, except perhaps due to the way it's written (should be {::/0}). I.e., I think it's very important to specify the grammar for properly so that the IPv4 and IPv6 addresses can be distinguished properly in all cases. 8) related to point 5), it is not clear whether the document is intended to be include conclusive lists of class attributes or just modified ones; for example: 3. New route6 Class member-of list of optional, multi-valued aggr-bndry optional, single-valued aggr-mtd inbound or outbound optional, single-valued [] mnt-lower list of optional, multi-valued ==> note that there are multiple attributes which do not seem to be referred to in this document. Is the list in the document intended as a conclusive list of attributes or just examples? Based on that, one may have to decide whether to remove non-modified ones, or whether to ensure that everything is always present [where's route-set-name or as-expression, for example?] (and possibly separate new and classic attributes). ==> similar in section 5, at least. 9) there seem to be some mismatches or missing specification; for example, in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the like, but the only similar thing in the document so far as been "": mp-members list of ( optional, multi-valued or or or ) and: In RPSLng, these attributes are extended to the route6 and inet6num (described below) classes. Further, the syntax of the existing mnt-routes attribute is modified to allow the optional specification of IPv6 prefix range lists when present in inet6num, route6, and aut-num class objects. ==> it seems the document may be trying to take too many shortcuts by leaving the values undefined and to be intuitively filled in by the implementors. 10) remote-endpoint-address specifies some some encapsulations: indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. denotes the encapsulation used in the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing policies for these routers should be described in the appropriate classes (eg. aut-num). ==> I believe DVMRP is probably very much obsolete in this interdomain, RPSLng context and could be removed. ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already cover that, *assuming* that one looks at the and to figure out what it is. Including both in here seems redundant to me; but if that's the path, also include IPv6inIPv6 and IPv4inIPv6, please! 11) split the references to normative and informative; the first two are probably normative, and the last one informative. editorial --------- ==> the document requires Table of Contents, as it's more than 15 pages long. RPSLng draft-blunk-rpslng-01.txt ==> spell out RPSLng in the title. Abstract This memo presents a new set of simple extensions to the RPSL language enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. ==> similarly, spell out RPSL here. Blunk, et al. Expires January 23, 2004 [Page 1] Internet-Draft RPSLng July 2003 ==> I note that the document does not have page breaks (^L) , so it's more difficult to read and does not print correctly. This document proposes to extend RPSL according to the following goals and requirements: Provide RPSL extensibility in the dimension of address families. Specifically, to allow users to document routing policy for IPv6 and multicast. ==> add bullets, dashes, or whatever to the list of four goals/requirements. Clarity and non-ambiguity: RPSL information is used by humans in addition to software tools. ==> s/Clarity/Maintain clarity/ Address Family Identifier, , is a RPSL list of address families ==> s/a RPSL/an RPSL/ (everywhere where applicable) ? mp-import ::= [protocol ] [into ] ==> these should probably be protocol-1 and protocol-2, to be in line with the rest of the document conventions? The expression is an extension of the RPSL expression [section 5.4 of RFC 2622 [1]] s/[section 5.4 of RFC 2622 [1]]/(section 5.4 of RFC 2622 [1])/ (similar in a few other places) mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo except { afi ipv6.unicast,ipv4 from AS2 action pref = 2; accept AS226 except { afi ipv6.unicast from AS3 action pref = 3; accept {3FFE:FFFF::/35} } } ==> should probably use a some more bogus AS number in the example ==> should probably use the /32 prefix length in the example, the same in some exampler later on. Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy: ==> s/evaluation/the evaluation/ ==> s/that is/that is,/ to a particular address family using the traditional filtering mechanism in use in IRR systems today. ==> spell out IRR. mp-peer or optional, or multi-valued ==> in here, and many other places, one uses "ipv4_address" and the like. Note tha lower dash, not dash in the middle; in many other places it's "ipv4-address" and the like. Pick one approach and stick to it, please :-) In the aut-num class, the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. They keyword "ANY" is also allowed which means all more specifics. The default when no additional set items are specified is "ANY". ==> s/They/The/. ==> s/all more specifics/any route/? (why would keyword "ANY" refer to more specifics only? that would be highly confusing) The must be a valid two-letter ISO 3166 country code identifier. is a symbolic name for the specified IPv6 address space. ==> the country code specification is, at least, outside of the scope of this document, I guess :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Wed Sep 10 20:44:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24770 for ; Wed, 10 Sep 2003 20:44:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xFZ3-0004mT-7Y; Wed, 10 Sep 2003 20:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xFP6-0003Tq-EU for rps@optimus.ietf.org; Wed, 10 Sep 2003 20:33:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24397; Wed, 10 Sep 2003 20:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xFOr-0006xA-00; Wed, 10 Sep 2003 20:33:29 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19xFOr-0006wx-00; Wed, 10 Sep 2003 20:33:29 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8B0XML1014485; Wed, 10 Sep 2003 20:33:23 -0400 Message-Id: <200309110033.h8B0XML1014485@mail.avici.com> To: Pekka Savola cc: iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Wed, 10 Sep 2003 13:14:27 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 20:33:25 -0400 In message , Pekka Savola writes: > On Tue, 26 Aug 2003, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > > 'RPSLng' as a Proposed Standard. This document > > has been reviewed in the IETF but is not the product of an IETF Working > > Group. > [...] > > File(s) can be obtained via > > http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt > > If I'd use the "sirs (or airs)" classification of this document review, > I'd say: > > * This draft is on the right track but has open issues, > described in the review. > > Below are my comments to the draft. Overall, I think the document is > pretty good, and a very relevant piece of work; it's needed by IPv6 ops > folks. Thanks for providing the comments. I'll offer some information that may clarify some of the points you brought up, but Larry is the author and is much closer to the implementation and deployment than I am. Larry can correct me if I'm inaccurate in any of my comments. First a bit on history, just as an FYI. RPSL has been in use by RIPE to manage the European routing registry for nearly a decade and its predicessor RIPE-181 before that. There are numerous other shared RPSL repositories such as the US RADB and quite a few providers that run their own private repository. See rfc2650 "Using RPSL in Practice" for details. The existing RPSL documents how IPv4 policy was described but the RAToolSet supported syntax for IPv6. At the time we had extensive operational experience with the IPv4 subset and none at all with the IPv6 subset. Larry Blunk is the current primary developer/maintainer, having taken over from the original author, Cengiz Alaettinoglu. The IPv6 syntax has evolved and is now in use. One of the reasons this document has seen so little comment is it describes something people have been using for quite some time and it works. > However, there seem to be a number of (more or less) textual inaccuracies > and confusion in the document, which should be settled prior to > publication. > > I think there are the three most important issues here are: > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > conflicting information about IPv4 unicast, then what? Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements. > * issue 3) -- whether ipvX should imply only unicast or both unicast and > multicast? Unicast and multicast are defined in separate statements. The document is clear on this. If you want both unicast and multicast you just specify ipvX,ipvX.multicast. The text is completely unambigous stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast (equivalent to ipv6)" under "The possible values for are:" stating "An is defined as a comma separated list of one or more afi values", showing where is used and multiple examples are given. > * issue 5) and others-- whether the document needs to specify all the > relevant modifications explicitly, or not. IMHO, Stds Track document > should describe every change, not just say something like "other > attributes are modified in a similar fashion" (or something to that > effect) There is no need to repeat lengthy syntax descriptions contained in the base RFC if a straightforward modification is being made. The example you gave points to text that is perfectly clear. The existing accepts IPv4 addresses. The allows either IPv4 or IPv6 addresses to be specified. Perhaps this statement could be worded differently, but the syntax definitely should not be repeated. The syntax definition in RPSL remains authoritative except the additions defined here and no definitions that are not being changed should be included. > substantial > ----------- > > 1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", > or > something like that -- if for no other reason than to have a forward > references in the RFC index to this document? This document extends RFC-1622. If it updated RFC-1622 it would mean that it represents a change to all usage of RFC-1622. > 2) one important aspect to consider is interaction with old specification, > that is: > > Keeping this in mind, the "import:", "export:", and "default:" > attributes implicitly specify IPv4 unicast policy and remain as > defined previously in RPSL, and new multi-protocol (prefixed with the > string "mp-") attributes are introduced. These will be described > below. > > ==> so, should one get information from both the RPSLng multiprotocol > attributes and the old ones? What if they conflict? Maybe some words would > be useful on how to effectively transition/co-exist with both RPSL and > RPSLng? See prior note. Not an issue. > 3) I note that there is no way to specify "these attributes affect both > multicast and unicast", you have to always include the both, in: > > The possible values for are: > > > ipv4 > ipv4.unicast (equivalent to ipv4) > ipv4.multicast > ipv6 > ipv6.unicast (equivalent to ipv6) > ipv6.multicast > > ==> is this intended? Is there a particular reason why we couldn't just > assume that "ipv4" includes both unicast and multicast? Where multicast is > deployed, it's typically mostly congruent with unicast infrastructure, and > where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" > implication? Or should there be a separate value which would imply the > both? Yes this is intended. See prior note. > 4) it seems that ipv6_address dictionary attribute (though trivial) has not > been defined: > > In order to support IPv6 addresses specified with the next-hop > rp-attribute, a new predefined dictionary type entitled ipv6_address > is added to the RPSL dictionary. > > ==> this should probably be something like: > > An IPv6 address is represented as [blah blah blah] Next-hop is part of the initial RPSL Dictionary defined in RFC1622 section 7.1 and is used to define the next hop of a static route. In order to support this ipv6_address is added. The dictionary type is not defined, just at the builtin dictionary type ipv4_address is not defined in RPSL. The format is assumed to be the same as ipv4-address. Integer is also not defined. RPSL does however give the format for ipv4-address. An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses. A similar entry should appear for ipv6-address in this draft. Though numerous examples are given, the syntax is not spelled out. > 5) As the document is Standards Track (and not e.g. Informational, which > would also be a possibility), I'm not sure whether it's appropriate to wave > away some, possibly important, pieces of the specification, with like: > > 2.3.2 > > The expression is an extension of the RPSL > expression [section 5.4 of RFC 2622 [1]], with the inclusion of the > ability to specify IPv6 address prefixes in Address-Prefix sets. For > the sake of brevity, we do not include the full definition of > here and refer the reader to RFC 2622 [1]. > > and: > > 4.5 inet-rtr Class > > The "mp-peer:" attribute is defined below. The difference between > this attribute and the "peer:" attribute is the inclusion of support > for IPv6 addresses. How hard is this to figure out. In RPSL peer is defined as: Each peer attribute, if present, specifies a protocol peering with another router. The value of a peer attribute has the following syntax: | | | ... Just substitute ipv6-address for ipv4-address. The above definition need not be repeated in the new draft with the trivial substitution. > 6) there seem to be a case or two where it is not clear whether including > the discussion in this specification is appropriate (and just not > implementation-specific issues, or issues relating to the user's RPSL user > interface); in below, the last sentence seems a bit dubious: > > The evaluation of an is done by evaluating all of > its components. Evaluation of peering-sets and filter-sets is > constrained by the address family. Such constraints may result in a > {NOT ANY} or invalid depending on implicit > or explicit definitions of the address family in the set. In the > latter case an error is returned. {NOT ANY} may issue a > warning. This just explains a situation in which an invalid can be specified or an expression can evaluate to {NOT ANY} . Removing the explanation results in: If an evaluates to an invalid then an error is returned. If an evaluates to {NOT ANY} a warning may be issued. I think the existing content with the clarifying text is much better but could stand a little rewording. > 7) related to point 4), it may not be apparent what's the intent of the > specification, unless done explicitly; for example: > > Conflicts with explicit or implicit declarations are resolved at > runtime, that is during evaluation of a policy expression. For > example, when evaluating the following import policy: > > > aut-num: AS2 > mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} > > > the mp-filter should be evaluated as {NOT ANY}. And according to the above text a warning may be issued. > ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? > Note that that's very valid for IPv6 too, except perhaps due to the way it's > written (should be {::/0}). I.e., I think it's very important to specify > the grammar for properly so that the IPv4 and IPv6 addresses can be > distinguished properly in all cases. This is why ipv6-address should be specified and 0/0 should then be distinguishable from ::/0 and there is then no ambiguity in the example you gave. Since the address format for IPv6 has been accepted for a long time it may have been overlooked. At least a reference should be made if the exact syntax is defined elsewhere. > 8) related to point 5), it is not clear whether the document is intended to > be include conclusive lists of class attributes or just modified ones; for > example: > 3. New route6 Class > member-of list of optional, multi-valued > aggr-bndry optional, single-valued > aggr-mtd inbound or outbound optional, single-valued > [] > mnt-lower list of optional, multi-valued > > ==> note that there are multiple attributes which do not seem to be referred > to in this document. Is the list in the document intended as a conclusive > list of attributes or just examples? Based on that, one may have to decide > whether to remove non-modified ones, or whether to ensure that everything is > always present [where's route-set-name or as-expression, for example?] > (and possibly separate new and classic attributes). That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 provides extensions to RFC-1622 and explicitly mentions "mnt-routes" and "mnt-lower" attributes. > ==> similar in section 5, at least. > > 9) there seem to be some mismatches or missing specification; for example, > in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the > like, but the only similar thing in the document so far as been > "": > > mp-members list of ( optional, multi-valued > or > or > or ) > > and: > > In RPSLng, these attributes are extended to the route6 and inet6num > (described below) classes. Further, the syntax of the existing > mnt-routes attribute is modified to allow the optional specification > of IPv6 prefix range lists when present in inet6num, route6, and > aut-num class objects. > > ==> it seems the document may be trying to take too many shortcuts by > leaving the values undefined and to be intuitively filled in by the > implementors. RPSL defined , , and , in consecutive entries under "RPSL Names, Reserved Words, and Representation". It should be sufficient to state that is the same as except that a is used in place of a and is the same as except that a is used in place of a . > 10) remote-endpoint-address specifies some some encapsulations: > > indicates the IPv4 or IPv6 address of the > remote endpoint of the tunnel. The address family must match that of > the local endpoint. denotes the encapsulation used in > the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing > policies for these routers should be described in the appropriate > classes (eg. aut-num). > > ==> I believe DVMRP is probably very much obsolete in this interdomain, > RPSLng context and could be removed. Whether used or not, DVMRP is supported by RPSL implementations and it does no harm to continue to mantion it until it is determined that there really is no use for DVMRP (ie: when the experiment is declared over). > ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already > cover that, *assuming* that one looks at the and > to figure out what it is. Including both in here seems > redundant to me; but if that's the path, also include IPv6inIPv6 and > IPv4inIPv6, please! Tunnels may be IPv4 in IPv4 due to incomplete native multicast deployment in the IPv4 world. If multicast were not widely deployed in IPv6, then IPv6inIPv6 might be needed. If there existed IPv4 tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is forseen. > 11) split the references to normative and informative; the first two are > probably normative, and the last one informative. > > > editorial > --------- > > ==> the document requires Table of Contents, as it's more than 15 pages > long. > > RPSLng > draft-blunk-rpslng-01.txt > > ==> spell out RPSLng in the title. > > Abstract > > > This memo presents a new set of simple extensions to the RPSL > language enabling the language to document routing policies for the > IPv6 and multicast address families currently used in the Internet. > > ==> similarly, spell out RPSL here. > > Blunk, et al. Expires January 23, 2004 [Page 1] > > > Internet-Draft RPSLng July 2003 > > ==> I note that the document does not have page breaks (^L) , so it's more > difficult to read and does not print correctly. > > This document proposes to extend RPSL according to the following > goals and requirements: > > > Provide RPSL extensibility in the dimension of address families. > Specifically, to allow users to document routing policy for IPv6 > and multicast. > > ==> add bullets, dashes, or whatever to the list of four goals/requirements. > > Clarity and non-ambiguity: RPSL information is used by humans in > addition to software tools. > > ==> s/Clarity/Maintain clarity/ > > Address Family Identifier, , is a RPSL list of address families > > ==> s/a RPSL/an RPSL/ (everywhere where applicable) ? > > mp-import ::= > [protocol ] [into ] > > ==> these should probably be protocol-1 and protocol-2, to be in line with > the rest of the document conventions? > > The expression is an extension of the RPSL > expression [section 5.4 of RFC 2622 [1]] > > s/[section 5.4 of RFC 2622 [1]]/(section 5.4 of RFC 2622 [1])/ (similar in a > few other places) > > mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo > except { afi ipv6.unicast,ipv4 > from AS2 action pref = 2; accept AS226 > except { afi ipv6.unicast > from AS3 action pref = 3; accept {3FFE:FFFF::/35} > } > } > > ==> should probably use a some more bogus AS number in the example > ==> should probably use the /32 prefix length in the example, the same in > some exampler later on. > > Conflicts with explicit or implicit declarations are resolved at > runtime, that is during evaluation of a policy expression. For > example, when evaluating the following import policy: > > ==> s/evaluation/the evaluation/ > ==> s/that is/that is,/ > > to a particular address family using the traditional filtering > mechanism in use in IRR systems today. > > ==> spell out IRR. > > mp-peer or optional, > or multi-valued > > ==> in here, and many other places, one uses "ipv4_address" and the like. > Note tha lower dash, not dash in the middle; in many other places it's > "ipv4-address" and the like. Pick one approach and stick to it, please :-) > > In the aut-num class, > the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. They keyword "ANY" is also allowed which means all more specifics. The > default when no additional set items are specified is "ANY". > > ==> s/They/The/. > ==> s/all more specifics/any route/? (why would keyword "ANY" refer to more > specifics only? that would be highly confusing) > > The must be a valid two-letter ISO 3166 country code > identifier. is a symbolic name for the specified IPv6 > address space. > > ==> the country code specification is, at least, outside of the scope of > this document, I guess :-) > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Thanks again. You did a very thorough read of the document. Some of the issues you brought up may have been misunderstandings on your part. You point out a few ommisions such as failure to explicitly defined the syntax for and failure to point out some analogous attributes such as where the definition is just a matter of s/ipv4/ipv6/, some text in need of clarity, and some needed editorial changes. Regards, Curtis ps - once again, Larry, or the folks at RIPE, please feel free to point out any errors I've made. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Wed Sep 10 20:44:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24785 for ; Wed, 10 Sep 2003 20:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xFZF-0004pB-1J for rps-archive@odin.ietf.org; Wed, 10 Sep 2003 20:44:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8B0iCmb018538 for rps-archive@odin.ietf.org; Wed, 10 Sep 2003 20:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xFZE-0004ou-TL for rps-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 20:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24733 for ; Wed, 10 Sep 2003 20:44:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xFZC-00008Y-00 for rps-web-archive@ietf.org; Wed, 10 Sep 2003 20:44:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xFZB-00008S-00 for rps-web-archive@ietf.org; Wed, 10 Sep 2003 20:44:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xFZ3-0004mT-7Y; Wed, 10 Sep 2003 20:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xFP6-0003Tq-EU for rps@optimus.ietf.org; Wed, 10 Sep 2003 20:33:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24397; Wed, 10 Sep 2003 20:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xFOr-0006xA-00; Wed, 10 Sep 2003 20:33:29 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19xFOr-0006wx-00; Wed, 10 Sep 2003 20:33:29 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8B0XML1014485; Wed, 10 Sep 2003 20:33:23 -0400 Message-Id: <200309110033.h8B0XML1014485@mail.avici.com> To: Pekka Savola cc: iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Wed, 10 Sep 2003 13:14:27 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 20:33:25 -0400 In message , Pekka Savola writes: > On Tue, 26 Aug 2003, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > > 'RPSLng' as a Proposed Standard. This document > > has been reviewed in the IETF but is not the product of an IETF Working > > Group. > [...] > > File(s) can be obtained via > > http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt > > If I'd use the "sirs (or airs)" classification of this document review, > I'd say: > > * This draft is on the right track but has open issues, > described in the review. > > Below are my comments to the draft. Overall, I think the document is > pretty good, and a very relevant piece of work; it's needed by IPv6 ops > folks. Thanks for providing the comments. I'll offer some information that may clarify some of the points you brought up, but Larry is the author and is much closer to the implementation and deployment than I am. Larry can correct me if I'm inaccurate in any of my comments. First a bit on history, just as an FYI. RPSL has been in use by RIPE to manage the European routing registry for nearly a decade and its predicessor RIPE-181 before that. There are numerous other shared RPSL repositories such as the US RADB and quite a few providers that run their own private repository. See rfc2650 "Using RPSL in Practice" for details. The existing RPSL documents how IPv4 policy was described but the RAToolSet supported syntax for IPv6. At the time we had extensive operational experience with the IPv4 subset and none at all with the IPv6 subset. Larry Blunk is the current primary developer/maintainer, having taken over from the original author, Cengiz Alaettinoglu. The IPv6 syntax has evolved and is now in use. One of the reasons this document has seen so little comment is it describes something people have been using for quite some time and it works. > However, there seem to be a number of (more or less) textual inaccuracies > and confusion in the document, which should be settled prior to > publication. > > I think there are the three most important issues here are: > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > conflicting information about IPv4 unicast, then what? Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements. > * issue 3) -- whether ipvX should imply only unicast or both unicast and > multicast? Unicast and multicast are defined in separate statements. The document is clear on this. If you want both unicast and multicast you just specify ipvX,ipvX.multicast. The text is completely unambigous stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast (equivalent to ipv6)" under "The possible values for are:" stating "An is defined as a comma separated list of one or more afi values", showing where is used and multiple examples are given. > * issue 5) and others-- whether the document needs to specify all the > relevant modifications explicitly, or not. IMHO, Stds Track document > should describe every change, not just say something like "other > attributes are modified in a similar fashion" (or something to that > effect) There is no need to repeat lengthy syntax descriptions contained in the base RFC if a straightforward modification is being made. The example you gave points to text that is perfectly clear. The existing accepts IPv4 addresses. The allows either IPv4 or IPv6 addresses to be specified. Perhaps this statement could be worded differently, but the syntax definitely should not be repeated. The syntax definition in RPSL remains authoritative except the additions defined here and no definitions that are not being changed should be included. > substantial > ----------- > > 1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", > or > something like that -- if for no other reason than to have a forward > references in the RFC index to this document? This document extends RFC-1622. If it updated RFC-1622 it would mean that it represents a change to all usage of RFC-1622. > 2) one important aspect to consider is interaction with old specification, > that is: > > Keeping this in mind, the "import:", "export:", and "default:" > attributes implicitly specify IPv4 unicast policy and remain as > defined previously in RPSL, and new multi-protocol (prefixed with the > string "mp-") attributes are introduced. These will be described > below. > > ==> so, should one get information from both the RPSLng multiprotocol > attributes and the old ones? What if they conflict? Maybe some words would > be useful on how to effectively transition/co-exist with both RPSL and > RPSLng? See prior note. Not an issue. > 3) I note that there is no way to specify "these attributes affect both > multicast and unicast", you have to always include the both, in: > > The possible values for are: > > > ipv4 > ipv4.unicast (equivalent to ipv4) > ipv4.multicast > ipv6 > ipv6.unicast (equivalent to ipv6) > ipv6.multicast > > ==> is this intended? Is there a particular reason why we couldn't just > assume that "ipv4" includes both unicast and multicast? Where multicast is > deployed, it's typically mostly congruent with unicast infrastructure, and > where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" > implication? Or should there be a separate value which would imply the > both? Yes this is intended. See prior note. > 4) it seems that ipv6_address dictionary attribute (though trivial) has not > been defined: > > In order to support IPv6 addresses specified with the next-hop > rp-attribute, a new predefined dictionary type entitled ipv6_address > is added to the RPSL dictionary. > > ==> this should probably be something like: > > An IPv6 address is represented as [blah blah blah] Next-hop is part of the initial RPSL Dictionary defined in RFC1622 section 7.1 and is used to define the next hop of a static route. In order to support this ipv6_address is added. The dictionary type is not defined, just at the builtin dictionary type ipv4_address is not defined in RPSL. The format is assumed to be the same as ipv4-address. Integer is also not defined. RPSL does however give the format for ipv4-address. An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses. A similar entry should appear for ipv6-address in this draft. Though numerous examples are given, the syntax is not spelled out. > 5) As the document is Standards Track (and not e.g. Informational, which > would also be a possibility), I'm not sure whether it's appropriate to wave > away some, possibly important, pieces of the specification, with like: > > 2.3.2 > > The expression is an extension of the RPSL > expression [section 5.4 of RFC 2622 [1]], with the inclusion of the > ability to specify IPv6 address prefixes in Address-Prefix sets. For > the sake of brevity, we do not include the full definition of > here and refer the reader to RFC 2622 [1]. > > and: > > 4.5 inet-rtr Class > > The "mp-peer:" attribute is defined below. The difference between > this attribute and the "peer:" attribute is the inclusion of support > for IPv6 addresses. How hard is this to figure out. In RPSL peer is defined as: Each peer attribute, if present, specifies a protocol peering with another router. The value of a peer attribute has the following syntax: | | | ... Just substitute ipv6-address for ipv4-address. The above definition need not be repeated in the new draft with the trivial substitution. > 6) there seem to be a case or two where it is not clear whether including > the discussion in this specification is appropriate (and just not > implementation-specific issues, or issues relating to the user's RPSL user > interface); in below, the last sentence seems a bit dubious: > > The evaluation of an is done by evaluating all of > its components. Evaluation of peering-sets and filter-sets is > constrained by the address family. Such constraints may result in a > {NOT ANY} or invalid depending on implicit > or explicit definitions of the address family in the set. In the > latter case an error is returned. {NOT ANY} may issue a > warning. This just explains a situation in which an invalid can be specified or an expression can evaluate to {NOT ANY} . Removing the explanation results in: If an evaluates to an invalid then an error is returned. If an evaluates to {NOT ANY} a warning may be issued. I think the existing content with the clarifying text is much better but could stand a little rewording. > 7) related to point 4), it may not be apparent what's the intent of the > specification, unless done explicitly; for example: > > Conflicts with explicit or implicit declarations are resolved at > runtime, that is during evaluation of a policy expression. For > example, when evaluating the following import policy: > > > aut-num: AS2 > mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} > > > the mp-filter should be evaluated as {NOT ANY}. And according to the above text a warning may be issued. > ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? > Note that that's very valid for IPv6 too, except perhaps due to the way it's > written (should be {::/0}). I.e., I think it's very important to specify > the grammar for properly so that the IPv4 and IPv6 addresses can be > distinguished properly in all cases. This is why ipv6-address should be specified and 0/0 should then be distinguishable from ::/0 and there is then no ambiguity in the example you gave. Since the address format for IPv6 has been accepted for a long time it may have been overlooked. At least a reference should be made if the exact syntax is defined elsewhere. > 8) related to point 5), it is not clear whether the document is intended to > be include conclusive lists of class attributes or just modified ones; for > example: > 3. New route6 Class > member-of list of optional, multi-valued > aggr-bndry optional, single-valued > aggr-mtd inbound or outbound optional, single-valued > [] > mnt-lower list of optional, multi-valued > > ==> note that there are multiple attributes which do not seem to be referred > to in this document. Is the list in the document intended as a conclusive > list of attributes or just examples? Based on that, one may have to decide > whether to remove non-modified ones, or whether to ensure that everything is > always present [where's route-set-name or as-expression, for example?] > (and possibly separate new and classic attributes). That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 provides extensions to RFC-1622 and explicitly mentions "mnt-routes" and "mnt-lower" attributes. > ==> similar in section 5, at least. > > 9) there seem to be some mismatches or missing specification; for example, > in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the > like, but the only similar thing in the document so far as been > "": > > mp-members list of ( optional, multi-valued > or > or > or ) > > and: > > In RPSLng, these attributes are extended to the route6 and inet6num > (described below) classes. Further, the syntax of the existing > mnt-routes attribute is modified to allow the optional specification > of IPv6 prefix range lists when present in inet6num, route6, and > aut-num class objects. > > ==> it seems the document may be trying to take too many shortcuts by > leaving the values undefined and to be intuitively filled in by the > implementors. RPSL defined , , and , in consecutive entries under "RPSL Names, Reserved Words, and Representation". It should be sufficient to state that is the same as except that a is used in place of a and is the same as except that a is used in place of a . > 10) remote-endpoint-address specifies some some encapsulations: > > indicates the IPv4 or IPv6 address of the > remote endpoint of the tunnel. The address family must match that of > the local endpoint. denotes the encapsulation used in > the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing > policies for these routers should be described in the appropriate > classes (eg. aut-num). > > ==> I believe DVMRP is probably very much obsolete in this interdomain, > RPSLng context and could be removed. Whether used or not, DVMRP is supported by RPSL implementations and it does no harm to continue to mantion it until it is determined that there really is no use for DVMRP (ie: when the experiment is declared over). > ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already > cover that, *assuming* that one looks at the and > to figure out what it is. Including both in here seems > redundant to me; but if that's the path, also include IPv6inIPv6 and > IPv4inIPv6, please! Tunnels may be IPv4 in IPv4 due to incomplete native multicast deployment in the IPv4 world. If multicast were not widely deployed in IPv6, then IPv6inIPv6 might be needed. If there existed IPv4 tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is forseen. > 11) split the references to normative and informative; the first two are > probably normative, and the last one informative. > > > editorial > --------- > > ==> the document requires Table of Contents, as it's more than 15 pages > long. > > RPSLng > draft-blunk-rpslng-01.txt > > ==> spell out RPSLng in the title. > > Abstract > > > This memo presents a new set of simple extensions to the RPSL > language enabling the language to document routing policies for the > IPv6 and multicast address families currently used in the Internet. > > ==> similarly, spell out RPSL here. > > Blunk, et al. Expires January 23, 2004 [Page 1] > > > Internet-Draft RPSLng July 2003 > > ==> I note that the document does not have page breaks (^L) , so it's more > difficult to read and does not print correctly. > > This document proposes to extend RPSL according to the following > goals and requirements: > > > Provide RPSL extensibility in the dimension of address families. > Specifically, to allow users to document routing policy for IPv6 > and multicast. > > ==> add bullets, dashes, or whatever to the list of four goals/requirements. > > Clarity and non-ambiguity: RPSL information is used by humans in > addition to software tools. > > ==> s/Clarity/Maintain clarity/ > > Address Family Identifier, , is a RPSL list of address families > > ==> s/a RPSL/an RPSL/ (everywhere where applicable) ? > > mp-import ::= > [protocol ] [into ] > > ==> these should probably be protocol-1 and protocol-2, to be in line with > the rest of the document conventions? > > The expression is an extension of the RPSL > expression [section 5.4 of RFC 2622 [1]] > > s/[section 5.4 of RFC 2622 [1]]/(section 5.4 of RFC 2622 [1])/ (similar in a > few other places) > > mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo > except { afi ipv6.unicast,ipv4 > from AS2 action pref = 2; accept AS226 > except { afi ipv6.unicast > from AS3 action pref = 3; accept {3FFE:FFFF::/35} > } > } > > ==> should probably use a some more bogus AS number in the example > ==> should probably use the /32 prefix length in the example, the same in > some exampler later on. > > Conflicts with explicit or implicit declarations are resolved at > runtime, that is during evaluation of a policy expression. For > example, when evaluating the following import policy: > > ==> s/evaluation/the evaluation/ > ==> s/that is/that is,/ > > to a particular address family using the traditional filtering > mechanism in use in IRR systems today. > > ==> spell out IRR. > > mp-peer or optional, > or multi-valued > > ==> in here, and many other places, one uses "ipv4_address" and the like. > Note tha lower dash, not dash in the middle; in many other places it's > "ipv4-address" and the like. Pick one approach and stick to it, please :-) > > In the aut-num class, > the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. They keyword "ANY" is also allowed which means all more specifics. The > default when no additional set items are specified is "ANY". > > ==> s/They/The/. > ==> s/all more specifics/any route/? (why would keyword "ANY" refer to more > specifics only? that would be highly confusing) > > The must be a valid two-letter ISO 3166 country code > identifier. is a symbolic name for the specified IPv6 > address space. > > ==> the country code specification is, at least, outside of the scope of > this document, I guess :-) > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Thanks again. You did a very thorough read of the document. Some of the issues you brought up may have been misunderstandings on your part. You point out a few ommisions such as failure to explicitly defined the syntax for and failure to point out some analogous attributes such as where the definition is just a matter of s/ipv4/ipv6/, some text in need of clarity, and some needed editorial changes. Regards, Curtis ps - once again, Larry, or the folks at RIPE, please feel free to point out any errors I've made. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Thu Sep 11 11:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27772 for ; Thu, 11 Sep 2003 11:34:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTSM-0003bB-2p; Thu, 11 Sep 2003 11:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xRzr-0007dl-St for rps@optimus.ietf.org; Thu, 11 Sep 2003 10:00:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23024; Thu, 11 Sep 2003 10:00:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xRzk-0001Yl-00; Thu, 11 Sep 2003 10:00:24 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19xRzZ-0001Y4-00; Thu, 11 Sep 2003 10:00:14 -0400 Received: from mrp.net (CPE-144-137-214-219.sa.bigpond.net.au [144.137.214.219]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8BDw79e014888 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 11 Sep 2003 23:28:13 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F607F6D.90209@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309110033.h8B0XML1014485@mail.avici.com> In-Reply-To: <200309110033.h8B0XML1014485@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Sep 2003 23:28:05 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Larry Blunk is the current primary developer/maintainer, having taken > over from the original author, Cengiz Alaettinoglu. The IPv6 syntax > has evolved and is now in use. One of the reasons this document has > seen so little comment is it describes something people have been > using for quite some time and it works. I don't know if that is true. I just lost interest in continuing to complain about the clunky syntax. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Thu Sep 11 11:34:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27799 for ; Thu, 11 Sep 2003 11:34:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTSX-0003dX-Ah for rps-archive@odin.ietf.org; Thu, 11 Sep 2003 11:34:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BFYDCV013971 for rps-archive@odin.ietf.org; Thu, 11 Sep 2003 11:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTSX-0003dF-3e for rps-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 11:34:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27723 for ; Thu, 11 Sep 2003 11:34:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xTSV-0002Py-00 for rps-web-archive@ietf.org; Thu, 11 Sep 2003 11:34:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xTSV-0002Pu-00 for rps-web-archive@ietf.org; Thu, 11 Sep 2003 11:34:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTSL-0003b3-Km; Thu, 11 Sep 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xNDw-0005hf-QY for rps@optimus.ietf.org; Thu, 11 Sep 2003 04:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15822; Thu, 11 Sep 2003 04:54:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xNDt-00079B-00; Thu, 11 Sep 2003 04:54:41 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19xNDs-00078z-00; Thu, 11 Sep 2003 04:54:40 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8B8rtY10791; Thu, 11 Sep 2003 11:53:55 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309110033.h8B0XML1014485@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Sep 2003 11:53:54 +0300 (EEST) Inline.. On Wed, 10 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola > writes: [...] > > However, there seem to be a number of (more or less) textual inaccuracies > > and confusion in the document, which should be settled prior to > > publication. > > > > I think there are the three most important issues here are: > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > conflicting information about IPv4 unicast, then what? > > Not an issue. If only IPv4 policy is specified by a given statement, > then either the old form or the new form can be used. Currently > multiple import, export, and default statements can appear. Their > effects are additive. The effect of adding mp-* statements specifying > ipv4 using the longer syntax is the same as adding more of the > existing import, export, and default statements. I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to cause inconsistencies in the data. > > * issue 3) -- whether ipvX should imply only unicast or both unicast and > > multicast? > > Unicast and multicast are defined in separate statements. The > document is clear on this. If you want both unicast and multicast you > just specify ipvX,ipvX.multicast. The text is completely unambigous > stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast > (equivalent to ipv6)" under "The possible values for are:" > stating "An is defined as a comma separated list of one or > more afi values", showing where is used and multiple > examples are given. Yes, I'm not saying the document is ambiguous; it's very clear on this. However, what I'm saying is that one perhaps should consider whether a different kind of definitions would be useful -- so that if you want to specify the topology for both unicast and multicast like, you could do it without "ipv4,ipv4.multicast" or "ipv6,ipv6.multicast". > > * issue 5) and others-- whether the document needs to specify all the > > relevant modifications explicitly, or not. IMHO, Stds Track document > > should describe every change, not just say something like "other > > attributes are modified in a similar fashion" (or something to that > > effect) > > There is no need to repeat lengthy syntax descriptions contained in > the base RFC if a straightforward modification is being made. The > example you gave points to text that is perfectly clear. The existing > accepts IPv4 addresses. The allows either IPv4 > or IPv6 addresses to be specified. Perhaps this statement could be > worded differently, but the syntax definitely should not be repeated. > The syntax definition in RPSL remains authoritative except the > additions defined here and no definitions that are not being changed > should be included. I'm not sure if all those modifications are completely straightfoward. > > substantial > > ----------- > > > > 1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", > > or > > something like that -- if for no other reason than to have a forward > > references in the RFC index to this document? > > This document extends RFC-1622. If it updated RFC-1622 it would mean > that it represents a change to all usage of RFC-1622. You mean 2622, not 1622, obviously. I don't see Updates like that at all. What you're describing would seem closer to "Obsoletes". This spec DOES make changes/additions to the existing sec, e.g. at rp-attribute next-hop. > > 2) one important aspect to consider is interaction with old specification, > > that is: > > > > Keeping this in mind, the "import:", "export:", and "default:" > > attributes implicitly specify IPv4 unicast policy and remain as > > defined previously in RPSL, and new multi-protocol (prefixed with the > > string "mp-") attributes are introduced. These will be described > > below. > > > > ==> so, should one get information from both the RPSLng multiprotocol > > attributes and the old ones? What if they conflict? Maybe some words would > > be useful on how to effectively transition/co-exist with both RPSL and > > RPSLng? > > See prior note. Not an issue. Not so sure on that. > > 3) I note that there is no way to specify "these attributes affect both > > multicast and unicast", you have to always include the both, in: > > > > The possible values for are: > > > > > > ipv4 > > ipv4.unicast (equivalent to ipv4) > > ipv4.multicast > > ipv6 > > ipv6.unicast (equivalent to ipv6) > > ipv6.multicast > > > > ==> is this intended? Is there a particular reason why we couldn't just > > assume that "ipv4" includes both unicast and multicast? Where multicast is > > deployed, it's typically mostly congruent with unicast infrastructure, and > > where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" > > implication? Or should there be a separate value which would imply the > > both? > > Yes this is intended. See prior note. I question the intent, but this is not a critical issue for me. It would seem more obvious that "ipv6" should refer to both unicast and multicast, as they're both ipv6. > > 4) it seems that ipv6_address dictionary attribute (though trivial) has not > > been defined: > > > > In order to support IPv6 addresses specified with the next-hop > > rp-attribute, a new predefined dictionary type entitled ipv6_address > > is added to the RPSL dictionary. > > > > ==> this should probably be something like: > > > > An IPv6 address is represented as [blah blah blah] > > Next-hop is part of the initial RPSL Dictionary defined in RFC1622 > section 7.1 and is used to define the next hop of a static route. In > order to support this ipv6_address is added. The dictionary type is > not defined, just at the builtin dictionary type ipv4_address is not > defined in RPSL. The format is assumed to be the same as > ipv4-address. Integer is also not defined. > > RPSL does however give the format for ipv4-address. > > An IPv4 address is represented as a sequence of four > integers in the range from 0 to 255 separated by the character > dot ".". For example, 128.9.128.5 represents a valid IPv4 > address. In the rest of this document, we may refer to IPv4 > addresses as IP addresses. > > A similar entry should appear for ipv6-address in this draft. Though > numerous examples are given, the syntax is not spelled out. Yep. > > 5) As the document is Standards Track (and not e.g. Informational, which > > would also be a possibility), I'm not sure whether it's appropriate to wave > > away some, possibly important, pieces of the specification, with like: > > > > 2.3.2 > > > > The expression is an extension of the RPSL > > expression [section 5.4 of RFC 2622 [1]], with the inclusion of the > > ability to specify IPv6 address prefixes in Address-Prefix sets. For > > the sake of brevity, we do not include the full definition of > > here and refer the reader to RFC 2622 [1]. > > > > and: > > > > 4.5 inet-rtr Class > > > > The "mp-peer:" attribute is defined below. The difference between > > this attribute and the "peer:" attribute is the inclusion of support > > for IPv6 addresses. > > How hard is this to figure out. In RPSL peer is defined as: Not so hard, but still not given. I'd prefer to spell things out. > Each peer attribute, if present, specifies a protocol peering with > another router. The value of a peer attribute has the following > syntax: > > > | > | > | > > ... > > Just substitute ipv6-address for ipv4-address. The above definition > need not be repeated in the new draft with the trivial substitution. Not the whole definition, maybe. > > 6) there seem to be a case or two where it is not clear whether including > > the discussion in this specification is appropriate (and just not > > implementation-specific issues, or issues relating to the user's RPSL user > > interface); in below, the last sentence seems a bit dubious: > > > > The evaluation of an is done by evaluating all of > > its components. Evaluation of peering-sets and filter-sets is > > constrained by the address family. Such constraints may result in a > > {NOT ANY} or invalid depending on implicit > > or explicit definitions of the address family in the set. In the > > latter case an error is returned. {NOT ANY} may issue a > > warning. > > This just explains a situation in which an invalid can be > specified or an expression can evaluate to {NOT ANY} . > Removing the explanation results in: > > If an evaluates to an invalid then > an error is returned. If an evaluates to {NOT > ANY} a warning may be issued. > > I think the existing content with the clarifying text is much better > but could stand a little rewording. Fine with me. > > 7) related to point 4), it may not be apparent what's the intent of the > > specification, unless done explicitly; for example: > > > > Conflicts with explicit or implicit declarations are resolved at > > runtime, that is during evaluation of a policy expression. For > > example, when evaluating the following import policy: > > > > aut-num: AS2 > > mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} > > > > the mp-filter should be evaluated as {NOT ANY}. > > And according to the above text a warning may be issued. > > > ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? > > Note that that's very valid for IPv6 too, except perhaps due to the way it's > > written (should be {::/0}). I.e., I think it's very important to specify > > the grammar for properly so that the IPv4 and IPv6 addresses can be > > distinguished properly in all cases. > > This is why ipv6-address should be specified and 0/0 should then be > distinguishable from ::/0 and there is then no ambiguity in the > example you gave. > > Since the address format for IPv6 has been accepted for a long time it > may have been overlooked. At least a reference should be made if the > exact syntax is defined elsewhere. right. > > 8) related to point 5), it is not clear whether the document is intended to > > be include conclusive lists of class attributes or just modified ones; for > > example: > > > 3. New route6 Class > > member-of list of optional, multi-valued > > aggr-bndry optional, single-valued > > aggr-mtd inbound or outbound optional, single-valued > > [] > > mnt-lower list of optional, multi-valued > > > > ==> note that there are multiple attributes which do not seem to be referred > > to in this document. Is the list in the document intended as a conclusive > > list of attributes or just examples? Based on that, one may have to decide > > whether to remove non-modified ones, or whether to ensure that everything is > > always present [where's route-set-name or as-expression, for example?] > > (and possibly separate new and classic attributes). > > That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. > RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 > provides extensions to RFC-1622 and explicitly mentions "mnt-routes" > and "mnt-lower" attributes. > > > ==> similar in section 5, at least. > > > > 9) there seem to be some mismatches or missing specification; for example, > > in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the > > like, but the only similar thing in the document so far as been > > "": > > > > mp-members list of ( optional, multi-valued > > or > > or > > or ) > > > > and: > > > > In RPSLng, these attributes are extended to the route6 and inet6num > > (described below) classes. Further, the syntax of the existing > > mnt-routes attribute is modified to allow the optional specification > > of IPv6 prefix range lists when present in inet6num, route6, and > > aut-num class objects. > > > > ==> it seems the document may be trying to take too many shortcuts by > > leaving the values undefined and to be intuitively filled in by the > > implementors. > > RPSL defined , , and > , in consecutive entries under "RPSL Names, > Reserved Words, and Representation". It should be sufficient to state > that is the same as except that > a is used in place of a and > is the same as > except that a is used in place of a > . maybe > > 10) remote-endpoint-address specifies some some encapsulations: > > > > indicates the IPv4 or IPv6 address of the > > remote endpoint of the tunnel. The address family must match that of > > the local endpoint. denotes the encapsulation used in > > the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing > > policies for these routers should be described in the appropriate > > classes (eg. aut-num). > > > > ==> I believe DVMRP is probably very much obsolete in this interdomain, > > RPSLng context and could be removed. > > Whether used or not, DVMRP is supported by RPSL implementations and it > does no harm to continue to mantion it until it is determined that > there really is no use for DVMRP (ie: when the experiment is declared > over). It seems irrelevant in this context, and potentially even harmful (building public interdomain DVMRP tunnels is not one of the brightest notions..). > > ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already > > cover that, *assuming* that one looks at the and > > to figure out what it is. Including both in here seems > > redundant to me; but if that's the path, also include IPv6inIPv6 and > > IPv4inIPv6, please! > > Tunnels may be IPv4 in IPv4 due to incomplete native multicast > deployment in the IPv4 world. Right. > If multicast were not widely deployed > in IPv6, then IPv6inIPv6 might be needed. That's the case today; our IPv6 multicast infra uses v6-over-v6 tunnels extensively. > If there existed IPv4 > tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is > forseen. You keep obsolete and dangerous entries like DVMRP, but fail to add those that are really needed now, and in the future? Doesn't seem like a good practice. But my point was not that; if you read it closely, my point was that you don't have to specify the inner and outer protocols of the tunnel, necessarily. Endpoint addresses and addresses assigned on the tunnel already yield that information! [snip to the end] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Thu Sep 11 12:21:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27800 for ; Thu, 11 Sep 2003 11:34:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTSX-0003dg-EZ for rps-archive@odin.ietf.org; Thu, 11 Sep 2003 11:34:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BFYDbi013984 for rps-archive@odin.ietf.org; Thu, 11 Sep 2003 11:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTSX-0003dK-6r for rps-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 11:34:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27725 for ; Thu, 11 Sep 2003 11:34:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xTSV-0002Q1-00 for rps-web-archive@ietf.org; Thu, 11 Sep 2003 11:34:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xTSV-0002Pv-00 for rps-web-archive@ietf.org; Thu, 11 Sep 2003 11:34:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTSM-0003bB-2p; Thu, 11 Sep 2003 11:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xRzr-0007dl-St for rps@optimus.ietf.org; Thu, 11 Sep 2003 10:00:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23024; Thu, 11 Sep 2003 10:00:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xRzk-0001Yl-00; Thu, 11 Sep 2003 10:00:24 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19xRzZ-0001Y4-00; Thu, 11 Sep 2003 10:00:14 -0400 Received: from mrp.net (CPE-144-137-214-219.sa.bigpond.net.au [144.137.214.219]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8BDw79e014888 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 11 Sep 2003 23:28:13 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F607F6D.90209@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309110033.h8B0XML1014485@mail.avici.com> In-Reply-To: <200309110033.h8B0XML1014485@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Sep 2003 23:28:05 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Larry Blunk is the current primary developer/maintainer, having taken > over from the original author, Cengiz Alaettinoglu. The IPv6 syntax > has evolved and is now in use. One of the reasons this document has > seen so little comment is it describes something people have been > using for quite some time and it works. I don't know if that is true. I just lost interest in continuing to complain about the clunky syntax. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Thu Sep 11 12:21:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27771 for ; Thu, 11 Sep 2003 11:34:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTSL-0003b3-Km; Thu, 11 Sep 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xNDw-0005hf-QY for rps@optimus.ietf.org; Thu, 11 Sep 2003 04:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15822; Thu, 11 Sep 2003 04:54:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xNDt-00079B-00; Thu, 11 Sep 2003 04:54:41 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19xNDs-00078z-00; Thu, 11 Sep 2003 04:54:40 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8B8rtY10791; Thu, 11 Sep 2003 11:53:55 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309110033.h8B0XML1014485@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Sep 2003 11:53:54 +0300 (EEST) Inline.. On Wed, 10 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola > writes: [...] > > However, there seem to be a number of (more or less) textual inaccuracies > > and confusion in the document, which should be settled prior to > > publication. > > > > I think there are the three most important issues here are: > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > conflicting information about IPv4 unicast, then what? > > Not an issue. If only IPv4 policy is specified by a given statement, > then either the old form or the new form can be used. Currently > multiple import, export, and default statements can appear. Their > effects are additive. The effect of adding mp-* statements specifying > ipv4 using the longer syntax is the same as adding more of the > existing import, export, and default statements. I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to cause inconsistencies in the data. > > * issue 3) -- whether ipvX should imply only unicast or both unicast and > > multicast? > > Unicast and multicast are defined in separate statements. The > document is clear on this. If you want both unicast and multicast you > just specify ipvX,ipvX.multicast. The text is completely unambigous > stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast > (equivalent to ipv6)" under "The possible values for are:" > stating "An is defined as a comma separated list of one or > more afi values", showing where is used and multiple > examples are given. Yes, I'm not saying the document is ambiguous; it's very clear on this. However, what I'm saying is that one perhaps should consider whether a different kind of definitions would be useful -- so that if you want to specify the topology for both unicast and multicast like, you could do it without "ipv4,ipv4.multicast" or "ipv6,ipv6.multicast". > > * issue 5) and others-- whether the document needs to specify all the > > relevant modifications explicitly, or not. IMHO, Stds Track document > > should describe every change, not just say something like "other > > attributes are modified in a similar fashion" (or something to that > > effect) > > There is no need to repeat lengthy syntax descriptions contained in > the base RFC if a straightforward modification is being made. The > example you gave points to text that is perfectly clear. The existing > accepts IPv4 addresses. The allows either IPv4 > or IPv6 addresses to be specified. Perhaps this statement could be > worded differently, but the syntax definitely should not be repeated. > The syntax definition in RPSL remains authoritative except the > additions defined here and no definitions that are not being changed > should be included. I'm not sure if all those modifications are completely straightfoward. > > substantial > > ----------- > > > > 1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", > > or > > something like that -- if for no other reason than to have a forward > > references in the RFC index to this document? > > This document extends RFC-1622. If it updated RFC-1622 it would mean > that it represents a change to all usage of RFC-1622. You mean 2622, not 1622, obviously. I don't see Updates like that at all. What you're describing would seem closer to "Obsoletes". This spec DOES make changes/additions to the existing sec, e.g. at rp-attribute next-hop. > > 2) one important aspect to consider is interaction with old specification, > > that is: > > > > Keeping this in mind, the "import:", "export:", and "default:" > > attributes implicitly specify IPv4 unicast policy and remain as > > defined previously in RPSL, and new multi-protocol (prefixed with the > > string "mp-") attributes are introduced. These will be described > > below. > > > > ==> so, should one get information from both the RPSLng multiprotocol > > attributes and the old ones? What if they conflict? Maybe some words would > > be useful on how to effectively transition/co-exist with both RPSL and > > RPSLng? > > See prior note. Not an issue. Not so sure on that. > > 3) I note that there is no way to specify "these attributes affect both > > multicast and unicast", you have to always include the both, in: > > > > The possible values for are: > > > > > > ipv4 > > ipv4.unicast (equivalent to ipv4) > > ipv4.multicast > > ipv6 > > ipv6.unicast (equivalent to ipv6) > > ipv6.multicast > > > > ==> is this intended? Is there a particular reason why we couldn't just > > assume that "ipv4" includes both unicast and multicast? Where multicast is > > deployed, it's typically mostly congruent with unicast infrastructure, and > > where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" > > implication? Or should there be a separate value which would imply the > > both? > > Yes this is intended. See prior note. I question the intent, but this is not a critical issue for me. It would seem more obvious that "ipv6" should refer to both unicast and multicast, as they're both ipv6. > > 4) it seems that ipv6_address dictionary attribute (though trivial) has not > > been defined: > > > > In order to support IPv6 addresses specified with the next-hop > > rp-attribute, a new predefined dictionary type entitled ipv6_address > > is added to the RPSL dictionary. > > > > ==> this should probably be something like: > > > > An IPv6 address is represented as [blah blah blah] > > Next-hop is part of the initial RPSL Dictionary defined in RFC1622 > section 7.1 and is used to define the next hop of a static route. In > order to support this ipv6_address is added. The dictionary type is > not defined, just at the builtin dictionary type ipv4_address is not > defined in RPSL. The format is assumed to be the same as > ipv4-address. Integer is also not defined. > > RPSL does however give the format for ipv4-address. > > An IPv4 address is represented as a sequence of four > integers in the range from 0 to 255 separated by the character > dot ".". For example, 128.9.128.5 represents a valid IPv4 > address. In the rest of this document, we may refer to IPv4 > addresses as IP addresses. > > A similar entry should appear for ipv6-address in this draft. Though > numerous examples are given, the syntax is not spelled out. Yep. > > 5) As the document is Standards Track (and not e.g. Informational, which > > would also be a possibility), I'm not sure whether it's appropriate to wave > > away some, possibly important, pieces of the specification, with like: > > > > 2.3.2 > > > > The expression is an extension of the RPSL > > expression [section 5.4 of RFC 2622 [1]], with the inclusion of the > > ability to specify IPv6 address prefixes in Address-Prefix sets. For > > the sake of brevity, we do not include the full definition of > > here and refer the reader to RFC 2622 [1]. > > > > and: > > > > 4.5 inet-rtr Class > > > > The "mp-peer:" attribute is defined below. The difference between > > this attribute and the "peer:" attribute is the inclusion of support > > for IPv6 addresses. > > How hard is this to figure out. In RPSL peer is defined as: Not so hard, but still not given. I'd prefer to spell things out. > Each peer attribute, if present, specifies a protocol peering with > another router. The value of a peer attribute has the following > syntax: > > > | > | > | > > ... > > Just substitute ipv6-address for ipv4-address. The above definition > need not be repeated in the new draft with the trivial substitution. Not the whole definition, maybe. > > 6) there seem to be a case or two where it is not clear whether including > > the discussion in this specification is appropriate (and just not > > implementation-specific issues, or issues relating to the user's RPSL user > > interface); in below, the last sentence seems a bit dubious: > > > > The evaluation of an is done by evaluating all of > > its components. Evaluation of peering-sets and filter-sets is > > constrained by the address family. Such constraints may result in a > > {NOT ANY} or invalid depending on implicit > > or explicit definitions of the address family in the set. In the > > latter case an error is returned. {NOT ANY} may issue a > > warning. > > This just explains a situation in which an invalid can be > specified or an expression can evaluate to {NOT ANY} . > Removing the explanation results in: > > If an evaluates to an invalid then > an error is returned. If an evaluates to {NOT > ANY} a warning may be issued. > > I think the existing content with the clarifying text is much better > but could stand a little rewording. Fine with me. > > 7) related to point 4), it may not be apparent what's the intent of the > > specification, unless done explicitly; for example: > > > > Conflicts with explicit or implicit declarations are resolved at > > runtime, that is during evaluation of a policy expression. For > > example, when evaluating the following import policy: > > > > aut-num: AS2 > > mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} > > > > the mp-filter should be evaluated as {NOT ANY}. > > And according to the above text a warning may be issued. > > > ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? > > Note that that's very valid for IPv6 too, except perhaps due to the way it's > > written (should be {::/0}). I.e., I think it's very important to specify > > the grammar for properly so that the IPv4 and IPv6 addresses can be > > distinguished properly in all cases. > > This is why ipv6-address should be specified and 0/0 should then be > distinguishable from ::/0 and there is then no ambiguity in the > example you gave. > > Since the address format for IPv6 has been accepted for a long time it > may have been overlooked. At least a reference should be made if the > exact syntax is defined elsewhere. right. > > 8) related to point 5), it is not clear whether the document is intended to > > be include conclusive lists of class attributes or just modified ones; for > > example: > > > 3. New route6 Class > > member-of list of optional, multi-valued > > aggr-bndry optional, single-valued > > aggr-mtd inbound or outbound optional, single-valued > > [] > > mnt-lower list of optional, multi-valued > > > > ==> note that there are multiple attributes which do not seem to be referred > > to in this document. Is the list in the document intended as a conclusive > > list of attributes or just examples? Based on that, one may have to decide > > whether to remove non-modified ones, or whether to ensure that everything is > > always present [where's route-set-name or as-expression, for example?] > > (and possibly separate new and classic attributes). > > That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. > RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 > provides extensions to RFC-1622 and explicitly mentions "mnt-routes" > and "mnt-lower" attributes. > > > ==> similar in section 5, at least. > > > > 9) there seem to be some mismatches or missing specification; for example, > > in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the > > like, but the only similar thing in the document so far as been > > "": > > > > mp-members list of ( optional, multi-valued > > or > > or > > or ) > > > > and: > > > > In RPSLng, these attributes are extended to the route6 and inet6num > > (described below) classes. Further, the syntax of the existing > > mnt-routes attribute is modified to allow the optional specification > > of IPv6 prefix range lists when present in inet6num, route6, and > > aut-num class objects. > > > > ==> it seems the document may be trying to take too many shortcuts by > > leaving the values undefined and to be intuitively filled in by the > > implementors. > > RPSL defined , , and > , in consecutive entries under "RPSL Names, > Reserved Words, and Representation". It should be sufficient to state > that is the same as except that > a is used in place of a and > is the same as > except that a is used in place of a > . maybe > > 10) remote-endpoint-address specifies some some encapsulations: > > > > indicates the IPv4 or IPv6 address of the > > remote endpoint of the tunnel. The address family must match that of > > the local endpoint. denotes the encapsulation used in > > the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing > > policies for these routers should be described in the appropriate > > classes (eg. aut-num). > > > > ==> I believe DVMRP is probably very much obsolete in this interdomain, > > RPSLng context and could be removed. > > Whether used or not, DVMRP is supported by RPSL implementations and it > does no harm to continue to mantion it until it is determined that > there really is no use for DVMRP (ie: when the experiment is declared > over). It seems irrelevant in this context, and potentially even harmful (building public interdomain DVMRP tunnels is not one of the brightest notions..). > > ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already > > cover that, *assuming* that one looks at the and > > to figure out what it is. Including both in here seems > > redundant to me; but if that's the path, also include IPv6inIPv6 and > > IPv4inIPv6, please! > > Tunnels may be IPv4 in IPv4 due to incomplete native multicast > deployment in the IPv4 world. Right. > If multicast were not widely deployed > in IPv6, then IPv6inIPv6 might be needed. That's the case today; our IPv6 multicast infra uses v6-over-v6 tunnels extensively. > If there existed IPv4 > tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is > forseen. You keep obsolete and dangerous entries like DVMRP, but fail to add those that are really needed now, and in the future? Doesn't seem like a good practice. But my point was not that; if you read it closely, my point was that you don't have to specify the inner and outer protocols of the tunnel, necessarily. Endpoint addresses and addresses assigned on the tunnel already yield that information! [snip to the end] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Fri Sep 12 13:29:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05920 for ; Fri, 12 Sep 2003 13:29:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrjA-00060E-MG; Fri, 12 Sep 2003 13:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrec-0005tO-NB for rps@optimus.ietf.org; Fri, 12 Sep 2003 13:24:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05723; Fri, 12 Sep 2003 13:24:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xreZ-0002eW-00; Fri, 12 Sep 2003 13:24:15 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19xreY-0002eR-00; Fri, 12 Sep 2003 13:24:14 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8CHNEL1023831; Fri, 12 Sep 2003 13:23:16 -0400 Message-Id: <200309121723.h8CHNEL1023831@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Thu, 11 Sep 2003 11:53:54 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 13:23:21 -0400 In message , Pekka Savola writes: > Inline.. > > On Wed, 10 Sep 2003, Curtis Villamizar wrote: > > In message , Pekka Sav > ola > > writes: > [...] > > > However, there seem to be a number of (more or less) textual inaccuracies > > > > and confusion in the document, which should be settled prior to > > > publication. > > > > > > I think there are the three most important issues here are: > > > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > > conflicting information about IPv4 unicast, then what? > > > > Not an issue. If only IPv4 policy is specified by a given statement, > > then either the old form or the new form can be used. Currently > > multiple import, export, and default statements can appear. Their > > effects are additive. The effect of adding mp-* statements specifying > > ipv4 using the longer syntax is the same as adding more of the > > existing import, export, and default statements. > > I'm not sure if I see it as the same. The user running RPSL tool must > check both the traditional and RPSLng entries. This is a change. More > likely than not, depending on the transition/co-existence plan, he will > also have to maintain records on both old and new. This is bound to cause > inconsistencies in the data. The transition is quite easy. The change adds mp-* but does not depricate (ever) the use of the non mp- forms. Just keep all the IPv4 unicast policy in the old form until conversion is considered complete. If it is never certain that conversion is complete, keep the IPv4 unicast in the old form indefinitely. > > > * issue 3) -- whether ipvX should imply only unicast or both unicast and > > > > multicast? > > > > Unicast and multicast are defined in separate statements. The > > document is clear on this. If you want both unicast and multicast you > > just specify ipvX,ipvX.multicast. The text is completely unambigous > > stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast > > (equivalent to ipv6)" under "The possible values for are:" > > stating "An is defined as a comma separated list of one or > > more afi values", showing where is used and multiple > > examples are given. > > Yes, I'm not saying the document is ambiguous; it's very clear on this. > > However, what I'm saying is that one perhaps should consider whether a > different kind of definitions would be useful -- so that if you want to > specify the topology for both unicast and multicast like, you could do it > without "ipv4,ipv4.multicast" or "ipv6,ipv6.multicast". People are using this in production networks. I'd give more weight to the preferences of people using it for quite some time. > > > * issue 5) and others-- whether the document needs to specify all the > > > relevant modifications explicitly, or not. IMHO, Stds Track document > > > should describe every change, not just say something like "other > > > attributes are modified in a similar fashion" (or something to that > > > effect) > > > > There is no need to repeat lengthy syntax descriptions contained in > > the base RFC if a straightforward modification is being made. The > > example you gave points to text that is perfectly clear. The existing > > accepts IPv4 addresses. The allows either IPv4 > > or IPv6 addresses to be specified. Perhaps this statement could be > > worded differently, but the syntax definitely should not be repeated. > > The syntax definition in RPSL remains authoritative except the > > additions defined here and no definitions that are not being changed > > should be included. > > I'm not sure if all those modifications are completely straightfoward. That's fine. Sometimes when something has been in use for a while the people that have been using it won't see an ambiguity or ommission because they already know how things work. Please be specific if there are instances of this. > > > substantial > > > ----------- > > > > > > 1) would it be useful to have the RPSLng document have "Updates: 2622, 27 > 25", > > > or > > > something like that -- if for no other reason than to have a forward > > > references in the RFC index to this document? > > > > This document extends RFC-1622. If it updated RFC-1622 it would mean > > that it represents a change to all usage of RFC-1622. > > You mean 2622, not 1622, obviously. Oops. Yeah. > I don't see Updates like that at all. What you're describing would seem > closer to "Obsoletes". This spec DOES make changes/additions to the > existing sec, e.g. at rp-attribute next-hop. It makes additions only. For example, IPv6 changes to next-hop only apply to IPv6 static routes. > > > 2) one important aspect to consider is interaction with old specification > , > > > that is: > > > > > > Keeping this in mind, the "import:", "export:", and "default:" > > > attributes implicitly specify IPv4 unicast policy and remain as > > > defined previously in RPSL, and new multi-protocol (prefixed with the > > > string "mp-") attributes are introduced. These will be described > > > below. > > > > > > ==> so, should one get information from both the RPSLng multiprotocol > > > attributes and the old ones? What if they conflict? Maybe some words wo > uld > > > be useful on how to effectively transition/co-exist with both RPSL and > > > RPSLng? > > > > See prior note. Not an issue. > > Not so sure on that. Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use. > > > 3) I note that there is no way to specify "these attributes affect both > > > multicast and unicast", you have to always include the both, in: > > > > > > The possible values for are: > > > > > > > > > > ipv4 > > > ipv4.unicast (equivalent to ipv4) > > > ipv4.multicast > > > ipv6 > > > ipv6.unicast (equivalent to ipv6) > > > ipv6.multicast > > > > > > ==> is this intended? Is there a particular reason why we couldn't just > > > assume that "ipv4" includes both unicast and multicast? Where multicast > is > > > deployed, it's typically mostly congruent with unicast infrastructure, an > d > > > where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" > > > implication? Or should there be a separate value which would imply the > > > both? > > > > Yes this is intended. See prior note. > > I question the intent, but this is not a critical issue for me. It would > seem more obvious that "ipv6" should refer to both unicast and multicast, > as they're both ipv6. Quite frankly - tough luck. The people using this recognize that the vast majority of policy statements are for unicast and therefore dropping the .unicast makes the most sense to the people that are already using this. > > > 4) it seems that ipv6_address dictionary attribute (though trivial) has n > ot > > > been defined: > > > > > > In order to support IPv6 addresses specified with the next-hop > > > rp-attribute, a new predefined dictionary type entitled ipv6_address > > > is added to the RPSL dictionary. > > > > > > ==> this should probably be something like: > > > > > > An IPv6 address is represented as [blah blah blah] > > > > Next-hop is part of the initial RPSL Dictionary defined in RFC1622 > > section 7.1 and is used to define the next hop of a static route. In > > order to support this ipv6_address is added. The dictionary type is > > not defined, just at the builtin dictionary type ipv4_address is not > > defined in RPSL. The format is assumed to be the same as > > ipv4-address. Integer is also not defined. > > > > RPSL does however give the format for ipv4-address. > > > > An IPv4 address is represented as a sequence of four > > integers in the range from 0 to 255 separated by the character > > dot ".". For example, 128.9.128.5 represents a valid IPv4 > > address. In the rest of this document, we may refer to IPv4 > > addresses as IP addresses. > > > > A similar entry should appear for ipv6-address in this draft. Though > > numerous examples are given, the syntax is not spelled out. > > Yep. ... Larry - it looks like you have an edit to make. > > > 5) As the document is Standards Track (and not e.g. Informational, which > > > would also be a possibility), I'm not sure whether it's appropriate to wa > ve > > > away some, possibly important, pieces of the specification, with like: > > > > > > 2.3.2 > > > > > > The expression is an extension of the RPSL > > > expression [section 5.4 of RFC 2622 [1]], with the inclusion of the > > > ability to specify IPv6 address prefixes in Address-Prefix sets. For > > > the sake of brevity, we do not include the full definition of > > > here and refer the reader to RFC 2622 [1]. > > > > > > and: > > > > > > 4.5 inet-rtr Class > > > > > > The "mp-peer:" attribute is defined below. The difference between > > > this attribute and the "peer:" attribute is the inclusion of support > > > for IPv6 addresses. > > > > How hard is this to figure out. In RPSL peer is defined as: > > Not so hard, but still not given. I'd prefer to spell things out. Again. Tough luck. As long as it is unambiguous it should not need to be spelled out at the cost of lots of pages that duplicate another spec and for which the other spec is still authoritative. > > Each peer attribute, if present, specifies a protocol peering with > > another router. The value of a peer attribute has the following > > syntax: > > > > > > | > > | > > | > > > > ... > > > > Just substitute ipv6-address for ipv4-address. The above definition > > need not be repeated in the new draft with the trivial substitution. > > Not the whole definition, maybe. That is the definition and it need not be repeated with the substitution. > > > 6) there seem to be a case or two where it is not clear whether including > > > the discussion in this specification is appropriate (and just not > > > implementation-specific issues, or issues relating to the user's RPSL use > r > > > interface); in below, the last sentence seems a bit dubious: > > > > > > The evaluation of an is done by evaluating all of > > > its components. Evaluation of peering-sets and filter-sets is > > > constrained by the address family. Such constraints may result in a > > > {NOT ANY} or invalid depending on implicit > > > or explicit definitions of the address family in the set. In the > > > latter case an error is returned. {NOT ANY} may issue a > > > warning. > > > > This just explains a situation in which an invalid can be > > specified or an expression can evaluate to {NOT ANY} . > > Removing the explanation results in: > > > > If an evaluates to an invalid then > > an error is returned. If an evaluates to {NOT > > ANY} a warning may be issued. > > > > I think the existing content with the clarifying text is much better > > but could stand a little rewording. > > Fine with me. > > > > 7) related to point 4), it may not be apparent what's the intent of the > > > specification, unless done explicitly; for example: > > > > > > Conflicts with explicit or implicit declarations are resolved at > > > runtime, that is during evaluation of a policy expression. For > > > example, when evaluating the following import policy: > > > > > > aut-num: AS2 > > > mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} > > > > > > > the mp-filter should be evaluated as {NOT ANY}. > > > > And according to the above text a warning may be issued. > > > > > ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? > > > Note that that's very valid for IPv6 too, except perhaps due to the way i > t's > > > written (should be {::/0}). I.e., I think it's very important to specify > > > the grammar for properly so that the IPv4 and IPv6 addresses can be > > > distinguished properly in all cases. > > > > This is why ipv6-address should be specified and 0/0 should then be > > distinguishable from ::/0 and there is then no ambiguity in the > > example you gave. > > > > Since the address format for IPv6 has been accepted for a long time it > > may have been overlooked. At least a reference should be made if the > > exact syntax is defined elsewhere. > > right. ... Larry - same edit - some details here. > > > 8) related to point 5), it is not clear whether the document is intended > to > > > be include conclusive lists of class attributes or just modified ones; fo > r > > > example: > > > > > 3. New route6 Class > > > member-of list of optional, multi-valued > > > aggr-bndry optional, single-valu > ed > > > aggr-mtd inbound or outbound optional, single-value > d > > > [] > > > mnt-lower list of optional, multi-value > d > > > > > > ==> note that there are multiple attributes which do not seem to be refer > red > > > to in this document. Is the list in the document intended as a conclusiv > e > > > list of attributes or just examples? Based on that, one may have to deci > de > > > whether to remove non-modified ones, or whether to ensure that everything > is > > > always present [where's route-set-name or as-expression, for example?] > > > (and possibly separate new and classic attributes). > > > > That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. > > RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 > > provides extensions to RFC-1622 and explicitly mentions "mnt-routes" > > and "mnt-lower" attributes. > > > > > ==> similar in section 5, at least. > > > > > > 9) there seem to be some mismatches or missing specification; for example > , > > > in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the > > > like, but the only similar thing in the document so far as been > > > "": > > > > > > mp-members list of ( optional, multi-valu > ed > > > or > > > or > > > or ) > > > > > > and: > > > > > > In RPSLng, these attributes are extended to the route6 and inet6num > > > (described below) classes. Further, the syntax of the existing > > > mnt-routes attribute is modified to allow the optional specification > > > of IPv6 prefix range lists when present in inet6num, route6, and > > > aut-num class objects. > > > > > > ==> it seems the document may be trying to take too many shortcuts by > > > leaving the values undefined and to be intuitively filled in by the > > > implementors. > > > > RPSL defined , , and > > , in consecutive entries under "RPSL Names, > > Reserved Words, and Representation". It should be sufficient to state > > that is the same as except that > > a is used in place of a and > > is the same as > > except that a is used in place of a > > . > > maybe ... Larry - looks to me like a second edit. > > > 10) remote-endpoint-address specifies some some encapsulations: > > > > > > indicates the IPv4 or IPv6 address of the > > > remote endpoint of the tunnel. The address family must match that of > > > the local endpoint. denotes the encapsulation used in > > > the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing > > > policies for these routers should be described in the appropriate > > > classes (eg. aut-num). > > > > > ==> I believe DVMRP is probably very much obsolete in this interdomain, > > > RPSLng context and could be removed. > > > > Whether used or not, DVMRP is supported by RPSL implementations and it > > does no harm to continue to mantion it until it is determined that > > there really is no use for DVMRP (ie: when the experiment is declared > > over). > > It seems irrelevant in this context, and potentially even harmful > (building public interdomain DVMRP tunnels is not one of the brightest > notions..). Until DVMRP moves to historic it doesn't hurt to include it here. If it isn't used it doesn't hurt anything. I'll let Larry make that call. > > > ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP alread > y > > > cover that, *assuming* that one looks at the and > > > to figure out what it is. Including both in here seems > > > redundant to me; but if that's the path, also include IPv6inIPv6 and > > > IPv4inIPv6, please! > > > > Tunnels may be IPv4 in IPv4 due to incomplete native multicast > > deployment in the IPv4 world. > > Right. > > > If multicast were not widely deployed > > in IPv6, then IPv6inIPv6 might be needed. > > That's the case today; our IPv6 multicast infra uses v6-over-v6 tunnels > extensively. OK. Then its needed. ... Larry - add one to the enumeration. > > If there existed IPv4 > > tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is > > forseen. > > You keep obsolete and dangerous entries like DVMRP, but fail to add those > that are really needed now, and in the future? Doesn't seem like a good > practice. Fine. If you think its needed. ... Larry - another entry. > But my point was not that; if you read it closely, my point was that you > don't have to specify the inner and outer protocols of the tunnel, > necessarily. Endpoint addresses and addresses assigned on the tunnel > already yield that information! You are smarter than Larry's parser. It needs the help. > [snip to the end] > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Thanks again for the comments. You've pointed to what look to be a few serious ommissions - , and are not defined. Adding IPv6inIPv6 and IPv4inIPv6 wouldn't hurt so those are good additions too. I don't think DVMRP should be deleted without consulting the users. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Fri Sep 12 13:29:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05950 for ; Fri, 12 Sep 2003 13:29:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrjT-00062I-7h for rps-archive@odin.ietf.org; Fri, 12 Sep 2003 13:29:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CHTJOF023198 for rps-archive@odin.ietf.org; Fri, 12 Sep 2003 13:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrjT-000625-2h for rps-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 13:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05917 for ; Fri, 12 Sep 2003 13:29:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrjQ-0002j0-00 for rps-web-archive@ietf.org; Fri, 12 Sep 2003 13:29:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xrjQ-0002iw-00 for rps-web-archive@ietf.org; Fri, 12 Sep 2003 13:29:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrjA-00060E-MG; Fri, 12 Sep 2003 13:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrec-0005tO-NB for rps@optimus.ietf.org; Fri, 12 Sep 2003 13:24:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05723; Fri, 12 Sep 2003 13:24:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xreZ-0002eW-00; Fri, 12 Sep 2003 13:24:15 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19xreY-0002eR-00; Fri, 12 Sep 2003 13:24:14 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8CHNEL1023831; Fri, 12 Sep 2003 13:23:16 -0400 Message-Id: <200309121723.h8CHNEL1023831@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Thu, 11 Sep 2003 11:53:54 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 13:23:21 -0400 In message , Pekka Savola writes: > Inline.. > > On Wed, 10 Sep 2003, Curtis Villamizar wrote: > > In message , Pekka Sav > ola > > writes: > [...] > > > However, there seem to be a number of (more or less) textual inaccuracies > > > > and confusion in the document, which should be settled prior to > > > publication. > > > > > > I think there are the three most important issues here are: > > > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > > conflicting information about IPv4 unicast, then what? > > > > Not an issue. If only IPv4 policy is specified by a given statement, > > then either the old form or the new form can be used. Currently > > multiple import, export, and default statements can appear. Their > > effects are additive. The effect of adding mp-* statements specifying > > ipv4 using the longer syntax is the same as adding more of the > > existing import, export, and default statements. > > I'm not sure if I see it as the same. The user running RPSL tool must > check both the traditional and RPSLng entries. This is a change. More > likely than not, depending on the transition/co-existence plan, he will > also have to maintain records on both old and new. This is bound to cause > inconsistencies in the data. The transition is quite easy. The change adds mp-* but does not depricate (ever) the use of the non mp- forms. Just keep all the IPv4 unicast policy in the old form until conversion is considered complete. If it is never certain that conversion is complete, keep the IPv4 unicast in the old form indefinitely. > > > * issue 3) -- whether ipvX should imply only unicast or both unicast and > > > > multicast? > > > > Unicast and multicast are defined in separate statements. The > > document is clear on this. If you want both unicast and multicast you > > just specify ipvX,ipvX.multicast. The text is completely unambigous > > stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast > > (equivalent to ipv6)" under "The possible values for are:" > > stating "An is defined as a comma separated list of one or > > more afi values", showing where is used and multiple > > examples are given. > > Yes, I'm not saying the document is ambiguous; it's very clear on this. > > However, what I'm saying is that one perhaps should consider whether a > different kind of definitions would be useful -- so that if you want to > specify the topology for both unicast and multicast like, you could do it > without "ipv4,ipv4.multicast" or "ipv6,ipv6.multicast". People are using this in production networks. I'd give more weight to the preferences of people using it for quite some time. > > > * issue 5) and others-- whether the document needs to specify all the > > > relevant modifications explicitly, or not. IMHO, Stds Track document > > > should describe every change, not just say something like "other > > > attributes are modified in a similar fashion" (or something to that > > > effect) > > > > There is no need to repeat lengthy syntax descriptions contained in > > the base RFC if a straightforward modification is being made. The > > example you gave points to text that is perfectly clear. The existing > > accepts IPv4 addresses. The allows either IPv4 > > or IPv6 addresses to be specified. Perhaps this statement could be > > worded differently, but the syntax definitely should not be repeated. > > The syntax definition in RPSL remains authoritative except the > > additions defined here and no definitions that are not being changed > > should be included. > > I'm not sure if all those modifications are completely straightfoward. That's fine. Sometimes when something has been in use for a while the people that have been using it won't see an ambiguity or ommission because they already know how things work. Please be specific if there are instances of this. > > > substantial > > > ----------- > > > > > > 1) would it be useful to have the RPSLng document have "Updates: 2622, 27 > 25", > > > or > > > something like that -- if for no other reason than to have a forward > > > references in the RFC index to this document? > > > > This document extends RFC-1622. If it updated RFC-1622 it would mean > > that it represents a change to all usage of RFC-1622. > > You mean 2622, not 1622, obviously. Oops. Yeah. > I don't see Updates like that at all. What you're describing would seem > closer to "Obsoletes". This spec DOES make changes/additions to the > existing sec, e.g. at rp-attribute next-hop. It makes additions only. For example, IPv6 changes to next-hop only apply to IPv6 static routes. > > > 2) one important aspect to consider is interaction with old specification > , > > > that is: > > > > > > Keeping this in mind, the "import:", "export:", and "default:" > > > attributes implicitly specify IPv4 unicast policy and remain as > > > defined previously in RPSL, and new multi-protocol (prefixed with the > > > string "mp-") attributes are introduced. These will be described > > > below. > > > > > > ==> so, should one get information from both the RPSLng multiprotocol > > > attributes and the old ones? What if they conflict? Maybe some words wo > uld > > > be useful on how to effectively transition/co-exist with both RPSL and > > > RPSLng? > > > > See prior note. Not an issue. > > Not so sure on that. Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use. > > > 3) I note that there is no way to specify "these attributes affect both > > > multicast and unicast", you have to always include the both, in: > > > > > > The possible values for are: > > > > > > > > > > ipv4 > > > ipv4.unicast (equivalent to ipv4) > > > ipv4.multicast > > > ipv6 > > > ipv6.unicast (equivalent to ipv6) > > > ipv6.multicast > > > > > > ==> is this intended? Is there a particular reason why we couldn't just > > > assume that "ipv4" includes both unicast and multicast? Where multicast > is > > > deployed, it's typically mostly congruent with unicast infrastructure, an > d > > > where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" > > > implication? Or should there be a separate value which would imply the > > > both? > > > > Yes this is intended. See prior note. > > I question the intent, but this is not a critical issue for me. It would > seem more obvious that "ipv6" should refer to both unicast and multicast, > as they're both ipv6. Quite frankly - tough luck. The people using this recognize that the vast majority of policy statements are for unicast and therefore dropping the .unicast makes the most sense to the people that are already using this. > > > 4) it seems that ipv6_address dictionary attribute (though trivial) has n > ot > > > been defined: > > > > > > In order to support IPv6 addresses specified with the next-hop > > > rp-attribute, a new predefined dictionary type entitled ipv6_address > > > is added to the RPSL dictionary. > > > > > > ==> this should probably be something like: > > > > > > An IPv6 address is represented as [blah blah blah] > > > > Next-hop is part of the initial RPSL Dictionary defined in RFC1622 > > section 7.1 and is used to define the next hop of a static route. In > > order to support this ipv6_address is added. The dictionary type is > > not defined, just at the builtin dictionary type ipv4_address is not > > defined in RPSL. The format is assumed to be the same as > > ipv4-address. Integer is also not defined. > > > > RPSL does however give the format for ipv4-address. > > > > An IPv4 address is represented as a sequence of four > > integers in the range from 0 to 255 separated by the character > > dot ".". For example, 128.9.128.5 represents a valid IPv4 > > address. In the rest of this document, we may refer to IPv4 > > addresses as IP addresses. > > > > A similar entry should appear for ipv6-address in this draft. Though > > numerous examples are given, the syntax is not spelled out. > > Yep. ... Larry - it looks like you have an edit to make. > > > 5) As the document is Standards Track (and not e.g. Informational, which > > > would also be a possibility), I'm not sure whether it's appropriate to wa > ve > > > away some, possibly important, pieces of the specification, with like: > > > > > > 2.3.2 > > > > > > The expression is an extension of the RPSL > > > expression [section 5.4 of RFC 2622 [1]], with the inclusion of the > > > ability to specify IPv6 address prefixes in Address-Prefix sets. For > > > the sake of brevity, we do not include the full definition of > > > here and refer the reader to RFC 2622 [1]. > > > > > > and: > > > > > > 4.5 inet-rtr Class > > > > > > The "mp-peer:" attribute is defined below. The difference between > > > this attribute and the "peer:" attribute is the inclusion of support > > > for IPv6 addresses. > > > > How hard is this to figure out. In RPSL peer is defined as: > > Not so hard, but still not given. I'd prefer to spell things out. Again. Tough luck. As long as it is unambiguous it should not need to be spelled out at the cost of lots of pages that duplicate another spec and for which the other spec is still authoritative. > > Each peer attribute, if present, specifies a protocol peering with > > another router. The value of a peer attribute has the following > > syntax: > > > > > > | > > | > > | > > > > ... > > > > Just substitute ipv6-address for ipv4-address. The above definition > > need not be repeated in the new draft with the trivial substitution. > > Not the whole definition, maybe. That is the definition and it need not be repeated with the substitution. > > > 6) there seem to be a case or two where it is not clear whether including > > > the discussion in this specification is appropriate (and just not > > > implementation-specific issues, or issues relating to the user's RPSL use > r > > > interface); in below, the last sentence seems a bit dubious: > > > > > > The evaluation of an is done by evaluating all of > > > its components. Evaluation of peering-sets and filter-sets is > > > constrained by the address family. Such constraints may result in a > > > {NOT ANY} or invalid depending on implicit > > > or explicit definitions of the address family in the set. In the > > > latter case an error is returned. {NOT ANY} may issue a > > > warning. > > > > This just explains a situation in which an invalid can be > > specified or an expression can evaluate to {NOT ANY} . > > Removing the explanation results in: > > > > If an evaluates to an invalid then > > an error is returned. If an evaluates to {NOT > > ANY} a warning may be issued. > > > > I think the existing content with the clarifying text is much better > > but could stand a little rewording. > > Fine with me. > > > > 7) related to point 4), it may not be apparent what's the intent of the > > > specification, unless done explicitly; for example: > > > > > > Conflicts with explicit or implicit declarations are resolved at > > > runtime, that is during evaluation of a policy expression. For > > > example, when evaluating the following import policy: > > > > > > aut-num: AS2 > > > mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} > > > > > > > the mp-filter should be evaluated as {NOT ANY}. > > > > And according to the above text a warning may be issued. > > > > > ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? > > > Note that that's very valid for IPv6 too, except perhaps due to the way i > t's > > > written (should be {::/0}). I.e., I think it's very important to specify > > > the grammar for properly so that the IPv4 and IPv6 addresses can be > > > distinguished properly in all cases. > > > > This is why ipv6-address should be specified and 0/0 should then be > > distinguishable from ::/0 and there is then no ambiguity in the > > example you gave. > > > > Since the address format for IPv6 has been accepted for a long time it > > may have been overlooked. At least a reference should be made if the > > exact syntax is defined elsewhere. > > right. ... Larry - same edit - some details here. > > > 8) related to point 5), it is not clear whether the document is intended > to > > > be include conclusive lists of class attributes or just modified ones; fo > r > > > example: > > > > > 3. New route6 Class > > > member-of list of optional, multi-valued > > > aggr-bndry optional, single-valu > ed > > > aggr-mtd inbound or outbound optional, single-value > d > > > [] > > > mnt-lower list of optional, multi-value > d > > > > > > ==> note that there are multiple attributes which do not seem to be refer > red > > > to in this document. Is the list in the document intended as a conclusiv > e > > > list of attributes or just examples? Based on that, one may have to deci > de > > > whether to remove non-modified ones, or whether to ensure that everything > is > > > always present [where's route-set-name or as-expression, for example?] > > > (and possibly separate new and classic attributes). > > > > That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. > > RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 > > provides extensions to RFC-1622 and explicitly mentions "mnt-routes" > > and "mnt-lower" attributes. > > > > > ==> similar in section 5, at least. > > > > > > 9) there seem to be some mismatches or missing specification; for example > , > > > in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the > > > like, but the only similar thing in the document so far as been > > > "": > > > > > > mp-members list of ( optional, multi-valu > ed > > > or > > > or > > > or ) > > > > > > and: > > > > > > In RPSLng, these attributes are extended to the route6 and inet6num > > > (described below) classes. Further, the syntax of the existing > > > mnt-routes attribute is modified to allow the optional specification > > > of IPv6 prefix range lists when present in inet6num, route6, and > > > aut-num class objects. > > > > > > ==> it seems the document may be trying to take too many shortcuts by > > > leaving the values undefined and to be intuitively filled in by the > > > implementors. > > > > RPSL defined , , and > > , in consecutive entries under "RPSL Names, > > Reserved Words, and Representation". It should be sufficient to state > > that is the same as except that > > a is used in place of a and > > is the same as > > except that a is used in place of a > > . > > maybe ... Larry - looks to me like a second edit. > > > 10) remote-endpoint-address specifies some some encapsulations: > > > > > > indicates the IPv4 or IPv6 address of the > > > remote endpoint of the tunnel. The address family must match that of > > > the local endpoint. denotes the encapsulation used in > > > the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing > > > policies for these routers should be described in the appropriate > > > classes (eg. aut-num). > > > > > ==> I believe DVMRP is probably very much obsolete in this interdomain, > > > RPSLng context and could be removed. > > > > Whether used or not, DVMRP is supported by RPSL implementations and it > > does no harm to continue to mantion it until it is determined that > > there really is no use for DVMRP (ie: when the experiment is declared > > over). > > It seems irrelevant in this context, and potentially even harmful > (building public interdomain DVMRP tunnels is not one of the brightest > notions..). Until DVMRP moves to historic it doesn't hurt to include it here. If it isn't used it doesn't hurt anything. I'll let Larry make that call. > > > ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP alread > y > > > cover that, *assuming* that one looks at the and > > > to figure out what it is. Including both in here seems > > > redundant to me; but if that's the path, also include IPv6inIPv6 and > > > IPv4inIPv6, please! > > > > Tunnels may be IPv4 in IPv4 due to incomplete native multicast > > deployment in the IPv4 world. > > Right. > > > If multicast were not widely deployed > > in IPv6, then IPv6inIPv6 might be needed. > > That's the case today; our IPv6 multicast infra uses v6-over-v6 tunnels > extensively. OK. Then its needed. ... Larry - add one to the enumeration. > > If there existed IPv4 > > tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is > > forseen. > > You keep obsolete and dangerous entries like DVMRP, but fail to add those > that are really needed now, and in the future? Doesn't seem like a good > practice. Fine. If you think its needed. ... Larry - another entry. > But my point was not that; if you read it closely, my point was that you > don't have to specify the inner and outer protocols of the tunnel, > necessarily. Endpoint addresses and addresses assigned on the tunnel > already yield that information! You are smarter than Larry's parser. It needs the help. > [snip to the end] > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Thanks again for the comments. You've pointed to what look to be a few serious ommissions - , and are not defined. Adding IPv6inIPv6 and IPv4inIPv6 wouldn't hurt so those are good additions too. I don't think DVMRP should be deleted without consulting the users. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Fri Sep 12 13:39:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06320 for ; Fri, 12 Sep 2003 13:39:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrsq-0006UE-V5; Fri, 12 Sep 2003 13:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrjy-000630-62 for rps@optimus.ietf.org; Fri, 12 Sep 2003 13:29:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05925; Fri, 12 Sep 2003 13:29:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrju-0002jE-00; Fri, 12 Sep 2003 13:29:46 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19xrju-0002it-00; Fri, 12 Sep 2003 13:29:46 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8CHRcL1024228; Fri, 12 Sep 2003 13:27:40 -0400 Message-Id: <200309121727.h8CHRcL1024228@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Thu, 11 Sep 2003 23:28:05 +0930." <3F607F6D.90209@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 13:27:45 -0400 In message <3F607F6D.90209@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > Larry Blunk is the current primary developer/maintainer, having taken > > over from the original author, Cengiz Alaettinoglu. The IPv6 syntax > > has evolved and is now in use. One of the reasons this document has > > seen so little comment is it describes something people have been > > using for quite some time and it works. > > I don't know if that is true. I just lost interest in continuing to > complain about the clunky syntax. > > Mark. Mark, Why don't you try it one more time. I don't remember seeing anything on the RPS mailing list in a long time so you must have given up quite some time ago or not copied the RPS mailing list. It would be best if you gave specific syntax changes you'd like to see and why, plus how to transition to the new syntax. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Fri Sep 12 13:39:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06335 for ; Fri, 12 Sep 2003 13:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrsu-0006W1-HU for rps-archive@odin.ietf.org; Fri, 12 Sep 2003 13:39:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CHd48W025039 for rps-archive@odin.ietf.org; Fri, 12 Sep 2003 13:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrsu-0006Vm-Cf for rps-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 13:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06283 for ; Fri, 12 Sep 2003 13:38:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrss-0002px-00 for rps-web-archive@ietf.org; Fri, 12 Sep 2003 13:39:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xrsr-0002pu-00 for rps-web-archive@ietf.org; Fri, 12 Sep 2003 13:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrsq-0006UE-V5; Fri, 12 Sep 2003 13:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrjy-000630-62 for rps@optimus.ietf.org; Fri, 12 Sep 2003 13:29:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05925; Fri, 12 Sep 2003 13:29:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrju-0002jE-00; Fri, 12 Sep 2003 13:29:46 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19xrju-0002it-00; Fri, 12 Sep 2003 13:29:46 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8CHRcL1024228; Fri, 12 Sep 2003 13:27:40 -0400 Message-Id: <200309121727.h8CHRcL1024228@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Thu, 11 Sep 2003 23:28:05 +0930." <3F607F6D.90209@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 13:27:45 -0400 In message <3F607F6D.90209@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > Larry Blunk is the current primary developer/maintainer, having taken > > over from the original author, Cengiz Alaettinoglu. The IPv6 syntax > > has evolved and is now in use. One of the reasons this document has > > seen so little comment is it describes something people have been > > using for quite some time and it works. > > I don't know if that is true. I just lost interest in continuing to > complain about the clunky syntax. > > Mark. Mark, Why don't you try it one more time. I don't remember seeing anything on the RPS mailing list in a long time so you must have given up quite some time ago or not copied the RPS mailing list. It would be best if you gave specific syntax changes you'd like to see and why, plus how to transition to the new syntax. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Sat Sep 13 01:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28555 for ; Sat, 13 Sep 2003 01:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19y2fa-0007uZ-7b; Sat, 13 Sep 2003 01:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19y2c5-0007bJ-2o for rps@optimus.ietf.org; Sat, 13 Sep 2003 01:06:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28485; Sat, 13 Sep 2003 01:06:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19y2c2-0001cO-00; Sat, 13 Sep 2003 01:06:22 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19y2c1-0001cK-00; Sat, 13 Sep 2003 01:06:21 -0400 Received: from mrp.net (CPE-144-137-214-219.sa.bigpond.net.au [144.137.214.219]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8D55M9e021958 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Sat, 13 Sep 2003 14:35:26 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F62A591.2070405@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309121727.h8CHRcL1024228@mail.avici.com> In-Reply-To: <200309121727.h8CHRcL1024228@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Sep 2003 14:35:21 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Why don't you try it one more time. I don't remember seeing anything > on the RPS mailing list in a long time so you must have given up quite > some time ago or not copied the RPS mailing list. > I was probably just using the rpslng list. > It would be best if you gave specific syntax changes you'd like to see > and why, plus how to transition to the new syntax. > My argument has always been about making is easier for the poor user and pushing the complexity to the software. This meant I wanted most of the syntax to remain the same, with optional phrases for the MP bits and certainly not grow "MP" variants of import, export, etc. Also I believed that the software could work out from its context if it wanted a IPv4 address or a IPv6 one and so there only needed to be one route object. The complaints about this approach seemed to revolve around backward compatability with existing software and my approach to that was to get newer software to perform some handshake with the server to say what it wanted otherwise the server would just return data acceptable to a RPSL client. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Sat Sep 13 01:10:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28570 for ; Sat, 13 Sep 2003 01:10:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19y2fi-0007wa-KF for rps-archive@odin.ietf.org; Sat, 13 Sep 2003 01:10:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8D5AA84030529 for rps-archive@odin.ietf.org; Sat, 13 Sep 2003 01:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19y2fi-0007wJ-GG for rps-web-archive@optimus.ietf.org; Sat, 13 Sep 2003 01:10:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28534 for ; Sat, 13 Sep 2003 01:10:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19y2ff-0001dt-00 for rps-web-archive@ietf.org; Sat, 13 Sep 2003 01:10:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19y2ff-0001dq-00 for rps-web-archive@ietf.org; Sat, 13 Sep 2003 01:10:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19y2fa-0007uZ-7b; Sat, 13 Sep 2003 01:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19y2c5-0007bJ-2o for rps@optimus.ietf.org; Sat, 13 Sep 2003 01:06:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28485; Sat, 13 Sep 2003 01:06:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19y2c2-0001cO-00; Sat, 13 Sep 2003 01:06:22 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19y2c1-0001cK-00; Sat, 13 Sep 2003 01:06:21 -0400 Received: from mrp.net (CPE-144-137-214-219.sa.bigpond.net.au [144.137.214.219]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8D55M9e021958 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Sat, 13 Sep 2003 14:35:26 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F62A591.2070405@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309121727.h8CHRcL1024228@mail.avici.com> In-Reply-To: <200309121727.h8CHRcL1024228@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Sep 2003 14:35:21 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Why don't you try it one more time. I don't remember seeing anything > on the RPS mailing list in a long time so you must have given up quite > some time ago or not copied the RPS mailing list. > I was probably just using the rpslng list. > It would be best if you gave specific syntax changes you'd like to see > and why, plus how to transition to the new syntax. > My argument has always been about making is easier for the poor user and pushing the complexity to the software. This meant I wanted most of the syntax to remain the same, with optional phrases for the MP bits and certainly not grow "MP" variants of import, export, etc. Also I believed that the software could work out from its context if it wanted a IPv4 address or a IPv6 one and so there only needed to be one route object. The complaints about this approach seemed to revolve around backward compatability with existing software and my approach to that was to get newer software to perform some handshake with the server to say what it wanted otherwise the server would just return data acceptable to a RPSL client. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 15 04:10:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16806 for ; Mon, 15 Sep 2003 04:10:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoQv-0003U6-DI; Mon, 15 Sep 2003 04:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoIJ-00023X-B9 for rps@optimus.ietf.org; Mon, 15 Sep 2003 04:01:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16263; Mon, 15 Sep 2003 04:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yoIG-0007Le-00; Mon, 15 Sep 2003 04:01:08 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19yoIF-0007GO-00; Mon, 15 Sep 2003 04:01:07 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8F80Mr27401; Mon, 15 Sep 2003 11:00:23 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309121723.h8CHNEL1023831@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Sep 2003 11:00:22 +0300 (EEST) I'm not sure if I agree with what you call "tough luck", but I've omitted them from the response, as more arguing on those wouldn't seem to be productive. On Fri, 12 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola > writes: > > On Wed, 10 Sep 2003, Curtis Villamizar wrote: > > > In message , Pekka Sav > > ola > > > writes: > > [...] > > > > However, there seem to be a number of (more or less) textual inaccuracies > > > > > > and confusion in the document, which should be settled prior to > > > > publication. > > > > > > > > I think there are the three most important issues here are: > > > > > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > > > conflicting information about IPv4 unicast, then what? > > > > > > Not an issue. If only IPv4 policy is specified by a given statement, > > > then either the old form or the new form can be used. Currently > > > multiple import, export, and default statements can appear. Their > > > effects are additive. The effect of adding mp-* statements specifying > > > ipv4 using the longer syntax is the same as adding more of the > > > existing import, export, and default statements. > > > > I'm not sure if I see it as the same. The user running RPSL tool must > > check both the traditional and RPSLng entries. This is a change. More > > likely than not, depending on the transition/co-existence plan, he will > > also have to maintain records on both old and new. This is bound to cause > > inconsistencies in the data. > > The transition is quite easy. The change adds mp-* but does not > depricate (ever) the use of the non mp- forms. Just keep all the IPv4 > unicast policy in the old form until conversion is considered > complete. If it is never certain that conversion is complete, keep > the IPv4 unicast in the old form indefinitely. "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right? But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach. As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features. Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only. But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure. Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng! We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. > > > > * issue 5) and others-- whether the document needs to specify all the > > > > relevant modifications explicitly, or not. IMHO, Stds Track document > > > > should describe every change, not just say something like "other > > > > attributes are modified in a similar fashion" (or something to that > > > > effect) > > > > > > There is no need to repeat lengthy syntax descriptions contained in > > > the base RFC if a straightforward modification is being made. The > > > example you gave points to text that is perfectly clear. The existing > > > accepts IPv4 addresses. The allows either IPv4 > > > or IPv6 addresses to be specified. Perhaps this statement could be > > > worded differently, but the syntax definitely should not be repeated. > > > The syntax definition in RPSL remains authoritative except the > > > additions defined here and no definitions that are not being changed > > > should be included. > > > > I'm not sure if all those modifications are completely straightfoward. > > That's fine. Sometimes when something has been in use for a while the > people that have been using it won't see an ambiguity or ommission > because they already know how things work. Please be specific if > there are instances of this. I think I've already pointed out some of those. All in all, I think *at least* the document should mention which things are being changed, and how (e.g. as a list, even if not "repeating lengthy discussions"). > > I don't see Updates like that at all. What you're describing would seem > > closer to "Obsoletes". This spec DOES make changes/additions to the > > existing sec, e.g. at rp-attribute next-hop. > > It makes additions only. For example, IPv6 changes to next-hop only > apply to IPv6 static routes. But still, it changes the rp-attribute. > > > > 2) one important aspect to consider is interaction with old specification > > , > > > > that is: > > > > > > > > Keeping this in mind, the "import:", "export:", and "default:" > > > > attributes implicitly specify IPv4 unicast policy and remain as > > > > defined previously in RPSL, and new multi-protocol (prefixed with the > > > > string "mp-") attributes are introduced. These will be described > > > > below. > > > > > > > > ==> so, should one get information from both the RPSLng multiprotocol > > > > attributes and the old ones? What if they conflict? Maybe some words wo > > uld > > > > be useful on how to effectively transition/co-exist with both RPSL and > > > > RPSLng? > > > > > > See prior note. Not an issue. > > > > Not so sure on that. > > Its deployed so obviously it works. We're not talking about something > no one has ever tried. This is documenting a set of extensions that > are in use. Being used by a few people and being used as widely as RPSL is used today are two different things. It is obviously not being used widely if RIPE just got it's test version of the database and the tools out a month or something like that ago. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 15 04:10:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16821 for ; Mon, 15 Sep 2003 04:10:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoRF-0003Y4-91 for rps-archive@odin.ietf.org; Mon, 15 Sep 2003 04:10:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F8APQe013634 for rps-archive@odin.ietf.org; Mon, 15 Sep 2003 04:10:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoRE-0003Xk-51 for rps-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 04:10:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16774 for ; Mon, 15 Sep 2003 04:10:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yoRB-0000Ob-00 for rps-web-archive@ietf.org; Mon, 15 Sep 2003 04:10:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yoRA-0000OX-00 for rps-web-archive@ietf.org; Mon, 15 Sep 2003 04:10:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoQv-0003U6-DI; Mon, 15 Sep 2003 04:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yoIJ-00023X-B9 for rps@optimus.ietf.org; Mon, 15 Sep 2003 04:01:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16263; Mon, 15 Sep 2003 04:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yoIG-0007Le-00; Mon, 15 Sep 2003 04:01:08 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19yoIF-0007GO-00; Mon, 15 Sep 2003 04:01:07 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8F80Mr27401; Mon, 15 Sep 2003 11:00:23 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309121723.h8CHNEL1023831@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Sep 2003 11:00:22 +0300 (EEST) I'm not sure if I agree with what you call "tough luck", but I've omitted them from the response, as more arguing on those wouldn't seem to be productive. On Fri, 12 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola > writes: > > On Wed, 10 Sep 2003, Curtis Villamizar wrote: > > > In message , Pekka Sav > > ola > > > writes: > > [...] > > > > However, there seem to be a number of (more or less) textual inaccuracies > > > > > > and confusion in the document, which should be settled prior to > > > > publication. > > > > > > > > I think there are the three most important issues here are: > > > > > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > > > conflicting information about IPv4 unicast, then what? > > > > > > Not an issue. If only IPv4 policy is specified by a given statement, > > > then either the old form or the new form can be used. Currently > > > multiple import, export, and default statements can appear. Their > > > effects are additive. The effect of adding mp-* statements specifying > > > ipv4 using the longer syntax is the same as adding more of the > > > existing import, export, and default statements. > > > > I'm not sure if I see it as the same. The user running RPSL tool must > > check both the traditional and RPSLng entries. This is a change. More > > likely than not, depending on the transition/co-existence plan, he will > > also have to maintain records on both old and new. This is bound to cause > > inconsistencies in the data. > > The transition is quite easy. The change adds mp-* but does not > depricate (ever) the use of the non mp- forms. Just keep all the IPv4 > unicast policy in the old form until conversion is considered > complete. If it is never certain that conversion is complete, keep > the IPv4 unicast in the old form indefinitely. "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right? But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach. As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features. Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only. But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure. Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng! We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. > > > > * issue 5) and others-- whether the document needs to specify all the > > > > relevant modifications explicitly, or not. IMHO, Stds Track document > > > > should describe every change, not just say something like "other > > > > attributes are modified in a similar fashion" (or something to that > > > > effect) > > > > > > There is no need to repeat lengthy syntax descriptions contained in > > > the base RFC if a straightforward modification is being made. The > > > example you gave points to text that is perfectly clear. The existing > > > accepts IPv4 addresses. The allows either IPv4 > > > or IPv6 addresses to be specified. Perhaps this statement could be > > > worded differently, but the syntax definitely should not be repeated. > > > The syntax definition in RPSL remains authoritative except the > > > additions defined here and no definitions that are not being changed > > > should be included. > > > > I'm not sure if all those modifications are completely straightfoward. > > That's fine. Sometimes when something has been in use for a while the > people that have been using it won't see an ambiguity or ommission > because they already know how things work. Please be specific if > there are instances of this. I think I've already pointed out some of those. All in all, I think *at least* the document should mention which things are being changed, and how (e.g. as a list, even if not "repeating lengthy discussions"). > > I don't see Updates like that at all. What you're describing would seem > > closer to "Obsoletes". This spec DOES make changes/additions to the > > existing sec, e.g. at rp-attribute next-hop. > > It makes additions only. For example, IPv6 changes to next-hop only > apply to IPv6 static routes. But still, it changes the rp-attribute. > > > > 2) one important aspect to consider is interaction with old specification > > , > > > > that is: > > > > > > > > Keeping this in mind, the "import:", "export:", and "default:" > > > > attributes implicitly specify IPv4 unicast policy and remain as > > > > defined previously in RPSL, and new multi-protocol (prefixed with the > > > > string "mp-") attributes are introduced. These will be described > > > > below. > > > > > > > > ==> so, should one get information from both the RPSLng multiprotocol > > > > attributes and the old ones? What if they conflict? Maybe some words wo > > uld > > > > be useful on how to effectively transition/co-exist with both RPSL and > > > > RPSLng? > > > > > > See prior note. Not an issue. > > > > Not so sure on that. > > Its deployed so obviously it works. We're not talking about something > no one has ever tried. This is documenting a set of extensions that > are in use. Being used by a few people and being used as widely as RPSL is used today are two different things. It is obviously not being used widely if RIPE just got it's test version of the database and the tools out a month or something like that ago. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 15 15:38:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22460 for ; Mon, 15 Sep 2003 15:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzAf-0000PX-Qp; Mon, 15 Sep 2003 15:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yz5V-0008Ls-Uz for rps@optimus.ietf.org; Mon, 15 Sep 2003 15:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22152; Mon, 15 Sep 2003 15:32:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yz5U-00056l-00; Mon, 15 Sep 2003 15:32:40 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19yz5T-000563-00; Mon, 15 Sep 2003 15:32:39 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8FJUlL1011384; Mon, 15 Sep 2003 15:30:55 -0400 Message-Id: <200309151930.h8FJUlL1011384@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Mon, 15 Sep 2003 11:00:22 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Sep 2003 15:30:56 -0400 In message , Pekka Savola writes: > I'm not sure if I agree with what you call "tough luck", but I've omitted > them from the response, as more arguing on those wouldn't seem to be > productive. > > On Fri, 12 Sep 2003, Curtis Villamizar wrote: > > In message , Pekka Sav > ola > > writes: > > > On Wed, 10 Sep 2003, Curtis Villamizar wrote: > > > > In message , Pekka > Sav > > > ola > > > > writes: > > > [...] > > > > > However, there seem to be a number of (more or less) textual inaccura > cies > > > > > > > > and confusion in the document, which should be settled prior to > > > > > publication. > > > > > > > > > > I think there are the three most important issues here are: > > > > > > > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > > > > conflicting information about IPv4 unicast, then what? > > > > > > > > Not an issue. If only IPv4 policy is specified by a given statement, > > > > then either the old form or the new form can be used. Currently > > > multiple import, export, and default statements can appear. Their > > > > effects are additive. The effect of adding mp-* statements specifying > > > > ipv4 using the longer syntax is the same as adding more of the > > > > existing import, export, and default statements. > > > > > > I'm not sure if I see it as the same. The user running RPSL tool must > > > check both the traditional and RPSLng entries. This is a change. More > > > likely than not, depending on the transition/co-existence plan, he will > > > also have to maintain records on both old and new. This is bound to caus > e > > > inconsistencies in the data. > > > > The transition is quite easy. The change adds mp-* but does not > > depricate (ever) the use of the non mp- forms. Just keep all the IPv4 > > unicast policy in the old form until conversion is considered > > complete. If it is never certain that conversion is complete, keep > > the IPv4 unicast in the old form indefinitely. > > "until conversion is considered complete". Do you think this takes a > year, two, or ten years? Note that for the conversion to be complete, > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > But then again, you're advocating keeping the v4 unicast policy only in > the old form RPSL. Now, many sites want to mention their multicast > policies as well, or IPv6 policies. They have to maintain two different > databases and records to do this, using this transition approach. > > As for another approach, what might help a bit could be to have the > ability of the RPSLng databases to automatically generate the old form > RPSL data from the IPv4 unicast data which has possibly been entered in > the RPSLng registry, for maintaining the automatic backward compatibility > and minimizing the maintenance effort of all ISPs desiring to use the > RPSLng features. > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > data, so that everyone could start "safely" to use RPSLng only. > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > here, not sure. > > Or, there could be some other approaches, I don't know. These might not > even require modifications (at least major ones) in the RPSLng spec. But > this seems like a subject which is non-trivial and bears some thinking > about... *before* we set off to really deploying RPSLng! Any AS object that provides policy already has many import and export statements. Today IPv4 and IPv6 policy does not match so different statements are needed anyway. For example, AS3561 has 737 import statements and 738 export statements. I would venture to guess their IPv6 policy is a lot simpler. > We've been learning that lesson with the IPv6 transition work. Folks > probably thought it would be trivial, at first, and didn't pay attention > to the operational details.. I had a lot to do with IPv4 deployment (NSFNET 1992-1995, ANS and UUNET 1995-1998) and I had a lot to do with definition of RPSL and use of RPSL. Considering how long widespread IPv6 deployment has been "coming RSN" the IPv6 world has got nowhere by comparison. I suggest you get off your soapbox and stick with concrete comments and suggestions. > > Its deployed so obviously it works. We're not talking about something > > no one has ever tried. This is documenting a set of extensions that > > are in use. > > Being used by a few people and being used as widely as RPSL is used today > are two different things. It is obviously not being used widely if RIPE > just got it's test version of the database and the tools out a month or > something like that ago. Larry could probably give you the lineage of this work better than I could. I think David Kessens was working on expressing IPv6 policy in RPSL as far back as 1997 or so. RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 15 15:38:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22487 for ; Mon, 15 Sep 2003 15:38:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzAo-0000SV-NL for rps-archive@odin.ietf.org; Mon, 15 Sep 2003 15:38:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FJcAh0001755 for rps-archive@odin.ietf.org; Mon, 15 Sep 2003 15:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzAo-0000S5-BB for rps-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 15:38:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22420 for ; Mon, 15 Sep 2003 15:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yzAm-0005Ca-00 for rps-web-archive@ietf.org; Mon, 15 Sep 2003 15:38:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yzAm-0005CX-00 for rps-web-archive@ietf.org; Mon, 15 Sep 2003 15:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzAh-0000Pf-CG; Mon, 15 Sep 2003 15:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yz6F-0008Qu-R1 for rps@optimus.ietf.org; Mon, 15 Sep 2003 15:33:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22181; Mon, 15 Sep 2003 15:33:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yz6E-00057o-00; Mon, 15 Sep 2003 15:33:26 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19yz6D-00057D-00; Mon, 15 Sep 2003 15:33:25 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8FJVGL1011419; Mon, 15 Sep 2003 15:31:18 -0400 Message-Id: <200309151931.h8FJVGL1011419@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Sat, 13 Sep 2003 14:35:21 +0930." <3F62A591.2070405@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Sep 2003 15:31:25 -0400 In message <3F62A591.2070405@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > Why don't you try it one more time. I don't remember seeing anything > > on the RPS mailing list in a long time so you must have given up quite > > some time ago or not copied the RPS mailing list. > > > I was probably just using the rpslng list. > > > It would be best if you gave specific syntax changes you'd like to see > > and why, plus how to transition to the new syntax. > > > My argument has always been about making is easier for the poor user and > pushing the complexity to the software. This meant I wanted most of the > syntax to remain the same, with optional phrases for the MP bits and > certainly not grow "MP" variants of import, export, etc. Also I believed > that the software could work out from its context if it wanted a IPv4 > address or a IPv6 one and so there only needed to be one route object. > > The complaints about this approach seemed to revolve around backward > compatability with existing software and my approach to that was to get > newer software to perform some handshake with the server to say what it > wanted otherwise the server would just return data acceptable to a RPSL > client. > > Mark. I wasn't part of that discussion, but if you don't mind a last minute comment on this... Transition issues are very important in a RR. You have to assume that old software will be around for quite a long time. Someone is bound to be using old code for a very long time. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 15 16:23:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22462 for ; Mon, 15 Sep 2003 15:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzAh-0000Pf-CG; Mon, 15 Sep 2003 15:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yz6F-0008Qu-R1 for rps@optimus.ietf.org; Mon, 15 Sep 2003 15:33:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22181; Mon, 15 Sep 2003 15:33:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yz6E-00057o-00; Mon, 15 Sep 2003 15:33:26 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19yz6D-00057D-00; Mon, 15 Sep 2003 15:33:25 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8FJVGL1011419; Mon, 15 Sep 2003 15:31:18 -0400 Message-Id: <200309151931.h8FJVGL1011419@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Sat, 13 Sep 2003 14:35:21 +0930." <3F62A591.2070405@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Sep 2003 15:31:25 -0400 In message <3F62A591.2070405@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > Why don't you try it one more time. I don't remember seeing anything > > on the RPS mailing list in a long time so you must have given up quite > > some time ago or not copied the RPS mailing list. > > > I was probably just using the rpslng list. > > > It would be best if you gave specific syntax changes you'd like to see > > and why, plus how to transition to the new syntax. > > > My argument has always been about making is easier for the poor user and > pushing the complexity to the software. This meant I wanted most of the > syntax to remain the same, with optional phrases for the MP bits and > certainly not grow "MP" variants of import, export, etc. Also I believed > that the software could work out from its context if it wanted a IPv4 > address or a IPv6 one and so there only needed to be one route object. > > The complaints about this approach seemed to revolve around backward > compatability with existing software and my approach to that was to get > newer software to perform some handshake with the server to say what it > wanted otherwise the server would just return data acceptable to a RPSL > client. > > Mark. I wasn't part of that discussion, but if you don't mind a last minute comment on this... Transition issues are very important in a RR. You have to assume that old software will be around for quite a long time. Someone is bound to be using old code for a very long time. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 15 16:23:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22488 for ; Mon, 15 Sep 2003 15:38:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzAo-0000SU-MK for rps-archive@odin.ietf.org; Mon, 15 Sep 2003 15:38:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FJcA1n001746 for rps-archive@odin.ietf.org; Mon, 15 Sep 2003 15:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzAo-0000S4-80 for rps-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 15:38:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22417 for ; Mon, 15 Sep 2003 15:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yzAm-0005CV-00 for rps-web-archive@ietf.org; Mon, 15 Sep 2003 15:38:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yzAm-0005CS-00 for rps-web-archive@ietf.org; Mon, 15 Sep 2003 15:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzAf-0000PX-Qp; Mon, 15 Sep 2003 15:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yz5V-0008Ls-Uz for rps@optimus.ietf.org; Mon, 15 Sep 2003 15:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22152; Mon, 15 Sep 2003 15:32:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yz5U-00056l-00; Mon, 15 Sep 2003 15:32:40 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19yz5T-000563-00; Mon, 15 Sep 2003 15:32:39 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8FJUlL1011384; Mon, 15 Sep 2003 15:30:55 -0400 Message-Id: <200309151930.h8FJUlL1011384@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Mon, 15 Sep 2003 11:00:22 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Sep 2003 15:30:56 -0400 In message , Pekka Savola writes: > I'm not sure if I agree with what you call "tough luck", but I've omitted > them from the response, as more arguing on those wouldn't seem to be > productive. > > On Fri, 12 Sep 2003, Curtis Villamizar wrote: > > In message , Pekka Sav > ola > > writes: > > > On Wed, 10 Sep 2003, Curtis Villamizar wrote: > > > > In message , Pekka > Sav > > > ola > > > > writes: > > > [...] > > > > > However, there seem to be a number of (more or less) textual inaccura > cies > > > > > > > > and confusion in the document, which should be settled prior to > > > > > publication. > > > > > > > > > > I think there are the three most important issues here are: > > > > > > > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > > > > conflicting information about IPv4 unicast, then what? > > > > > > > > Not an issue. If only IPv4 policy is specified by a given statement, > > > > then either the old form or the new form can be used. Currently > > > multiple import, export, and default statements can appear. Their > > > > effects are additive. The effect of adding mp-* statements specifying > > > > ipv4 using the longer syntax is the same as adding more of the > > > > existing import, export, and default statements. > > > > > > I'm not sure if I see it as the same. The user running RPSL tool must > > > check both the traditional and RPSLng entries. This is a change. More > > > likely than not, depending on the transition/co-existence plan, he will > > > also have to maintain records on both old and new. This is bound to caus > e > > > inconsistencies in the data. > > > > The transition is quite easy. The change adds mp-* but does not > > depricate (ever) the use of the non mp- forms. Just keep all the IPv4 > > unicast policy in the old form until conversion is considered > > complete. If it is never certain that conversion is complete, keep > > the IPv4 unicast in the old form indefinitely. > > "until conversion is considered complete". Do you think this takes a > year, two, or ten years? Note that for the conversion to be complete, > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > But then again, you're advocating keeping the v4 unicast policy only in > the old form RPSL. Now, many sites want to mention their multicast > policies as well, or IPv6 policies. They have to maintain two different > databases and records to do this, using this transition approach. > > As for another approach, what might help a bit could be to have the > ability of the RPSLng databases to automatically generate the old form > RPSL data from the IPv4 unicast data which has possibly been entered in > the RPSLng registry, for maintaining the automatic backward compatibility > and minimizing the maintenance effort of all ISPs desiring to use the > RPSLng features. > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > data, so that everyone could start "safely" to use RPSLng only. > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > here, not sure. > > Or, there could be some other approaches, I don't know. These might not > even require modifications (at least major ones) in the RPSLng spec. But > this seems like a subject which is non-trivial and bears some thinking > about... *before* we set off to really deploying RPSLng! Any AS object that provides policy already has many import and export statements. Today IPv4 and IPv6 policy does not match so different statements are needed anyway. For example, AS3561 has 737 import statements and 738 export statements. I would venture to guess their IPv6 policy is a lot simpler. > We've been learning that lesson with the IPv6 transition work. Folks > probably thought it would be trivial, at first, and didn't pay attention > to the operational details.. I had a lot to do with IPv4 deployment (NSFNET 1992-1995, ANS and UUNET 1995-1998) and I had a lot to do with definition of RPSL and use of RPSL. Considering how long widespread IPv6 deployment has been "coming RSN" the IPv6 world has got nowhere by comparison. I suggest you get off your soapbox and stick with concrete comments and suggestions. > > Its deployed so obviously it works. We're not talking about something > > no one has ever tried. This is documenting a set of extensions that > > are in use. > > Being used by a few people and being used as widely as RPSL is used today > are two different things. It is obviously not being used widely if RIPE > just got it's test version of the database and the tools out a month or > something like that ago. Larry could probably give you the lineage of this work better than I could. I think David Kessens was working on expressing IPv6 policy in RPSL as far back as 1997 or so. RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 01:49:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12837 for ; Tue, 16 Sep 2003 01:49:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8hx-0007Gg-Af; Tue, 16 Sep 2003 01:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8GK-0005qY-T6 for rps@optimus.ietf.org; Tue, 16 Sep 2003 01:20:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11934; Tue, 16 Sep 2003 01:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z8GH-0003Xw-00; Tue, 16 Sep 2003 01:20:25 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19z8GH-0003Xe-00; Tue, 16 Sep 2003 01:20:25 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8G5JoR05787; Tue, 16 Sep 2003 08:19:50 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309151930.h8FJUlL1011384@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 08:19:49 +0300 (EEST) On Mon, 15 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola > writes: > > I'm not sure if I agree with what you call "tough luck", but I've omitted > > them from the response, as more arguing on those wouldn't seem to be > > productive. > > > > On Fri, 12 Sep 2003, Curtis Villamizar wrote: > > > In message , Pekka Sav > > ola > > > writes: > > > > On Wed, 10 Sep 2003, Curtis Villamizar wrote: > > > > > In message , Pekka > > Sav > > > > ola > > > > > writes: > > > > [...] > > > > > > However, there seem to be a number of (more or less) textual inaccura > > cies > > > > > > > > > > and confusion in the document, which should be settled prior to > > > > > > publication. > > > > > > > > > > > > I think there are the three most important issues here are: > > > > > > > > > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > > > > > conflicting information about IPv4 unicast, then what? > > > > > > > > > > Not an issue. If only IPv4 policy is specified by a given statement, > > > > > then either the old form or the new form can be used. Currently > > > > multiple import, export, and default statements can appear. Their > > > > > effects are additive. The effect of adding mp-* statements specifying > > > > > ipv4 using the longer syntax is the same as adding more of the > > > > > existing import, export, and default statements. > > > > > > > > I'm not sure if I see it as the same. The user running RPSL tool must > > > > check both the traditional and RPSLng entries. This is a change. More > > > > likely than not, depending on the transition/co-existence plan, he will > > > > also have to maintain records on both old and new. This is bound to caus > > e > > > > inconsistencies in the data. > > > > > > The transition is quite easy. The change adds mp-* but does not > > > depricate (ever) the use of the non mp- forms. Just keep all the IPv4 > > > unicast policy in the old form until conversion is considered > > > complete. If it is never certain that conversion is complete, keep > > > the IPv4 unicast in the old form indefinitely. > > > > "until conversion is considered complete". Do you think this takes a > > year, two, or ten years? Note that for the conversion to be complete, > > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > > > But then again, you're advocating keeping the v4 unicast policy only in > > the old form RPSL. Now, many sites want to mention their multicast > > policies as well, or IPv6 policies. They have to maintain two different > > databases and records to do this, using this transition approach. > > > > As for another approach, what might help a bit could be to have the > > ability of the RPSLng databases to automatically generate the old form > > RPSL data from the IPv4 unicast data which has possibly been entered in > > the RPSLng registry, for maintaining the automatic backward compatibility > > and minimizing the maintenance effort of all ISPs desiring to use the > > RPSLng features. > > > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > > data, so that everyone could start "safely" to use RPSLng only. > > > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > > here, not sure. > > > > Or, there could be some other approaches, I don't know. These might not > > even require modifications (at least major ones) in the RPSLng spec. But > > this seems like a subject which is non-trivial and bears some thinking > > about... *before* we set off to really deploying RPSLng! > > Any AS object that provides policy already has many import and export > statements. Today IPv4 and IPv6 policy does not match so different > statements are needed anyway. For example, AS3561 has 737 import > statements and 738 export statements. I would venture to guess their > IPv6 policy is a lot simpler. > > > We've been learning that lesson with the IPv6 transition work. Folks > > probably thought it would be trivial, at first, and didn't pay attention > > to the operational details.. > > I had a lot to do with IPv4 deployment (NSFNET 1992-1995, ANS and > UUNET 1995-1998) and I had a lot to do with definition of RPSL and use > of RPSL. Considering how long widespread IPv6 deployment has been > "coming RSN" the IPv6 world has got nowhere by comparison. I suggest > you get off your soapbox and stick with concrete comments and > suggestions. Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to be different anyway. I believe I gave a couple of points to consider as well. > > > Its deployed so obviously it works. We're not talking about something > > > no one has ever tried. This is documenting a set of extensions that > > > are in use. > > > > Being used by a few people and being used as widely as RPSL is used today > > are two different things. It is obviously not being used widely if RIPE > > just got it's test version of the database and the tools out a month or > > something like that ago. > > Larry could probably give you the lineage of this work better than I > could. I think David Kessens was working on expressing IPv6 policy in > RPSL as far back as 1997 or so. Right.. but it has gotten nowhere in about five years if so. > RIPE uses its database mostly as a Internet address and AS registry. > That you can express policy in RPSL for RIPE is just an added benefit > for their customers. RIPE has had IPv6 inetnum records for a very > long time for the purpose of address registry. This is irrelevant: the fact stands that at least in the RIPE region (I don't know much of the others, but I guess the situation is pretty much the same), RPSLng has *not* been deployed at all. So, it seems to me that any statements of its wide use are quite questionable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 01:49:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12852 for ; Tue, 16 Sep 2003 01:49:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8i4-0007I2-7H for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 01:49:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G5n8vH028016 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 01:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8i4-0007Hn-3B for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 01:49:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12820 for ; Tue, 16 Sep 2003 01:49:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z8i0-0003sO-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 01:49:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z8i0-0003sL-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 01:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8hx-0007Gg-Af; Tue, 16 Sep 2003 01:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z8GK-0005qY-T6 for rps@optimus.ietf.org; Tue, 16 Sep 2003 01:20:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11934; Tue, 16 Sep 2003 01:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z8GH-0003Xw-00; Tue, 16 Sep 2003 01:20:25 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19z8GH-0003Xe-00; Tue, 16 Sep 2003 01:20:25 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8G5JoR05787; Tue, 16 Sep 2003 08:19:50 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309151930.h8FJUlL1011384@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 08:19:49 +0300 (EEST) On Mon, 15 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola > writes: > > I'm not sure if I agree with what you call "tough luck", but I've omitted > > them from the response, as more arguing on those wouldn't seem to be > > productive. > > > > On Fri, 12 Sep 2003, Curtis Villamizar wrote: > > > In message , Pekka Sav > > ola > > > writes: > > > > On Wed, 10 Sep 2003, Curtis Villamizar wrote: > > > > > In message , Pekka > > Sav > > > > ola > > > > > writes: > > > > [...] > > > > > > However, there seem to be a number of (more or less) textual inaccura > > cies > > > > > > > > > > and confusion in the document, which should be settled prior to > > > > > > publication. > > > > > > > > > > > > I think there are the three most important issues here are: > > > > > > > > > > > > * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you > > > > > > conflicting information about IPv4 unicast, then what? > > > > > > > > > > Not an issue. If only IPv4 policy is specified by a given statement, > > > > > then either the old form or the new form can be used. Currently > > > > multiple import, export, and default statements can appear. Their > > > > > effects are additive. The effect of adding mp-* statements specifying > > > > > ipv4 using the longer syntax is the same as adding more of the > > > > > existing import, export, and default statements. > > > > > > > > I'm not sure if I see it as the same. The user running RPSL tool must > > > > check both the traditional and RPSLng entries. This is a change. More > > > > likely than not, depending on the transition/co-existence plan, he will > > > > also have to maintain records on both old and new. This is bound to caus > > e > > > > inconsistencies in the data. > > > > > > The transition is quite easy. The change adds mp-* but does not > > > depricate (ever) the use of the non mp- forms. Just keep all the IPv4 > > > unicast policy in the old form until conversion is considered > > > complete. If it is never certain that conversion is complete, keep > > > the IPv4 unicast in the old form indefinitely. > > > > "until conversion is considered complete". Do you think this takes a > > year, two, or ten years? Note that for the conversion to be complete, > > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > > > But then again, you're advocating keeping the v4 unicast policy only in > > the old form RPSL. Now, many sites want to mention their multicast > > policies as well, or IPv6 policies. They have to maintain two different > > databases and records to do this, using this transition approach. > > > > As for another approach, what might help a bit could be to have the > > ability of the RPSLng databases to automatically generate the old form > > RPSL data from the IPv4 unicast data which has possibly been entered in > > the RPSLng registry, for maintaining the automatic backward compatibility > > and minimizing the maintenance effort of all ISPs desiring to use the > > RPSLng features. > > > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > > data, so that everyone could start "safely" to use RPSLng only. > > > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > > here, not sure. > > > > Or, there could be some other approaches, I don't know. These might not > > even require modifications (at least major ones) in the RPSLng spec. But > > this seems like a subject which is non-trivial and bears some thinking > > about... *before* we set off to really deploying RPSLng! > > Any AS object that provides policy already has many import and export > statements. Today IPv4 and IPv6 policy does not match so different > statements are needed anyway. For example, AS3561 has 737 import > statements and 738 export statements. I would venture to guess their > IPv6 policy is a lot simpler. > > > We've been learning that lesson with the IPv6 transition work. Folks > > probably thought it would be trivial, at first, and didn't pay attention > > to the operational details.. > > I had a lot to do with IPv4 deployment (NSFNET 1992-1995, ANS and > UUNET 1995-1998) and I had a lot to do with definition of RPSL and use > of RPSL. Considering how long widespread IPv6 deployment has been > "coming RSN" the IPv6 world has got nowhere by comparison. I suggest > you get off your soapbox and stick with concrete comments and > suggestions. Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to be different anyway. I believe I gave a couple of points to consider as well. > > > Its deployed so obviously it works. We're not talking about something > > > no one has ever tried. This is documenting a set of extensions that > > > are in use. > > > > Being used by a few people and being used as widely as RPSL is used today > > are two different things. It is obviously not being used widely if RIPE > > just got it's test version of the database and the tools out a month or > > something like that ago. > > Larry could probably give you the lineage of this work better than I > could. I think David Kessens was working on expressing IPv6 policy in > RPSL as far back as 1997 or so. Right.. but it has gotten nowhere in about five years if so. > RIPE uses its database mostly as a Internet address and AS registry. > That you can express policy in RPSL for RIPE is just an added benefit > for their customers. RIPE has had IPv6 inetnum records for a very > long time for the purpose of address registry. This is irrelevant: the fact stands that at least in the RIPE region (I don't know much of the others, but I guess the situation is pretty much the same), RPSLng has *not* been deployed at all. So, it seems to me that any statements of its wide use are quite questionable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 07:09:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03160 for ; Tue, 16 Sep 2003 07:09:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDgf-0001Ar-Gg; Tue, 16 Sep 2003 07:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDgD-00014V-Gk for rps@optimus.ietf.org; Tue, 16 Sep 2003 07:07:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03046; Tue, 16 Sep 2003 07:07:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zDg9-0006tD-00; Tue, 16 Sep 2003 07:07:29 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19zDg8-0006sn-00; Tue, 16 Sep 2003 07:07:28 -0400 Received: from mrp.net (CPE-144-137-204-169.sa.bigpond.net.au [144.137.204.169]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8GB5p9e004214 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 16 Sep 2003 20:36:34 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F66EE8E.1060104@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309151931.h8FJVGL1011419@mail.avici.com> In-Reply-To: <200309151931.h8FJVGL1011419@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 20:35:50 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Transition issues are very important in a RR. You have to assume that > old software will be around for quite a long time. Someone is bound > to be using old code for a very long time. > I'm not disputing that. What I am suggesting is that if there was a version number (say) negotiation mechanism then new code could negotiate for support of new features with a server but without this a new server would return old style data (which will avoid the old code barfing). Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 07:09:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03175 for ; Tue, 16 Sep 2003 07:09:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDhY-0001Dx-QA for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 07:08:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GB8uoA004699 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 07:08:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDhY-0001Di-Kl for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 07:08:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03119 for ; Tue, 16 Sep 2003 07:08:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zDhU-0006v9-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 07:08:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zDhT-0006v5-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 07:08:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDgf-0001Ar-Gg; Tue, 16 Sep 2003 07:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDgD-00014V-Gk for rps@optimus.ietf.org; Tue, 16 Sep 2003 07:07:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03046; Tue, 16 Sep 2003 07:07:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zDg9-0006tD-00; Tue, 16 Sep 2003 07:07:29 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19zDg8-0006sn-00; Tue, 16 Sep 2003 07:07:28 -0400 Received: from mrp.net (CPE-144-137-204-169.sa.bigpond.net.au [144.137.204.169]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8GB5p9e004214 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 16 Sep 2003 20:36:34 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F66EE8E.1060104@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309151931.h8FJVGL1011419@mail.avici.com> In-Reply-To: <200309151931.h8FJVGL1011419@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 20:35:50 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Transition issues are very important in a RR. You have to assume that > old software will be around for quite a long time. Someone is bound > to be using old code for a very long time. > I'm not disputing that. What I am suggesting is that if there was a version number (say) negotiation mechanism then new code could negotiate for support of new features with a server but without this a new server would return old style data (which will avoid the old code barfing). Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 07:11:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03329 for ; Tue, 16 Sep 2003 07:11:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDjZ-0001Om-7P; Tue, 16 Sep 2003 07:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDjM-0001ON-Sv for rps@optimus.ietf.org; Tue, 16 Sep 2003 07:10:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03263; Tue, 16 Sep 2003 07:10:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zDjI-0006xu-00; Tue, 16 Sep 2003 07:10:44 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19zDjH-0006wo-00; Tue, 16 Sep 2003 07:10:43 -0400 Received: from mrp.net (CPE-144-137-204-169.sa.bigpond.net.au [144.137.204.169]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8GB9i9e004249 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 16 Sep 2003 20:39:53 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F66EF77.1000908@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309151930.h8FJUlL1011384@mail.avici.com> In-Reply-To: <200309151930.h8FJUlL1011384@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 20:39:43 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Any AS object that provides policy already has many import and export > statements. Today IPv4 and IPv6 policy does not match so different > statements are needed anyway. For example, AS3561 has 737 import > statements and 738 export statements. I would venture to guess their > IPv6 policy is a lot simpler. > My high level policy (ignoring encoding it in some language) is likely to be the same irrespective of whether it is IPv4 or IPv6. My _application_ of that policy to a peer may be different, ie if the peer doesn't speak IPv4 there would be no need to include any IPv4 components. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 07:11:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03350 for ; Tue, 16 Sep 2003 07:11:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDjb-0001Qk-BQ for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 07:11:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GBB3dN005492 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 07:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDjb-0001QV-5w for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 07:11:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03270 for ; Tue, 16 Sep 2003 07:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zDjW-0006yB-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 07:10:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zDjW-0006y8-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 07:10:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDjZ-0001Om-7P; Tue, 16 Sep 2003 07:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDjM-0001ON-Sv for rps@optimus.ietf.org; Tue, 16 Sep 2003 07:10:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03263; Tue, 16 Sep 2003 07:10:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zDjI-0006xu-00; Tue, 16 Sep 2003 07:10:44 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19zDjH-0006wo-00; Tue, 16 Sep 2003 07:10:43 -0400 Received: from mrp.net (CPE-144-137-204-169.sa.bigpond.net.au [144.137.204.169]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8GB9i9e004249 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 16 Sep 2003 20:39:53 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F66EF77.1000908@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309151930.h8FJUlL1011384@mail.avici.com> In-Reply-To: <200309151930.h8FJUlL1011384@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 20:39:43 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Any AS object that provides policy already has many import and export > statements. Today IPv4 and IPv6 policy does not match so different > statements are needed anyway. For example, AS3561 has 737 import > statements and 738 export statements. I would venture to guess their > IPv6 policy is a lot simpler. > My high level policy (ignoring encoding it in some language) is likely to be the same irrespective of whether it is IPv4 or IPv6. My _application_ of that policy to a peer may be different, ie if the peer doesn't speak IPv4 there would be no need to include any IPv4 components. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 08:43:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09733 for ; Tue, 16 Sep 2003 08:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFAa-0003ta-HT; Tue, 16 Sep 2003 08:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zF9k-0003t4-3O for rps@optimus.ietf.org; Tue, 16 Sep 2003 08:42:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09683; Tue, 16 Sep 2003 08:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zF9i-0000gL-00; Tue, 16 Sep 2003 08:42:06 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19zF9h-0000g4-00; Tue, 16 Sep 2003 08:42:06 -0400 Received: from mrp.net (CPE-144-137-204-169.sa.bigpond.net.au [144.137.204.169]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8GCdu9e004557 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 16 Sep 2003 22:11:14 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F67049B.2030403@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309161153.h8GBrJL1029455@mail.avici.com> In-Reply-To: <200309161153.h8GBrJL1029455@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 22:09:55 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Since there is no version negotiation, we'd need a new set of queries > with version negotiation. The old set could be assumed to be the old > versions. > Well the obvious question to ask is why not add it (version negotiation that is). This would require some codification of the exchange between a client and a server but wouldn't this be a good thing anyway? > The next issue is you'd need a reliable means to translate the new > format into the old. This does constrain the syntax somewhat, but > would allow ipv4,ipv6 policy to be specified and just the ipv4 part > returned to the old query. > Ah but would an organisation using an old client write new syntax objects anyway? > This boild down to just a "small matter of code". RtConfig is open > source. Would you like to contribute the changes? :-) > Given my lack of C++ skills (combined with my lack of gcc v2 compiler) I'm not sure I would be too helpful in that regard :-) However I guess I would be happy to assist updating RFC 2650. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 08:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09752 for ; Tue, 16 Sep 2003 08:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFAf-0003uz-Mi for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 08:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GCh5l9015055 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 08:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFAf-0003uk-Ek for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 08:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09708 for ; Tue, 16 Sep 2003 08:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zFAe-0000gv-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 08:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zFAd-0000gs-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 08:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFAa-0003ta-HT; Tue, 16 Sep 2003 08:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zF9k-0003t4-3O for rps@optimus.ietf.org; Tue, 16 Sep 2003 08:42:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09683; Tue, 16 Sep 2003 08:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zF9i-0000gL-00; Tue, 16 Sep 2003 08:42:06 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 19zF9h-0000g4-00; Tue, 16 Sep 2003 08:42:06 -0400 Received: from mrp.net (CPE-144-137-204-169.sa.bigpond.net.au [144.137.204.169]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.9/8.12.9) with ESMTP id h8GCdu9e004557 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 16 Sep 2003 22:11:14 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F67049B.2030403@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309161153.h8GBrJL1029455@mail.avici.com> In-Reply-To: <200309161153.h8GBrJL1029455@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 22:09:55 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Since there is no version negotiation, we'd need a new set of queries > with version negotiation. The old set could be assumed to be the old > versions. > Well the obvious question to ask is why not add it (version negotiation that is). This would require some codification of the exchange between a client and a server but wouldn't this be a good thing anyway? > The next issue is you'd need a reliable means to translate the new > format into the old. This does constrain the syntax somewhat, but > would allow ipv4,ipv6 policy to be specified and just the ipv4 part > returned to the old query. > Ah but would an organisation using an old client write new syntax objects anyway? > This boild down to just a "small matter of code". RtConfig is open > source. Would you like to contribute the changes? :-) > Given my lack of C++ skills (combined with my lack of gcc v2 compiler) I'm not sure I would be too helpful in that regard :-) However I guess I would be happy to assist updating RFC 2650. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 09:57:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13248 for ; Tue, 16 Sep 2003 09:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGKD-0007qr-9r; Tue, 16 Sep 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zEIw-0002Pz-TX for rps@optimus.ietf.org; Tue, 16 Sep 2003 07:47:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04313; Tue, 16 Sep 2003 07:47:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zEIw-0007Ma-00; Tue, 16 Sep 2003 07:47:34 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19zEIv-0007MX-00; Tue, 16 Sep 2003 07:47:33 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8GBkfL1029244; Tue, 16 Sep 2003 07:46:43 -0400 Message-Id: <200309161146.h8GBkfL1029244@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 16 Sep 2003 08:19:49 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 07:46:52 -0400 In message , Pekka Savola w rites: > > Did you even read what I wrote? I certainly didn't see a problem in > having different IPv6 and IPv4 records, because, well, they have to be > different anyway. I believe I gave a couple of points to consider as > well. If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst. As an aside, my guess is that we'll have older RPSL tools around for anywhere from 2-5 years or until IPv4 only networks become rare (which is likely to be longer the way things are going). > > > > Its deployed so obviously it works. We're not talking about something > > > > no one has ever tried. This is documenting a set of extensions that > > > > are in use. > > > > > > Being used by a few people and being used as widely as RPSL is used today > > > > are two different things. It is obviously not being used widely if RIPE > > > just got it's test version of the database and the tools out a month or > > > something like that ago. > > > > Larry could probably give you the lineage of this work better than I > > could. I think David Kessens was working on expressing IPv6 policy in > > RPSL as far back as 1997 or so. > > Right.. but it has gotten nowhere in about five years if so. The document you are reviewing is the result of the work expressing policy for IPv6, so it hasn't gone nowhere. I'm not sure whether David was working more with the IPv6 inetnum records used for address registry or policy back then. > > RIPE uses its database mostly as a Internet address and AS registry. > > That you can express policy in RPSL for RIPE is just an added benefit > > for their customers. RIPE has had IPv6 inetnum records for a very > > long time for the purpose of address registry. > > This is irrelevant: the fact stands that at least in the RIPE region (I > don't know much of the others, but I guess the situation is pretty much > the same), RPSLng has *not* been deployed at all. So, it seems to me that > any statements of its wide use are quite questionable. A lot of RPSL use is explicitly to express routing policy. While RIPE is a major user of RPSL and one of the major contributors to RPSL, their use of it is limited in this way. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 09:57:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13275 for ; Tue, 16 Sep 2003 09:57:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGKN-0007uQ-Ul for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 09:57:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GDvBA0030396 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 09:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGKN-0007uB-R3 for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 09:57:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13206 for ; Tue, 16 Sep 2003 09:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zGKL-0001u7-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 09:57:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zGKL-0001u3-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 09:57:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGKD-0007qr-9r; Tue, 16 Sep 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zEIw-0002Pz-TX for rps@optimus.ietf.org; Tue, 16 Sep 2003 07:47:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04313; Tue, 16 Sep 2003 07:47:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zEIw-0007Ma-00; Tue, 16 Sep 2003 07:47:34 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19zEIv-0007MX-00; Tue, 16 Sep 2003 07:47:33 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8GBkfL1029244; Tue, 16 Sep 2003 07:46:43 -0400 Message-Id: <200309161146.h8GBkfL1029244@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 16 Sep 2003 08:19:49 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 07:46:52 -0400 In message , Pekka Savola w rites: > > Did you even read what I wrote? I certainly didn't see a problem in > having different IPv6 and IPv4 records, because, well, they have to be > different anyway. I believe I gave a couple of points to consider as > well. If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst. As an aside, my guess is that we'll have older RPSL tools around for anywhere from 2-5 years or until IPv4 only networks become rare (which is likely to be longer the way things are going). > > > > Its deployed so obviously it works. We're not talking about something > > > > no one has ever tried. This is documenting a set of extensions that > > > > are in use. > > > > > > Being used by a few people and being used as widely as RPSL is used today > > > > are two different things. It is obviously not being used widely if RIPE > > > just got it's test version of the database and the tools out a month or > > > something like that ago. > > > > Larry could probably give you the lineage of this work better than I > > could. I think David Kessens was working on expressing IPv6 policy in > > RPSL as far back as 1997 or so. > > Right.. but it has gotten nowhere in about five years if so. The document you are reviewing is the result of the work expressing policy for IPv6, so it hasn't gone nowhere. I'm not sure whether David was working more with the IPv6 inetnum records used for address registry or policy back then. > > RIPE uses its database mostly as a Internet address and AS registry. > > That you can express policy in RPSL for RIPE is just an added benefit > > for their customers. RIPE has had IPv6 inetnum records for a very > > long time for the purpose of address registry. > > This is irrelevant: the fact stands that at least in the RIPE region (I > don't know much of the others, but I guess the situation is pretty much > the same), RPSLng has *not* been deployed at all. So, it seems to me that > any statements of its wide use are quite questionable. A lot of RPSL use is explicitly to express routing policy. While RIPE is a major user of RPSL and one of the major contributors to RPSL, their use of it is limited in this way. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 10:42:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13249 for ; Tue, 16 Sep 2003 09:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGKD-0007qz-GL; Tue, 16 Sep 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zEQc-0002V8-48 for rps@optimus.ietf.org; Tue, 16 Sep 2003 07:55:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04556; Tue, 16 Sep 2003 07:55:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zEQb-0007Pc-00; Tue, 16 Sep 2003 07:55:29 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19zEQa-0007PM-00; Tue, 16 Sep 2003 07:55:28 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8GBrJL1029455; Tue, 16 Sep 2003 07:53:20 -0400 Message-Id: <200309161153.h8GBrJL1029455@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 16 Sep 2003 20:35:50 +0930." <3F66EE8E.1060104@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 07:53:30 -0400 In message <3F66EE8E.1060104@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > Transition issues are very important in a RR. You have to assume that > > old software will be around for quite a long time. Someone is bound > > to be using old code for a very long time. > > > > I'm not disputing that. What I am suggesting is that if there was a > version number (say) negotiation mechanism then new code could negotiate > for support of new features with a server but without this a new server > would return old style data (which will avoid the old code barfing). > > Mark. Since there is no version negotiation, we'd need a new set of queries with version negotiation. The old set could be assumed to be the old versions. The next issue is you'd need a reliable means to translate the new format into the old. This does constrain the syntax somewhat, but would allow ipv4,ipv6 policy to be specified and just the ipv4 part returned to the old query. This boild down to just a "small matter of code". RtConfig is open source. Would you like to contribute the changes? :-) Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 10:42:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13276 for ; Tue, 16 Sep 2003 09:57:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGKO-0007ug-Pw for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 09:57:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GDvCZh030412 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 09:57:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGKO-0007uR-LT for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 09:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13205 for ; Tue, 16 Sep 2003 09:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zGKL-0001uA-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 09:57:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zGKL-0001u4-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 09:57:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGKD-0007qz-GL; Tue, 16 Sep 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zEQc-0002V8-48 for rps@optimus.ietf.org; Tue, 16 Sep 2003 07:55:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04556; Tue, 16 Sep 2003 07:55:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zEQb-0007Pc-00; Tue, 16 Sep 2003 07:55:29 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19zEQa-0007PM-00; Tue, 16 Sep 2003 07:55:28 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8GBrJL1029455; Tue, 16 Sep 2003 07:53:20 -0400 Message-Id: <200309161153.h8GBrJL1029455@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 16 Sep 2003 20:35:50 +0930." <3F66EE8E.1060104@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 07:53:30 -0400 In message <3F66EE8E.1060104@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > Transition issues are very important in a RR. You have to assume that > > old software will be around for quite a long time. Someone is bound > > to be using old code for a very long time. > > > > I'm not disputing that. What I am suggesting is that if there was a > version number (say) negotiation mechanism then new code could negotiate > for support of new features with a server but without this a new server > would return old style data (which will avoid the old code barfing). > > Mark. Since there is no version negotiation, we'd need a new set of queries with version negotiation. The old set could be assumed to be the old versions. The next issue is you'd need a reliable means to translate the new format into the old. This does constrain the syntax somewhat, but would allow ipv4,ipv6 policy to be specified and just the ipv4 part returned to the old query. This boild down to just a "small matter of code". RtConfig is open source. Would you like to contribute the changes? :-) Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 14:36:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01030 for ; Tue, 16 Sep 2003 14:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKgD-0002z1-A9; Tue, 16 Sep 2003 14:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKfY-0002xp-E2 for rps@optimus.ietf.org; Tue, 16 Sep 2003 14:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00951; Tue, 16 Sep 2003 14:35:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKfV-0007Mm-00; Tue, 16 Sep 2003 14:35:17 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKfV-0007MC-00; Tue, 16 Sep 2003 14:35:17 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8GIYcg32214; Tue, 16 Sep 2003 21:34:39 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309161146.h8GBkfL1029244@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 21:34:37 +0300 (EEST) On Tue, 16 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola w > rites: > > > > Did you even read what I wrote? I certainly didn't see a problem in > > having different IPv6 and IPv4 records, because, well, they have to be > > different anyway. I believe I gave a couple of points to consider as > > well. > > If you have no issue with separate IPv6 and IPv4 records then the > matter is resolved. There is no transition problem, nor is there any > long term problem other than separate IPv6 and IPv4 records which may > be a nuisance later at worst. I recall that RPSLng also supports ipv4.unicast (which is supported by RPSL as well), and ipv4.multicast. The issue is clearly not settled by that, I think, > > > RIPE uses its database mostly as a Internet address and AS registry. > > > That you can express policy in RPSL for RIPE is just an added benefit > > > for their customers. RIPE has had IPv6 inetnum records for a very > > > long time for the purpose of address registry. > > > > This is irrelevant: the fact stands that at least in the RIPE region (I > > don't know much of the others, but I guess the situation is pretty much > > the same), RPSLng has *not* been deployed at all. So, it seems to me that > > any statements of its wide use are quite questionable. > > A lot of RPSL use is explicitly to express routing policy. While RIPE > is a major user of RPSL and one of the major contributors to RPSL, > their use of it is limited in this way. Exactly. Operators in the RIPE region have, for some time now, expressed a need for a database supporting expressing IPv6 routing policies (more than anything else!). It only recently got announced (as a test version, I recall). Which seems to strongly say that the RPSLng use has been minimal at best, and there has been no real deployment. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 14:36:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01048 for ; Tue, 16 Sep 2003 14:36:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKgO-00031S-5X for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 14:36:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GIaCFt011611 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 14:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKgO-00031C-2F for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 14:36:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01015 for ; Tue, 16 Sep 2003 14:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKgL-0007Nk-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 14:36:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zKgK-0007Nh-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 14:36:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKgD-0002z1-A9; Tue, 16 Sep 2003 14:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKfY-0002xp-E2 for rps@optimus.ietf.org; Tue, 16 Sep 2003 14:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00951; Tue, 16 Sep 2003 14:35:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKfV-0007Mm-00; Tue, 16 Sep 2003 14:35:17 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKfV-0007MC-00; Tue, 16 Sep 2003 14:35:17 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8GIYcg32214; Tue, 16 Sep 2003 21:34:39 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309161146.h8GBkfL1029244@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 21:34:37 +0300 (EEST) On Tue, 16 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola w > rites: > > > > Did you even read what I wrote? I certainly didn't see a problem in > > having different IPv6 and IPv4 records, because, well, they have to be > > different anyway. I believe I gave a couple of points to consider as > > well. > > If you have no issue with separate IPv6 and IPv4 records then the > matter is resolved. There is no transition problem, nor is there any > long term problem other than separate IPv6 and IPv4 records which may > be a nuisance later at worst. I recall that RPSLng also supports ipv4.unicast (which is supported by RPSL as well), and ipv4.multicast. The issue is clearly not settled by that, I think, > > > RIPE uses its database mostly as a Internet address and AS registry. > > > That you can express policy in RPSL for RIPE is just an added benefit > > > for their customers. RIPE has had IPv6 inetnum records for a very > > > long time for the purpose of address registry. > > > > This is irrelevant: the fact stands that at least in the RIPE region (I > > don't know much of the others, but I guess the situation is pretty much > > the same), RPSLng has *not* been deployed at all. So, it seems to me that > > any statements of its wide use are quite questionable. > > A lot of RPSL use is explicitly to express routing policy. While RIPE > is a major user of RPSL and one of the major contributors to RPSL, > their use of it is limited in this way. Exactly. Operators in the RIPE region have, for some time now, expressed a need for a database supporting expressing IPv6 routing policies (more than anything else!). It only recently got announced (as a test version, I recall). Which seems to strongly say that the RPSLng use has been minimal at best, and there has been no real deployment. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 16:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10194 for ; Tue, 16 Sep 2003 16:25:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMNh-0007Yv-1i; Tue, 16 Sep 2003 16:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zM9c-0006s7-NE for rps@optimus.ietf.org; Tue, 16 Sep 2003 16:10:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09109; Tue, 16 Sep 2003 16:10:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zM9b-0001Y9-00; Tue, 16 Sep 2003 16:10:27 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19zM9a-0001Y6-00; Tue, 16 Sep 2003 16:10:26 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8GK9QYf027155; Tue, 16 Sep 2003 16:09:33 -0400 Message-Id: <200309162009.h8GK9QYf027155@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 16 Sep 2003 22:09:55 +0930." <3F67049B.2030403@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 16:09:36 -0400 In message <3F67049B.2030403@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > Since there is no version negotiation, we'd need a new set of queries > > with version negotiation. The old set could be assumed to be the old > > versions. > > > Well the obvious question to ask is why not add it (version negotiation > that is). This would require some codification of the exchange between a > client and a server but wouldn't this be a good thing anyway? That's entirely an RtConfig issue but it would make RPSL transitions easier. Handling multiple protocol versions is not trivial though. > > The next issue is you'd need a reliable means to translate the new > > format into the old. This does constrain the syntax somewhat, but > > would allow ipv4,ipv6 policy to be specified and just the ipv4 part > > returned to the old query. > > > Ah but would an organisation using an old client write new syntax > objects anyway? No but they may need to be able to read new objects that others have written to figure out what's going on. > > This boild down to just a "small matter of code". RtConfig is open > > source. Would you like to contribute the changes? :-) > > > Given my lack of C++ skills (combined with my lack of gcc v2 compiler) > I'm not sure I would be too helpful in that regard :-) However I guess I > would be happy to assist updating RFC 2650. I was kidding about writing code for RtConfig, but the point is that keeping specification acheivable has always been an IETF goal. In this case we want to keep in mind the limited staff working on the tools or we end up with nothing that works in a reasonable time. > Mark. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 16:25:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10213 for ; Tue, 16 Sep 2003 16:25:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMNo-0007au-5J for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 16:25:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GKP8Jo029186 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 16:25:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMNo-0007af-1r for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 16:25:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10176 for ; Tue, 16 Sep 2003 16:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMNm-0001sd-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 16:25:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zMNl-0001sa-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 16:25:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMNh-0007Yv-1i; Tue, 16 Sep 2003 16:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zM9c-0006s7-NE for rps@optimus.ietf.org; Tue, 16 Sep 2003 16:10:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09109; Tue, 16 Sep 2003 16:10:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zM9b-0001Y9-00; Tue, 16 Sep 2003 16:10:27 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19zM9a-0001Y6-00; Tue, 16 Sep 2003 16:10:26 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8GK9QYf027155; Tue, 16 Sep 2003 16:09:33 -0400 Message-Id: <200309162009.h8GK9QYf027155@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 16 Sep 2003 22:09:55 +0930." <3F67049B.2030403@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 16:09:36 -0400 In message <3F67049B.2030403@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > Since there is no version negotiation, we'd need a new set of queries > > with version negotiation. The old set could be assumed to be the old > > versions. > > > Well the obvious question to ask is why not add it (version negotiation > that is). This would require some codification of the exchange between a > client and a server but wouldn't this be a good thing anyway? That's entirely an RtConfig issue but it would make RPSL transitions easier. Handling multiple protocol versions is not trivial though. > > The next issue is you'd need a reliable means to translate the new > > format into the old. This does constrain the syntax somewhat, but > > would allow ipv4,ipv6 policy to be specified and just the ipv4 part > > returned to the old query. > > > Ah but would an organisation using an old client write new syntax > objects anyway? No but they may need to be able to read new objects that others have written to figure out what's going on. > > This boild down to just a "small matter of code". RtConfig is open > > source. Would you like to contribute the changes? :-) > > > Given my lack of C++ skills (combined with my lack of gcc v2 compiler) > I'm not sure I would be too helpful in that regard :-) However I guess I > would be happy to assist updating RFC 2650. I was kidding about writing code for RtConfig, but the point is that keeping specification acheivable has always been an IETF goal. In this case we want to keep in mind the limited staff working on the tools or we end up with nothing that works in a reasonable time. > Mark. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 16 16:58:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11820 for ; Tue, 16 Sep 2003 16:58:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMsf-00008H-ME; Tue, 16 Sep 2003 16:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMaB-0008A0-AV for rps@optimus.ietf.org; Tue, 16 Sep 2003 16:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10857; Tue, 16 Sep 2003 16:37:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMa9-00025x-00; Tue, 16 Sep 2003 16:37:53 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19zMa8-00025u-00; Tue, 16 Sep 2003 16:37:53 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8GKaNYf030833; Tue, 16 Sep 2003 16:36:24 -0400 Message-Id: <200309162036.h8GKaNYf030833@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 16 Sep 2003 21:34:37 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 16:36:33 -0400 In message , Pekka Savola writes: > On Tue, 16 Sep 2003, Curtis Villamizar wrote: > > In message , Pekka Savo > la w > > rites: > > > > > > Did you even read what I wrote? I certainly didn't see a problem in > > > having different IPv6 and IPv4 records, because, well, they have to be > > > different anyway. I believe I gave a couple of points to consider as > > > well. > > > > If you have no issue with separate IPv6 and IPv4 records then the > > matter is resolved. There is no transition problem, nor is there any > > long term problem other than separate IPv6 and IPv4 records which may > > be a nuisance later at worst. > > I recall that RPSLng also supports ipv4.unicast (which is supported by > RPSL as well), and ipv4.multicast. The issue is clearly not settled by > that, I think, As far as I can tell you have made no point which has withstood strutiny. If you think there is a problem, please state the problem concisely. > > > > RIPE uses its database mostly as a Internet address and AS registry. > > > > That you can express policy in RPSL for RIPE is just an added benefit > > > > for their customers. RIPE has had IPv6 inetnum records for a very > > > > long time for the purpose of address registry. > > > > > > This is irrelevant: the fact stands that at least in the RIPE region (I > > > don't know much of the others, but I guess the situation is pretty much > > > the same), RPSLng has *not* been deployed at all. So, it seems to me tha > t > > > any statements of its wide use are quite questionable. > > > > A lot of RPSL use is explicitly to express routing policy. While RIPE > > is a major user of RPSL and one of the major contributors to RPSL, > > their use of it is limited in this way. > > Exactly. Operators in the RIPE region have, for some time now, expressed > a need for a database supporting expressing IPv6 routing policies (more > than anything else!). It only recently got announced (as a test version, > I recall). Which seems to strongly say that the RPSLng use has been > minimal at best, and there has been no real deployment. Long before RPSL itself showed up on RIPE at all it was used in production by some major ISPs. For example, the server at rpsl.ra.net was used as production by some ISP while they also populated the server that returned queries as whois.ra.net. It was over a year after RPSL was in production use that RIPE officially supported it. Might even have been two years lag. That RIPE is not going to risk disrupting their IPv4 business for IPv6 needs is not surprising. I'm not in operations anymore so I don't know the extent to which RPSLng is used. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 16 16:58:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11852 for ; Tue, 16 Sep 2003 16:58:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMtO-0000BL-Ey for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 16:57:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GKvkE6000698 for rps-archive@odin.ietf.org; Tue, 16 Sep 2003 16:57:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMtO-0000BB-8x for rps-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 16:57:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11803 for ; Tue, 16 Sep 2003 16:57:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMtM-0002Q6-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 16:57:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zMtL-0002Q3-00 for rps-web-archive@ietf.org; Tue, 16 Sep 2003 16:57:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMsf-00008H-ME; Tue, 16 Sep 2003 16:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMaB-0008A0-AV for rps@optimus.ietf.org; Tue, 16 Sep 2003 16:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10857; Tue, 16 Sep 2003 16:37:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMa9-00025x-00; Tue, 16 Sep 2003 16:37:53 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19zMa8-00025u-00; Tue, 16 Sep 2003 16:37:53 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8GKaNYf030833; Tue, 16 Sep 2003 16:36:24 -0400 Message-Id: <200309162036.h8GKaNYf030833@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 16 Sep 2003 21:34:37 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 16:36:33 -0400 In message , Pekka Savola writes: > On Tue, 16 Sep 2003, Curtis Villamizar wrote: > > In message , Pekka Savo > la w > > rites: > > > > > > Did you even read what I wrote? I certainly didn't see a problem in > > > having different IPv6 and IPv4 records, because, well, they have to be > > > different anyway. I believe I gave a couple of points to consider as > > > well. > > > > If you have no issue with separate IPv6 and IPv4 records then the > > matter is resolved. There is no transition problem, nor is there any > > long term problem other than separate IPv6 and IPv4 records which may > > be a nuisance later at worst. > > I recall that RPSLng also supports ipv4.unicast (which is supported by > RPSL as well), and ipv4.multicast. The issue is clearly not settled by > that, I think, As far as I can tell you have made no point which has withstood strutiny. If you think there is a problem, please state the problem concisely. > > > > RIPE uses its database mostly as a Internet address and AS registry. > > > > That you can express policy in RPSL for RIPE is just an added benefit > > > > for their customers. RIPE has had IPv6 inetnum records for a very > > > > long time for the purpose of address registry. > > > > > > This is irrelevant: the fact stands that at least in the RIPE region (I > > > don't know much of the others, but I guess the situation is pretty much > > > the same), RPSLng has *not* been deployed at all. So, it seems to me tha > t > > > any statements of its wide use are quite questionable. > > > > A lot of RPSL use is explicitly to express routing policy. While RIPE > > is a major user of RPSL and one of the major contributors to RPSL, > > their use of it is limited in this way. > > Exactly. Operators in the RIPE region have, for some time now, expressed > a need for a database supporting expressing IPv6 routing policies (more > than anything else!). It only recently got announced (as a test version, > I recall). Which seems to strongly say that the RPSLng use has been > minimal at best, and there has been no real deployment. Long before RPSL itself showed up on RIPE at all it was used in production by some major ISPs. For example, the server at rpsl.ra.net was used as production by some ISP while they also populated the server that returned queries as whois.ra.net. It was over a year after RPSL was in production use that RIPE officially supported it. Might even have been two years lag. That RIPE is not going to risk disrupting their IPv4 business for IPv6 needs is not surprising. I'm not in operations anymore so I don't know the extent to which RPSLng is used. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Thu Sep 18 07:13:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07212 for ; Thu, 18 Sep 2003 07:13:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zwic-0000iC-0D; Thu, 18 Sep 2003 07:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zwhn-0000hZ-CL for rps@optimus.ietf.org; Thu, 18 Sep 2003 07:12:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07160; Thu, 18 Sep 2003 07:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zwhm-0004Sq-00; Thu, 18 Sep 2003 07:12:10 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19zwhl-0004S0-00; Thu, 18 Sep 2003 07:12:10 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8IBBOm17793; Thu, 18 Sep 2003 14:11:25 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309162036.h8GKaNYf030833@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Sep 2003 14:11:24 +0300 (EEST) On Tue, 16 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola > writes: > > On Tue, 16 Sep 2003, Curtis Villamizar wrote: > > > In message , Pekka Savo > > la w > > > rites: > > > > > > > > Did you even read what I wrote? I certainly didn't see a problem in > > > > having different IPv6 and IPv4 records, because, well, they have to be > > > > different anyway. I believe I gave a couple of points to consider as > > > > well. > > > > > > If you have no issue with separate IPv6 and IPv4 records then the > > > matter is resolved. There is no transition problem, nor is there any > > > long term problem other than separate IPv6 and IPv4 records which may > > > be a nuisance later at worst. > > > > I recall that RPSLng also supports ipv4.unicast (which is supported by > > RPSL as well), and ipv4.multicast. The issue is clearly not settled by > > that, I think, > > As far as I can tell you have made no point which has withstood > strutiny. If you think there is a problem, please state the problem > concisely. I'll just cut-n-paste my earlier response below. There are certainly open issues on keeping IPv4 unicast and multicast data in sync. Further, it might be desirable to have IPv4 unicast in the same database, so that you could just run the IRRToolSet (or some other tool) just once, from one database to get both v4 and v6 data, but this is a smaller point. ====== "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right? But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach. As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features. Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only. But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure. Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng! We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. ===== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Thu Sep 18 07:13:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07227 for ; Thu, 18 Sep 2003 07:13:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zwit-0000kV-PS for rps-archive@odin.ietf.org; Thu, 18 Sep 2003 07:13:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IBDJLc002880 for rps-archive@odin.ietf.org; Thu, 18 Sep 2003 07:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zwit-0000kN-3m for rps-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 07:13:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07190 for ; Thu, 18 Sep 2003 07:13:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zwis-0004Tm-00 for rps-web-archive@ietf.org; Thu, 18 Sep 2003 07:13:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zwis-0004Ti-00 for rps-web-archive@ietf.org; Thu, 18 Sep 2003 07:13:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zwic-0000iC-0D; Thu, 18 Sep 2003 07:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zwhn-0000hZ-CL for rps@optimus.ietf.org; Thu, 18 Sep 2003 07:12:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07160; Thu, 18 Sep 2003 07:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zwhm-0004Sq-00; Thu, 18 Sep 2003 07:12:10 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19zwhl-0004S0-00; Thu, 18 Sep 2003 07:12:10 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8IBBOm17793; Thu, 18 Sep 2003 14:11:25 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309162036.h8GKaNYf030833@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Sep 2003 14:11:24 +0300 (EEST) On Tue, 16 Sep 2003, Curtis Villamizar wrote: > In message , Pekka Savola > writes: > > On Tue, 16 Sep 2003, Curtis Villamizar wrote: > > > In message , Pekka Savo > > la w > > > rites: > > > > > > > > Did you even read what I wrote? I certainly didn't see a problem in > > > > having different IPv6 and IPv4 records, because, well, they have to be > > > > different anyway. I believe I gave a couple of points to consider as > > > > well. > > > > > > If you have no issue with separate IPv6 and IPv4 records then the > > > matter is resolved. There is no transition problem, nor is there any > > > long term problem other than separate IPv6 and IPv4 records which may > > > be a nuisance later at worst. > > > > I recall that RPSLng also supports ipv4.unicast (which is supported by > > RPSL as well), and ipv4.multicast. The issue is clearly not settled by > > that, I think, > > As far as I can tell you have made no point which has withstood > strutiny. If you think there is a problem, please state the problem > concisely. I'll just cut-n-paste my earlier response below. There are certainly open issues on keeping IPv4 unicast and multicast data in sync. Further, it might be desirable to have IPv4 unicast in the same database, so that you could just run the IRRToolSet (or some other tool) just once, from one database to get both v4 and v6 data, but this is a smaller point. ====== "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right? But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach. As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features. Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only. But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure. Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng! We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. ===== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Fri Sep 19 12:49:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13994 for ; Fri, 19 Sep 2003 12:49:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ORK-0000Ol-Vu; Fri, 19 Sep 2003 12:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nfq-0007N1-G8 for rps@optimus.ietf.org; Fri, 19 Sep 2003 11:59:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02321; Fri, 19 Sep 2003 11:59:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0MJY-00026j-00; Fri, 19 Sep 2003 10:32:52 -0400 Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx with esmtp (Exim 4.12) id 1A0M7n-0003XY-00; Fri, 19 Sep 2003 10:20:44 -0400 Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by segue.merit.edu (Postfix) with ESMTP id 7A6BB5DD9C; Fri, 19 Sep 2003 10:20:07 -0400 (EDT) Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard From: "Larry J. Blunk" To: Pekka Savola Cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Merit Network, Inc. Message-Id: <1063981473.3370.23.camel@ablate.merit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Sep 2003 10:24:33 -0400 Content-Transfer-Encoding: 7bit Pekka and Curtis, Thanks for the feedback. Sorry for not responding sooner (I've been trying to absorb everything and formulate a response). I've been updating the draft to reflect many of your comments (thanks, Pekka). On Fri, 2003-09-19 at 03:21, Pekka Savola wrote: > On Thu, 18 Sep 2003, Curtis Villamizar wrote: > > You seem not to be missing something. The mp-* and non- mp-* entries > > will be in the same database. > > Probably yes, in the longer term; that helps some scenarios but doesn't > eliminate the issues. I think there indeed needs to be some text to clarify the use of mp-* and non mp-* entries. Should the document recommend the use of non-mp entries to express v4 policies for existing non-RPSLng compliant tools? Should this be mandatory or optional? And perhaps more controversily, if there are mp- attributes present in an object, should the non-mp attributes be ignored by RPSLng compliant tools to reduce the possibility for conflicts. Further should there be clarification on the case where an import, export, or default attribute references a route-set/filter-set/etc. which contains mp- attributes? Should RPSLng compliant tools ignore the mp- attributes in this case (as non-RPSLng compliant tools would do). > > > For backwards compatibility the ipv4 > > unicast policy will be in the same database but at least initially > > expressed as non- mp-* policy statements. > > Right. One option I thought about would be to change the mp-members, mp-filter, mp-peer, mp-peering, and interface attributes to be IPv6 specific. In other words, rename them to something like members6, filter6, peer6, peering6, and interface6 (well, perhaps not the interface attribute since it introduces new functionality). This would preserve explicit support for backward compatibility with IPv4 as one would need to continue to express IPv4 prefixes and policy info in the existing RPSL attributes. I think backward compatibility in these attributes is more important than the import, export, and default attributes as I believe one is more likely to reference another org's route-set, filter-set, etc., than another org's aut-num object. -Larry Blunk Merit > > > Since policy is currently > > quite different between unicase and multicase > > A fatal assumption. In about all academic networks and backbone transit > providers -- which are significant users of RPSLng -- multicast and > unicast topologies are very much the same. > > Ours (and many others') policies are identical. > > > and ipv4 and ipv6 this > > is not only not a problem, it is not even an inconvenience. > > A smaller issues, yes. However, from "the use of tools" perspective, > people will use both IPv4 and IPv6, and similar formats would be useful. > > > At some later time the server software may be able to recognize older > > client code and return non- mp-* entries converted from policy expressed > > as mp-* entries. At some time, probably even later, it is expected that > > older clients will disappear. At some point it may no longer be > > practical to run an IPv4 only network and/or run a unicast only network > > (though this seems not to be "on the horizon" at the moment) and then > > all clients which did not understand the mp-* syntax would be> gone > > because they would all need that syntax to support IPv6. > > These are the issues I think will need *explicit* consideration before > going down the path of happily adopting RPSLng. What if there are some > holes in the spec or how it is implemented, or a clear view (for everyone) > on what's the overall plan for deploying RPSL and RPSLng? > > > > ====== > > > "until conversion is considered complete". Do you think this takes a > > > year, two, or ten years? Note that for the conversion to be complete, > > > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > > > > > But then again, you're advocating keeping the v4 unicast policy only in > > > the old form RPSL. Now, many sites want to mention their multicast > > > policies as well, or IPv6 policies. They have to maintain two different > > > databases and records to do this, using this transition approach. > > > > > > As for another approach, what might help a bit could be to have the > > > ability of the RPSLng databases to automatically generate the old form > > > RPSL data from the IPv4 unicast data which has possibly been entered in > > > the RPSLng registry, for maintaining the automatic backward compatibility > > > and minimizing the maintenance effort of all ISPs desiring to use the > > > RPSLng features. > > > > > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > > > data, so that everyone could start "safely" to use RPSLng only. > > > > > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > > > here, not sure. > > > > > > Or, there could be some other approaches, I don't know. These might not > > > even require modifications (at least major ones) in the RPSLng spec. But > > > this seems like a subject which is non-trivial and bears some thinking > > > about... *before* we set off to really deploying RPSLng! > > > > > > We've been learning that lesson with the IPv6 transition work. Folks > > > probably thought it would be trivial, at first, and didn't pay attention > > > to the operational details.. > > > ===== > > > > > > -- > > > Pekka Savola "You each name yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Fri Sep 19 13:32:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16386 for ; Fri, 19 Sep 2003 13:32:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P6x-0005CM-8p; Fri, 19 Sep 2003 13:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P6b-0004mF-Re for rps@optimus.ietf.org; Fri, 19 Sep 2003 13:31:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05853; Fri, 19 Sep 2003 12:04:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0FjH-0006Aa-00; Fri, 19 Sep 2003 03:30:59 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0FbA-0004vv-00; Fri, 19 Sep 2003 03:22:36 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8J7M2029260; Fri, 19 Sep 2003 10:22:02 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309181818.h8IIIHYf008358@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 10:21:58 +0300 (EEST) On Thu, 18 Sep 2003, Curtis Villamizar wrote: > You seem not to be missing something. The mp-* and non- mp-* entries > will be in the same database. Probably yes, in the longer term; that helps some scenarios but doesn't eliminate the issues. > For backwards compatibility the ipv4 > unicast policy will be in the same database but at least initially > expressed as non- mp-* policy statements. Right. > Since policy is currently > quite different between unicase and multicase A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same. Ours (and many others') policies are identical. > and ipv4 and ipv6 this > is not only not a problem, it is not even an inconvenience. A smaller issues, yes. However, from "the use of tools" perspective, people will use both IPv4 and IPv6, and similar formats would be useful. > At some later time the server software may be able to recognize older > client code and return non- mp-* entries converted from policy expressed > as mp-* entries. At some time, probably even later, it is expected that > older clients will disappear. At some point it may no longer be > practical to run an IPv4 only network and/or run a unicast only network > (though this seems not to be "on the horizon" at the moment) and then > all clients which did not understand the mp-* syntax would be> gone > because they would all need that syntax to support IPv6. These are the issues I think will need *explicit* consideration before going down the path of happily adopting RPSLng. What if there are some holes in the spec or how it is implemented, or a clear view (for everyone) on what's the overall plan for deploying RPSL and RPSLng? > > ====== > > "until conversion is considered complete". Do you think this takes a > > year, two, or ten years? Note that for the conversion to be complete, > > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > > > But then again, you're advocating keeping the v4 unicast policy only in > > the old form RPSL. Now, many sites want to mention their multicast > > policies as well, or IPv6 policies. They have to maintain two different > > databases and records to do this, using this transition approach. > > > > As for another approach, what might help a bit could be to have the > > ability of the RPSLng databases to automatically generate the old form > > RPSL data from the IPv4 unicast data which has possibly been entered in > > the RPSLng registry, for maintaining the automatic backward compatibility > > and minimizing the maintenance effort of all ISPs desiring to use the > > RPSLng features. > > > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > > data, so that everyone could start "safely" to use RPSLng only. > > > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > > here, not sure. > > > > Or, there could be some other approaches, I don't know. These might not > > even require modifications (at least major ones) in the RPSLng spec. But > > this seems like a subject which is non-trivial and bears some thinking > > about... *before* we set off to really deploying RPSLng! > > > > We've been learning that lesson with the IPv6 transition work. Folks > > probably thought it would be trivial, at first, and didn't pay attention > > to the operational details.. > > ===== > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > _______________________________________________ > > Rps mailing list > > Rps@ietf.org > > https://www1.ietf.org/mailman/listinfo/rps > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Fri Sep 19 13:34:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13995 for ; Fri, 19 Sep 2003 12:49:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ORL-0000P1-EC; Fri, 19 Sep 2003 12:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0O8D-00077V-64 for rps@optimus.ietf.org; Fri, 19 Sep 2003 12:29:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08884; Fri, 19 Sep 2003 12:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A03Tr-0002Gj-00; Thu, 18 Sep 2003 14:26:15 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A03NP-0001lh-00; Thu, 18 Sep 2003 14:19:35 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8IIIHYf008358; Thu, 18 Sep 2003 14:18:18 -0400 Message-Id: <200309181818.h8IIIHYf008358@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Thu, 18 Sep 2003 14:11:24 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Sep 2003 14:18:30 -0400 In message , Pekka Savola writes: > On Tue, 16 Sep 2003, Curtis Villamizar wrote: > > In message , Pekka Sav > ola > > writes: > > > On Tue, 16 Sep 2003, Curtis Villamizar wrote: > > > > In message , Pekka > Savo > > > la w > > > > rites: > > > > > > > > > > Did you even read what I wrote? I certainly didn't see a problem in > > > > > having different IPv6 and IPv4 records, because, well, they have to b > e > > > > > different anyway. I believe I gave a couple of points to consider as > > > > > > well. > > > > > > > > If you have no issue with separate IPv6 and IPv4 records then the > > > > matter is resolved. There is no transition problem, nor is there any > > > > long term problem other than separate IPv6 and IPv4 records which may > > > > be a nuisance later at worst. > > > > > > I recall that RPSLng also supports ipv4.unicast (which is supported by > > > RPSL as well), and ipv4.multicast. The issue is clearly not settled by > > > that, I think, > > > > As far as I can tell you have made no point which has withstood > > strutiny. If you think there is a problem, please state the problem > > concisely. > > I'll just cut-n-paste my earlier response below. There are certainly open > issues on keeping IPv4 unicast and multicast data in sync. Further, it > might be desirable to have IPv4 unicast in the same database, so that you > could just run the IRRToolSet (or some other tool) just once, from one > database to get both v4 and v6 data, but this is a smaller point. You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database. For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements. Since policy is currently quite different between unicase and multicase and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience. At some later time the server software may be able to recognize older client code and return non- mp-* entries converted from policy expressed as mp-* entries. At some time, probably even later, it is expected that older clients will disappear. At some point it may no longer be practical to run an IPv4 only network and/or run a unicast only network (though this seems not to be "on the horizon" at the moment) and then all clients which did not understand the mp-* syntax would be gone because they would all need that syntax to support IPv6. So none of your objections below are valid. Curtis > ====== > "until conversion is considered complete". Do you think this takes a > year, two, or ten years? Note that for the conversion to be complete, > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > But then again, you're advocating keeping the v4 unicast policy only in > the old form RPSL. Now, many sites want to mention their multicast > policies as well, or IPv6 policies. They have to maintain two different > databases and records to do this, using this transition approach. > > As for another approach, what might help a bit could be to have the > ability of the RPSLng databases to automatically generate the old form > RPSL data from the IPv4 unicast data which has possibly been entered in > the RPSLng registry, for maintaining the automatic backward compatibility > and minimizing the maintenance effort of all ISPs desiring to use the > RPSLng features. > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > data, so that everyone could start "safely" to use RPSLng only. > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > here, not sure. > > Or, there could be some other approaches, I don't know. These might not > even require modifications (at least major ones) in the RPSLng spec. But > this seems like a subject which is non-trivial and bears some thinking > about... *before* we set off to really deploying RPSLng! > > We've been learning that lesson with the IPv6 transition work. Folks > probably thought it would be trivial, at first, and didn't pay attention > to the operational details.. > ===== > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > Rps mailing list > Rps@ietf.org > https://www1.ietf.org/mailman/listinfo/rps _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Fri Sep 19 13:34:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13996 for ; Fri, 19 Sep 2003 12:49:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ORL-0000Ot-72; Fri, 19 Sep 2003 12:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nfq-0007SJ-1M for rps@optimus.ietf.org; Fri, 19 Sep 2003 12:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02559; Fri, 19 Sep 2003 11:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Lkf-000152-00; Fri, 19 Sep 2003 09:56:49 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A0LHB-0005fd-00; Fri, 19 Sep 2003 09:26:21 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8JDOIYf014211; Fri, 19 Sep 2003 09:24:18 -0400 Message-Id: <200309191324.h8JDOIYf014211@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Fri, 19 Sep 2003 10:21:58 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 09:24:33 -0400 In message , Pekka Savola writes: > On Thu, 18 Sep 2003, Curtis Villamizar wrote: > > You seem not to be missing something. The mp-* and non- mp-* entries > > will be in the same database. > > Probably yes, in the longer term; that helps some scenarios but doesn't > eliminate the issues. > > > For backwards compatibility the ipv4 > > unicast policy will be in the same database but at least initially > > expressed as non- mp-* policy statements. > > Right. > > > Since policy is currently > > quite different between unicase and multicase > > A fatal assumption. In about all academic networks and backbone transit > providers -- which are significant users of RPSLng -- multicast and > unicast topologies are very much the same. > > Ours (and many others') policies are identical. I seriously doubt this is common unless you have a small number of peers. The majority of providers support IPv4 unicast only so policy for multicast or IPv6 is meaningless. Regardless, for a transition period you have duplicate entries if the policies were identical. One entry would be in import (for IPv4) the other would be otherwise identical mp-import for ipv6,ipv4-multicast,ipv6-multicast. If the server side can recognize older clients, then the inconvenience of duplicate entries can be elimitated. See paragraph below. > > and ipv4 and ipv6 this > > is not only not a problem, it is not even an inconvenience. > > A smaller issues, yes. However, from "the use of tools" perspective, > people will use both IPv4 and IPv6, and similar formats would be useful. They are similar formats. > > At some later time the server software may be able to recognize older > > client code and return non- mp-* entries converted from policy expressed > > as mp-* entries. At some time, probably even later, it is expected that > > older clients will disappear. At some point it may no longer be > > practical to run an IPv4 only network and/or run a unicast only network > > (though this seems not to be "on the horizon" at the moment) and then > > all clients which did not understand the mp-* syntax would be> gone > > because they would all need that syntax to support IPv6. > > These are the issues I think will need *explicit* consideration before > going down the path of happily adopting RPSLng. What if there are some > holes in the spec or how it is implemented, or a clear view (for everyone) > on what's the overall plan for deploying RPSL and RPSLng? It was just considered above. I thought that was obvious enough since this is similar to past transitions and I understand how the mp-* were intended to be used. If you want something in the spec on transition, a paragraph or two from this email message can be added. I don't think its needed but it wouldn't hurt. Curtis > > > ====== > > > "until conversion is considered complete". Do you think this takes a > > > year, two, or ten years? Note that for the conversion to be complete, > > > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > > > > > But then again, you're advocating keeping the v4 unicast policy only in > > > the old form RPSL. Now, many sites want to mention their multicast > > > policies as well, or IPv6 policies. They have to maintain two different > > > databases and records to do this, using this transition approach. > > > > > > As for another approach, what might help a bit could be to have the > > > ability of the RPSLng databases to automatically generate the old form > > > RPSL data from the IPv4 unicast data which has possibly been entered in > > > the RPSLng registry, for maintaining the automatic backward compatibility > > > and minimizing the maintenance effort of all ISPs desiring to use the > > > RPSLng features. > > > > > > Another approach might be to general IPv4.unicast data to RPSLng from RPS > L > > > data, so that everyone could start "safely" to use RPSLng only. > > > > > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > > > here, not sure. > > > > > > Or, there could be some other approaches, I don't know. These might not > > > even require modifications (at least major ones) in the RPSLng spec. But > > > this seems like a subject which is non-trivial and bears some thinking > > > about... *before* we set off to really deploying RPSLng! > > > > > > We've been learning that lesson with the IPv6 transition work. Folks > > > probably thought it would be trivial, at first, and didn't pay attention > > > to the operational details.. > > > ===== > > > > > > -- > > > Pekka Savola "You each name yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > > > _______________________________________________ > > > Rps mailing list > > > Rps@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rps > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Sat Sep 20 09:52:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03998 for ; Sat, 20 Sep 2003 09:52:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Pgh-0008IQ-2m for rps-archive@odin.ietf.org; Fri, 19 Sep 2003 14:08:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JI8xeI031884 for rps-archive@odin.ietf.org; Fri, 19 Sep 2003 14:08:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Pgg-0008IB-TS for rps-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 14:08:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17954 for ; Fri, 19 Sep 2003 14:08:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Pge-0007RD-00 for rps-web-archive@ietf.org; Fri, 19 Sep 2003 14:08:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0PWa-00074R-00 for rps-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P6x-0005CM-8p; Fri, 19 Sep 2003 13:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P6b-0004mF-Re for rps@optimus.ietf.org; Fri, 19 Sep 2003 13:31:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05853; Fri, 19 Sep 2003 12:04:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0FjH-0006Aa-00; Fri, 19 Sep 2003 03:30:59 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0FbA-0004vv-00; Fri, 19 Sep 2003 03:22:36 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8J7M2029260; Fri, 19 Sep 2003 10:22:02 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309181818.h8IIIHYf008358@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 10:21:58 +0300 (EEST) On Thu, 18 Sep 2003, Curtis Villamizar wrote: > You seem not to be missing something. The mp-* and non- mp-* entries > will be in the same database. Probably yes, in the longer term; that helps some scenarios but doesn't eliminate the issues. > For backwards compatibility the ipv4 > unicast policy will be in the same database but at least initially > expressed as non- mp-* policy statements. Right. > Since policy is currently > quite different between unicase and multicase A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same. Ours (and many others') policies are identical. > and ipv4 and ipv6 this > is not only not a problem, it is not even an inconvenience. A smaller issues, yes. However, from "the use of tools" perspective, people will use both IPv4 and IPv6, and similar formats would be useful. > At some later time the server software may be able to recognize older > client code and return non- mp-* entries converted from policy expressed > as mp-* entries. At some time, probably even later, it is expected that > older clients will disappear. At some point it may no longer be > practical to run an IPv4 only network and/or run a unicast only network > (though this seems not to be "on the horizon" at the moment) and then > all clients which did not understand the mp-* syntax would be> gone > because they would all need that syntax to support IPv6. These are the issues I think will need *explicit* consideration before going down the path of happily adopting RPSLng. What if there are some holes in the spec or how it is implemented, or a clear view (for everyone) on what's the overall plan for deploying RPSL and RPSLng? > > ====== > > "until conversion is considered complete". Do you think this takes a > > year, two, or ten years? Note that for the conversion to be complete, > > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > > > But then again, you're advocating keeping the v4 unicast policy only in > > the old form RPSL. Now, many sites want to mention their multicast > > policies as well, or IPv6 policies. They have to maintain two different > > databases and records to do this, using this transition approach. > > > > As for another approach, what might help a bit could be to have the > > ability of the RPSLng databases to automatically generate the old form > > RPSL data from the IPv4 unicast data which has possibly been entered in > > the RPSLng registry, for maintaining the automatic backward compatibility > > and minimizing the maintenance effort of all ISPs desiring to use the > > RPSLng features. > > > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > > data, so that everyone could start "safely" to use RPSLng only. > > > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > > here, not sure. > > > > Or, there could be some other approaches, I don't know. These might not > > even require modifications (at least major ones) in the RPSLng spec. But > > this seems like a subject which is non-trivial and bears some thinking > > about... *before* we set off to really deploying RPSLng! > > > > We've been learning that lesson with the IPv6 transition work. Folks > > probably thought it would be trivial, at first, and didn't pay attention > > to the operational details.. > > ===== > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > _______________________________________________ > > Rps mailing list > > Rps@ietf.org > > https://www1.ietf.org/mailman/listinfo/rps > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Sat Sep 20 09:52:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04001 for ; Sat, 20 Sep 2003 09:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Pep-0007zY-TB for rps-archive@odin.ietf.org; Fri, 19 Sep 2003 14:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JI73HM030714 for rps-archive@odin.ietf.org; Fri, 19 Sep 2003 14:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Pef-0007xm-Bv for rps-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 14:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17821 for ; Fri, 19 Sep 2003 14:06:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Pec-0007NH-00 for rps-web-archive@ietf.org; Fri, 19 Sep 2003 14:06:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0PWb-00075i-00 for rps-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ORL-0000Ot-72; Fri, 19 Sep 2003 12:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nfq-0007SJ-1M for rps@optimus.ietf.org; Fri, 19 Sep 2003 12:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02559; Fri, 19 Sep 2003 11:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Lkf-000152-00; Fri, 19 Sep 2003 09:56:49 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A0LHB-0005fd-00; Fri, 19 Sep 2003 09:26:21 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8JDOIYf014211; Fri, 19 Sep 2003 09:24:18 -0400 Message-Id: <200309191324.h8JDOIYf014211@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Fri, 19 Sep 2003 10:21:58 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 09:24:33 -0400 In message , Pekka Savola writes: > On Thu, 18 Sep 2003, Curtis Villamizar wrote: > > You seem not to be missing something. The mp-* and non- mp-* entries > > will be in the same database. > > Probably yes, in the longer term; that helps some scenarios but doesn't > eliminate the issues. > > > For backwards compatibility the ipv4 > > unicast policy will be in the same database but at least initially > > expressed as non- mp-* policy statements. > > Right. > > > Since policy is currently > > quite different between unicase and multicase > > A fatal assumption. In about all academic networks and backbone transit > providers -- which are significant users of RPSLng -- multicast and > unicast topologies are very much the same. > > Ours (and many others') policies are identical. I seriously doubt this is common unless you have a small number of peers. The majority of providers support IPv4 unicast only so policy for multicast or IPv6 is meaningless. Regardless, for a transition period you have duplicate entries if the policies were identical. One entry would be in import (for IPv4) the other would be otherwise identical mp-import for ipv6,ipv4-multicast,ipv6-multicast. If the server side can recognize older clients, then the inconvenience of duplicate entries can be elimitated. See paragraph below. > > and ipv4 and ipv6 this > > is not only not a problem, it is not even an inconvenience. > > A smaller issues, yes. However, from "the use of tools" perspective, > people will use both IPv4 and IPv6, and similar formats would be useful. They are similar formats. > > At some later time the server software may be able to recognize older > > client code and return non- mp-* entries converted from policy expressed > > as mp-* entries. At some time, probably even later, it is expected that > > older clients will disappear. At some point it may no longer be > > practical to run an IPv4 only network and/or run a unicast only network > > (though this seems not to be "on the horizon" at the moment) and then > > all clients which did not understand the mp-* syntax would be> gone > > because they would all need that syntax to support IPv6. > > These are the issues I think will need *explicit* consideration before > going down the path of happily adopting RPSLng. What if there are some > holes in the spec or how it is implemented, or a clear view (for everyone) > on what's the overall plan for deploying RPSL and RPSLng? It was just considered above. I thought that was obvious enough since this is similar to past transitions and I understand how the mp-* were intended to be used. If you want something in the spec on transition, a paragraph or two from this email message can be added. I don't think its needed but it wouldn't hurt. Curtis > > > ====== > > > "until conversion is considered complete". Do you think this takes a > > > year, two, or ten years? Note that for the conversion to be complete, > > > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > > > > > But then again, you're advocating keeping the v4 unicast policy only in > > > the old form RPSL. Now, many sites want to mention their multicast > > > policies as well, or IPv6 policies. They have to maintain two different > > > databases and records to do this, using this transition approach. > > > > > > As for another approach, what might help a bit could be to have the > > > ability of the RPSLng databases to automatically generate the old form > > > RPSL data from the IPv4 unicast data which has possibly been entered in > > > the RPSLng registry, for maintaining the automatic backward compatibility > > > and minimizing the maintenance effort of all ISPs desiring to use the > > > RPSLng features. > > > > > > Another approach might be to general IPv4.unicast data to RPSLng from RPS > L > > > data, so that everyone could start "safely" to use RPSLng only. > > > > > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > > > here, not sure. > > > > > > Or, there could be some other approaches, I don't know. These might not > > > even require modifications (at least major ones) in the RPSLng spec. But > > > this seems like a subject which is non-trivial and bears some thinking > > > about... *before* we set off to really deploying RPSLng! > > > > > > We've been learning that lesson with the IPv6 transition work. Folks > > > probably thought it would be trivial, at first, and didn't pay attention > > > to the operational details.. > > > ===== > > > > > > -- > > > Pekka Savola "You each name yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > > > _______________________________________________ > > > Rps mailing list > > > Rps@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rps > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Sat Sep 20 09:53:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04232 for ; Sat, 20 Sep 2003 09:53:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PWZ-0007DL-0s for rps-archive@odin.ietf.org; Fri, 19 Sep 2003 13:58:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHwUuI027700 for rps-archive@odin.ietf.org; Fri, 19 Sep 2003 13:58:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PWY-0007CG-FJ for rps-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 13:58:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17353 for ; Fri, 19 Sep 2003 13:58:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0PWT-00075Y-00 for rps-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0PWK-00075i-03 for rps-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ORK-0000Ol-Vu; Fri, 19 Sep 2003 12:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nfq-0007N1-G8 for rps@optimus.ietf.org; Fri, 19 Sep 2003 11:59:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02321; Fri, 19 Sep 2003 11:59:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0MJY-00026j-00; Fri, 19 Sep 2003 10:32:52 -0400 Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx with esmtp (Exim 4.12) id 1A0M7n-0003XY-00; Fri, 19 Sep 2003 10:20:44 -0400 Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by segue.merit.edu (Postfix) with ESMTP id 7A6BB5DD9C; Fri, 19 Sep 2003 10:20:07 -0400 (EDT) Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard From: "Larry J. Blunk" To: Pekka Savola Cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Merit Network, Inc. Message-Id: <1063981473.3370.23.camel@ablate.merit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Sep 2003 10:24:33 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka and Curtis, Thanks for the feedback. Sorry for not responding sooner (I've been trying to absorb everything and formulate a response). I've been updating the draft to reflect many of your comments (thanks, Pekka). On Fri, 2003-09-19 at 03:21, Pekka Savola wrote: > On Thu, 18 Sep 2003, Curtis Villamizar wrote: > > You seem not to be missing something. The mp-* and non- mp-* entries > > will be in the same database. > > Probably yes, in the longer term; that helps some scenarios but doesn't > eliminate the issues. I think there indeed needs to be some text to clarify the use of mp-* and non mp-* entries. Should the document recommend the use of non-mp entries to express v4 policies for existing non-RPSLng compliant tools? Should this be mandatory or optional? And perhaps more controversily, if there are mp- attributes present in an object, should the non-mp attributes be ignored by RPSLng compliant tools to reduce the possibility for conflicts. Further should there be clarification on the case where an import, export, or default attribute references a route-set/filter-set/etc. which contains mp- attributes? Should RPSLng compliant tools ignore the mp- attributes in this case (as non-RPSLng compliant tools would do). > > > For backwards compatibility the ipv4 > > unicast policy will be in the same database but at least initially > > expressed as non- mp-* policy statements. > > Right. One option I thought about would be to change the mp-members, mp-filter, mp-peer, mp-peering, and interface attributes to be IPv6 specific. In other words, rename them to something like members6, filter6, peer6, peering6, and interface6 (well, perhaps not the interface attribute since it introduces new functionality). This would preserve explicit support for backward compatibility with IPv4 as one would need to continue to express IPv4 prefixes and policy info in the existing RPSL attributes. I think backward compatibility in these attributes is more important than the import, export, and default attributes as I believe one is more likely to reference another org's route-set, filter-set, etc., than another org's aut-num object. -Larry Blunk Merit > > > Since policy is currently > > quite different between unicase and multicase > > A fatal assumption. In about all academic networks and backbone transit > providers -- which are significant users of RPSLng -- multicast and > unicast topologies are very much the same. > > Ours (and many others') policies are identical. > > > and ipv4 and ipv6 this > > is not only not a problem, it is not even an inconvenience. > > A smaller issues, yes. However, from "the use of tools" perspective, > people will use both IPv4 and IPv6, and similar formats would be useful. > > > At some later time the server software may be able to recognize older > > client code and return non- mp-* entries converted from policy expressed > > as mp-* entries. At some time, probably even later, it is expected that > > older clients will disappear. At some point it may no longer be > > practical to run an IPv4 only network and/or run a unicast only network > > (though this seems not to be "on the horizon" at the moment) and then > > all clients which did not understand the mp-* syntax would be> gone > > because they would all need that syntax to support IPv6. > > These are the issues I think will need *explicit* consideration before > going down the path of happily adopting RPSLng. What if there are some > holes in the spec or how it is implemented, or a clear view (for everyone) > on what's the overall plan for deploying RPSL and RPSLng? > > > > ====== > > > "until conversion is considered complete". Do you think this takes a > > > year, two, or ten years? Note that for the conversion to be complete, > > > *EVERY* user or RPSL must have upgraded to RPSLng, right? > > > > > > But then again, you're advocating keeping the v4 unicast policy only in > > > the old form RPSL. Now, many sites want to mention their multicast > > > policies as well, or IPv6 policies. They have to maintain two different > > > databases and records to do this, using this transition approach. > > > > > > As for another approach, what might help a bit could be to have the > > > ability of the RPSLng databases to automatically generate the old form > > > RPSL data from the IPv4 unicast data which has possibly been entered in > > > the RPSLng registry, for maintaining the automatic backward compatibility > > > and minimizing the maintenance effort of all ISPs desiring to use the > > > RPSLng features. > > > > > > Another approach might be to general IPv4.unicast data to RPSLng from RPSL > > > data, so that everyone could start "safely" to use RPSLng only. > > > > > > But there are some potential "overlapping policy in RPSL or RPSLng" issue > > > here, not sure. > > > > > > Or, there could be some other approaches, I don't know. These might not > > > even require modifications (at least major ones) in the RPSLng spec. But > > > this seems like a subject which is non-trivial and bears some thinking > > > about... *before* we set off to really deploying RPSLng! > > > > > > We've been learning that lesson with the IPv6 transition work. Folks > > > probably thought it would be trivial, at first, and didn't pay attention > > > to the operational details.. > > > ===== > > > > > > -- > > > Pekka Savola "You each name yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Sat Sep 20 11:27:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12222 for ; Sat, 20 Sep 2003 11:27:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jch-0005aK-7u; Sat, 20 Sep 2003 11:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ihi-0006f7-F6 for rps@optimus.ietf.org; Sat, 20 Sep 2003 10:27:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20534; Fri, 19 Sep 2003 16:12:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Rce-0000ue-00; Fri, 19 Sep 2003 16:12:56 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A0RcR-0000tZ-00; Fri, 19 Sep 2003 16:12:45 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8JJ6nYf023030; Fri, 19 Sep 2003 15:06:49 -0400 Message-Id: <200309191906.h8JJ6nYf023030@mail.avici.com> To: "Larry J. Blunk" cc: Pekka Savola , curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "19 Sep 2003 10:24:33 EDT." <1063981473.3370.23.camel@ablate.merit.edu> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 15:07:03 -0400 Larry, Good to hear from you. Comments inline. I think we can converge on something that we can all live with by just adding a transition issue appendix and deciding what needs to go into it. Curtis In message <1063981473.3370.23.camel@ablate.merit.edu>, "Larry J. Blunk" writes : > Pekka and Curtis, > Thanks for the feedback. Sorry for not responding sooner (I've > been trying to absorb everything and formulate a response). I've > been updating the draft to reflect many of your comments > (thanks, Pekka). > > > On Fri, 2003-09-19 at 03:21, Pekka Savola wrote: > > On Thu, 18 Sep 2003, Curtis Villamizar wrote: > > > You seem not to be missing something. The mp-* and non- mp-* entries > > > will be in the same database. > > > > Probably yes, in the longer term; that helps some scenarios but doesn't > > eliminate the issues. > > I think there indeed needs to be some text to clarify the use of > mp-* and non mp-* entries. Should the document recommend the use of > non-mp entries to express v4 policies for existing non-RPSLng > compliant tools? Should this be mandatory or optional? And perhaps > more controversily, if there are mp- attributes present in an object, > should the non-mp attributes be ignored by RPSLng compliant tools > to reduce the possibility for conflicts. This is strictly a transition issue and a strong recommendation to specify non mp-* for IPv4 should be made for initial transition purposes. See comments below about eliminating this need with better server code. Any such recommendation should be in an appendix on transition issues, not in the main body of the document. > Further should there be clarification on the case where an import, > export, or default attribute references a route-set/filter-set/etc. > which contains mp- attributes? Should RPSLng compliant tools ignore > the mp- attributes in this case (as non-RPSLng compliant tools would > do). > > > > > > For backwards compatibility the ipv4 > > > unicast policy will be in the same database but at least initially > > > expressed as non- mp-* policy statements. > > > > Right. > > One option I thought about would be to change the mp-members, > mp-filter, mp-peer, mp-peering, and interface attributes to be > IPv6 specific. In other words, rename them to something like > members6, filter6, peer6, peering6, and interface6 (well, perhaps > not the interface attribute since it introduces new functionality). > This would preserve explicit support for backward compatibility > with IPv4 as one would need to continue to express IPv4 prefixes > and policy info in the existing RPSL attributes. > > I think backward compatibility in these attributes is more > important than the import, export, and default attributes as > I believe one is more likely to reference another org's route-set, > filter-set, etc., than another org's aut-num object. > > -Larry Blunk > Merit It would be best if old clients could be recognized. This would mean conversion to new server code only before mp-* could be freely used. At that point when an old client is recognized all mp-* attributes can be returned with s/mp-// as long as they apply to IPv4. With the server code hiding the mp- stuff a query that hits an mp-import or import that referenced an mp-filter or filter would alway be returning just a import and filter to the older client. This is not so much an issue for the spec as it is for the implementation and a transition consideration for deployment. It doesn't hurt to mention the issues in the spec, but there is no need to change the spec. There is always a need to make a smooth transition. Rather than change the spec to make mp-peer etc into peer6 etc, leave the spec as is but for early transition only accept a mp-peer if it is specifies a non-IPv4-unicast peering. When the server code is updated in enough places you can accept a mp-peer that specifies ipv4 but return a plain peering to older clients. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Sun Sep 21 10:21:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28468 for ; Sun, 21 Sep 2003 10:21:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A155A-0001wQ-MG; Sun, 21 Sep 2003 10:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A154m-0001tS-0k for rps@optimus.ietf.org; Sun, 21 Sep 2003 10:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28416; Sun, 21 Sep 2003 10:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A154e-0003CJ-00; Sun, 21 Sep 2003 10:20:28 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A154T-0003Ay-00; Sun, 21 Sep 2003 10:20:18 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8LEIq308226; Sun, 21 Sep 2003 17:18:53 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309191324.h8JDOIYf014211@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Sep 2003 17:18:52 +0300 (EEST) On Fri, 19 Sep 2003, Curtis Villamizar wrote: > > > Since policy is currently > > > quite different between unicase and multicase > > > > A fatal assumption. In about all academic networks and backbone transit > > providers -- which are significant users of RPSLng -- multicast and > > unicast topologies are very much the same. > > > > Ours (and many others') policies are identical. > > I seriously doubt this is common unless you have a small number of > peers. The majority of providers support IPv4 unicast only so policy > for multicast or IPv6 is meaningless. You fail to see that *we* set up the policies common to everyone we peer with; we advertise both BGP unicast and multicast routes to everybody equally. Almost nobody uses them, though, but that's not *our* problem. We just wnt to have an equal policy for everyone. [...] > > > and ipv4 and ipv6 this > > > is not only not a problem, it is not even an inconvenience. > > > > A smaller issues, yes. However, from "the use of tools" perspective, > > people will use both IPv4 and IPv6, and similar formats would be useful. > > They are similar formats. That's good. Taking an example with IRRToolSet, I want to embed both RPSL and RPSLng format attributes or commands in a single text document, which I will pass through IRRToolSet _once_. (e.g., requiring to run the tool twice, once for each support with different command-line arguments is unreasonable.) > > > At some later time the server software may be able to recognize older > > > client code and return non- mp-* entries converted from policy expressed > > > as mp-* entries. At some time, probably even later, it is expected that > > > older clients will disappear. At some point it may no longer be > > > practical to run an IPv4 only network and/or run a unicast only network > > > (though this seems not to be "on the horizon" at the moment) and then > > > all clients which did not understand the mp-* syntax would be> gone > > > because they would all need that syntax to support IPv6. > > > > These are the issues I think will need *explicit* consideration before > > going down the path of happily adopting RPSLng. What if there are some > > holes in the spec or how it is implemented, or a clear view (for everyone) > > on what's the overall plan for deploying RPSL and RPSLng? > > It was just considered above. I thought that was obvious enough since > this is similar to past transitions and I understand how the mp-* were > intended to be used. If you want something in the spec on transition, > a paragraph or two from this email message can be added. I don't > think its needed but it wouldn't hurt. Well, I can see multiple possible ways to do so -- so this the way forward does seem to use a bit of phrasing. Something added to an appendix would likely be very useful. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Sun Sep 21 10:21:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28485 for ; Sun, 21 Sep 2003 10:21:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A155T-0001zF-Ug for rps-archive@odin.ietf.org; Sun, 21 Sep 2003 10:21:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8LELJ7v007631 for rps-archive@odin.ietf.org; Sun, 21 Sep 2003 10:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A155T-0001z0-QO for rps-web-archive@optimus.ietf.org; Sun, 21 Sep 2003 10:21:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28453 for ; Sun, 21 Sep 2003 10:21:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A155R-0003DC-00 for rps-web-archive@ietf.org; Sun, 21 Sep 2003 10:21:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A155M-0003D2-00 for rps-web-archive@ietf.org; Sun, 21 Sep 2003 10:21:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A155A-0001wQ-MG; Sun, 21 Sep 2003 10:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A154m-0001tS-0k for rps@optimus.ietf.org; Sun, 21 Sep 2003 10:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28416; Sun, 21 Sep 2003 10:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A154e-0003CJ-00; Sun, 21 Sep 2003 10:20:28 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A154T-0003Ay-00; Sun, 21 Sep 2003 10:20:18 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8LEIq308226; Sun, 21 Sep 2003 17:18:53 +0300 From: Pekka Savola To: curtis@fictitious.org cc: iesg@ietf.org, , Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-Reply-To: <200309191324.h8JDOIYf014211@mail.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Sep 2003 17:18:52 +0300 (EEST) On Fri, 19 Sep 2003, Curtis Villamizar wrote: > > > Since policy is currently > > > quite different between unicase and multicase > > > > A fatal assumption. In about all academic networks and backbone transit > > providers -- which are significant users of RPSLng -- multicast and > > unicast topologies are very much the same. > > > > Ours (and many others') policies are identical. > > I seriously doubt this is common unless you have a small number of > peers. The majority of providers support IPv4 unicast only so policy > for multicast or IPv6 is meaningless. You fail to see that *we* set up the policies common to everyone we peer with; we advertise both BGP unicast and multicast routes to everybody equally. Almost nobody uses them, though, but that's not *our* problem. We just wnt to have an equal policy for everyone. [...] > > > and ipv4 and ipv6 this > > > is not only not a problem, it is not even an inconvenience. > > > > A smaller issues, yes. However, from "the use of tools" perspective, > > people will use both IPv4 and IPv6, and similar formats would be useful. > > They are similar formats. That's good. Taking an example with IRRToolSet, I want to embed both RPSL and RPSLng format attributes or commands in a single text document, which I will pass through IRRToolSet _once_. (e.g., requiring to run the tool twice, once for each support with different command-line arguments is unreasonable.) > > > At some later time the server software may be able to recognize older > > > client code and return non- mp-* entries converted from policy expressed > > > as mp-* entries. At some time, probably even later, it is expected that > > > older clients will disappear. At some point it may no longer be > > > practical to run an IPv4 only network and/or run a unicast only network > > > (though this seems not to be "on the horizon" at the moment) and then > > > all clients which did not understand the mp-* syntax would be> gone > > > because they would all need that syntax to support IPv6. > > > > These are the issues I think will need *explicit* consideration before > > going down the path of happily adopting RPSLng. What if there are some > > holes in the spec or how it is implemented, or a clear view (for everyone) > > on what's the overall plan for deploying RPSL and RPSLng? > > It was just considered above. I thought that was obvious enough since > this is similar to past transitions and I understand how the mp-* were > intended to be used. If you want something in the spec on transition, > a paragraph or two from this email message can be added. I don't > think its needed but it wouldn't hurt. Well, I can see multiple possible ways to do so -- so this the way forward does seem to use a bit of phrasing. Something added to an appendix would likely be very useful. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Sun Sep 21 19:37:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12638 for ; Sun, 21 Sep 2003 19:37:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1DlF-0008T6-Qu; Sun, 21 Sep 2003 19:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1DkK-0008SC-05 for rps@optimus.ietf.org; Sun, 21 Sep 2003 19:36:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12595; Sun, 21 Sep 2003 19:35:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1DkE-00001v-00; Sun, 21 Sep 2003 19:35:58 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1Dk3-00001g-00; Sun, 21 Sep 2003 19:35:47 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8LNYChu000335 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Mon, 22 Sep 2003 09:04:19 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6E3574.1040300@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 09:04:12 +0930 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Fri, 19 Sep 2003, Curtis Villamizar wrote: > >>>>Since policy is currently >>>>quite different between unicase and multicase >>> >>>A fatal assumption. In about all academic networks and backbone transit >>>providers -- which are significant users of RPSLng -- multicast and >>>unicast topologies are very much the same. >>> >>>Ours (and many others') policies are identical. >> >>I seriously doubt this is common unless you have a small number of >>peers. The majority of providers support IPv4 unicast only so policy >>for multicast or IPv6 is meaningless. > > > You fail to see that *we* set up the policies common to everyone we peer > with; we advertise both BGP unicast and multicast routes to everybody > equally. Almost nobody uses them, though, but that's not *our* problem. > We just wnt to have an equal policy for everyone. > Just in case anything thinks Pekka is alone in doing that I also consider the protocol irrelevant in my policy. Whether the peer wants all of them is another matter totally unrelated to specifying my policy. > That's good. Taking an example with IRRToolSet, I want to embed both RPSL > and RPSLng format attributes or commands in a single text document, which > I will pass through IRRToolSet _once_. (e.g., requiring to run the tool > twice, once for each support with different command-line arguments is > unreasonable.) > Personally I would prefer it if RPSLng was a super set of RPSL and from my point of view RPSLng policy = RPSL policy would be really nice. I still fail to see why we need most of the mp-* stuff anyway. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Sun Sep 21 19:37:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12653 for ; Sun, 21 Sep 2003 19:37:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1DlW-00009D-2H for rps-archive@odin.ietf.org; Sun, 21 Sep 2003 19:37:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8LNbHKc000561 for rps-archive@odin.ietf.org; Sun, 21 Sep 2003 19:37:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1DlV-00008y-P7 for rps-web-archive@optimus.ietf.org; Sun, 21 Sep 2003 19:37:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12616 for ; Sun, 21 Sep 2003 19:37:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1DlU-00002f-00 for rps-web-archive@ietf.org; Sun, 21 Sep 2003 19:37:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1DlO-00002b-00 for rps-web-archive@ietf.org; Sun, 21 Sep 2003 19:37:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1DlF-0008T6-Qu; Sun, 21 Sep 2003 19:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1DkK-0008SC-05 for rps@optimus.ietf.org; Sun, 21 Sep 2003 19:36:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12595; Sun, 21 Sep 2003 19:35:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1DkE-00001v-00; Sun, 21 Sep 2003 19:35:58 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1Dk3-00001g-00; Sun, 21 Sep 2003 19:35:47 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8LNYChu000335 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Mon, 22 Sep 2003 09:04:19 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6E3574.1040300@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 09:04:12 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Fri, 19 Sep 2003, Curtis Villamizar wrote: > >>>>Since policy is currently >>>>quite different between unicase and multicase >>> >>>A fatal assumption. In about all academic networks and backbone transit >>>providers -- which are significant users of RPSLng -- multicast and >>>unicast topologies are very much the same. >>> >>>Ours (and many others') policies are identical. >> >>I seriously doubt this is common unless you have a small number of >>peers. The majority of providers support IPv4 unicast only so policy >>for multicast or IPv6 is meaningless. > > > You fail to see that *we* set up the policies common to everyone we peer > with; we advertise both BGP unicast and multicast routes to everybody > equally. Almost nobody uses them, though, but that's not *our* problem. > We just wnt to have an equal policy for everyone. > Just in case anything thinks Pekka is alone in doing that I also consider the protocol irrelevant in my policy. Whether the peer wants all of them is another matter totally unrelated to specifying my policy. > That's good. Taking an example with IRRToolSet, I want to embed both RPSL > and RPSLng format attributes or commands in a single text document, which > I will pass through IRRToolSet _once_. (e.g., requiring to run the tool > twice, once for each support with different command-line arguments is > unreasonable.) > Personally I would prefer it if RPSLng was a super set of RPSL and from my point of view RPSLng policy = RPSL policy would be really nice. I still fail to see why we need most of the mp-* stuff anyway. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 22 12:32:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23761 for ; Mon, 22 Sep 2003 12:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TbU-0007mF-V5; Mon, 22 Sep 2003 12:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TbF-0007kt-Rl for rps@optimus.ietf.org; Mon, 22 Sep 2003 12:31:55 -0400 Received: from mail.avici.com ([12.38.212.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23720; Mon, 22 Sep 2003 12:31:31 -0400 (EDT) Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8MGOW6Z024243; Mon, 22 Sep 2003 12:24:32 -0400 Message-Id: <200309221624.h8MGOW6Z024243@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Sun, 21 Sep 2003 17:18:52 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 12:24:42 -0400 In message , Pekka Savola w rites: > On Fri, 19 Sep 2003, Curtis Villamizar wrote: > > > > Since policy is currently > > > > quite different between unicase and multicase > > > > > > A fatal assumption. In about all academic networks and backbone transit > > > providers -- which are significant users of RPSLng -- multicast and > > > unicast topologies are very much the same. > > > > > > Ours (and many others') policies are identical. > > > > I seriously doubt this is common unless you have a small number of > > peers. The majority of providers support IPv4 unicast only so policy > > for multicast or IPv6 is meaningless. > > You fail to see that *we* set up the policies common to everyone we peer > with; we advertise both BGP unicast and multicast routes to everybody > equally. Almost nobody uses them, though, but that's not *our* problem. > We just wnt to have an equal policy for everyone. > > [...] > > > > and ipv4 and ipv6 this > > > > is not only not a problem, it is not even an inconvenience. > > > > > > A smaller issues, yes. However, from "the use of tools" perspective, > > > people will use both IPv4 and IPv6, and similar formats would be useful. > > > > They are similar formats. > > That's good. Taking an example with IRRToolSet, I want to embed both RPSL > and RPSLng format attributes or commands in a single text document, which > I will pass through IRRToolSet _once_. (e.g., requiring to run the tool > twice, once for each support with different command-line arguments is > unreasonable.) RPSLng is a superset of RPSL. After some **testing** of the RPSLng server code, the entire database will be RPSLng. The only issue will be whether RPSL only query clients will be accommodated by 1) extracting the non mp-* RPSL from any RPSLng entries that match the queries (by the server code) or 2) non mp-* RPSL will be generated for the IPv4 part of the mp-* entries when entered into the database, or 3) whether end users will have to submit non mp-* for ipv4-unicast. The point it that there are multiple ways to accommodate older client code during transition. Which method of transition to pick is something more appropriate for a RIPE meeting, not for the language spec. > > > > At some later time the server software may be able to recognize older > > > > client code and return non- mp-* entries converted from policy expresse > d > > > > as mp-* entries. At some time, probably even later, it is expected tha > t > > > > older clients will disappear. At some point it may no longer be > > > > practical to run an IPv4 only network and/or run a unicast only network > > > > (though this seems not to be "on the horizon" at the moment) and then > > > > all clients which did not understand the mp-* syntax would be> gone > > > > because they would all need that syntax to support IPv6. > > > > > > These are the issues I think will need *explicit* consideration before > > > going down the path of happily adopting RPSLng. What if there are some > > > holes in the spec or how it is implemented, or a clear view (for everyone > ) > > > on what's the overall plan for deploying RPSL and RPSLng? > > > > It was just considered above. I thought that was obvious enough since > > this is similar to past transitions and I understand how the mp-* were > > intended to be used. If you want something in the spec on transition, > > a paragraph or two from this email message can be added. I don't > > think its needed but it wouldn't hurt. > > Well, I can see multiple possible ways to do so -- so this the way forward > does seem to use a bit of phrasing. > > Something added to an appendix would likely be very useful. Good. The comment above about 3 ways to do the transition might also help. The draft authors should feel free to reword any of this as they see fit. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 22 12:33:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23808 for ; Mon, 22 Sep 2003 12:33:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TcB-0007s2-GH for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 12:32:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MGWhvu030248 for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 12:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TcB-0007rn-CC for rps-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 12:32:43 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23760 for ; Mon, 22 Sep 2003 12:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TbU-0007mF-V5; Mon, 22 Sep 2003 12:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TbF-0007kt-Rl for rps@optimus.ietf.org; Mon, 22 Sep 2003 12:31:55 -0400 Received: from mail.avici.com ([12.38.212.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23720; Mon, 22 Sep 2003 12:31:31 -0400 (EDT) Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8MGOW6Z024243; Mon, 22 Sep 2003 12:24:32 -0400 Message-Id: <200309221624.h8MGOW6Z024243@mail.avici.com> To: Pekka Savola cc: curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Sun, 21 Sep 2003 17:18:52 +0300." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 12:24:42 -0400 In message , Pekka Savola w rites: > On Fri, 19 Sep 2003, Curtis Villamizar wrote: > > > > Since policy is currently > > > > quite different between unicase and multicase > > > > > > A fatal assumption. In about all academic networks and backbone transit > > > providers -- which are significant users of RPSLng -- multicast and > > > unicast topologies are very much the same. > > > > > > Ours (and many others') policies are identical. > > > > I seriously doubt this is common unless you have a small number of > > peers. The majority of providers support IPv4 unicast only so policy > > for multicast or IPv6 is meaningless. > > You fail to see that *we* set up the policies common to everyone we peer > with; we advertise both BGP unicast and multicast routes to everybody > equally. Almost nobody uses them, though, but that's not *our* problem. > We just wnt to have an equal policy for everyone. > > [...] > > > > and ipv4 and ipv6 this > > > > is not only not a problem, it is not even an inconvenience. > > > > > > A smaller issues, yes. However, from "the use of tools" perspective, > > > people will use both IPv4 and IPv6, and similar formats would be useful. > > > > They are similar formats. > > That's good. Taking an example with IRRToolSet, I want to embed both RPSL > and RPSLng format attributes or commands in a single text document, which > I will pass through IRRToolSet _once_. (e.g., requiring to run the tool > twice, once for each support with different command-line arguments is > unreasonable.) RPSLng is a superset of RPSL. After some **testing** of the RPSLng server code, the entire database will be RPSLng. The only issue will be whether RPSL only query clients will be accommodated by 1) extracting the non mp-* RPSL from any RPSLng entries that match the queries (by the server code) or 2) non mp-* RPSL will be generated for the IPv4 part of the mp-* entries when entered into the database, or 3) whether end users will have to submit non mp-* for ipv4-unicast. The point it that there are multiple ways to accommodate older client code during transition. Which method of transition to pick is something more appropriate for a RIPE meeting, not for the language spec. > > > > At some later time the server software may be able to recognize older > > > > client code and return non- mp-* entries converted from policy expresse > d > > > > as mp-* entries. At some time, probably even later, it is expected tha > t > > > > older clients will disappear. At some point it may no longer be > > > > practical to run an IPv4 only network and/or run a unicast only network > > > > (though this seems not to be "on the horizon" at the moment) and then > > > > all clients which did not understand the mp-* syntax would be> gone > > > > because they would all need that syntax to support IPv6. > > > > > > These are the issues I think will need *explicit* consideration before > > > going down the path of happily adopting RPSLng. What if there are some > > > holes in the spec or how it is implemented, or a clear view (for everyone > ) > > > on what's the overall plan for deploying RPSL and RPSLng? > > > > It was just considered above. I thought that was obvious enough since > > this is similar to past transitions and I understand how the mp-* were > > intended to be used. If you want something in the spec on transition, > > a paragraph or two from this email message can be added. I don't > > think its needed but it wouldn't hurt. > > Well, I can see multiple possible ways to do so -- so this the way forward > does seem to use a bit of phrasing. > > Something added to an appendix would likely be very useful. Good. The comment above about 3 ways to do the transition might also help. The draft authors should feel free to reword any of this as they see fit. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 22 12:43:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24392 for ; Mon, 22 Sep 2003 12:43:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Tm9-0000ii-1h; Mon, 22 Sep 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Tlk-0000gK-5h for rps@optimus.ietf.org; Mon, 22 Sep 2003 12:42:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24315; Mon, 22 Sep 2003 12:42:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Tli-00041e-00; Mon, 22 Sep 2003 12:42:34 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A1TlX-0003uB-00; Mon, 22 Sep 2003 12:42:23 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8MGe66Z026475; Mon, 22 Sep 2003 12:40:08 -0400 Message-Id: <200309221640.h8MGe66Z026475@mail.avici.com> To: Mark Prior cc: Pekka Savola , curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Mon, 22 Sep 2003 09:04:12 +0930." <3F6E3574.1040300@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 12:40:16 -0400 In message <3F6E3574.1040300@mrp.net>, Mark Prior writes: > > Personally I would prefer it if RPSLng was a super set of RPSL and from > my point of view RPSLng policy = RPSL policy would be really nice. I > still fail to see why we need most of the mp-* stuff anyway. > > Mark. Mark, How is RPSLng not a superset of RPSL? Nothing has been removed from RPSL. The issue is just how do you make transition easiest, supporting older RPSL only clients. If you just extend import rather than rename it mp-import and extend it, then old RPSL only clients will consider you autnum broken. If you include mp-import but forget to reflect you IPv4 policy in plain import then the old RPSL client will pick up a subset of you policy. In either case, extending import, or adding mp-import and putting the extensions there, it would make for a smoother transition if the server code could recognize old clients and feed them with objects translated into plain RPSL. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 22 12:43:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24440 for ; Mon, 22 Sep 2003 12:43:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Tmg-0000o3-Ew for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 12:43:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MGhYtg003092 for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 12:43:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Tmg-0000nl-AP for rps-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 12:43:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24393 for ; Mon, 22 Sep 2003 12:43:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Tm9-0000ii-1h; Mon, 22 Sep 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Tlk-0000gK-5h for rps@optimus.ietf.org; Mon, 22 Sep 2003 12:42:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24315; Mon, 22 Sep 2003 12:42:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Tli-00041e-00; Mon, 22 Sep 2003 12:42:34 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A1TlX-0003uB-00; Mon, 22 Sep 2003 12:42:23 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8MGe66Z026475; Mon, 22 Sep 2003 12:40:08 -0400 Message-Id: <200309221640.h8MGe66Z026475@mail.avici.com> To: Mark Prior cc: Pekka Savola , curtis@fictitious.org, iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Mon, 22 Sep 2003 09:04:12 +0930." <3F6E3574.1040300@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 12:40:16 -0400 In message <3F6E3574.1040300@mrp.net>, Mark Prior writes: > > Personally I would prefer it if RPSLng was a super set of RPSL and from > my point of view RPSLng policy = RPSL policy would be really nice. I > still fail to see why we need most of the mp-* stuff anyway. > > Mark. Mark, How is RPSLng not a superset of RPSL? Nothing has been removed from RPSL. The issue is just how do you make transition easiest, supporting older RPSL only clients. If you just extend import rather than rename it mp-import and extend it, then old RPSL only clients will consider you autnum broken. If you include mp-import but forget to reflect you IPv4 policy in plain import then the old RPSL client will pick up a subset of you policy. In either case, extending import, or adding mp-import and putting the extensions there, it would make for a smoother transition if the server code could recognize old clients and feed them with objects translated into plain RPSL. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 22 20:16:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18573 for ; Mon, 22 Sep 2003 20:16:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1aqX-0001lw-2L; Mon, 22 Sep 2003 20:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1apb-0001g9-6N for rps@optimus.ietf.org; Mon, 22 Sep 2003 20:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18504; Mon, 22 Sep 2003 20:14:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1apW-0000yA-00; Mon, 22 Sep 2003 20:14:58 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1apV-0000vM-00; Mon, 22 Sep 2003 20:14:58 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8MNU6hu017800 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 23 Sep 2003 09:00:38 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6F85FE.1020302@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309221640.h8MGe66Z026475@mail.avici.com> In-Reply-To: <200309221640.h8MGe66Z026475@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 09:00:06 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > How is RPSLng not a superset of RPSL? Nothing has been removed from > RPSL. Superset is probably not the best word to describe what I want. > The issue is just how do you make transition easiest, supporting older > RPSL only clients. If you just extend import rather than rename it > mp-import and extend it, then old RPSL only clients will consider you > autnum broken. If you include mp-import but forget to reflect you > IPv4 policy in plain import then the old RPSL client will pick up a > subset of you policy. > > In either case, extending import, or adding mp-import and putting the > extensions there, it would make for a smoother transition if the > server code could recognize old clients and feed them with objects > translated into plain RPSL. I think I have been consistent in wanting the smarts to be in the software and not the language. I would prefer to overload the syntax then create new syntax and let the software work out what is required. We don't use different syntax in computer languages when we want to operate on integers rather than reals so why make the distinction in RPSL? If we have a route object that has a IPv6 address in it surely the software can work out if it wants it or not given it's current context? I know you (and others :-) keep on about the old clients but we have left them behind once before in the transition from RIPE 181 to RPSL so do it again but this time lets leave some mechanism behind so that when we need (RPSLng)ng we don't go through this pain yet again. Saying it's not part of the language is a pathetic excuse in my book for not fixing it. If we need a "shim" document to describe the interaction between a server and a client then lets do it. It would make the client software writers life a lot easier if there weren't (at least) 3 server interaction languages to deal with. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 22 20:16:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18588 for ; Mon, 22 Sep 2003 20:16:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1aqt-0001ph-7R for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 20:16:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N0GNLV007041 for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 20:16:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1aqt-0001pU-2Y for rps-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 20:16:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18542 for ; Mon, 22 Sep 2003 20:16:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1aqq-00014x-00 for rps-web-archive@ietf.org; Mon, 22 Sep 2003 20:16:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1aqq-00014s-00 for rps-web-archive@ietf.org; Mon, 22 Sep 2003 20:16:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1aqX-0001lw-2L; Mon, 22 Sep 2003 20:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1apb-0001g9-6N for rps@optimus.ietf.org; Mon, 22 Sep 2003 20:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18504; Mon, 22 Sep 2003 20:14:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1apW-0000yA-00; Mon, 22 Sep 2003 20:14:58 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1apV-0000vM-00; Mon, 22 Sep 2003 20:14:58 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8MNU6hu017800 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 23 Sep 2003 09:00:38 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6F85FE.1020302@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309221640.h8MGe66Z026475@mail.avici.com> In-Reply-To: <200309221640.h8MGe66Z026475@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 09:00:06 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > How is RPSLng not a superset of RPSL? Nothing has been removed from > RPSL. Superset is probably not the best word to describe what I want. > The issue is just how do you make transition easiest, supporting older > RPSL only clients. If you just extend import rather than rename it > mp-import and extend it, then old RPSL only clients will consider you > autnum broken. If you include mp-import but forget to reflect you > IPv4 policy in plain import then the old RPSL client will pick up a > subset of you policy. > > In either case, extending import, or adding mp-import and putting the > extensions there, it would make for a smoother transition if the > server code could recognize old clients and feed them with objects > translated into plain RPSL. I think I have been consistent in wanting the smarts to be in the software and not the language. I would prefer to overload the syntax then create new syntax and let the software work out what is required. We don't use different syntax in computer languages when we want to operate on integers rather than reals so why make the distinction in RPSL? If we have a route object that has a IPv6 address in it surely the software can work out if it wants it or not given it's current context? I know you (and others :-) keep on about the old clients but we have left them behind once before in the transition from RIPE 181 to RPSL so do it again but this time lets leave some mechanism behind so that when we need (RPSLng)ng we don't go through this pain yet again. Saying it's not part of the language is a pathetic excuse in my book for not fixing it. If we need a "shim" document to describe the interaction between a server and a client then lets do it. It would make the client software writers life a lot easier if there weren't (at least) 3 server interaction languages to deal with. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 22 22:15:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23532 for ; Mon, 22 Sep 2003 22:15:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1chh-0006le-DX; Mon, 22 Sep 2003 22:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1cgz-0006hU-2s for rps@optimus.ietf.org; Mon, 22 Sep 2003 22:14:17 -0400 Received: from mail.avici.com ([12.38.212.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23224; Mon, 22 Sep 2003 22:14:07 -0400 (EDT) Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8N2Bx6Z022900; Mon, 22 Sep 2003 22:12:00 -0400 Message-Id: <200309230212.h8N2Bx6Z022900@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 23 Sep 2003 09:00:06 +0930." <3F6F85FE.1020302@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 22:12:09 -0400 In message <3F6F85FE.1020302@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > RPSL. > > Superset is probably not the best word to describe what I want. > > > The issue is just how do you make transition easiest, supporting older > > RPSL only clients. If you just extend import rather than rename it > > mp-import and extend it, then old RPSL only clients will consider you > > autnum broken. If you include mp-import but forget to reflect you > > IPv4 policy in plain import then the old RPSL client will pick up a > > subset of you policy. > > > > In either case, extending import, or adding mp-import and putting the > > extensions there, it would make for a smoother transition if the > > server code could recognize old clients and feed them with objects > > translated into plain RPSL. > > I think I have been consistent in wanting the smarts to be in the > software and not the language. I would prefer to overload the syntax > then create new syntax and let the software work out what is required. > We don't use different syntax in computer languages when we want to > operate on integers rather than reals so why make the distinction in > RPSL? If we have a route object that has a IPv6 address in it surely the > software can work out if it wants it or not given it's current context? The default right now for the non mp-* import, export, etc is to assume ipv4-unicast. Maybe what you want is adding the option to the existing non mp-* syntax to specify other protocol. What might be better is to keep the idea of mp-* but make the default protocol ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we need an ipv4-all and ipv6-all. The ip-all or ip-everything would be shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, which is a lot to type. If a lot of providers have common policy then omitting any protocol spec could default to ip-everything. > I know you (and others :-) keep on about the old clients but we have > left them behind once before in the transition from RIPE 181 to RPSL so > do it again but this time lets leave some mechanism behind so that when > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > not part of the language is a pathetic excuse in my book for not fixing > it. If we need a "shim" document to describe the interaction between a > server and a client then lets do it. It would make the client software > writers life a lot easier if there weren't (at least) 3 server > interaction languages to deal with. Having written plenty of small compilers I can understand why implementors would prefer to keep things simple for them. For something like an mp-import if you specify ip-everything (may that is needed) then you can mix ipv4 and ipv6 addresses and the code should figure it out. If you submit an autnum with import it would imply ipv4-unicast. If you submit an sutnum (could be the same autnum) with mp-import but no protocol specified it would be ip-everything. Does that sound like an improvement to you? My reasoning for keeping mp-* is that for import you'd want the lack of newly attributes to mean what they meant in objects submitted a long time ago (for example ipv4-unicast only), but with a new mp-import defaults can be whatever case is thought to be most common. For other objects this seems to make sense too. For mp-peer, a default of ip-everything makes sense, keeping peer to mean ipv4-unicast. > Mark. I'm waiting to hear if implementors think that returning an import in place of an mp-import (etc) to an RPSL-only client will be difficult or whether it doesn't sound so hard after thinking about it. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 22 22:15:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23619 for ; Mon, 22 Sep 2003 22:15:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ciG-0006sc-Bg for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 22:15:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N2FaC4026439 for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 22:15:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ciG-0006sL-81 for rps-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 22:15:36 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23531 for ; Mon, 22 Sep 2003 22:15:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1chh-0006le-DX; Mon, 22 Sep 2003 22:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1cgz-0006hU-2s for rps@optimus.ietf.org; Mon, 22 Sep 2003 22:14:17 -0400 Received: from mail.avici.com ([12.38.212.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23224; Mon, 22 Sep 2003 22:14:07 -0400 (EDT) Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8N2Bx6Z022900; Mon, 22 Sep 2003 22:12:00 -0400 Message-Id: <200309230212.h8N2Bx6Z022900@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 23 Sep 2003 09:00:06 +0930." <3F6F85FE.1020302@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 22:12:09 -0400 In message <3F6F85FE.1020302@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > RPSL. > > Superset is probably not the best word to describe what I want. > > > The issue is just how do you make transition easiest, supporting older > > RPSL only clients. If you just extend import rather than rename it > > mp-import and extend it, then old RPSL only clients will consider you > > autnum broken. If you include mp-import but forget to reflect you > > IPv4 policy in plain import then the old RPSL client will pick up a > > subset of you policy. > > > > In either case, extending import, or adding mp-import and putting the > > extensions there, it would make for a smoother transition if the > > server code could recognize old clients and feed them with objects > > translated into plain RPSL. > > I think I have been consistent in wanting the smarts to be in the > software and not the language. I would prefer to overload the syntax > then create new syntax and let the software work out what is required. > We don't use different syntax in computer languages when we want to > operate on integers rather than reals so why make the distinction in > RPSL? If we have a route object that has a IPv6 address in it surely the > software can work out if it wants it or not given it's current context? The default right now for the non mp-* import, export, etc is to assume ipv4-unicast. Maybe what you want is adding the option to the existing non mp-* syntax to specify other protocol. What might be better is to keep the idea of mp-* but make the default protocol ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we need an ipv4-all and ipv6-all. The ip-all or ip-everything would be shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, which is a lot to type. If a lot of providers have common policy then omitting any protocol spec could default to ip-everything. > I know you (and others :-) keep on about the old clients but we have > left them behind once before in the transition from RIPE 181 to RPSL so > do it again but this time lets leave some mechanism behind so that when > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > not part of the language is a pathetic excuse in my book for not fixing > it. If we need a "shim" document to describe the interaction between a > server and a client then lets do it. It would make the client software > writers life a lot easier if there weren't (at least) 3 server > interaction languages to deal with. Having written plenty of small compilers I can understand why implementors would prefer to keep things simple for them. For something like an mp-import if you specify ip-everything (may that is needed) then you can mix ipv4 and ipv6 addresses and the code should figure it out. If you submit an autnum with import it would imply ipv4-unicast. If you submit an sutnum (could be the same autnum) with mp-import but no protocol specified it would be ip-everything. Does that sound like an improvement to you? My reasoning for keeping mp-* is that for import you'd want the lack of newly attributes to mean what they meant in objects submitted a long time ago (for example ipv4-unicast only), but with a new mp-import defaults can be whatever case is thought to be most common. For other objects this seems to make sense too. For mp-peer, a default of ip-everything makes sense, keeping peer to mean ipv4-unicast. > Mark. I'm waiting to hear if implementors think that returning an import in place of an mp-import (etc) to an RPSL-only client will be difficult or whether it doesn't sound so hard after thinking about it. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 22 22:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04745 for ; Mon, 22 Sep 2003 22:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dIS-0003mx-KX; Mon, 22 Sep 2003 22:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dHc-0003hi-OK for rps@optimus.ietf.org; Mon, 22 Sep 2003 22:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04679; Mon, 22 Sep 2003 22:51:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dHZ-00040H-00; Mon, 22 Sep 2003 22:52:05 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1dHY-0003x6-00; Mon, 22 Sep 2003 22:52:04 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8N2oghu018507 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 23 Sep 2003 12:21:13 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6FB501.5020902@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309230212.h8N2Bx6Z022900@mail.avici.com> In-Reply-To: <200309230212.h8N2Bx6Z022900@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 12:20:41 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Having written plenty of small compilers I can understand why > implementors would prefer to keep things simple for them. One group writes one compiler once, many clients use that compiler, many times. I know which group I would prefer to make life easier for :-) Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 22 22:53:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04818 for ; Mon, 22 Sep 2003 22:53:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dJ4-00046r-Hm for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 22:53:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N2rcgu015791 for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 22:53:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dJ4-00046b-DS for rps-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 22:53:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04746 for ; Mon, 22 Sep 2003 22:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dIS-0003mx-KX; Mon, 22 Sep 2003 22:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dHc-0003hi-OK for rps@optimus.ietf.org; Mon, 22 Sep 2003 22:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04679; Mon, 22 Sep 2003 22:51:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dHZ-00040H-00; Mon, 22 Sep 2003 22:52:05 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1dHY-0003x6-00; Mon, 22 Sep 2003 22:52:04 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8N2oghu018507 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 23 Sep 2003 12:21:13 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6FB501.5020902@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309230212.h8N2Bx6Z022900@mail.avici.com> In-Reply-To: <200309230212.h8N2Bx6Z022900@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 12:20:41 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Having written plenty of small compilers I can understand why > implementors would prefer to keep things simple for them. One group writes one compiler once, many clients use that compiler, many times. I know which group I would prefer to make life easier for :-) Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 22 23:08:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05469 for ; Mon, 22 Sep 2003 23:08:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dWz-0006H4-2a; Mon, 22 Sep 2003 23:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dWc-000683-3K for rps@optimus.ietf.org; Mon, 22 Sep 2003 23:07:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05429; Mon, 22 Sep 2003 23:07:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dWY-0005Rk-00; Mon, 22 Sep 2003 23:07:34 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1dWW-0005P5-00; Mon, 22 Sep 2003 23:07:33 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8N36ahu018571 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 23 Sep 2003 12:36:44 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6FB8BC.5000506@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309230212.h8N2Bx6Z022900@mail.avici.com> In-Reply-To: <200309230212.h8N2Bx6Z022900@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 12:36:36 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > The default right now for the non mp-* import, export, etc is to > assume ipv4-unicast. Maybe what you want is adding the option to the > existing non mp-* syntax to specify other protocol. What might be > better is to keep the idea of mp-* but make the default protocol > ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we > need an ipv4-all and ipv6-all. The ip-all or ip-everything would be > shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, > which is a lot to type. If a lot of providers have common policy then > omitting any protocol spec could default to ip-everything. I would prefer that the meaning be taken from the context of its use. If your policy is the same, irrespective of protocol, then a single import statement is sufficent and from a policy statement point of view it probably doesn't matter if it is read as ipv4 unicast or ip anything or ... It is the application of the policy statement where the intent is important and one would hope the user knows what they are doing. This would mean that the syntax of the tool using the policy might now say use the import/export policy relating to this AS number but I only need unicast IPv4 here so just get me the appropriate bits. If you do actually have different policy for different protocols then you probably want an additional mechanism that specifies that the policy fragment only applies to that protocol. In this case you could add the appropriate protocol modifier to the statement. I would expect that this is the exception rather than the rule in real life. > For something like an mp-import if you specify ip-everything (may that > is needed) then you can mix ipv4 and ipv6 addresses and the code > should figure it out. If you submit an autnum with import it would > imply ipv4-unicast. If you submit an sutnum (could be the same > autnum) with mp-import but no protocol specified it would be > ip-everything. Does that sound like an improvement to you? I don't see the point of the mp-import. I would see import implying ip everything. I would think it is rare for anyone to use someone else's autnum, or in fact rely on anyone else's sets, so I don't see the danger of using an old RPSL only tool with RPSLng data. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 22 23:08:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05489 for ; Mon, 22 Sep 2003 23:08:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dX3-0006JK-4U for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 23:08:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N385X5024252 for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 23:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dX3-0006J4-0T for rps-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 23:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05444 for ; Mon, 22 Sep 2003 23:07:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dWz-0005UT-00 for rps-web-archive@ietf.org; Mon, 22 Sep 2003 23:08:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1dWy-0005UP-00 for rps-web-archive@ietf.org; Mon, 22 Sep 2003 23:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dWz-0006H4-2a; Mon, 22 Sep 2003 23:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dWc-000683-3K for rps@optimus.ietf.org; Mon, 22 Sep 2003 23:07:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05429; Mon, 22 Sep 2003 23:07:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dWY-0005Rk-00; Mon, 22 Sep 2003 23:07:34 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1dWW-0005P5-00; Mon, 22 Sep 2003 23:07:33 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8N36ahu018571 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 23 Sep 2003 12:36:44 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6FB8BC.5000506@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309230212.h8N2Bx6Z022900@mail.avici.com> In-Reply-To: <200309230212.h8N2Bx6Z022900@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 12:36:36 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > The default right now for the non mp-* import, export, etc is to > assume ipv4-unicast. Maybe what you want is adding the option to the > existing non mp-* syntax to specify other protocol. What might be > better is to keep the idea of mp-* but make the default protocol > ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we > need an ipv4-all and ipv6-all. The ip-all or ip-everything would be > shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, > which is a lot to type. If a lot of providers have common policy then > omitting any protocol spec could default to ip-everything. I would prefer that the meaning be taken from the context of its use. If your policy is the same, irrespective of protocol, then a single import statement is sufficent and from a policy statement point of view it probably doesn't matter if it is read as ipv4 unicast or ip anything or ... It is the application of the policy statement where the intent is important and one would hope the user knows what they are doing. This would mean that the syntax of the tool using the policy might now say use the import/export policy relating to this AS number but I only need unicast IPv4 here so just get me the appropriate bits. If you do actually have different policy for different protocols then you probably want an additional mechanism that specifies that the policy fragment only applies to that protocol. In this case you could add the appropriate protocol modifier to the statement. I would expect that this is the exception rather than the rule in real life. > For something like an mp-import if you specify ip-everything (may that > is needed) then you can mix ipv4 and ipv6 addresses and the code > should figure it out. If you submit an autnum with import it would > imply ipv4-unicast. If you submit an sutnum (could be the same > autnum) with mp-import but no protocol specified it would be > ip-everything. Does that sound like an improvement to you? I don't see the point of the mp-import. I would see import implying ip everything. I would think it is rare for anyone to use someone else's autnum, or in fact rely on anyone else's sets, so I don't see the danger of using an old RPSL only tool with RPSLng data. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Sep 22 23:36:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06594 for ; Mon, 22 Sep 2003 23:36:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dy4-0001Pc-1D; Mon, 22 Sep 2003 23:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dxy-0001Ov-Gj for rps@optimus.ietf.org; Mon, 22 Sep 2003 23:35:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06556; Mon, 22 Sep 2003 23:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dxw-0000P1-00; Mon, 22 Sep 2003 23:35:52 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A1dxv-0000Ou-00; Mon, 22 Sep 2003 23:35:51 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8N3Z36Z028732; Mon, 22 Sep 2003 23:35:05 -0400 Message-Id: <200309230335.h8N3Z36Z028732@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 23 Sep 2003 12:36:36 +0930." <3F6FB8BC.5000506@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 23:35:13 -0400 In message <3F6FB8BC.5000506@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > The default right now for the non mp-* import, export, etc is to > > assume ipv4-unicast. Maybe what you want is adding the option to the > > existing non mp-* syntax to specify other protocol. What might be > > better is to keep the idea of mp-* but make the default protocol > > ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we > > need an ipv4-all and ipv6-all. The ip-all or ip-everything would be > > shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, > > which is a lot to type. If a lot of providers have common policy then > > omitting any protocol spec could default to ip-everything. > > I would prefer that the meaning be taken from the context of its use. If > your policy is the same, irrespective of protocol, then a single import > statement is sufficent and from a policy statement point of view it > probably doesn't matter if it is read as ipv4 unicast or ip anything or > ... It is the application of the policy statement where the intent is > important and one would hope the user knows what they are doing. This > would mean that the syntax of the tool using the policy might now say > use the import/export policy relating to this AS number but I only need > unicast IPv4 here so just get me the appropriate bits. > > If you do actually have different policy for different protocols then > you probably want an additional mechanism that specifies that the policy > fragment only applies to that protocol. In this case you could add the > appropriate protocol modifier to the statement. I would expect that this > is the exception rather than the rule in real life. > > > For something like an mp-import if you specify ip-everything (may that > > is needed) then you can mix ipv4 and ipv6 addresses and the code > > should figure it out. If you submit an autnum with import it would > > imply ipv4-unicast. If you submit an sutnum (could be the same > > autnum) with mp-import but no protocol specified it would be > > ip-everything. Does that sound like an improvement to you? > > I don't see the point of the mp-import. I would see import implying ip > everything. I would think it is rare for anyone to use someone else's > autnum, or in fact rely on anyone else's sets, so I don't see the danger > of using an old RPSL only tool with RPSLng data. > > Mark. Mark, You might be right about no one using other peoples autnum and if they are using it for some sort of analysis, they are probably sophisticated enough users to keep their tool collection up to date. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Sep 22 23:36:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06609 for ; Mon, 22 Sep 2003 23:36:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dy9-0001SX-PZ for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 23:36:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N3a5Fc005603 for rps-archive@odin.ietf.org; Mon, 22 Sep 2003 23:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dy9-0001SI-Lw for rps-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 23:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06570 for ; Mon, 22 Sep 2003 23:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dy7-0000QN-00 for rps-web-archive@ietf.org; Mon, 22 Sep 2003 23:36:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1dy7-0000QK-00 for rps-web-archive@ietf.org; Mon, 22 Sep 2003 23:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dy4-0001Pc-1D; Mon, 22 Sep 2003 23:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dxy-0001Ov-Gj for rps@optimus.ietf.org; Mon, 22 Sep 2003 23:35:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06556; Mon, 22 Sep 2003 23:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dxw-0000P1-00; Mon, 22 Sep 2003 23:35:52 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A1dxv-0000Ou-00; Mon, 22 Sep 2003 23:35:51 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8N3Z36Z028732; Mon, 22 Sep 2003 23:35:05 -0400 Message-Id: <200309230335.h8N3Z36Z028732@mail.avici.com> To: Mark Prior cc: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 23 Sep 2003 12:36:36 +0930." <3F6FB8BC.5000506@mrp.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 23:35:13 -0400 In message <3F6FB8BC.5000506@mrp.net>, Mark Prior writes: > Curtis Villamizar wrote: > > > The default right now for the non mp-* import, export, etc is to > > assume ipv4-unicast. Maybe what you want is adding the option to the > > existing non mp-* syntax to specify other protocol. What might be > > better is to keep the idea of mp-* but make the default protocol > > ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we > > need an ipv4-all and ipv6-all. The ip-all or ip-everything would be > > shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, > > which is a lot to type. If a lot of providers have common policy then > > omitting any protocol spec could default to ip-everything. > > I would prefer that the meaning be taken from the context of its use. If > your policy is the same, irrespective of protocol, then a single import > statement is sufficent and from a policy statement point of view it > probably doesn't matter if it is read as ipv4 unicast or ip anything or > ... It is the application of the policy statement where the intent is > important and one would hope the user knows what they are doing. This > would mean that the syntax of the tool using the policy might now say > use the import/export policy relating to this AS number but I only need > unicast IPv4 here so just get me the appropriate bits. > > If you do actually have different policy for different protocols then > you probably want an additional mechanism that specifies that the policy > fragment only applies to that protocol. In this case you could add the > appropriate protocol modifier to the statement. I would expect that this > is the exception rather than the rule in real life. > > > For something like an mp-import if you specify ip-everything (may that > > is needed) then you can mix ipv4 and ipv6 addresses and the code > > should figure it out. If you submit an autnum with import it would > > imply ipv4-unicast. If you submit an sutnum (could be the same > > autnum) with mp-import but no protocol specified it would be > > ip-everything. Does that sound like an improvement to you? > > I don't see the point of the mp-import. I would see import implying ip > everything. I would think it is rare for anyone to use someone else's > autnum, or in fact rely on anyone else's sets, so I don't see the danger > of using an old RPSL only tool with RPSLng data. > > Mark. Mark, You might be right about no one using other peoples autnum and if they are using it for some sort of analysis, they are probably sophisticated enough users to keep their tool collection up to date. Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 23 00:00:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07756 for ; Tue, 23 Sep 2003 00:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eLK-0004LI-Df; Tue, 23 Sep 2003 00:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eLE-0004KA-5M for rps@optimus.ietf.org; Mon, 22 Sep 2003 23:59:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07667; Mon, 22 Sep 2003 23:59:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1eLB-0002hu-00; Mon, 22 Sep 2003 23:59:53 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1eLB-0002et-00; Mon, 22 Sep 2003 23:59:53 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8N3nfhu018703 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 23 Sep 2003 13:20:12 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6FC2D5.9020700@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309230335.h8N3Z36Z028732@mail.avici.com> In-Reply-To: <200309230335.h8N3Z36Z028732@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 13:19:41 +0930 Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > You might be right about no one using other peoples autnum and if they > are using it for some sort of analysis, they are probably > sophisticated enough users to keep their tool collection up to date. The typical problem I found was that not all peers had the objects I wanted (AS sets) and so I had to build them anyway. No great drama for me since I had my own server to populate anyway but I did end up with quite a few stub autnum objects so the hierarchical authentication for the as sets would work :-) Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 23 00:00:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07782 for ; Tue, 23 Sep 2003 00:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eLR-0004Ng-2z for rps-archive@odin.ietf.org; Tue, 23 Sep 2003 00:00:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N4071b016831 for rps-archive@odin.ietf.org; Tue, 23 Sep 2003 00:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eLO-0004NG-OR for rps-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 00:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07684 for ; Mon, 22 Sep 2003 23:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1eLM-0002jO-00 for rps-web-archive@ietf.org; Tue, 23 Sep 2003 00:00:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1eLM-0002jJ-00 for rps-web-archive@ietf.org; Tue, 23 Sep 2003 00:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eLK-0004LI-Df; Tue, 23 Sep 2003 00:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1eLE-0004KA-5M for rps@optimus.ietf.org; Mon, 22 Sep 2003 23:59:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07667; Mon, 22 Sep 2003 23:59:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1eLB-0002hu-00; Mon, 22 Sep 2003 23:59:53 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1eLB-0002et-00; Mon, 22 Sep 2003 23:59:53 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8N3nfhu018703 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 23 Sep 2003 13:20:12 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F6FC2D5.9020700@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <200309230335.h8N3Z36Z028732@mail.avici.com> In-Reply-To: <200309230335.h8N3Z36Z028732@mail.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 13:19:41 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > You might be right about no one using other peoples autnum and if they > are using it for some sort of analysis, they are probably > sophisticated enough users to keep their tool collection up to date. The typical problem I found was that not all peers had the objects I wanted (AS sets) and so I had to build them anyway. No great drama for me since I had my own server to populate anyway but I did end up with quite a few stub autnum objects so the hierarchical authentication for the as sets would work :-) Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 23 17:09:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07077 for ; Tue, 23 Sep 2003 17:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uP6-0006bn-Vk; Tue, 23 Sep 2003 17:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uOk-0006bM-Tu for rps@optimus.ietf.org; Tue, 23 Sep 2003 17:08:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07030; Tue, 23 Sep 2003 17:08:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1uOi-0006vj-00; Tue, 23 Sep 2003 17:08:36 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1A1uOi-0006vd-00; Tue, 23 Sep 2003 17:08:36 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 09F0C4FD9A; Tue, 23 Sep 2003 23:08:06 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A4FB94FD98; Tue, 23 Sep 2003 23:08:05 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h8NL85JO027065; Tue, 23 Sep 2003 23:08:05 +0200 Received: (from engin@localhost) by cow.ripe.net (8.12.10/8.12.6) id h8NL842C005018; Tue, 23 Sep 2003 23:08:04 +0200 From: Engin Gunduz To: curtis@fictitious.org Cc: Mark Prior , Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Message-ID: <20030923210804.GA4850@cow.ripe.net> References: <3F6F85FE.1020302@mrp.net> <200309230212.h8N2Bx6Z022900@mail.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: <200309230212.h8N2Bx6Z022900@mail.avici.com> User-Agent: Mutt/1.4.1i X-RIPE-Spam-Status: N 0.001626 X-RIPE-Signature: 8247c1d1e23262f978ea47b38cf11a86 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 23:08:04 +0200 On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: [...] > > I'm waiting to hear if implementors think that returning an import in > place of an mp-import (etc) to an RPSL-only client will be difficult > or whether it doesn't sound so hard after thinking about it. The whois "protocol" does not allow the server to know if the client is RPSL-only or not. Changing the protocol to accomplish it is I think out of scope. CRISP will be the solution to this problem. -engin > > Curtis -- Engin Gunduz RIPE NCC Database Group _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 23 17:09:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07093 for ; Tue, 23 Sep 2003 17:09:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uPD-0006dm-FW for rps-archive@odin.ietf.org; Tue, 23 Sep 2003 17:09:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NL97hK025520 for rps-archive@odin.ietf.org; Tue, 23 Sep 2003 17:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uPD-0006dX-Ac for rps-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 17:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07049 for ; Tue, 23 Sep 2003 17:08:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1uPA-0006w2-00 for rps-web-archive@ietf.org; Tue, 23 Sep 2003 17:09:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1uPA-0006vz-00 for rps-web-archive@ietf.org; Tue, 23 Sep 2003 17:09:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uP6-0006bn-Vk; Tue, 23 Sep 2003 17:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uOk-0006bM-Tu for rps@optimus.ietf.org; Tue, 23 Sep 2003 17:08:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07030; Tue, 23 Sep 2003 17:08:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1uOi-0006vj-00; Tue, 23 Sep 2003 17:08:36 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1A1uOi-0006vd-00; Tue, 23 Sep 2003 17:08:36 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 09F0C4FD9A; Tue, 23 Sep 2003 23:08:06 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A4FB94FD98; Tue, 23 Sep 2003 23:08:05 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h8NL85JO027065; Tue, 23 Sep 2003 23:08:05 +0200 Received: (from engin@localhost) by cow.ripe.net (8.12.10/8.12.6) id h8NL842C005018; Tue, 23 Sep 2003 23:08:04 +0200 From: Engin Gunduz To: curtis@fictitious.org Cc: Mark Prior , Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Message-ID: <20030923210804.GA4850@cow.ripe.net> References: <3F6F85FE.1020302@mrp.net> <200309230212.h8N2Bx6Z022900@mail.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: <200309230212.h8N2Bx6Z022900@mail.avici.com> User-Agent: Mutt/1.4.1i X-RIPE-Spam-Status: N 0.001626 X-RIPE-Signature: 8247c1d1e23262f978ea47b38cf11a86 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 23:08:04 +0200 On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: [...] > > I'm waiting to hear if implementors think that returning an import in > place of an mp-import (etc) to an RPSL-only client will be difficult > or whether it doesn't sound so hard after thinking about it. The whois "protocol" does not allow the server to know if the client is RPSL-only or not. Changing the protocol to accomplish it is I think out of scope. CRISP will be the solution to this problem. -engin > > Curtis -- Engin Gunduz RIPE NCC Database Group _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 23 19:25:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12936 for ; Tue, 23 Sep 2003 19:25:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wWj-0005XW-KJ; Tue, 23 Sep 2003 19:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wVr-0005V3-1r for rps@optimus.ietf.org; Tue, 23 Sep 2003 19:24:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12838; Tue, 23 Sep 2003 19:24:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1wVp-0000h5-00; Tue, 23 Sep 2003 19:24:05 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A1wVo-0000gT-00; Tue, 23 Sep 2003 19:24:04 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8NNM16Z020030; Tue, 23 Sep 2003 19:22:02 -0400 Message-Id: <200309232322.h8NNM16Z020030@mail.avici.com> To: Engin Gunduz cc: curtis@fictitious.org, Mark Prior , Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 23 Sep 2003 23:08:04 +0200." <20030923210804.GA4850@cow.ripe.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 19:22:11 -0400 In message <20030923210804.GA4850@cow.ripe.net>, Engin Gunduz writes: > On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: > [...] > > > > I'm waiting to hear if implementors think that returning an import in > > place of an mp-import (etc) to an RPSL-only client will be difficult > > or whether it doesn't sound so hard after thinking about it. > > The whois "protocol" does not allow the server to know if the client > is RPSL-only or not. Changing the protocol to accomplish it is I think > out of scope. CRISP will be the solution to this problem. > -engin > > > Curtis > > -- > Engin Gunduz > RIPE NCC Database Group Something like RtConfig could use a newer protocol. A common trick for the whois program has been to include flags in the whois query: whois -h rpslng.ripe.net " --use-rpsl-ng as3561" Tools such as RtConfig are better served by other protocols. It is the older tools that are perl programs or shell scripts built on top of whois, either calling the whois executable or connecting to port 43. For those you can use the trick above or something similar. In the absense of the --use-rpsl-ng only ipv4 policy would be returned, translating mp-* objects at the server on behalf of the client. Make sense? Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 23 19:25:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12951 for ; Tue, 23 Sep 2003 19:25:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wWt-0005aN-Kl for rps-archive@odin.ietf.org; Tue, 23 Sep 2003 19:25:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NNPBAd021467 for rps-archive@odin.ietf.org; Tue, 23 Sep 2003 19:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wWt-0005aA-GW for rps-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 19:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12922 for ; Tue, 23 Sep 2003 19:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1wWr-0000jS-00 for rps-web-archive@ietf.org; Tue, 23 Sep 2003 19:25:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1wWr-0000jP-00 for rps-web-archive@ietf.org; Tue, 23 Sep 2003 19:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wWj-0005XW-KJ; Tue, 23 Sep 2003 19:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wVr-0005V3-1r for rps@optimus.ietf.org; Tue, 23 Sep 2003 19:24:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12838; Tue, 23 Sep 2003 19:24:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1wVp-0000h5-00; Tue, 23 Sep 2003 19:24:05 -0400 Received: from [12.38.212.174] (helo=mail.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1A1wVo-0000gT-00; Tue, 23 Sep 2003 19:24:04 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8NNM16Z020030; Tue, 23 Sep 2003 19:22:02 -0400 Message-Id: <200309232322.h8NNM16Z020030@mail.avici.com> To: Engin Gunduz cc: curtis@fictitious.org, Mark Prior , Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard In-reply-to: Your message of "Tue, 23 Sep 2003 23:08:04 +0200." <20030923210804.GA4850@cow.ripe.net> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 19:22:11 -0400 In message <20030923210804.GA4850@cow.ripe.net>, Engin Gunduz writes: > On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: > [...] > > > > I'm waiting to hear if implementors think that returning an import in > > place of an mp-import (etc) to an RPSL-only client will be difficult > > or whether it doesn't sound so hard after thinking about it. > > The whois "protocol" does not allow the server to know if the client > is RPSL-only or not. Changing the protocol to accomplish it is I think > out of scope. CRISP will be the solution to this problem. > -engin > > > Curtis > > -- > Engin Gunduz > RIPE NCC Database Group Something like RtConfig could use a newer protocol. A common trick for the whois program has been to include flags in the whois query: whois -h rpslng.ripe.net " --use-rpsl-ng as3561" Tools such as RtConfig are better served by other protocols. It is the older tools that are perl programs or shell scripts built on top of whois, either calling the whois executable or connecting to port 43. For those you can use the trick above or something similar. In the absense of the --use-rpsl-ng only ipv4 policy would be returned, translating mp-* objects at the server on behalf of the client. Make sense? Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 23 19:36:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13154 for ; Tue, 23 Sep 2003 19:36:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1whM-0005wJ-U8; Tue, 23 Sep 2003 19:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wgk-0005t0-Ae for rps@optimus.ietf.org; Tue, 23 Sep 2003 19:35:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13114; Tue, 23 Sep 2003 19:35:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1wgi-0000mw-00; Tue, 23 Sep 2003 19:35:20 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1wgh-0000me-00; Tue, 23 Sep 2003 19:35:19 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8NNYMhu001370 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Wed, 24 Sep 2003 09:04:28 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F70D87E.3000508@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Engin Gunduz CC: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <3F6F85FE.1020302@mrp.net> <200309230212.h8N2Bx6Z022900@mail.avici.com> <20030923210804.GA4850@cow.ripe.net> In-Reply-To: <20030923210804.GA4850@cow.ripe.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 09:04:22 +0930 Content-Transfer-Encoding: 7bit Engin Gunduz wrote: > On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: > [...] > >>I'm waiting to hear if implementors think that returning an import in >>place of an mp-import (etc) to an RPSL-only client will be difficult >>or whether it doesn't sound so hard after thinking about it. > > > The whois "protocol" does not allow the server to know if the client > is RPSL-only or not. Changing the protocol to accomplish it is I think > out of scope. CRISP will be the solution to this problem. This is true but at least one of the whois servers used for RPSL already has a mechansim to keep the session open for multiple queries and that isn't in the standard either. Expanding on that you could say that if the text string query (which is all the actual standard allows for) contains some particular token then a server will hold the session open and negotiate options with the client. This behaviour would allow a server to support RPSL, RPSLng, ... concurrently if it wished. Mark. PS I do wonder if the IESG really want to be cc'ed on these messages but I guess they wouldn't be shy in telling us to stop :-) _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 23 19:36:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13169 for ; Tue, 23 Sep 2003 19:36:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1whP-0005xx-9W for rps-archive@odin.ietf.org; Tue, 23 Sep 2003 19:36:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NNa3Gs022927 for rps-archive@odin.ietf.org; Tue, 23 Sep 2003 19:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1whP-0005xi-5k for rps-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 19:36:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13145 for ; Tue, 23 Sep 2003 19:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1whN-0000ne-00 for rps-web-archive@ietf.org; Tue, 23 Sep 2003 19:36:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1whN-0000nb-00 for rps-web-archive@ietf.org; Tue, 23 Sep 2003 19:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1whM-0005wJ-U8; Tue, 23 Sep 2003 19:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1wgk-0005t0-Ae for rps@optimus.ietf.org; Tue, 23 Sep 2003 19:35:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13114; Tue, 23 Sep 2003 19:35:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1wgi-0000mw-00; Tue, 23 Sep 2003 19:35:20 -0400 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1A1wgh-0000me-00; Tue, 23 Sep 2003 19:35:19 -0400 Received: from mrp.net ([192.43.230.3]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id h8NNYMhu001370 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Wed, 24 Sep 2003 09:04:28 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F70D87E.3000508@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Engin Gunduz CC: curtis@fictitious.org, Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard References: <3F6F85FE.1020302@mrp.net> <200309230212.h8N2Bx6Z022900@mail.avici.com> <20030923210804.GA4850@cow.ripe.net> In-Reply-To: <20030923210804.GA4850@cow.ripe.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 09:04:22 +0930 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Engin Gunduz wrote: > On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: > [...] > >>I'm waiting to hear if implementors think that returning an import in >>place of an mp-import (etc) to an RPSL-only client will be difficult >>or whether it doesn't sound so hard after thinking about it. > > > The whois "protocol" does not allow the server to know if the client > is RPSL-only or not. Changing the protocol to accomplish it is I think > out of scope. CRISP will be the solution to this problem. This is true but at least one of the whois servers used for RPSL already has a mechansim to keep the session open for multiple queries and that isn't in the standard either. Expanding on that you could say that if the text string query (which is all the actual standard allows for) contains some particular token then a server will hold the session open and negotiate options with the client. This behaviour would allow a server to support RPSL, RPSLng, ... concurrently if it wished. Mark. PS I do wonder if the IESG really want to be cc'ed on these messages but I guess they wouldn't be shy in telling us to stop :-) _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Sep 30 04:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12563 for ; Tue, 30 Sep 2003 04:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G52-0001SC-LX; Tue, 30 Sep 2003 04:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G4u-0001Rt-47 for rps@optimus.ietf.org; Tue, 30 Sep 2003 04:41:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12515; Tue, 30 Sep 2003 04:41:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4G4q-0003qR-00; Tue, 30 Sep 2003 04:41:48 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1A4G4p-0003qH-00; Tue, 30 Sep 2003 04:41:47 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 923964E15F; Tue, 30 Sep 2003 10:41:18 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DEBFD4E0FA; Tue, 30 Sep 2003 10:41:17 +0200 (CEST) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h8U8fHJO005961; Tue, 30 Sep 2003 10:41:17 +0200 Received: (from engin@localhost) by x47.ripe.net (8.12.10/8.12.6) id h8U8fHXm027107; Tue, 30 Sep 2003 10:41:17 +0200 From: Engin Gunduz To: rpslng@ripe.net, rps@ietf.org Cc: iesg@ietf.org, katie@ripe.net, shane@ripe.net Message-ID: <20030930084117.GE24588@x47.ripe.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-RIPE-Spam-Status: N 0.346929 X-RIPE-Signature: 3a75a762069f2eaa025c9919c40f81f0 Subject: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 10:41:17 +0200 Dear colleagues, We'd like to present the view of the RIPE NCC on the discussions on the RPSLng draft. Although it is not explicitly discussed in the draft, the transition issue was thought on. It was decided to use mp-* attributes to ease the transition. That way, the old clients that use the routing registry that supports RPSLng can simply ignore the new attributes and new object classes and continue to work (this is the expected behaviour of clients, RFC2622 sections 10.2 and 10.3). Thus, it is not really necessary to equip the whois server with the capability of detecting if the client is RPSLng capable or not. Perhaps what we need to do is to document these in the draft. At any rate, we think it is useful to change the protocol to allow negotiation of object format, but this is out of scope of RPSLng effort. The relevant effort to change (or, re-design) the protocol is the CRISP effort, please see http://www.ietf.org/html.charters/crisp-charter.html . On the subprotocol issue: IPv4 address family has defaulted to ipv4.unicast generally (in Cisco IOS software, for instance, which is widely used). Therefore the change of the meaning to ipv4.unicast+ipv4.multicast may cause confusion. We have been trying to come up with a solution so that the users of whois database can start using it to publish their IPv6 and multicast policies. The effort started more than a year ago and our users are getting more and more impatient to see a solution. Actually, long ago they started to "document" their IPv6 and multicast policies using alternative methods, please see aut-num: AS12702 as-name: UUNET-EMEA-IPV6 descr: WorldCom EMEA descr: IPv6 only Autonomous System remarks: detailed routingpolicy is documented at remarks: whois.6bone.net due to missing IPv6 support remarks: in the RIPE database: remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-DE remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-FR remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-NL remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-UK admin-c: ABN-RIPE tech-c: ABN-RIPE mnt-by: UUNET-MNT changed: hostmaster@ripe.net 19991004 changed: ehofmann@uu.net 20021122 source: RIPE or aut-num: AS1122 as-name: UNSPECIFIED descr: UK-AS admin-c: UK6107-RIPE tech-c: UK3 import: from AS760 action pref=100; accept ANY export: to AS760 announce AS1122 remarks: ------------------------- remarks: as-in-v6: from AS760 100 accept ANY remarks: as-in-v6: from AS10566 90 accept ANY remarks: ------------------------- remarks: as-out-v6: to AS760 announce AS1122 remarks: as-out-v6: to AS10566 announce AS1122 remarks: ------------------------- mnt-by: UK-MNT mnt-by: AS1853-MNT changed: Erik-Jan.Bos@surfnet.nl 19940314 changed: ripe-dbm@ripe.net 19990701 changed: woeber@cc.univie.ac.at 19990809 changed: woeber@cc.univie.ac.at 19990912 changed: ulrich.kiermayr@univie.ac.at 20020819 source: RIPE or aut-num: AS1938 as-name: FR-RENATER-IRISA descr: Irisa/Inria Rennes remarks: BEGIN IPv4 unicast routing policy import: from AS13019 action pref=1; accept ANY import: from AS20603 action pref=2; accept ANY export: to AS13019 announce AS1938 export: to AS20603 announce AS1938 remarks: END IPv4 unicast routing policy remarks: BEGIN IPv4 multicast routing policy import: from AS2200 accept ANY export: to AS2200 announce AS1938 remarks: END IPv4 multicast routing policy remarks: BEGIN IPv6 routing policy import: from AS2200 action pref=1; accept ANY import: from AS20603 action pref=2; accept ANY export: to AS2200 announce AS1938 export: to AS20603 announce AS1938 remarks: END IPv6 routing policy admin-c: GR1378-RIPE admin-c: CL4104-RIPE tech-c: DL169-RIPE tech-c: RT199-RIPE mnt-by: RENATER-MNT changed: rensvp@renater.fr 19991014 changed: er-transfer@ripe.net 20020919 changed: rensvp@renater.fr 20030620 source: RIPE so it seems like it's time come up with a solution and implement it. We think the current draft meets the needs. Best regards, -- RIPE NCC RPSLng Team Katie, Shane & Engin _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Sep 30 04:42:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12579 for ; Tue, 30 Sep 2003 04:42:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G5C-0001Tz-HX for rps-archive@odin.ietf.org; Tue, 30 Sep 2003 04:42:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U8gApD005699 for rps-archive@odin.ietf.org; Tue, 30 Sep 2003 04:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G5C-0001Tq-8V for rps-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 04:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12541 for ; Tue, 30 Sep 2003 04:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4G59-0003r4-00 for rps-web-archive@ietf.org; Tue, 30 Sep 2003 04:42:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4G58-0003qy-00 for rps-web-archive@ietf.org; Tue, 30 Sep 2003 04:42:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G52-0001SC-LX; Tue, 30 Sep 2003 04:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G4u-0001Rt-47 for rps@optimus.ietf.org; Tue, 30 Sep 2003 04:41:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12515; Tue, 30 Sep 2003 04:41:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4G4q-0003qR-00; Tue, 30 Sep 2003 04:41:48 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1A4G4p-0003qH-00; Tue, 30 Sep 2003 04:41:47 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 923964E15F; Tue, 30 Sep 2003 10:41:18 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DEBFD4E0FA; Tue, 30 Sep 2003 10:41:17 +0200 (CEST) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h8U8fHJO005961; Tue, 30 Sep 2003 10:41:17 +0200 Received: (from engin@localhost) by x47.ripe.net (8.12.10/8.12.6) id h8U8fHXm027107; Tue, 30 Sep 2003 10:41:17 +0200 From: Engin Gunduz To: rpslng@ripe.net, rps@ietf.org Cc: iesg@ietf.org, katie@ripe.net, shane@ripe.net Message-ID: <20030930084117.GE24588@x47.ripe.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-RIPE-Spam-Status: N 0.346929 X-RIPE-Signature: 3a75a762069f2eaa025c9919c40f81f0 Subject: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 10:41:17 +0200 Dear colleagues, We'd like to present the view of the RIPE NCC on the discussions on the RPSLng draft. Although it is not explicitly discussed in the draft, the transition issue was thought on. It was decided to use mp-* attributes to ease the transition. That way, the old clients that use the routing registry that supports RPSLng can simply ignore the new attributes and new object classes and continue to work (this is the expected behaviour of clients, RFC2622 sections 10.2 and 10.3). Thus, it is not really necessary to equip the whois server with the capability of detecting if the client is RPSLng capable or not. Perhaps what we need to do is to document these in the draft. At any rate, we think it is useful to change the protocol to allow negotiation of object format, but this is out of scope of RPSLng effort. The relevant effort to change (or, re-design) the protocol is the CRISP effort, please see http://www.ietf.org/html.charters/crisp-charter.html . On the subprotocol issue: IPv4 address family has defaulted to ipv4.unicast generally (in Cisco IOS software, for instance, which is widely used). Therefore the change of the meaning to ipv4.unicast+ipv4.multicast may cause confusion. We have been trying to come up with a solution so that the users of whois database can start using it to publish their IPv6 and multicast policies. The effort started more than a year ago and our users are getting more and more impatient to see a solution. Actually, long ago they started to "document" their IPv6 and multicast policies using alternative methods, please see aut-num: AS12702 as-name: UUNET-EMEA-IPV6 descr: WorldCom EMEA descr: IPv6 only Autonomous System remarks: detailed routingpolicy is documented at remarks: whois.6bone.net due to missing IPv6 support remarks: in the RIPE database: remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-DE remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-FR remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-NL remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-UK admin-c: ABN-RIPE tech-c: ABN-RIPE mnt-by: UUNET-MNT changed: hostmaster@ripe.net 19991004 changed: ehofmann@uu.net 20021122 source: RIPE or aut-num: AS1122 as-name: UNSPECIFIED descr: UK-AS admin-c: UK6107-RIPE tech-c: UK3 import: from AS760 action pref=100; accept ANY export: to AS760 announce AS1122 remarks: ------------------------- remarks: as-in-v6: from AS760 100 accept ANY remarks: as-in-v6: from AS10566 90 accept ANY remarks: ------------------------- remarks: as-out-v6: to AS760 announce AS1122 remarks: as-out-v6: to AS10566 announce AS1122 remarks: ------------------------- mnt-by: UK-MNT mnt-by: AS1853-MNT changed: Erik-Jan.Bos@surfnet.nl 19940314 changed: ripe-dbm@ripe.net 19990701 changed: woeber@cc.univie.ac.at 19990809 changed: woeber@cc.univie.ac.at 19990912 changed: ulrich.kiermayr@univie.ac.at 20020819 source: RIPE or aut-num: AS1938 as-name: FR-RENATER-IRISA descr: Irisa/Inria Rennes remarks: BEGIN IPv4 unicast routing policy import: from AS13019 action pref=1; accept ANY import: from AS20603 action pref=2; accept ANY export: to AS13019 announce AS1938 export: to AS20603 announce AS1938 remarks: END IPv4 unicast routing policy remarks: BEGIN IPv4 multicast routing policy import: from AS2200 accept ANY export: to AS2200 announce AS1938 remarks: END IPv4 multicast routing policy remarks: BEGIN IPv6 routing policy import: from AS2200 action pref=1; accept ANY import: from AS20603 action pref=2; accept ANY export: to AS2200 announce AS1938 export: to AS20603 announce AS1938 remarks: END IPv6 routing policy admin-c: GR1378-RIPE admin-c: CL4104-RIPE tech-c: DL169-RIPE tech-c: RT199-RIPE mnt-by: RENATER-MNT changed: rensvp@renater.fr 19991014 changed: er-transfer@ripe.net 20020919 changed: rensvp@renater.fr 20030620 source: RIPE so it seems like it's time come up with a solution and implement it. We think the current draft meets the needs. Best regards, -- RIPE NCC RPSLng Team Katie, Shane & Engin _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps