Subject: RPSL questions

From: Shane Kerr <[email-masked]>
Date: Tue, 01 Aug 2000 11:34:29 +0200

I've been working on reality checking the RIPE routing database versus the 
actual state of the routing tables, and have come to the point where I'd like 
to compare the AS paths of visible routes with the routes registered in the 
database.

Unfortunately, I think that this requires that my software actual analyse the 
relationships between the RPSL objects (previous checks could simply look at 
comparing origin AS's and the like).  RPSL turns out to be, well, non-trivial.

I have some observations and some questions.

My general approach on the RPSL side is to read an entire RPSL database from a 
file and then manipulate it in memory - it's less than 18 Mbyte, and memory is 
cheap.  ;)  It turns out that working with the set classes is fairly difficult.

For as-sets, I first go through each aut-num and add them to the appropriate 
as-sets where they are members by reference.  Next I've done a reachability 
analysis for the graph of sets, so that each as-set knows every aut-num that 
it contains, whether by being in a members list, being a member by reference, 
or by being included from another as-set.  Complicated, but handy for ease of 
use later on.

For filter-sets, the problem is more difficult.  One problem is that there's 
nothing in the RPSL specification that forbids loops in the recursive filter 
set name references.  For example:

    filter-set: fltr-me
    filter:     { 192.168.17.0/24 } or fltr-you
   
    filter-set: fltr-you
    filter:     { 192.168.16.0/24 } or fltr-me

Now, what my program does is maintain a list of traversed filter-set objects 
during evaluation, and abort the evaluation at that point with a warning.  So 
what you end up with is:

    filter-set: fltr-me
    filter:     { 192.168.17.0/24 } or { 192.168.16.0/24 or { } }

    filter-set: fltr-you
    filter:     { 192.168.16.0/24 } or { 192.168.17.0/24 or { } }

Yuck.  Hmm...I suppose I'll have to fix those nested braces and remove them.  
Also, is there a way to group in filters?  I didn't see one, and without one 
certain semantic operations are difficult:

    AS1 and not { 0.0.0.0/0 } or { 14.0.0.0/8 }

    (AS1 and not { 0.0.0.0/0 }) or { 14.0.0.0/8 }
    AS1 and not ( { 0.0.0.0/0 } or { 14.0.0.0/8 } )

Very different, yet both reasonable.  I suppose they can be re-ordered to be 
written in the desired order based on the order of evaluation, but that could 
be complicated from the user point of view, and hence error-prone.

Next, the handy network size operators, specifically ^-, allows for what I 
consider to be inconsistent recursive loops.  Another example:

    route-set:  rs-a
    members:    12.1.2.0/24, rs-b

    route-set:  rs-b
    members:    rs-a^-

Okay, so what could this mean?  Possibilities:

    route-set:  rs-a
    members:    12.1.2.0/24
   
    route-set:  rs-b
    members:    12.1.2.0/24^-

Or:
   
    route-set:  rs-a
    members:    12.1.2.0/24

    route-set:  rs-b
    members:

In the first case, route members are copied to all possible route-sets, and 
then the route set modifiers are applied.  In the second case, route members 
are copied, then the modifiers applied, and so on repeatedly (finally 
evaluating to {{{{{{{12.1.2.0/24^-}^-}^-}^-}^-}^-}^-}^-, which has no members).

Also, can PeerAS be modified with the caret operators?  It's not specified, so 
to me that indicates "no", but since PeerAS is basically a macro for AS###, 
and AS### can be so modified, it is possible.

Comments or pointers much appreciated.

Thanks,
Shane

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Tue, 1 Aug 2000 10:32:26 -0700 (PDT)

Here is a sample use of prtraceroute. It maps traceroute IP addresses
to AS paths, and then verifies if the policies registered allow that
AS path. In your approach you get the AS path directly from BGP (if I
understood it correctly). You can see some valid as hops, some first
choice, some second, and some hops (level3) not there.

[elf prtraceroute]$ sudo ./prtraceroute -h whois.radb.net -p 43 whois.ripe.net
prtraceroute to whois.ripe.net (193.0.0.129), 30 hops max, 12 byte packets
 1  [AS1207] leopard-wireless.ietf.marconi.com (147.73.132.1)  177.695 ms  180.676 ms  197.479 ms
 2  [AS1207] tiger.ietf.marconi.com (147.73.130.2)  336.505 ms [AS5050] nss5-ietf-a8-0-4.psc.net (192.88.115.157)  275.74 ms  190.007 ms
 3  [AS7018] 12.127.244.61 (12.127.244.61)  303.297 ms  5182.99 ms [AS5050] nss5-ietf-a8-0-4.psc.net (192.88.115.157)  166.32 ms
 4  [AS7018] gbr1-a30s9.n54ny.ip.att.net (12.126.7.162)  238.406 ms  175.822 ms  173.137 ms
 5  [AS7018] gbr3-p70.n54ny.ip.att.net (12.122.1.149)  496.015 ms  176.086 ms  175.448 ms
 6  [AS7018] gbr3-p30.wswdc.ip.att.net (12.122.2.166)  259.43 ms  199.438 ms  189.396 ms
 7  [AS7018] ggr1-p360.wswdc.ip.att.net (12.123.9.49)  5270.56 ms  181.35 ms  201.312 ms
 8  *  182.077 ms [AS0] posip2-3.core2.washington1.level3.net (209.0.227.97)  204.091 ms
 9  [AS0] so-6-0-0.mp1.Washington1.level3.net (209.247.10.69)  197.655 ms  190.27 ms *
10   183.928 ms [AS0] so-0-0-0.mp1.Weehawken1.level3.net (209.247.8.46)  209.398 ms  200.077 ms
11  [AS0] loopback0.core1.Weehawken1.Level3.net (209.247.2.1)  209.809 ms * [AS0] so-0-0-0.mp1.Weehawken1.level3.net (209.247.8.46)  190.06 ms
12  * * [AS0] loopback0.core1.Weehawken1.Level3.net (209.247.2.1)  195.378 ms
13  [AS9057] loopback0.ams-ix.Amsterdam1.Level3.net (212.72.32.8)  15518.6 ms [AS0] 63.211.89.1 (63.211.89.1)  329.187 ms  426.964 ms
14  [AS1200] Amsterdam1.ripe.net (193.148.15.68)  669.749 ms  315.879 ms *
15   265.704 ms  268.589 ms [AS6660] fe20.pampus.ripe.net (193.0.0.246)  421.115 ms
16  [AS6660] joshua.ripe.net (193.0.0.200)  593.68 ms [AS6660] fe20.pampus.ripe.net (193.0.0.246)  5426.7 ms  263.061 ms

Path taken: 
AS1207 AS5050 AS7018 (???) (???) (???) (???) (???) (???) AS1200 AS6660 

 16  AS6660 fe20.pampus.ripe.net                destination -> internal 
 15  AS6660 fe20.pampus.ripe.net                  internal -> !export 
 14  AS1200 Amsterdam1.ripe.net                  import: 2 -> peer unregistered  13  AS0 63.211.89.1                         !registered -> !registered 
 12  AS0 loopback0.core1.Weehawken1.Level3.net !registered -> !registered 
 11  AS0 so-0-0-0.mp1.Weehawken1.level3.net  !registered -> !registered 
 10  AS0 so-0-0-0.mp1.Weehawken1.level3.net  !registered -> !registered 
  9  AS0 so-6-0-0.mp1.Washington1.level3.net !registered -> !registered 
  8  AS0 posip2-3.core2.washington1.level3.net !registered -> !registered 
  7  AS7018 ggr1-p360.wswdc.ip.att.net           import: 2 -> internal 
  6  AS7018 gbr3-p30.wswdc.ip.att.net             internal -> internal 
  5  AS7018 gbr3-p70.n54ny.ip.att.net             internal -> internal 
  4  AS7018 gbr1-a30s9.n54ny.ip.att.net           internal -> !export 
  3  AS5050 nss5-ietf-a8-0-4.psc.net             import: 2 -> internal 
  2  AS5050 nss5-ietf-a8-0-4.psc.net              internal -> export 
  1  AS1207 leopard-wireless.ietf.marconi.com    import: 1 -> internal 
  0  AS1207 wireless-132-136.ietf.marconi.com     internal -> source 

Cengiz

-- 
Cengiz Alaettinoglu           Packet Design Inc.

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Tue, 1 Aug 2000 09:56:17 -0700 (PDT)

Shane,

> comparing origin AS's and the like).  RPSL turns out to be, well, non-trivial.

If you just want to compare the origin ASes. You only need to consider
the route objects:

route: 128.9.0.0/16
origin: as226

and see if the BGP AS path has as226 as the last AS. I think Merit
does this on a regular basis and puts the results to their web pages.

I suppose this is what you used to do in the past, and now you want to
do more and actually see if the two consecutive ASes in an AS path can
actually occur according to the policies registered. This is a good
and a novel approach. (Try to design your tool so that it is still
usable if some ASes in an AS path did not register their aut-num's.)

> set name references.  For example:

This recursive behavior is the same as the old well understood
ripe-181 behavior. Basically, you should expand recursions till you
hit a set that is already expanded (no matter the form it
apperars). That is below both filters equal to
   { 192.168.17.0/24 } or  { 192.168.16.0/24 }

>     AS1 and not ( { 0.0.0.0/0 } or { 14.0.0.0/8 } )

You may want to look at peval in RAToolSet, it puts any complicated
policy expression into disjunctive normal form. And also look at
prpath/prtraceroute's from RAToolSet. You will notice they are doing
similar operations on policy as you want to do. You may want to use
the RAToolSet libraries, but build your own application on top.

For example,
./peval -none
peval> {128.9.0.0/16} or {128.8.0.0/16} or {}
({128.8.0.0/16, 128.9.0.0/16})
peval> {128.9.0.0/16} and AS1 or {128.8.0.0/16} and AS1
({128.8.0.0/16, 128.9.0.0/16} AND (AS1 ))

(You can even have as paths and communities).

> Okay, so what could this mean?  Possibilities:

still the same thing, you expand recursion one level:

ra-a is 12.1.2.0/24 and rs-b is 12.1.2.0/24^-

>     members:    12.1.2.0/24^-

yup.

> and AS### can be so modified, it is possible.

PeerAS^+ is valid. And it is not hard. I.e. When it is time to
evaluate whether AS5 can come before AS4 in an AS path and if you are
looking at AS4's import policy, AS5 is the PeerAS.

P.S. A lot of these are already implemented in the RAToolSet
libraries. You may benefit from them.

Cengiz

---

From: Shane Kerr <[email-masked]>
Date: Wed, 02 Aug 2000 13:08:11 +0200

Cengiz Alaettinoglu <[email-masked]> writes:
 * 
 * If you just want to compare the origin ASes. You only need to consider
 * the route objects:
 * 
 * route: 128.9.0.0/16
 * origin: as226
 * 
 * and see if the BGP AS path has as226 as the last AS. I think Merit
 * does this on a regular basis and puts the results to their web pages.
 * 
 * I suppose this is what you used to do in the past, and now you want to
 * do more and actually see if the two consecutive ASes in an AS path can
 * actually occur according to the policies registered. This is a good
 * and a novel approach. (Try to design your tool so that it is still
 * usable if some ASes in an AS path did not register their aut-num's.)

Indeed, comparing the origin AS paths took about 4 hours of work - trivial.  
The stage I'm at now is seeing if every single single AS-path that we see at 
our router is registered correctly (or rather, what parts are registered 
correctly).

 * This recursive behavior is the same as the old well understood
 * ripe-181 behavior. Basically, you should expand recursions till you
 * hit a set that is already expanded (no matter the form it
 * apperars). That is below both filters equal to
 *    { 192.168.17.0/24 } or  { 192.168.16.0/24 }
 * 
 * >     filter-set: fltr-me
 * >     filter:     { 192.168.17.0/24 } or fltr-you
 * >    
 * >     filter-set: fltr-you
 * >     filter:     { 192.168.16.0/24 } or fltr-me
 * > 

I argue that the behaviour is *not* the same as the RIPE-181 behaviour.  There 
are no filter-sets or route-sets in RIPE-181, only as-sets (or as-macros, 
which I understand to be the same).  As I mentioned in my original e-mail, 
handling as-set recursion is not too difficult.  However, this is *not* the 
same as filter-set recursion, which is doing symbolic expansion in an 
expression.  Having a set without any members is not the same as having an 
incomplete expression:

  as-set: as-foo
  members: as-foo

  filter-set: fltr-foo
  filter: any and (not fltr-foo)

Perhaps it's just an aesthetic  preference, but this as-set doesn't bother me, 
but the filter-set does.

Also note that route-set recursion isn't the same as the RIPE-181 as-macro 
recursion, because of the range operators (see below).

 * You may want to look at peval in RAToolSet, it puts any complicated
 * policy expression into disjunctive normal form. And also look at
 * prpath/prtraceroute's from RAToolSet. You will notice they are doing
 * similar operations on policy as you want to do. You may want to use
 * the RAToolSet libraries, but build your own application on top.
 * 
 * For example,
 * ./peval -none
 * peval> {128.9.0.0/16} or {128.8.0.0/16} or {}
 * ({128.8.0.0/16, 128.9.0.0/16})
 * peval> {128.9.0.0/16} and AS1 or {128.8.0.0/16} and AS1
 * ({128.8.0.0/16, 128.9.0.0/16} AND (AS1 ))
 
Ah okay.  I don't really care about conjunctive normal form or anything fancy, 
just the text of RFC 2622 doesn't describe parenthesis as a grouping operator 
(although I now notice that the filter set example uses them).  The grammar 
defined in the appendix includes them, though.  Might be nice to document them 
in the text, especially since grammar doesn't define semantics, just form 
(although I'd say it's fairly safe as is since the meaning of parenthesis is 
obvious).

 * >     route-set:  rs-a
 * >     members:    12.1.2.0/24, rs-b
 * > 
 * >     route-set:  rs-b
 * >     members:    rs-a^-
 * > 
 * > Okay, so what could this mean?  Possibilities:
 * > 
 * 
 * still the same thing, you expand recursion one level:
 * 
 * ra-a is 12.1.2.0/24 and rs-b is 12.1.2.0/24^-

Is this documented anywhere (other than the RAToolSet source code)?  The 
description in RFC 2622 is very terse:  "An address prefix or a route-set name 
in a members attribute can be optionally followed by a range operator."  The 
example then given describes the ^+ operator, which is of course very simple.  
The effects of circular recursion are not documented at all (well, maybe 
buried somewhere in one of the portions after section 8, but I haven't studied 
those yet).

 * > Also, can PeerAS be modified with the caret operators?  It's not specified
 * , so 
 * > to me that indicates "no", but since PeerAS is basically a macro for AS###
 * , 
 * > and AS### can be so modified, it is possible.
 * 
 * PeerAS^+ is valid. And it is not hard. I.e. When it is time to
 * evaluate whether AS5 can come before AS4 in an AS path and if you are
 * looking at AS4's import policy, AS5 is the PeerAS.
 * 
 * P.S. A lot of these are already implemented in the RAToolSet
 * libraries. You may benefit from them.
 * 
 * Cengiz

Again, it might be nice if the use of range operators on PeerAS was 
documented.  I appreciate that much of this stuff is already implemented in 
the RAToolSet code.  I have downloaded it, and am perusing the prtraceroute 
code now (even though it won't compile on either BSDi 3.1 or Solaris 7 - 
complaints about some Linux header file that I don't feel like looking at 
now).  While it should be helpful to see how the libraries do things, I'd 
prefer to understand them at the same time.

It does worry me a bit that the answer to "How does feature xyz work?" seems 
to be "RAToolSet does it like this".  :(  Even so, I'll probably steal the 
BGPRoute::isMatching() code, at least in part.  :)

Speaking of which, is the code really copyright 1994 by USC and/or IBM?  I may 
not be able to use it then, since this is definitely for commercial purposes 
(at least, as long as RIPE NCC charges for services).

Shane

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Wed, 2 Aug 2000 10:33:47 -0700 (PDT)

Shane,

Please provide any clarifying text you think would make the document
more clear. This kind of text is OK to add during the proposed
standards stage.

Disallowing mutual recursion is not an option since those two objects
may be registered by different people. However the DB implementors are
encouraged to disallow or warn users of these. But if the semantics
are not clear when the recursion is used, as an author, I would
welcome a draft paragraph on what the semantics should be. I could
work from that paragraph and include it in the document.

>  * peval> {128.9.0.0/16} or {128.8.0.0/16} or {}

Actually, the document says parenthesis can be used to change the order
of evaluation. 

Perhaps what we need to make explicit the evaluation of a set in a
recursion chain a second time terminates in an empty set, (or "not
any" in case of filter set).

> buried somewhere in one of the portions after section 8, but I haven't studied 

The document explains ^ operators as operators that take a prefix as
an argument and make them a "set" of prefixes. The document also says
when ^ operators are applied to a "set" of prefixes, they distribute
over the members of the set. Hence the following is valid:

     { 128.9.160.0/24^+ }^32

{ 128.9.160.0/24^+ } is a set of 512 prefixes (i.e. all more
specifics of /24). You apply ^32 to all of these 512 prefixes. You get
256 prefixes as a result those are the ones with length 32. These 256
prefixes can be written as 128.9.160.0/24^32. But to get the semantics
right, always think of set of prefixes. rs-foo, or AS555 also all
define set of prefixes hence rs-foo^+ is also valid.

If you think the document is terse on this, please let me know, or
provide a paragraph.

> BGPRoute::isMatching() code, at least in part.  :)

Please reread my email, and you will see I have not done this. I only
pointed to you free (and IMO good) code that you may or may not
benefit from.

> (at least, as long as RIPE NCC charges for services).

Unless you intend to sell your BGP verification tool, ISI's view is
that you can do whatever you want with it. Note that most of our users
are ISP's who use them in their commercial networks. If you sell your
BGP tool and make money, ISI would like to get a cut, but this is not
how RIPE works. (I no longer can speak for ISI, but I dont think the
view has changed).

Cengiz

---

From: Shane Kerr <[email-masked]>
Date: Wed, 16 Aug 2000 16:36:47 +0200

Cengiz,

Sorry about taking so long to get back on this.  Fortunately (for me) 
the project I'm working on probably won't require much sophisticated 
RPSL interpreting, at least originally.

And all this after I wrote an RPSL interpreter in Perl (not complete, 
but it understands the current RIPE-181 to RPSL converted data).  ;)

Apologies if this has all been discussed before, and none of the 
following suggestions are meant to be taken with anything but a grain 
of proverb.

> work from that paragraph and include it in the document.

I understood mutual recursion may be important, but I still think the 
semantics are not well-defined by the RFC.  Again:

1. For as-sets there is no problem, because they are true sets, and set 
theory has no problem handling this (with no exclusion operators, you 
never get Russell's paradox after all).

2. For rs-sets there is a problem because it is not exactly defined 
what an inclusion of a more specific route, ^-, means in a recursive 
scenario.  I would suggest that the RFC say something like you mention 
in your reply:

"In the case of a recursive rs-set using a range operator, the range 
operators should be considered to apply after member sets have been 
added.  For example:

    route-set:  rs-louis
    members:    12.1.2.0/24, rs-wu

    route-set:  rs-wu
    members:    rs-louis^-

Is the same as:

    route-set:  rs-louis
    members:    12.1.2.0/24

    route-set:  rs-wu
    members:    12.1.2.0/24^-"

3. For filter-sets, first the easy addition:

"Any range operator may be applied on PeerAS, the same as any other AS."

Next, the more sticky problem of recursive filter-sets:

"In the case of a recursive filter-set, the recursive reference is 
considered to be an empty list when evaluated.  For example:

    filter-set: fltr-chmee
    filter:     any and (not fltr-chmee)

Is the same as:

    filter-set: fltr-chmee
    filter:     any and (not { })

This is true no matter at which point in the evaluation of the set the 
recursion occurs."

4. I'd also like to see comments handled differently.  I would suggest:

"An attribute with a free-form value may not have a comment.  The '#' 
character is considered part of the text."

I think it would be nice to allow:

  person:   Shane Kerr
  address:  RIPE NCC
  address:  Singel #258
  address:  1016 AB  Amsterdam
  address:  NL
  
Without the number being ripped off because it's a comment.  People 
really do use the (pound|hash|sharp|number) character!

5. Another nit-picky detail.  The phone specification is:

  +<country-code> <city> <subscriber> [ext. <extension>]

Unfortunately, this won't work for regions without city codes, e.g. 
North America.  I mean, you can fake it, but it's not strictly correct. 
Perhaps:

  +<country-code> [<city>] <subscriber> [ext. <extension>]

It's non-ambiguous still, and could be 100% correct.  :)

6. YANPD (Yet Another Nit-Picky Detail).  On page 9, it reads:

"The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and 
source attributes are attributes of all RPSL classes.  Their syntax,
semantics, and mandatory, optional, multi-valued, or single-valued 
status are the same for all RPSL classes." 

However, it doesn't then bother to say what those are.  Presumably 
(necessarily?) this is as defined under the maintainer class itself.  
I'd like to see this explicitly stated, or better yet defined before 
jumping in to class definitions (more on this below).

These would help me, at least.  Actually, having worked through the 
RFC, it fits in very well with the other IETF RFC's I've used to try to 
build software.  It's very difficult.  :P

I think perhaps a reorgani[sz]ation would be helpful.  I don't know if 
it is possible at this stage of the document, however.  I still haven't 
gotten especially familiar with all of the document (esp. the advanced 
route stuff), but from what I have done, I can suggest:

1. Move all attribute descriptions to a single section (section 2 is 
fine).  Perhaps put generic (i.e. date, free-form) and specific (i.e. 
phone, email-address) in different sub-sections.  Perhaps separate out 
routing related (i.e. ipv4-address, address-prefix-range) from other 
attributes (i.e. nic-handle, dns-name), on this assumption that most 
folks are already familiar with a DNS name, or can at least look it up.

2. Move the mntner class into a separate section, and make the 
description of the contact information an appendix.  The mntner objects 
are required, as they are used for mnt-by-ref, but the contact 
information is simply flavou?r text.

3. Move the description of sets to after the description of the data 
that the sets will contain.  I found forward referencing the contents 
of sets stranger than forward referencing sets themselves.

4. Move the description of the predefined set objects into the 
description of each set type.  For instance, put the description of ASx 
and AS-X into a subsection (with a title) of the as-set description, 
along with AS-ANY and PeerAS (not sure why that's not there).  Put the 
description of RS-ANY into a subsection on route-set.

5.  Move the description of filtering out of the filter-set description and 
either:

  - put it in front, after the description of attributes
  - make it an appendix

This filtering language is used by aut-num objects after all!

I found it interesting (and a pain) that routes have a key composed of 
multiple attributes.  They are, in fact, the only class that has a 
composite key.  Personally, I think it would be nice to eliminate this, 
and instead have:

  route:   <address-prefix>    mandatory, single-valued, class key
  origin:  <as-number>         mandatory, list-valued
  
I suppose you could have the same route from different origins with 
different maintainers, but realistically that doesn't happen very 
often - I checked the routing tables to be sure.  ;)

Actually, I found the use of list AND multi-valued attributes to be 
redundant.  It's not too bad, but in the code they end up getting 
combined into a single list, so why have both types?  Someone mentioned 
that it might be helpful for separation of duties (i.e. one list is 
maintained by maintainer A, a second list by maintainer B).  It seems 
like an explicit remark attribute would be much more helpful (better to 
explain what you mean than hope that people can figure it out).

Shane

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Thu, 24 Aug 2000 12:02:28 -0700 (PDT)

Shane, these are excellent comments. When we re-open, you can count on
seeing these in the document. 

I think # comments in free-text is a good point. The
multi-valued/list-valued was discusses a lot, for a while we
disallowed list-valued attributes to be multi-valued at the same time.

Cengiz

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Thu, 24 Aug 2000 12:09:14 -0700 (PDT)

> disallowed list-valued attributes to be multi-valued at the same time.

Oh, I was not clear. I meant we will not reopen the
multi-valued/list-valued discussion again since it was discussed a
lot.

Cengiz

---

From: Engin Gunduz <[email-masked]>
Date: Fri, 25 Aug 2000 09:37:55 +0200 (CEST)

Hi Cengiz,

> multi-valued/list-valued discussion again since it was discussed a

Do you have a document which contains changes to RFC 2622 
(which will possibly be incorporated into next RPSL RFC) ?

Thanks,
-engin

Engin Gunduz
RIPE NCC Database Group

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Fri, 25 Aug 2000 16:05:37 -0700 (PDT)

> (which will possibly be incorporated into next RPSL RFC) ?

No, only a todo list. It is almost entirely for clarification. There
is also one message from you regarding rps auth. May be one of these
days I can sum of the todo list.

Cengiz