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.