Re: NIC handle writeup

[bmanning@localhost]

> 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@localhost
> > > 
> > >    KH1 is local identifier ARIN.NET is global registry identifier (last
> > >    part of domain name can possibly be omitted)
> > 
> > I would suggest that KH1@localhost is less confusing than KH1@localhost, unless
> > e-mail to kh1@localhost 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@localhost
> > JA39@localhost

	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