In the spirit of Festivus

[Edward Lewis <Ed.Lewis@neustar.biz>]

In the belated spirit of Festivus 
(http://en.wikipedia.org/wiki/Festivus), particularly:

    "... the 'Airing of Grievances', in which each person tells everyone
     else all the ways they have disappointed him or her over the past year."

There is a question I wanted to ask this group. No, the group hasn't 
disappointed me, but once again I've run into difficulties in 
researching IETF entrails.  But it is the last day of the calendar 
year here and the mood is right for some bellyaching before the 
hangovers begin.

As part of my day job I am asked to list the RFCs that our DNS 
services "conform to."  Like, if the service does IXFR we comply with 
RFC 1995.  This kind of task is fairly routine, i.e., look at the 
last time the question was asked and reuse the same list.  (Psst - 
don't tell my boss this.)  Recently though I decided to try to do the 
list from scratch to see what I've been overlooking, etc.

What I did was go to rfc-editor.org and searched for "DNS" in the 
RFCs.  The first two that pop up are RFC 1034 and 1035 naturally.  To 
the right is a list of RFCs that they obsoleted and RFCs that have 
since updated them.  What got me was that a handful of the updating 
RFCs are obsolete, in one case the obsoleted RFC was obsoleted by an 
RFC which is also obsolete.  (The NSAP RR.)  Many important RFCs 
(measuring by the impact they have on the protocol definition) are 
not listed as updating the original specifications.  At least one of 
the RFCs updating the originals did not pop up in the rest of the 
search list.

This is a bit more than just a paperwork nuisance.  Well, it is all a 
just paperwork nuisance, but, e.g., recently I have seen people ask 
for RFC 2535 compliance.  I wondered why they wanted the obsolete 
DNSSEC definition, but 2535 is listed as updating RFC 1034 and 1035. 
I don't know if that is the reason they picked it out, still, once 
something is obsolete, it shouldn't be advertised as updating a STD.

So - the question is - is this a matter of the IETF updating the RFC 
Editor or is it a matter that the RFC Editor needs to clean this up? 
I am a bit reluctant to blindly try to do this myself because when I 
have tried to clean up matters in the IANA DNS parameters registry, 
my efforts seem to go for naught[0].  (I've been doing that a bit 
each year for about 4 now.  There is a draft Andrew Sullivan has 
volunteered to help write - sorry Andrew I haven't gotten back to you 
but I'm hung on getting someone else else where [ex-ATM forum 
members] to clear something up.)

(BTW, maybe it's literay coincidence, but I'm wearing a T-Shirt of 
Don Quixote today [http://en.wikipedia.org/wiki/Quixote].)

This is a question more for the chair than the hoi polloi I suppose. 
Is it the IETF's responsibility to list the updated-by, obsoleted-by, 
etc., dependencies between the RFCs or is this for the RFC Editor to 
"discover" and document?

[0] E.g., still listing references for some parameters as persons and 
not documents, such as EID.  There are documents on the web for that, 
neither has there been steps taken to put them somewhere "safe" and 
point to that nor mark the registration as obsolete.  E.g.

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

Think glocally.  Act confused.

--
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/>