I forgot to add that there is also an HTML version available at www.radb.net/rpslng.html -Larry
On 21 Nov 2003, Larry J. Blunk wrote:
I forgot to add that there is also an HTML version available at www.radb.net/rpslng.html
Sorry.. I tried to follow up on this quicker, but forgot. A glanced through the diffs between the documents. Seems pretty good. The one high-level comment still left is that I think it would probably make a bit more sense to specify that "ipv4" means "ipv4.unicast,ipv4.multicast" and the same for IPv6 -- that is, do not assume that only unicast would be specified by default. But I don't feel really strongly about this. A couple of minor issues.. <remote-endpoint-address> indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. <encapsulation> denotes the encapsulation used in the tunnel and is one of {GRE,IPinIP}. Routing policies for these routers should be described in the appropriate classes (eg. (e.g. aut-num). ==> This was changed to remove IPv6inIP (for the good), but maybe one should add a brief note on this, like reword to: <remote-endpoint-address> indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. <encapsulation> denotes the encapsulation used in the tunnel and is one of {GRE,IPinIP} (note the outer and inner IP protocol versions can be deduced from the interface context -- so e.g., IPv6-in-IPv4 encapsulation is just IPinIP). Routing policies for these routers should be described in the appropriate classes (eg. (e.g. aut-num). nits: Abstract This memo presents a new set of simple extensions to the Routing Policy Specification Language (RPSL) [1] enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. ==> remove the reference ([1]) from the abstract, it isn't allowed per IESG's ID-nits. It's good as it is without it. ==> I'd also state a very obvious thing that RPSLng is a superset of RPSL; this could be done by rewording s/enabling the language to document/enabling the language to also document/ The keyword "ANY" many also be used instead of prefix ranges ==> s/many/may/ ? Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Mon, 2003-12-01 at 12:18, Pekka Savola wrote:
On 21 Nov 2003, Larry J. Blunk wrote:
I forgot to add that there is also an HTML version available at www.radb.net/rpslng.html
Sorry.. I tried to follow up on this quicker, but forgot.
A glanced through the diffs between the documents. Seems pretty good. The one high-level comment still left is that I think it would probably make a bit more sense to specify that "ipv4" means "ipv4.unicast,ipv4.multicast" and the same for IPv6 -- that is, do not assume that only unicast would be specified by default. But I don't feel really strongly about this.
Okay, I guess that since you do not feel strongly about this, I will leave it as is. If there is anyone who feels very strongly about this, please speak-up now.
A couple of minor issues..
<remote-endpoint-address> indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. <encapsulation> denotes the encapsulation used in the tunnel and is one of {GRE,IPinIP}. Routing policies for these routers should be described in the appropriate classes (eg. (e.g. aut-num).
==> This was changed to remove IPv6inIP (for the good), but maybe one should add a brief note on this, like reword to:
<remote-endpoint-address> indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. <encapsulation> denotes the encapsulation used in the tunnel and is one of {GRE,IPinIP} (note the outer and inner IP protocol versions can be deduced from the interface context -- so e.g., IPv6-in-IPv4 encapsulation is just IPinIP). Routing policies for these routers should be described in the appropriate classes (eg. (e.g. aut-num).
Okay, I've updated the wording as suggested.
nits:
Abstract
This memo presents a new set of simple extensions to the Routing Policy Specification Language (RPSL) [1] enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet.
==> remove the reference ([1]) from the abstract, it isn't allowed per IESG's ID-nits. It's good as it is without it. ==> I'd also state a very obvious thing that RPSLng is a superset of RPSL; this could be done by rewording s/enabling the language to document/enabling the language to also document/
Done. By the way, the Abstract seems a bit light (the I-D guidelines recommends have 5-10 lines in the Abstract). Does anyone think we should add more text here?
The keyword "ANY" many also be used instead of prefix ranges
==> s/many/may/ ?
Fixed. Thanks. I've gone ahead and submitted an -02 draft to the IETF. Please let me know if there are any other objections/concerns. -Larry
The latest draft is now up on the IETF repository -- http://www.ietf.org/internet-drafts/draft-blunk-rpslng-02.txt I've also put an HTML copy at http://www.radb.net/rpslng.html Does anyone have any objections to going to last call again? -Larry
In message <1070985052.3794.5.camel@ablate.merit.edu>, "Larry J. Blunk" writes:
The latest draft is now up on the IETF repository -- http://www.ietf.org/internet-drafts/draft-blunk-rpslng-02.txt
I've also put an HTML copy at http://www.radb.net/rpslng.html
Does anyone have any objections to going to last call again?
-Larry
No objections here. There were no comments since you sent out this revision (so far at least). For this to go standards track, it would be best if this were a WG document which would mean we should reopen the WG. If so, then I suggest that the WG move this document toward PS. If we're going to reopen then we should decide whether to move RPSL RFC-2622 to DS, recycle as PS with changes, or merge with RPSLng and recycle as PS. The latter (combine RPSL and RPSLng) would be more work (a *lot* more work) but it has been suggested and might improve clarity. If the WG just wants to make RPSLng a WG doc and then advance it as PS, the WG might be able to do so with very strong concensus on the list but more likely would have to reopen and meet at least once, then close again. If the TCPLW WG can be considered as a valid precendence then this shouldn't be too much trouble, but IESG requirements for WG procedures have changed (and are continuing to change). Curtis
On Tue, 2003-12-09 at 12:01, Curtis Villamizar wrote:
In message <1070985052.3794.5.camel@ablate.merit.edu>, "Larry J. Blunk" writes:
The latest draft is now up on the IETF repository -- http://www.ietf.org/internet-drafts/draft-blunk-rpslng-02.txt
I've also put an HTML copy at http://www.radb.net/rpslng.html
Does anyone have any objections to going to last call again?
-Larry
No objections here. There were no comments since you sent out this revision (so far at least).
For this to go standards track, it would be best if this were a WG document which would mean we should reopen the WG. If so, then I suggest that the WG move this document toward PS. If we're going to reopen then we should decide whether to move RPSL RFC-2622 to DS, recycle as PS with changes, or merge with RPSLng and recycle as PS. The latter (combine RPSL and RPSLng) would be more work (a *lot* more work) but it has been suggested and might improve clarity. If the WG just wants to make RPSLng a WG doc and then advance it as PS, the WG might be able to do so with very strong concensus on the list but more likely would have to reopen and meet at least once, then close again. If the TCPLW WG can be considered as a valid precendence then this shouldn't be too much trouble, but IESG requirements for WG procedures have changed (and are continuing to change).
Curtis
Curtis, I'm not sure if there is big need to push this standards track or to merge the RPSL and RPSLng documents. At this point, we (the RPSLng group) have been working on this document for 2 years now and I think the consensus is to go forward without re-opening the WG. Since there have been no further comments I'd like to go to last call on draft-blunk-rpslng-02. As Randy is no longer an A-D, I assume it is up to Bert Wijnen to put this before the IESG? Regards, Larry Blunk
participants (3)
-
Curtis Villamizar -
Larry J. Blunk -
Pekka Savola