Re: enum services registry question

Edward Lewis <[email protected]>
Newsgroups gmane.ietf.enum
Message-ID <a06240800c3a7dbc6ccd1@[192.168.1.104]>
At 11:27 +0100 1/7/08, Bernie Hoeneisen wrote:

>The term "permanent and readily available public specification" states
>the intension, but I think it is a bit vague, when it comes to what
>qualifies to this term. Furthermore it does not say much about the change
>management of such a specification.
>
>To be on the safe side, I guess we should ensure that a copy of the
>specification (as reviewed by expert) is always maintained at IANA,
>unless there is an RFC (that can be simply referenced).

This is the specific situation I have run into.  There is a DNS RR 
type - as far as I know no one uses - called ATMA.  It was developed 
and then documented by the ATM Forum. The document was available on 
the ATM Forum's website.

The ATM Forum ceased operations quite a while ago and became part of, 
hmmm, some other organization whose name now escapes me.  Within the 
last year I exchanged email with members there but after being 
promised a response to a question about getting the document 
published under the name of the IETF the "line went dead."

So today we have an entry in the DNS RR type registry that has no 
reliable definition.  I haven't gotten permission from the successor 
organization to copy the document into the RFCs.  IANA is not 
equipped to archive documents so they can't just arrange to host the 
document - two issues, one is the mechanics and the other is the 
intellectual property.  We are also stuck without the ability to 
obsolete the registration because no one is willing to declare it 
dead without knowing who is using it.

So far what I've described is just a paperwork and bookkeeping 
migraine headache.  The reason I ever started to look into this was 
when I was asked to write DNSSEC code separate from any other 
implementation (in the 90's) and tried to research DNS from the 
specifications and not "what would BIND do?"  When asked if my code 
handled "all the types" I wanted to be sure of the answer.

If you were to build an implementation from scratch, that's when it matters.

(I realize I'm not throwing out a solution.  This is a reflection of 
my experience in DNS and why I stopped to make the comment.)

>On the other hand, this looks like an issue to be solved on rfc2434bis
>level. (I therefore have CC:ed the authors of rfc2434bis to this email.)

Do you have a URL for that document?

>Propsosal:
>
>  Unless there is some better solution proposed, I'll put a section
>  "reference" to the new IANA template in
>  draft-ietf-enum-enumservices-guide.
>  There can be either a reference to the RFC or an IANA internal reference
>  to the version of the specification after approval by the experts.
>
>Makes sense?

The issue is the "IANA internal reference" as I mentioned before.

>PS: It would be quite a bit easier, if we decided on "RFC required"
>instead...;-)

It certainly would be easier, but that means the RFC-Editor and IETF 
are creating a monopoly on what goes into IANA.  I believe that is 
undesired by the powers that be.  (I think the same was said in the 
DNS group talking about their IANA instructions "bis" document.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.