RE: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue

Sorry for the resend - Outlook screwed up Ed's email address on my first
try. - Andy

Tim,

Thanks for forwarding Ed's email. The document discussed below is
publicly available at
http://www.ipmplsforum.org/ftp/pub/approved-specs/af-dans-0152.000.pdf .

Ed,

The IP/MPLS Forum is now the permanent online repository for the ATM
Forum specifications. There is no problem with IANA downloading the
document and making it publicly available in perpetuity if they so
choose - just have them let me know by email if they end up doing so.
Does this work for you (or for them)?

I do not anticipate any further changes to this specification, which was
published in July 2000.

Please let me know if I can be of any further assistance.

Cheers,
Andy Malis
Chair and President, IP/MPLS Forum
www.ipmplsforum.org

-----Original Message-----
From: Dwight, Timothy M (Tim)
[mailto:[email protected]] 
Sent: Monday, January 07, 2008 9:18 AM
To: Malis, Andrew G. (Andy)
Subject: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue

Andy,

Looks like there's an issue with making one of the old ATM Forum
specifications (for a type of DNS resource record) publicly available.
Can you help Ed out?

Tim


-----Original Message-----
From: Edward Lewis [mailto:[email protected]] 
Sent: Monday, January 07, 2008 7:54 AM
To: Bernie Hoeneisen
Cc: [email protected]; [email protected]; Edward Lewis; [email protected]
Subject: Re: [Enum] enum services registry question

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.

_______________________________________________
enum mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/enum