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-03 18:35:16
On 04/06/2016 08:50, Joe Touch wrote:
FWIW, IMO this is all make-work.

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".

I'm for Barry's last proposed text.

(BTW, this could be semi-automated. It shouldn't be hard to do a scan of
the entire IANA registry to flag obsoleted RFCs; then it's a human job to
decide which references need to be updated.)

   Brian


Otherwise, IMO, this doc should basically say "IANA pointers should be
updated as deemed useful". In some cases, there's a benefit, but not in
all cases. E.g., we have docs that obsolete protocols but IANA still
keeps a pointer to the codepoint. I don't want the new pointer to be to
the doc that obsoletes them; I would want the pointer to be to the
original spec.

I.e., remember that "obsoleted by" can also effectively mean "moved to
Historic by". I.e., nobody looking at TCP-MD5 should necessarily get the
RFC to TCP-AO. And there's no way to know what's in active use *somewhere*.

I'd prefer to trust the author to do the right thing that to engineer
this document with an algorithm.

Joe

On 6/3/2016 12:47 PM, Barry Leiba wrote:
Would anyone object, and would this address your concern, Stephen, if
I should change the text like this:

OLD
   If information for registered items has been or is being moved to
   other documents, then, of course, the registration information should
   be changed to point to those other documents. In no case is it
   reasonable to leave documentation pointers to the obsoleted document
   for any registries or registered items that are still in current use.
NEW
   If information for registered items has been or is being moved to
   other documents, then the registration information should be changed
   to point to those other documents. In most cases, documentation
   references should not be left pointing to the obsoleted document
   for registries or registered items that are still in current use.
END
That is better, but I'm still worried that it'd be used by well meaning
folk to force authors to do more work than is needed for no real gain.

My preferred OLD/NEW would be:

OLD
   If information for registered items has been or is being moved to
   other documents, then, of course, the registration information should
   be changed to point to those other documents. In no case is it
   reasonable to leave documentation pointers to the obsoleted document
   for any registries or registered items that are still in current use.
NEW
   If information for registered items has been or is being moved to
   other documents, then the registration information should be changed
   to point to those other documents. Ensuring that registry entries
   point to the most recent document as their definition is encouraged
   but not necessary as the RFC series meta-data documents the relevant
   relationships (OBSOLETED by etc) so readers will not be misled.
END
Well, and *that* is so fluffy that I strongly object to it.  I think
it's bizarre to directly say that it's unnecessary and you don't need
to worry about it.  I can't think of any other place where we so
casually accept stale references.  For example, we flag I-Ds that
point to obsolete references and ask for justification to leave them
in... otherwise, they're updated before or by the RFC Editor (usually
before).

I think the change I've already proposed is a reasonable compromise.
"In most cases" isn't "in all cases".

Barry



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