Subject: Re: Type Code 31

From: [email-masked]
Date: Sun, 27 Mar 2005 01:11:56 +0000

for me - i'd prefer to have a persistant record of all defined
types - including the dead, obscure, and goofball.  including
some that were in early code bases and were excised in the reference
implementation simply for lack of an RFC...  even tho the IANA
listed them.

i guess my list w/ docs attached will have to go online. :)

--bill

On Fri, Mar 25, 2005 at 11:09:03AM -0500, Edward Lewis wrote:
> This isn't really about type code 31, but about the type codes 
> allocated by IANA that are not defined in persistent documents.
> 
> Recently I was asked to look at 
> http://www.iana.org/assignments/dns-parameters, to find better 
> references for things like:
> 
> # EID             31 Endpoint Identifier                    [Patton]
> # NIMLOC          32 Nimrod Locator                         [Patton]
> ...
> # [Patton] Michael Patton, <[email-masked]>, June 1995.
> 
> Now, Mike's a good guy and all and he doesn't deserve to be a walking 
> encylopedia of stuff no one uses.  I was able to find a document 
> covering these types here: 
> http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt.  This is not in a place 
> that IANA can count on to hold this forever, nor the IETF.
> 
> Another example along these lines is:
> # SINK            40 SINK                          [Eastlake]
> ...
> # [Eastlake] Donald E. Eastlake, III <[email-masked]>, January 
> 1995,
> #          November 1997.
> 
> It's last known address is this, another non-IETF/IANA provided site:
> 
> http://bgp.potaroo.net/ietf/all-ids/draft-eastlake-kitchen-sink-02.txt
> 
> You search the mail archives you can find that it was killed about 
> the time of WG last call.
> 
> The problem is - we need to have persistent definitions of types 
> *actively* allocated by IANA available to implementers.  (Relying on 
> looking at the BIND code notwithstanding.)
> 
> For types that are not in use, we should document that.  At the time 
> SINK was killed, there ought to have been an action to un-register 
> the type, or at least mark it as obsolete.  We don't need to revive a 
> definition of the SINK to kill it, just a note to IANA to mark it as 
> obsolete (like type 3) or return the code  to the available pool.
> 
> RFC 2929 does not cover "garbage collection," maybe it should.
> 
> Maybe we just need a document to cut out all the obsoleted types from IANA.
> 
> Comments on this?
> 
> PS - I'd do more, but I should be working on wcard.
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Achieving total enlightenment has taught me that ignorance is bliss.
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

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

---

From: Edward Lewis <[email-masked]>
Date: Sat, 26 Mar 2005 23:51:41 -0500

On the one hand, having a historical record is good - what killed a 
record is worth remembering.  On the other hand, let's not clutter up 
implementations with unnecessary code paths.

I think the latter is necessary, the other is nice to have.

---

From: Niall O'Reilly <[email-masked] >
Date: Tue, 29 Mar 2005 21:39:45 +0100

On 27 Mar 2005, at 05:51, Edward Lewis wrote:

> record is worth remembering.

The historical record also protects against collision with instances 
which may be
'undead' and lurking in the wild.

> On the other hand, let's not clutter up implementations with 
> unnecessary code paths.

Indeed.

/Niall