Subject: [Rps] Re: Latest RPSLng draft

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Dec 2003 19:18:50 +0200 (EET)

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

_______________________________________________
Rps mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rps

---

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Dec 2003 19:18:50 +0200 (EET)

nits:

Abstract

The

==> s/many/may/ ?

Thanks.

---

From: "Larry J. Blunk" <[email-masked]>
Date: 04 Dec 2003 13:39:58 -0500

> 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.

>    for these routers should be described in the appropriate classes 

   Okay, I've updated the wording as suggested.

> 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?

>    keyword "ANY" many also be used instead of prefix ranges

  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

---

From: "Larry J. Blunk" <[email-masked]>
Date: 04 Dec 2003 13:39:58 -0500

Fixed. Thanks.

 -Larry

---

From: "Larry J. Blunk" <[email-masked]>
Date: 09 Dec 2003 10:50:52 -0500

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

---

From: "Larry J. Blunk" <[email-masked]>
Date: 09 Dec 2003 10:50:52 -0500

-Larry

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 09 Dec 2003 12:01:21 -0500

>   Does anyone have any objections to going to last call again?

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 09 Dec 2003 12:01:21 -0500

Curtis

---

From: "Larry J. Blunk" <[email-masked]>
Date: 22 Dec 2003 15:38:45 -0500

> have changed (and are continuing to change).

  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

---

From: "Larry J. Blunk" <[email-masked]>
Date: 22 Dec 2003 15:38:45 -0500

Curtis,

 Regards,
   Larry Blunk