[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Type Code 31

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.

At 1:11 +0000 3/27/05, bmanning@vacation.karoshi.com wrote: 
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, <map@bbn.com>, 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 <dee3@torque.pothole.com>, 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 namedroppers-request@ops.ietf.org 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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.

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