Michael,
On 13/12/2016 10:31, Michael Richardson wrote:
Michael Richardson <mcr+ietf(_at_)sandelman(_dot_)ca> wrote:
> see inline. A great summary, just one nit which might be relevant:
I should add, having now read the document in question, which is remarkably
short, if a been ironic:
The obsoleted "Instructions to RFC Authors" [2] in Section 12
describe what "Updates" and "Obsoletes" mean. These descriptions do
not appear in RFC 7322, and even if they did, they might still not
always be sufficient to understand the exact nature of the update.
{RFC7322 obsoleted 2223, and 7322 doesn't include Updates or Obsoletes,
then it seems we've painted ourselves into a corner :-)}
but, my substantive comment is that we should obsolete the term "Updates"
due to:
Generally speaking, using "Updates" often has one of two possible
motivations: One is a bug fix ....
The second motivation is that the updating RFC is a backwards
compatible extension, which means that strictly speaking, it does not
and instead use terms "Extends" and "Corrects".
I think this illustrates the dictum that "there is always a well-known
solution to every human problem — neat, plausible, and wrong."
[HL Mencken, 1917]. It's not that it wouldn't clarify the exact
status of certain RFCs - but it would hardly scratch the surface
of the underlying standards spaghetti.
IMHO, the problem tackled in
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04
is too complex to be fixed by simple measures.
It's also worth looking at this (out of date) example:
https://tools.ietf.org/html/draft-ietf-newtrk-sample-isd-stdproc-00
Anybody up for newnewtrk?
Brian
I'm unclear if there is a new required section "Reasons for updating"?
--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software
Works
-= IPv6 IoT consulting =-