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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 

<<attachment: smime.p7s>>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]