Hi, First two general comments: 1. I do think we need to clarify this topic. However, I want to repeat my earlier comment: IMHO the *generic* explanation of what "Updates:" means should come from the RFC Editor. It can be quite short, and there should be some community discussion. So I will treat this draft as describing how the IETF stream interprets "Updates:", within that generic explanation, and the other RFC streams are free to make their own interpretations (or adopt this one, if they want). 2. John Klensin, at https://mailarchive.ietf.org/arch/msg/ietf/qdDAtDC0jIKoUgZUFwGUuQSDQyo referred to earlier discussions, including in NEWTRK. Indeed we have some unfinished business - how on earth is a consumer of RFCs supposed to know which bits of which RFCs she needs to implement, and which bits *not* to implement, to produce interoperable code? If A claims to be the standard, but B updates it, while C obsoletes A without mentioning B, etc. etc., what is a poor programmer to do? If you don't appreciate the complexity of this question, here are two illustrations, one of which is close to home for the IETF itself: https://tools.ietf.org/html/rfc6434 https://www.ietf.org/about/process-docs.html They are both out of date, of course. I suggest that this complicated question still needs to be answered, but this draft is not the place to do it. Now for my specific comments: > RFC authors that use "Updates" in their document should include > individual "Reasons for updating ..." sections for each updated RFC. > These sections should be placed relatively early in the document. In > each of these sections, there should be a short description of the > nature of the update. IMHO this is too bureaucratic and will make the result noisy and awkward to read. I believe it is reasonable to require that the changes are easy to find, but that doesn't require separate sections. For example, in https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host which updates RFC 4861, searching for the text string 4861 will do the trick, and you will see the changes in context. So I would advocate something more like: RFC authors that use "Updates" in their document should ensure that the specific updates are easy to identify, preferably by citing the specific section of the updated RFC in the updating text. A general rationale for the updates should be prominent in the document's Introduction. (Then the word "sections" in the following two paragraphs could be changed to "updating text".) An organizational comment: The three paragraphs starting with "Generally speaking,..." would be much better moved to the beginning of section 3, since they motivate what follows. > The second motivation is that the updating RFC is a backwards > compatible extension, which means that strictly speaking, it does not > even need to mention the updated RFC. I disagree. If I maintain the code for foobar, I'd really like to receive a ping when the RFC extending it to foobar+ comes out. So unless we introduce a new metadatum "Extends:", I think that we really should use "Updates:" for extensions. At the minimum, I need to check that incoming foobar+ extensions won't break anything. You might want to review RFC6709, in which the IAB uttered: " 1. Modifications or extensions to the underlying protocol. An extension document should be considered to update the underlying protocol specification if an implementation of the underlying protocol would need to be updated to accommodate the extension. This should not be necessary if the underlying protocol was designed with a modular interface." (https://tools.ietf.org/html/rfc6709#page-5) By the way, a can of worms that you don't mention is updates by other SDOs. There's a BCP for that: https://tools.ietf.org/html/rfc4775 Regards Brian Carpenter