Michael,
On 13/12/2016 10:31, Michael Richardson wrote:
>
> Michael Richardson <mcr+ietf@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>