[Rps] Re: Latest RPSLng draft
"Larry J. Blunk" <ljb@merit.edu> Thu, 04 December 2003 18:39 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07768 for <rps-archive@lists.ietf.org>; Thu, 4 Dec 2003 13:39:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyMS-0001T8-Py; Thu, 04 Dec 2003 13:38:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyLo-0001D5-5T for rps@optimus.ietf.org; Thu, 04 Dec 2003 13:37:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07624 for <rps@ietf.org>; Thu, 4 Dec 2003 13:37:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyLl-00064r-00 for rps@ietf.org; Thu, 04 Dec 2003 13:37:17 -0500
Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx with esmtp (Exim 4.12) id 1ARyLl-00064c-00 for rps@ietf.org; Thu, 04 Dec 2003 13:37:17 -0500
Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by segue.merit.edu (Postfix) with ESMTP id 8E82A5DF1A; Thu, 4 Dec 2003 13:37:15 -0500 (EST)
From: "Larry J. Blunk" <ljb@merit.edu>
To: Pekka Savola <pekkas@netcore.fi>
Cc: rpslng@ripe.net, rps@ietf.org
In-Reply-To: <Pine.LNX.4.44.0312011557570.21271-100000@netcore.fi>
References: <Pine.LNX.4.44.0312011557570.21271-100000@netcore.fi>
Content-Type: text/plain
Organization: Merit Network, Inc.
Message-Id: <1070563197.3791.20.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
Subject: [Rps] Re: Latest RPSLng draft
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: <https://www1.ietf.org/mailman/listinfo/rps>, <mailto:rps-request@ietf.org?subject=unsubscribe>
List-Id: Routing Policy System <rps.ietf.org>
List-Post: <mailto:rps@ietf.org>
List-Help: <mailto:rps-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rps>, <mailto:rps-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/rps/>
Date: Thu, 04 Dec 2003 13:39:58 -0500
Content-Transfer-Encoding: 7bit
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 _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps
- [Rps] Latest RPSLng draft Larry J. Blunk
- [Rps] Re: Latest RPSLng draft Pekka Savola
- [Rps] Re: Latest RPSLng draft Larry J. Blunk
- [Rps] Re: Latest RPSLng draft Larry J. Blunk
- RPS WG (was Re: [Rps] Re: Latest RPSLng draft) Curtis Villamizar
- Re: RPS WG (was Re: [Rps] Re: Latest RPSLng draft) Larry J. Blunk