more on prdb format

 * > Some more things on the format of prdb a la ripe-181:
 * > 
 * > - I thought we agreed to store the objects without syntactic sugar?
 * > The whois server automatically inserts the sugar and if it is already
 * > in the plain db file, it will show up twice in the whois output ....
 * 
 * Ok;  I'm changing this now.  Again, this code predates the decision about
 * syntatic sugar.

OK, excellent.

 * > - there are some extra keywords for the peer definition in an inet-rtr
 * > which are not ripe-181, what are we going to do with them? Examples:
 * > *pe: 144.171.1.254 AS2649 BGP passive
 * > *pe: 192.231.238.3 AS2020 EGP def
 * > 
 * > According to the spec, after the protocol indication there can be an
 * > optional AS number only ....
 * 
 * Yes, this is problem.  I doubt we can generate AS690 configs without
 * this information, or that any else can generate their configs without
 * it, either.  Suggestions?

Not sure. Perhaps we need some experimental extensions to the inet-rtr
object... You are probably closer to knowing what you want than us. I
would like to keep the attributes as they are defined now as they are
and any extra stuff needed should move to new (experimental)
attributes. We can't have a stable set of attributes if we keep
changing the form of them. This will confuse too many people.

 * > - then the number of AS objects that have no policy information. May
 * > of them have fake maintainers, many of them are European, and I
 * > personally do not think they should be in the prdb (or rrdb for that
 * > matter). 
 * 
 * Sounds like a problem for the GRR meeting at the IETF.  You don't
 * want to throw away the AS-name information just because there isn't any
 * policy registered for it, because then prtraceroute etc. become much
 * less valuable tools.  There should be a good way of picking the "best"
 * (or, probably, most authorative) source for data to be used by
 * tools.

Definately yes. Let's take this up at the GRR meeting.

 * Eliminating maintainer objects for which we have no contact information
 * has been on my queue for about three hours now;  that one will get solved
 * when I get some time.

No problem, all these comments were purely things that I noticed. Now
that we have a real spec in ripe-181, we should try and stick to it.
We should start with a stable set and only after that move on.

 * >           What we have done at the NCC is simply place them in their
 * > own little database (source NCC-AS-LIST) which is simply generated
 * > automatically and provides at least a descr for all unknown ASes in
 * > the RR. 
 * 
 * How is this different from having these little records in the
 * prdb.db?

Slightly in semantics. The AS list we keep is not part of the routing
registry as such. Again, we should take these issues up with the
general data distribution model.

 * >         I think you should only register the AS that have policy info.
 * > If not, the RRs have loads of overlapping and possibly inconsistent or
 * > differently formatted information which is no good.
 * 
 * Again, refusing to know the name of an AS because they haven't yet 
 * registered their policy strikes me as a bit self-defeating.  Overlapping
 * and therefore potentially inconsistent data is probably the central 
 * problem of the GRR;  we have it in a lot more cases than just this.

In my view (but I can be wrong) it is more what info is in a RR as
opposed to info being used by the tools ... Not a big deal, a data
distribution model should solve these things.

-Marten



-------- Logged at  Thu Nov 17 14:43:22 MET 1994  ---------