NIC handle writeup

From:	MX%"bmanning at ISI.EDU" 25-SEP-1998 20:56:00.16
To:	MX%"jabley at clear.co.nz"
CC:	MX%"db-wg at ripe.net"
Subj:	Re: NIC handle writeup

From: bmanning at ISI.EDU
Subject: Re: NIC handle writeup
To: jabley at clear.co.nz (Joe Abley)
Date: Fri, 25 Sep 1998 11:50:08 -0700 (PDT)
CC: db-wg at ripe.net

> "%" 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
--------------------------------------------------------------------------------
Return-Path: <owner-db-wg at ripe.net>
Received: from ns2.univie.ac.at by access.cc.univie.ac.at (MX V4.1 VAX) with
          SMTP; Fri, 25 Sep 1998 20:55:55 MET-DST
Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by
          ns2.univie.ac.at (8.8.8/8.8.8) with SMTP id UAA56164 for
          <woeber at cc.univie.ac.at>; Fri, 25 Sep 1998 20:55:54 +0200
Received: (qmail 918 invoked by alias); 25 Sep 1998 18:55:23 -0000
Delivered-To: lists-db-wg-out at lists.ripe.net
Received: (qmail 916 invoked by uid 66); 25 Sep 1998 18:55:23 -0000
Posted-Date: Fri, 25 Sep 1998 11:50:08 -0700 (PDT)
Message-ID: <199809251850.AA08047 at zed.isi.edu>
In-Reply-To: <19980925102909.B15327 at clear.co.nz> from "Joe Abley" at Sep 25, 98
    10:29:09 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-db-wg at ripe.net
Precedence: bulk