ietf
[Top] [All Lists]

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

2016-06-06 05:22:45

----- Original Message -----
From: "Barry Leiba" <barryleiba(_at_)computer(_dot_)org>
To: "Joe Touch" <touch(_at_)isi(_dot_)edu>
Cc: "IETF discussion list" <ietf(_at_)ietf(_dot_)org>
Sent: Sunday, June 05, 2016 10:10 PM

Case in point: TCP MD5. This was obsoleted by TCP-AO, but the TCP
option
number for TCP MD5 should not be changed to point to AO. It might be
appropriate to add a note that this codepoint represents an
obsoleted
protocol or even to point to the new one - or not. It depends on the
codepoint.

Sure, this is a very different situation.  The most current
documentation for the code point for TCP MD5 is the obsolete document.
So that's fine.  TCP AO will have a new code point, with a current
reference.  As I've said before, the "in current use" clause is what
applies here: It's not just that the documentation for TCP MD5 has
been updated and we're thinking about whether we should point the
reference to the new document.  It's that TCP MD5 itself has been made
obsolete.

Yes, as you say (and as I say), the point is to do what's right.  I
contend that in most cases, the right thing is to update the reference
*when we produce a more current reference*.  If we have not done that,
then we should not do that.

And also as you say (and as I say), we always want to leave
flexibility to use our heads and do the right thing.  That's why I'm
very happy to move away from the "in no case" phrase, to something
such as "in most cases."  I pretty much *always* want to allow people
to make sensible judgments, and not to stand behind firm, inflexible
rules.

At the risk of making an abstract discussion concrete, RFC7001 provides
an example of how not to do it.  It caused IANA to update the pointers
to RFC7001 in many places but RFC7001 did not contain the relevant
information on the registries, their fields, policies etc.  Nor did
the RFC that RFC7001 obsoleted.  You had to go back to the RFC that were
superseded by the RFC that were obsoleted by RFC7001, add in the
updates,
and piece together the information you needed.  Hence RFC7601 (which
used the then current draft-leiba-cotton as its guide).  Compare the
IANA Considerations in RFC7601 with those in RFC7001 and you can see
what an expert author might come up without further, careful
consideration, such as that provided by APPSAWG in March 2015:-)

I think that the pointer should be to where the information about the
registry is held, the fields, policy etc and if that is not reproduced
in an obsoleting document, then the reference should stay to the
obsoleted document.  It is easy to check for updates against a document
via rfc-index and, like checking for errata, it is something you have to
do before you can rely on an RFC; going in the opposite direction, back
in time, is harder.

Of course, present day ADs do not regard the addition of an entry to a
registry as a document update to the RFC that is the current definition
of the registry so it is crucial that IANA separate references for new
values in a registry from the reference for the registry as a whole -
which IANA well understands.

If the information about the registry is carried forward, then there is
no
problem and that is the best solution; but not all authors do that (see
above).

Tom Petch

Barry


<Prev in Thread] Current Thread [Next in Thread>