Routing Policy Specification Language next generation (RPSLng)
RFC 4012

Not all Last Call comments (Mark Prior's comments specifically) were yet addressed.

And there seems to be extra burdon on operators.
Discussion continues on rps@ietf.org mailing list

Date: Wed, 10 Sep 2003 13:14:27 +0300 (EEST)
From: Pekka Savola
To: iesg@ietf.org
cc: rpslng@ripe.net,
Subject: Re: Last Call: 'RPSLng' to Proposed Standard

On Tue, 26 Aug 2003, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> 'RPSLng'  as a Proposed Standard. This document
> has been reviewed in the IETF but is not the product of an IETF Working
> Group.
[...]
> File(s) can be obtained via
> http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt

If I'd use the "sirs (or airs)" classification of this document review,
I'd say:

    *    This draft is on the right track but has open issues,
          described in the review.

Below are my comments to the draft.  Overall, I think the document is
pretty good, and a very relevant piece of work; it's needed by IPv6 ops
folks.

However, there seem to be a number of (more or less) textual inaccuracies
and confusion in the document, which should be settled prior to
publication.

I think there are the three most important issues here are:

* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you
conflicting information about IPv4 unicast, then what?

* issue 3) -- whether ipvX should imply only unicast or both unicast and
multicast?

* issue 5) and others-- whether the document needs to specify all the
relevant modifications explicitly, or not.  IMHO, Stds Track document
should describe every change, not just say something like "other
attributes are modified in a similar fashion" (or something to that
effect)

substantial
-----------

1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", or
something like that -- if for no other reason than to have a forward
references in the RFC index to this document?

2) one important aspect to consider is interaction with old specification,
that is:

  Keeping this in mind, the "import:", "export:", and "default:"
  attributes implicitly specify IPv4 unicast policy and remain as
  defined previously in RPSL, and new multi-protocol (prefixed with the
  string "mp-") attributes are introduced. These will be described
  below.

==> so, should one get information from both the RPSLng multiprotocol
attributes and the old ones?  What if they conflict?  Maybe some words would
be useful on how to effectively transition/co-exist with both RPSL and
RPSLng?

3) I note that there is no way to specify "these attributes affect both
multicast and unicast", you have to always include the both, in:

  The possible values for  are:
                                                                                                     
      ipv4
      ipv4.unicast (equivalent to ipv4)
      ipv4.multicast
      ipv6
      ipv6.unicast (equivalent to ipv6)
      ipv6.multicast

==> is this intended?  Is there a particular reason why we couldn't just
assume that "ipv4" includes both unicast and multicast?  Where multicast is
deployed, it's typically mostly congruent with unicast infrastructure, and
where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}"
implication?  Or should there be a separate value which would imply the
both?

4) it seems that ipv6_address dictionary attribute (though trivial) has not
been defined:

  In order to support IPv6 addresses specified with the next-hop
  rp-attribute, a new predefined dictionary type entitled ipv6_address
  is added to the RPSL dictionary.

==> this should probably be something like:

    An IPv6 address is represented as [blah blah blah]

5) As the document is Standards Track (and not e.g. Informational, which
would also be a possibility), I'm not sure whether it's appropriate to wave
away some, possibly important, pieces of the specification, with like:

2.3.2
                                                                                                     
  The  expression is an extension of the RPSL
  expression [section 5.4 of RFC 2622 [1]], with the inclusion of the
  ability to specify IPv6 address prefixes in Address-Prefix sets.  For
  the sake of brevity, we do not include the full definition of
    here and refer the reader to RFC 2622 [1].

and:

4.5 inet-rtr Class

  The "mp-peer:" attribute is defined below.  The difference between
  this attribute and the "peer:" attribute is the inclusion of support
  for IPv6 addresses.

6) there seem to be a case or two where it is not clear whether including
the discussion in this specification is appropriate (and just not
implementation-specific issues, or issues relating to the user's RPSL user
interface); in below, the last sentence seems a bit dubious:

  The evaluation of an  is done by evaluating all of
  its components. Evaluation of peering-sets and filter-sets is
  constrained by the address family. Such constraints may result in a
  {NOT ANY}  or invalid  depending on implicit
  or explicit definitions of the address family in the set. In the
  latter case an error is returned. {NOT ANY}  may issue a
  warning.

7) related to point 4), it may not be apparent what's the intent of the
specification, unless done explicitly; for example:

  Conflicts with explicit or implicit declarations are resolved at
  runtime, that is during evaluation of a policy expression. For
  example, when evaluating the following import policy:
                                                                                                     
  aut-num: AS2
  mp-import: afi ipv6 from AS1 accept {193.0.0.0/22}
                                                                                                     
  the mp-filter should be evaluated as {NOT ANY}.

==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ?
Note that that's very valid for IPv6 too, except perhaps due to the way it's
written (should be {::/0}).  I.e., I think it's very important to specify
the grammar for properly so that the IPv4 and IPv6 addresses can be
distinguished properly in all cases.

8) related to point 5), it is not clear whether the document is intended to
be include conclusive lists of class attributes or just modified ones; for
example:

3. New route6 Class
  member-of    list of          optional, multi-valued
    aggr-bndry                      optional, single-valued
  aggr-mtd      inbound or outbound              optional, single-valued
                []
    mnt-lower    list of              optional, multi-valued

==> note that there are multiple attributes which do not seem to be referred
to in this document.  Is the list in the document intended as a conclusive
list of attributes or just examples?  Based on that, one may have to decide
whether to remove non-modified ones, or whether to ensure that everything is
always present [where's route-set-name or as-expression, for example?]
(and possibly separate new and classic attributes).

==> similar in section 5, at least.

9) there seem to be some mismatches or missing specification; for example,
in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the
like, but the only similar thing in the document so far as been
"":

  mp-members  list of (  optional, multi-valued
              or
              or
              or )

and:

  In RPSLng, these attributes are extended to the route6 and inet6num
  (described below) classes.  Further, the syntax of the existing
  mnt-routes attribute is modified to allow the optional specification
  of IPv6 prefix range lists when present in inet6num, route6, and
  aut-num class objects.

==> it seems the document may be trying to take too many shortcuts by
leaving the values undefined and to be intuitively filled in by the
implementors.

10) remote-endpoint-address specifies some some encapsulations:

    indicates the IPv4 or IPv6 address of the
  remote endpoint of the tunnel. The address family must match that of
  the local endpoint.  denotes the encapsulation used in
  the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}.  Routing
  policies for these routers should be described in the appropriate
  classes (eg. aut-num).

==> I believe DVMRP is probably very much obsolete in this interdomain,
RPSLng context and could be removed.

==> similarly, I do not see the use of IPv6inIPv4.  Doesn't IPinIP already
cover that, *assuming* that one looks at the  and
to figure out what it is.  Including both in here seems
redundant to me; but if that's the path, also include IPv6inIPv6 and
IPv4inIPv6, please!

11) split the references to normative and informative; the first two are
probably normative, and the last one informative.


editorial
---------

==> the document requires Table of Contents, as it's more than 15 pages
long.

                                RPSLng
                      draft-blunk-rpslng-01.txt

==> spell out RPSLng in the title.

Abstract
                                                                                                     
  This memo presents a new set of simple extensions to the RPSL
  language enabling the language to document routing policies for the
  IPv6 and multicast address families currently used in the Internet.

==> similarly, spell out RPSL here.

Blunk, et al.          Expires January 23, 2004                [Page 1]
                                                                                                     
Internet-Draft                  RPSLng                        July 2003

==> I note that the document does not have page breaks (^L) , so it's more
difficult to read and does not print correctly.

  This document proposes to extend RPSL according to the following
  goals and requirements:
                                                                                                     
      Provide RPSL extensibility in the dimension of address families.
      Specifically, to allow users to document routing policy for IPv6
      and multicast.

==> add bullets, dashes, or whatever to the list of four goals/requirements.

      Clarity and non-ambiguity: RPSL information is used by humans in
      addition to software tools.

==> s/Clarity/Maintain clarity/

  Address Family Identifier, , is a RPSL list of address families

==> s/a RPSL/an RPSL/ (everywhere where applicable) ?

  mp-import ::=
          [protocol ] [into ]

==> these should probably be protocol-1 and protocol-2, to be in line with
the rest of the document conventions?

  The  expression is an extension of the RPSL
  expression [section 5.4 of RFC 2622 [1]]

s/[section 5.4 of RFC 2622 [1]]/(section 5.4 of RFC 2622 [1])/ (similar in a
few other places)

  mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo
              except { afi ipv6.unicast,ipv4
              from AS2 action pref = 2; accept AS226
                  except { afi ipv6.unicast
                  from AS3 action pref = 3; accept {3FFE:FFFF::/35}
                        }
                      }

==> should probably use a some more bogus AS number in the example
==> should probably use the /32 prefix length in the example, the same in
some exampler later on.

  Conflicts with explicit or implicit declarations are resolved at
  runtime, that is during evaluation of a policy expression. For
  example, when evaluating the following import policy:

==> s/evaluation/the evaluation/
==> s/that is/that is,/

  to a particular address family using the traditional filtering
  mechanism in use in IRR systems today.

==> spell out IRR.

  mp-peer      or    optional,
                or    multi-valued

==> in here, and many other places, one uses "ipv4_address" and the like.
Note tha lower dash, not dash in the middle; in many other places it's
"ipv4-address" and the like.  Pick one approach and stick to it, please :-)

In the aut-num class,
  the IPv6 prefix ranges may be mixed with IPv4 prefix ranges.  They
  keyword "ANY" is also allowed which means all more specifics.  The
  default when no additional set items are specified is "ANY".

==> s/They/The/.
==> s/all more specifics/any route/?  (why would keyword "ANY" refer to more
specifics only?  that would be highly confusing)

  The  must be a valid two-letter ISO 3166 country code
  identifier.  is a symbolic name for the specified IPv6
  address space.

==> the country code specification is, at least, outside of the scope of
this document, I guess :-)

From: Randy Bush
Date: Tue, 26 Aug 2003 20:07:13 +0900
To: IESG Secretary
Cc: joao@psg.com,
    ljb@merit.edu,
    andrei@ripe.net,
    Florent.Parent@viagenie.qc.ca,
    Bert Wijnen
Subject: LAST CALL REQUEST - draft-blunk-rpslng-01.txt

secretariat,

i am assuming, by piecing together other email as joao did
not specify, he means draft-blunk-rpslng-01.txt.

please issue a FOUR WEEK last call for it.  it needs a four
week last call because it is an individual submission going
for proposed.

i also am assuming, by piecing together other email as joao
did not specify, that the relevant mailing list is

  rpslng@ripe.net

please cc: it, as well as

  rps@ietf.org

thanks.

joao, please tell us if my assumptions are off.

randy

Date: Tue, 26 Aug 2003 12:48:39 +0200
Subject: RPSL ng - next steps
Cc: rpslng@ripe.net
To: randy@psg.com
From: Joao Damas

Randy, all,

I have been in touch with Andrei and Larry (co-authors) recently to
discuss the status of  the -01 draft.
I think we are agreed that this is ready to move forward.
There have been no further comments on the latest draft as sent to the
list by Larry last month, which incorporated the discussions from
earlier in the year.

The RIPE NCC has announced their implementation and I believe Merit is
also doing one.

We would like to request that this draft is published as a proposed
standard.

The only other list I can think of where there might be people who
could provide input on this is the rps@ietf.org list, though I believe
everyone that had an interest is subscribed to the rpslng list.

Regards,
Joao