more on prdb format

Marten,

> From marten at ripe.net Wed Nov 16 14:19:42 1994
> To: rr-impl at ripe.net
> Subject: more on prdb format
> From: Marten Terpstra <Marten.Terpstra at ripe.net>
> Date: Wed, 16 Nov 1994 20:16:42 +0100
> Sender: Marten.Terpstra at ripe.net
> 
> 
> 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.

> - 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?

> - 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.

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.

>           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?

>         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.

> That's it for now,
> 
> -Marten

--Dale



-------- Logged at  Thu Nov 17 00:02:41 MET 1994  ---------