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