NIC handle writeup

On Thu, Sep 24, 1998 at 09:01:49AM -0700, bmanning at 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 at clear.co.nz>      Tel +64 9 912-4065, Fax +64 9 912-5008
Network Architect, CLEAR Net                      http://www.clear.net.nz/