[Rps] Re: Latest RPSLng draft

Pekka Savola <pekkas@netcore.fi> Mon, 01 December 2003 17:20 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18467 for <rps-archive@lists.ietf.org>; Mon, 1 Dec 2003 12:20:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQriM-0003EI-79; Mon, 01 Dec 2003 12:20:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrhq-0003DU-L8 for rps@optimus.ietf.org; Mon, 01 Dec 2003 12:19:31 -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 MAA18422 for <rps@ietf.org>; Mon, 1 Dec 2003 12:19:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrhp-0005Vw-00 for rps@ietf.org; Mon, 01 Dec 2003 12:19:29 -0500
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrho-0005VY-00 for rps@ietf.org; Mon, 01 Dec 2003 12:19:28 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hB1HIoN25061; Mon, 1 Dec 2003 19:18:50 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: "Larry J. Blunk" <ljb@merit.edu>
cc: rpslng@ripe.net, rps@ietf.org
In-Reply-To: <1069447019.3260.27.camel@ablate.merit.edu>
Message-ID: <Pine.LNX.4.44.0312011557570.21271-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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: Mon, 01 Dec 2003 19:18:50 +0200

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
Rps@ietf.org
https://www1.ietf.org/mailman/listinfo/rps