This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
Final Minutes for DB WG at RIPE 41
- Previous message (by thread): Final Minutes for DB WG at RIPE 41
- Next message (by thread): Final Minutes for DB WG at RIPE 41
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lu, Ping
PLu at cw.net
Mon Jul 22 17:06:27 CEST 2002
>From RFC2725 (maybe this is not part of RPSL ?):
==================================================================
9.6 Other Objects
Many of the RPSL ancillary objects have no natural hierarchy the way
AS numbers, Internet addresses and routes do have a numeric
hierarchy. Some examples are "maintainers", "people" and "role"
objects. For these objects, lack of any hierarchy leads to two
problems.
1. There is no hierarchy that can be exploited to direct queries to
alternate registries. At some point the query strategy of
searching all known registries becomes impractical.
2. There is no hierarchy on which authorizations of additions can be
based.
The first problem can be addressed by considering the name space for
each of the ancillary objects to be unique only within the local
database and to use explicit references to an external repository
where needed. To specify an external repository reference, the
object key is preceded by the name of the repository and the
delimiter "::". For example a NIC handle may take the form
"RIPE::CO19". Currently there is a desire to keep NIC handles unique
so the naming convention of appending a dash and the repository name
is used. Prepending the repository name provides the unique name
space since an object in the RIPE database referencing "CO19" would
be interpreted as "RIPE::CO19" by default, but it would still be
possible to query or reference "IANA::CO19". There is no possibility
of accidentally forgetting to adhere to the conventions when making
an addition and the existing objects are accommodated, including
cases where name conflicts have already occurred.
==================================================================
There is a need to address the "external repository reference" problem
for a long time. It is in the RFC already and just no implementation to
support the solution yet.
Now I think is the time to take this issue seriously (at least for "import:"
and "export:" :)
Best Regards.
Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net
> -----Original Message-----
> From: Mark Prior [mailto:mrp at mrp.net]
> Sent: Saturday, July 20, 2002 6:38 AM
> To: Lu, Ping; 'Nigel Titley'; db-wg at ripe.net
> Subject: RE: Final Minutes for DB WG at RIPE 41
>
>
> At 2:33 PM -0400 19/7/02, Lu, Ping wrote:
> >Hi, Nigel,
> >
> >About {AP-41.8 C&W]
> >> [AP-41.2 C&W] To send their proposal to allow
> referencing external
> >> objects in the DB to the mailing list for discussion.
> >> Ongoing, no action yet
> >We made a proposal to allow "import: from SRC::ASN:AS-SET"
> for using data
> >from other source of registry data. I haven't seen any
> formal response from
> >RIPE NCC yet. This shouldn't affect the database referential
> integrity but
> >will make RR closer to a distributed structure. Maybe the
> status is now
> >"Complete, pending response from RIPE NCC" ? Agreed ?
>
> That would require a change to the RPSL standard and I haven't seen
> any internet drafts suggesting such a change.
>
> Mark.
>
- Previous message (by thread): Final Minutes for DB WG at RIPE 41
- Next message (by thread): Final Minutes for DB WG at RIPE 41
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]