Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

[John C Klensin <[e-mail]>]

--On Saturday, June 04, 2016 11:35 +1200 Brian E Carpenter
<[e-mail]> wrote:

>...
> Disagree. Misleading pointers on the IANA site will mislead
> some junior programmer sometime in the future, by a simple
> application of Murphy's law.
> 
>> IANA pointers to the old doc should turn up "obsoleted by"
>> notices. That ought to be enough to trigger the user to
>> follow the right path.
> 
> That's not realistic. If IANA refers to RFC822, and the
> programmer has a copy of RFC822 on her disk, that's what she
> will follow, because RFC text never changes and does not say
> "I am obsolete".

Fairly arbitrarily choosing Brian's message to which to respond,
I see this a little differently.  I think the fundamentals of
the disagreement between Stephen and Barry are surrogates for
the long-standing one of what we mean by "obsolete" and
"obsoletes".  We have a shortage of clear definitions, the only
thing 2026 says is in Section 4.2.4, which clearly links
"obsolete" (and hence, presumably, "obsoleted") to Historic
status.  It even implies that classification is automatic, which
is certainly not current practice.

It seems to me that we should be citing obsolete documents only
for historical purposes.  If a parameter value is still in
active use, then the most recent definition should be cited for
multiple reasons.  Brian's example is certainly one of them, but
the whole idea of a normative dependency (and pointers to
definitions from IANA registries are, in most cases (see below),
certainly that) to part of an obsolete document should just not
be acceptable.

This is not "make work", it is running a standards and parameter
registry system professionally and for maximum utility by the
use audience.  I think I'm agreeing with Barry and Ben about
this.  And, especially when the RFCs contain information that is
not in the registry (see below), I'm someone else who has quite
often tracked down RFCs by starting from the registries. 

Those who want to avoid the burden of updating registries should
be more careful about listing documents as obsolete rather than
updating them.  "Obsoletes all material in RFCxxxx except for
the parameter registry value discussion in Sections N and M"
should be an easy statement to make.  If it is not, that
document is probably badly organized and the community would
benefit from an updated reference to an updated document.

The other issue is that there are two kinds of "reference"
pointers from IANA registries even though IANA has, AFAIK, never
explicitly made the distinction.  In one case, the registry is
self-contained and the reference provides "where did this come
from" or "what authorized this" information.  In that case, the
user of the registry should not need (or want) to consult an RFC
except as part of historical research and reference to the
document that actually created (or most recently changed) the
registry entry is probably the correct one.  In the other case,
the reference is actually to information that actually provides
a definition of, or important information about, the parameter
value.  In that case, the pointer should be up to date (and
should not point to anything Obsoleted or Historic).  

As I read this thread (circa 23 messages at the time of this
writing), it seems to me that different assumptions about what a
pointer from a registry means underlie parts of the
disagreement.  If that is really the case, the fix is to adjust
the registries so that each one is clear about what the pointers
mean, rather than trying to water text down enough to
accommodate both cases.

    john