Re: enum services registry question

Edward Lewis <[email protected]>
Newsgroups gmane.ietf.enum
Message-ID <a06240806c3a8422e5a60@[192.168.1.104]>
(If you want to skip my embellishment of the DNS case, here's the 
last paragraph, which relates back to ENUM.)

The goal is to be able to look at IANA for parameters and then find 
definitions of each via resolvable references.  For ENUM, a reference 
to an RFC (if that is the vehicle) ought to be explicit.  If it is 
another document, a fully fledged reference (not just a URL) is 
helpful.  And if it matters over the long haul, there should be 
someone making sure the registrations are up to date.

At 15:49 -0500 1/7/08, Thomas Narten wrote:
>And we should only do this if we are worried that a
>particular document is important and might "go away" at some point in
>the future. Is the document in question of this type?

In the situation I have described, the document has not been 
changing, is not in danger of being retired, and has been and 
continues to be publicly available.  The problem has been that the 
entry in the IANA registry has never pointed to the document nor has 
the entry been tracking the transfer of the document from one 
organization to another.

It's not the document, it's the static nature of the registration 
that is the issue.

The desire to have IANA only refer to RFCs lies in the shared fates 
of the IETF and IANA.  If one goes down, the other certainly will 
know about it.  Other organizations are capable of accomplishing what 
the IETF does (specifically here putting documents in public spaces 
for perpetuity) but there may or may not be enough cross-activity to 
maintain the registration.

I should add, specific to my case, it's not a matter of the URL 
changing.  The IANA registration doesn't even have the title of the 
document, only the personal name of the author and the email address 
I suppose the request came in on.  I had to track the document down 
by googling his name to find current employment, topic, etc., etc., 
and then maintain this searching over the years of while trying to 
get IANA to retain the information.  Even now, IANA still doesn't 
publish any more than the person's name and a defunct email address - 
despite my sending them notes on this.

Sorry to go on - this isn't an ENUM issue, but it is my experience 
with protocol parameter registries when the rules are not tight 
enough.  What would fix the case I am drawing upon is either 
mirroring all needed documents, maintaining liveness on all 
references (and at least have titles!), and or the ability to mark a 
registration as "historic" if there is no published reference 
publicly available.  (Really, I don't hold grudges or anything - I 
just don't want to see the same problem pop up with ENUM.)

BTW, the same DNS RR registry has other problematic registration 
references in which the issue isn't cross-organization. There are a 
few that are defined by retired internet drafts retrievable from 
those who maintain such things on their own.

The goal is to be able to look at IANA for parameters and then find 
definitions of each via resolvable references.  For ENUM, a reference 
to an RFC (if that is the vehicle) ought to be explicit.  If it is 
another document, a fully fledged reference (not just a URL) is 
helpful.  And if it matters over the long haul, there should be 
someone making sure the registrations are up to date.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.