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/
NIC handle writeup
- Previous message (by thread): Ripe change to whois
- Next message (by thread): Maintainer creation policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Curtis Villamizar
curtis at brookfield.ans.net
Wed Dec 2 03:15:26 CET 1998
In message <19980924092432.A931 at ISI.EDU>, David Kessens writes: > > Definition > > InternalIdentifier[@GlobalIdentifier] > > The global identifier is the same as a domain which is in use by the > registry. > > The internal identifier is an RPSL word [1]. > > Identifiers are not case sensitive. David, This conflicts with draft-ietf-rps-auth-01.txt 8.6 Other Objects Many of the RPSL ancillary objects have no natural hierarchy the way AS numbers, Internet addresses and routes 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. A possible syntax is to precede the object key with the name of the repository and a delimiter. For example, the delimiter ``::'' can be used to form the NIC handle ``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 ref- erence ``IANA::CO19''. There is no possibility of accidentally forget- ting to adhere to the conventions when making an addition and the exist- ing objects are accommodated, including cases where name conflicts have already occurred. The :: delimiter is used there. There has already been discussion suggesting : and some objection due to relevance to ipv6 and use in urls. Whatever we pick, we should be consistent across documents. Then if we are, isn't your draft then a subset of draft-ietf-rps-auth-01.txt? Do we need both? Curtis
- Previous message (by thread): Ripe change to whois
- Next message (by thread): Maintainer creation policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]