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/