About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: NIC handle writeup

  • To: David Kessens < >
  • From: Curtis Villamizar < >
  • Date: Tue, 01 Dec 1998 21:15:26 -0500
  • Reply-to:

In message <19980924092432.A931@localhost>, 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




  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community