Re: IANA type code registration clean up

[Mark Andrews <[e-mail]>]

> At 14:42 -0400 6/13/07, Andrew Sullivan wrote:
> >On Wed, Jun 13, 2007 at 12:57:17PM -0400, Edward Lewis wrote:
> >>
> >>  Answer A - document them.
> >>  Answer B - deprecate them.
> >
> >Answer AB: document _and_ deprecate.
> >
> >I'm serious.  I know this is work, but I think we should write these
> >down somewhere, and say they're deprecated and needn't be implemented.
> >At least then someone writing a compliant system that gets one of
> >these types in a query knows what it is supposed to be and that it can
> >be ignored.
> >
> >Yes, I am volunteering.  Do you have some pointers that I should go
> >read, so that I don't have to start all your forensic work from
> >scratch?
> 
> Yeah I do.  While thinking more about this, I realized that all we 
> would need to do is list the values and the mnemonics and then say 
> "just don't do it."  So I agree on an answer AB.
> 
> But there is one possible exception to outright deprecation of all 
> the un-RFC'd types, the ATMA record.  All but the ATMA died when 
> their draft expired.  The ATM one is defined in a document published 
> external to the IETF.  (But I get heartburn over that - the ATM Forum 
> is where the document was originally published.  The ATM Forum is no 
> longer amongst the living and even it's web site is gone.)
> 
> In talking to IANA on the side I noticed that they had cleaned up a 
> lot of the references (there were a few types in 2005 that were 
> RFC'd, like AAAA, that weren't documented as such and now are) but 
> these remain:
> 
> old NSAP-PTR        23
> new NSAP-PTR        23 for domain name pointer, NSAP style   [RFC1348]
> 
> old EID             31 Endpoint Identifier           [Patton]
> new EID             31 Endpoint Identifier
>      [http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt]
> 
> old NIMLOC          32 Nimrod Locator                [Patton]
> new NIMLOC          32 Nimrod Locator
>      [http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt]
> 
> old ATMA            34 ATM Address                   [Dobrowski]
> new ATMA            34 ATM Address
>      [http://www.mfaforum.org/ftp/pub/approved-specs/af-saa-0069.000.pdf]
> 
> old SINK            40 SINK                          [Eastlake]
> new SINK            40 SINK
>      [http://bgp.potaroo.net/ietf/all-ids/draft-eastlake-kitchen-sink-02.txt]
>
> The first may be just an editor's choice (see the page for what I 
> mean), the next two and last are types that were not quite formed. 
> The ATMA is the one defined elsewhere.  All URLs work as of today.

	Of the list above BIND 9 only implements NSAP-PTR.
	ATM looks like it is straight forward to implement.

> What I haven't considered are RFC'd types that are dead too - because 
> I am not looking at a bureaucratic cleansing, more at "what do we 
> need to leave for new implementors."
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                [phone]
> NeuStar
> 
> Sarcasm doesn't scale.
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>