Hi, We discussed in depth the issue of NIC handles during the db-wg session of the Stockholm RIPE meeting. I promised to write a draft with a proposal. It's enclosed below for your review, David K. --- Internet Engineering Task Force David Kessens Draft ISI Expires March 1999 <draft-kessens-registryobject-identifiers.txt> Registry Object Identifiers Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract NIC handles have existed for a long time while they were never properly defined. At the same time, many registries started with their own interpretation of a definition that didn't exist. This document attempts to describe a definition that mostly backwards compatible with the definitions that most registries currently use. Introduction For a long time, a need existed for a unique identifier to identify personal data in the regional registries. The NIC handle has been invented to address this issue. However, the concept of NIC handles has never been documented in any place and as a result, several registries use different definitions. This draft is an attempt to write up a definition that is compatible with the current definitions that most registries use and that allows other, possibly new registries, to design their own identifiers that Kessens [Page 1] Draft RIDE References August 1997 are guaranteed to be unique. In addition, this document generalizes the concept to allow registries to use these unique identifiers for other classes (like host objects) then the personal data classes. Concepts The identifier consists of two parts: - internal registry identifier The identifier is unique within the registry, but doesn't need to be unique on a global scale. This gives the registry maximum freedom to design their own identifiers for local use. In the past, one of the most difficult problems was the entropy in the the NIC handle name space. - global registry identifier This identifier makes the internal registry identifier unique on a global scale. A registry can be queried using the internal identifier or with a combination of internal and global identifier. The registry will add it's own identifier when the internal identifier is omitted. 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. Discussion No central authority was ever present to allocate global identifiers. This caused name collisions. However, it's undesirable to have such an authority. Therefore, it is needed to get an identifier from some other already defined namespace. The domain name system provides us such an identifier with minimal cost. A convention for internal identifiers for use in conjunction with Kessens [Page 2] Draft RIDE References August 1997 personal data exists: InitialsOfPerson# It is recommended but not required to follow this convention. The '@' sign is choosen since it cannot be part of the internal identifier. In the past '-' was used which is causing ambiguities. It is not required that every registry is actually using the convention. A registry can mirror another registries data that doesn't participate in the scheme and assign a global identifier using a domain that is used by the other registry. Example example: KH1@ARIN.NET KH1 is local identifier ARIN.NET is global registry identifier (last part of domain name can possibly be omitted) Security considerations The model describes a dataformat which doesn't have security problems in itself. It doesn't make the system more or less secure. Acknowledgments The ideas presented in this document are a composition of ideas and thoughts of the author and many other people that have developed over the years. In particular, the people that were present at the RIPE database working group, IETF ride BOFs and their respective mail lists have had quite some influence on the final outcome of this draft. References [1] Cengiz Alaettinoglu e.a., RPSL, rfc2280.txt Author's Address: David Kessens, ISI Kessens [Page 3] Draft RIDE References August 1997 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 USA davidk@ISI.EDU Kessens [Page 4]
On Thu, Sep 24, 1998 at 09:24:32AM +0000, David Kessens wrote:
Example
example: KH1@ARIN.NET
KH1 is local identifier ARIN.NET is global registry identifier (last part of domain name can possibly be omitted)
I would suggest that KH1@ARIN is less confusing than KH1@ARIN.NET, unless e-mail to kh1@arin.net will actually be forwarded to the appropriate real e-mail address of kh1. I presume this will not be the case, since the registries are not in the business of forwarding mail. Using the whole domain name would help scripts identify appropriate resources for queries (e.g. whois.ARIN.NET in this example), but since we seem to be moving towards every registry mirroring every other registry, this seems less important. Either way, it seems important to standardise on one or the other. The InterNIC assigned me JA39 a long time ago, and I continue to use it in the APNIC registry. What should this be now? JA39@APNIC.NET? JA39@INTERNIC.NET? I think these migration issues deserve further treatment. My $0.02, Joe -- Joe Abley <jabley@clear.co.nz> Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/
Joe, On Thu, Sep 24, 1998 at 09:40:21PM +1200, Joe Abley wrote:
On Thu, Sep 24, 1998 at 09:24:32AM +0000, David Kessens wrote:
Example
example: KH1@ARIN.NET
KH1 is local identifier ARIN.NET is global registry identifier (last part of domain name can possibly be omitted)
I would suggest that KH1@ARIN is less confusing than KH1@ARIN.NET, unless e-mail to kh1@arin.net will actually be forwarded to the appropriate real e-mail address of kh1. I presume this will not be the case, since the registries are not in the business of forwarding mail.
This could actually turn out to be an advantage if there are connectivity problems. You at least have two paths to the party that you want to reach, but spammers might like this feature too ... Anyways, there are other ways to get the same result (and this is not part of the problem that we try to solve so we better spend our time to discuss the NIC handle issue itself).
Using the whole domain name would help scripts identify appropriate resources for queries (e.g. whois.ARIN.NET in this example), but since we seem to be moving towards every registry mirroring every other registry, this seems less important.
Either way, it seems important to standardise on one or the other.
I agree. It really doesn't matter that much which one is choosen, as long we finally choose one ;-). The only issue that I have with the abbreviated one is that the algorithm to find the organization that issued the identifier gets a bit more complicated/less obvious: - 1) domain=identifier when a . is present 2) no . in identifier means, add .net 3) except, when it is a TLD (ambiguities are possible with 2) or - always add .net makes the namespace flatter, though you can still use subdomains, ties you in with one particular tld tld 'es' might not have 'es.net' or - add registries.int needs global coordination and judgements of independent party which is not desired (in my opinion) (do you have a better one ?!?)
The InterNIC assigned me JA39 a long time ago, and I continue to use it in the APNIC registry. What should this be now? JA39@APNIC.NET? JA39@INTERNIC.NET?
Depends were it is stored (or will be stored in the future). If it's in both databases, both would be fine. Note that we would like a perfect solution, but there are too many inconsistencies to keep the solution simple *and* covering all situations. The only thing that really matters is if we can find the data and that it improves the current situation.
I think these migration issues deserve further treatment.
Agreed. Please send me a paragraph ;-), David K. ---
Joe,
On Thu, Sep 24, 1998 at 09:40:21PM +1200, Joe Abley wrote:
On Thu, Sep 24, 1998 at 09:24:32AM +0000, David Kessens wrote:
Example
example: KH1@ARIN.NET
KH1 is local identifier ARIN.NET is global registry identifier (last part of domain name can possibly be omitted)
I would suggest that KH1@ARIN is less confusing than KH1@ARIN.NET, unless e-mail to kh1@arin.net will actually be forwarded to the appropriate real e-mail address of kh1. I presume this will not be the case, since the registries are not in the business of forwarding mail.
This could actually turn out to be an advantage if there are connectivity problems. You at least have two paths to the party that you want to reach, but spammers might like this feature too ... Anyways, there are other ways to get the same result (and this is not part of the problem that we try to solve so we better spend our time to discuss the NIC handle issue itself).
I think that there will be problems with "@" as the seperator. It's too much like a viable email address. I applaude the use of the domain name on the right and a domain specific unique handle on the left, the concern is the seperator. Howabout something like "%" ?
Using the whole domain name would help scripts identify appropriate resources for queries (e.g. whois.ARIN.NET in this example), but since we seem to be moving towards every registry mirroring every other registry, this seems less important.
IF this is true, (moving towards every registry mirroring every other registry) then we have more trouble than NIC handles. But that is a debate that must occur elsewhere.
The only issue that I have with the abbreviated one is that the algorithm to find the organization that issued the identifier gets a bit more complicated/less obvious:
- 1) domain=identifier when a . is present 2) no . in identifier means, add .net 3) except, when it is a TLD (ambiguities are possible with 2)
Bad move, too much overload on the semantic.
or - always add .net
Not all registries will be in ".net"
makes the namespace flatter, though you can still use subdomains, ties you in with one particular tld tld 'es' might not have 'es.net'
or
- add registries.int
It's already there. :(
The InterNIC assigned me JA39 a long time ago, and I continue to use it in the APNIC registry. What should this be now? JA39@APNIC.NET? JA39@INTERNIC.NET?
Hum.. how to deal w/ the demise of a registry...
Depends were it is stored (or will be stored in the future). If it's in both databases, both would be fine. Note that we would like a perfect solution, but there are too many inconsistencies to keep the solution simple *and* covering all situations. The only thing that really matters is if we can find the data and that it improves the current situation.
Thats two things. While desirable, the thing that I thought NIC handles did was to identify an entity that was responsible for some delegated level of responsibility. This could be a host, person, role, or organization that accepted the responsibility over some delegated Internet resources (numbers & lables). So each of these things would have an unambigious lable that could be tied to an assignment of responsibility. Those lables should be consistant, regardless of where they are listed. They should also have some token that indicates the listing origin and may include a method for determining the level of trust on the listing.
I think these migration issues deserve further treatment.
Agreed. Please send me a paragraph ;-),
David K. ---
-- --bill
On Thu, Sep 24, 1998 at 09:01:49AM -0700, bmanning@ISI.EDU wrote:
I think that there will be problems with "@" as the seperator. It's too much like a viable email address. I applaude the use of the domain name on the right and a domain specific unique handle on the left, the concern is the seperator. Howabout something like "%" ?
"%" still has mail-related connotations though, although far less so than "@". I presume that some registries are using internal identifiers with "-" in them, which is why the current practice of using the "-" character to separate the internal identifier and the parent registry token is an issue. Can we presume that the separator should fit the following criteria: + minimise confusion with other related services like e-mail and DNS + not be currently used as part of an internal identifier for any registry + not be a "special" shell character like "&", "!", "|", ";", as these are annoying to those of us who like to use whois from the shell + be easy to parse, e.g. to strip the registry component to reveal an internal identifier -- for example, JA39(APNIC.NET) might not be desirable How about ":"? JA39:APNIC.NET doesn't look like an e-mail address or a DNS name. It does however look slightly remotely like a URL ;)
The only thing that really matters is if we can find the data and that it improves the current situation.
Thats two things. While desirable, the thing that I thought NIC handles did was to identify an entity that was responsible for some delegated level of responsibility.
This could be a host, person, role, or organization that accepted the responsibility over some delegated Internet resources (numbers & lables).
In ripe-181 the habit seems to have been to put contact fields (tech-c, admin-c) in every record where contact was appropriate, so contact details via NIC handles are immediately available. In other words, the drill down path of (for example) inetnum -> netname -> admin-c/tech-c isn't necessary since there are direct relationships inetnum -> admin-c and inetnum -> tech-c. Has this changed significantly in RPSL, so that it is now important to have netname-type fields which have registry-internal and registry-external representation? Or have I misunderstood the point you were making?
So each of these things would have an unambigious lable that could be tied to an assignment of responsibility. Those lables should be consistant, regardless of where they are listed. They should also have some token that indicates the listing origin and may include a method for determining the level of trust on the listing.
Joe -- Joe Abley <jabley@clear.co.nz> Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/
"%" still has mail-related connotations though, although far less so than "@".
How about ":"? JA39:APNIC.NET doesn't look like an e-mail address or a DNS name. It does however look slightly remotely like a URL ;)
":" not only has URL significance, its also used w/ IPv6 in the address. IMHO a poor choice.
The only thing that really matters is if we can find the data and that it improves the current situation.
Thats two things. While desirable, the thing that I thought NIC handles did was to identify an entity that was responsible for some delegated level of responsibility.
This could be a host, person, role, or organization that accepted the responsibility over some delegated Internet resources (numbers & lables).
In ripe-181 the habit seems to have been to put contact fields (tech-c, admin-c) in every record where contact was appropriate, so contact details via NIC handles are immediately available. In other words, the drill down path of (for example) inetnum -> netname -> admin-c/tech-c isn't necessary since there are direct relationships inetnum -> admin-c and inetnum -> tech-c.
Has this changed significantly in RPSL, so that it is now important to have netname-type fields which have registry-internal and registry-external representation?
Or have I misunderstood the point you were making?
I think so. Back up a bit and take the 10,000m view. There are three classes of Internet intangibles that can be delegated, ASN's, Prefixes, Port numbers. (there are others, but these will do for this purpose) The recipiants of these delegations can be people (admin-c/tech-c), hosts (HST), organized groups (mntner & role accounts) I could make the case that the mntner:, admin-c:, tech-c:, mnt-by:, nic-hdl:, and the HST (C8-HST) are all, in a very real sense, NIC HANDLEs. They specify a relationship between Internet resources and those who are authorized to manage the delegation relationship.
So each of these things would have an unambigious lable that could be tied to an assignment of responsibility. Those lables should be consistant, regardless of where they are listed. They should also have some token that indicates the listing origin and may include a method for determining the level of trust on the listing.
Here, I expect that the handle: WM110 WM110-NSI WM110-ARIN all reflect me, first under the SRI-NIC, then Internic/NSI, then ARIN. I would hope the design of NIC-handles would allow migration of data between registries as well as allow for a deeply nested registration heirarchy. --bill
In message <19980924092432.A931@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
participants (4)
-
bmanning＠ISI.EDU -
Curtis Villamizar -
David Kessens -
Joe Abley