[ Apologies for prematurely pressing send. It's Friday afternoon :-( ]
=> "%" 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.
I don't think that we're going to find any character which isn't badly
overloaded already...
=> Or have I misunderstood the point you were making?
=
= I think so. Back up a bit and take the 10,000m view.
Yup: why do we need a special character at all?
Grab a handle, which simply must not contain the "." character,
and extend that with the DNS-part as proposed. Done.
And it is known to work (DNS SOA record)
My good old WW144 would then simply become WW144.INTERNIC.NET.
= 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)
While this is probably off-topic, I suppose you are mixing organisations
and contact information here...
= 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.
I have to disagree.
- We do have mechanisms to describe the privilege(s) for maintaining
objects.
- And we do have mechanism to get in touch with persons (or helpdesks or
NOCs) for operational purposes.
= 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.
What we've learned from past (failed) attempts:
- don't try to mix the issue generating globally unique identifiers with
- the issue of data exchange between registries
As soon as we've sorted out the first one, we can try to work on the
second one. Having the first one done is not going to interfere with
solving the other issue, I suppose :-)
Wilfried.
--------------------------------------------------------------------------
Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at
Computer Center - ACOnet : Tel: +43 1 4277 - 140 33
Vienna University : Fax: +43 1 4277 - 9 140
Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144
A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369
--------------------------------------------------------------------------
From: MX%"bmanning(a)ISI.EDU" 25-SEP-1998 20:56:00.16
To: MX%"jabley(a)clear.co.nz"
CC: MX%"db-wg(a)ripe.net"
Subj: Re: NIC handle writeup
From: bmanning(a)ISI.EDU
Subject: Re: NIC handle writeup
To: jabley(a)clear.co.nz (Joe Abley)
Date: Fri, 25 Sep 1998 11:50:08 -0700 (PDT)
CC: db-wg(a)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(a)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(a)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(a)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(a)zed.isi.edu>
In-Reply-To: <19980925102909.B15327(a)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(a)ripe.net
Precedence: bulk
