more on prdb format

Marten,

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

What is the mechanism for a tool to use data which is not in the
Registry?  What is the definition of "in the registry"?  My guess at a
definition would be:  if the data is available via whois or as part of
the ftp version of [database].db, then it is in the registry.  And that
(as far as possible subject to cron processing constraints) if it is in
one place, it should be in both places.  [Otherwise someone is going to
feel forced and justified in beating up your whois server for
everything it knows!]

This has been a big issue here with respect to Community
implementation.  At the moment we have not been released from the
responsibility to maintain AUP certification by nets, and to use this
list of AUP nets in the generation of config files.  (And therefore in
policy expressions).  Our current implementation of this is to use a
special-case community name (COMM_NSFNET), which refers to what was
called a "guardian file" under RIPE-81.  This bothers me enormously
because this means we have policy expressions which cannot be
interpreted without recourse to data that is not part of the ftpable
version of the database.  At the moment, that means that other members
of the GRR can't and don't get that "hidden" data.

It sounds like you have similar "hidden" data that the tools can get
to, but people who write other data crunchers can't?  

--Dale


==========================================================================

>  * >           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  Mon Nov 21 16:17:37 MET 1994  ---------