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