Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for

Hiya,

On 03/06/16 20:47, 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).
xml2rfc handles updated references. You're arguing for authors to do
a load of manual grunt work for IMO no benefit. So I do think those
are quite different.

> I think the change I've already proposed is a reasonable compromise.
> "In most cases" isn't "in all cases".
I accept that you think that:-)

Do you think "in most cases" would have meant you and the author
concerned would/would-not have had that discussion a couple of years
ago? If you would have had it anyway, then I don't think "in most
cases" is usefully different from the OLD text.

And to go back to the nub or the argument, I don't think we have IETF
consensus for that (but you do). I note that so far we only have people
disagreeing with the current draft text.

S.

> Barry

smime.p7s
Description: S/MIME Cryptographic Signature