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 =- > > >