Re: Proposed IESG Statement on the use of the “Updates” header

[tom petch <[e-mail]>]

Ben

I don't understand it! In particular

'Normative updates that do not use a known extension point should always
include an “Updates” header.'

leaves me ignorant.

'Normative' I am well familiar with from I-D references but that meaning
does not seem to apply here (since Normative as a Reference means you
must understand the referenced work)..

'..known extension point..' I am not familiar with except for a rather
technical discussion which I read - but did not understand - on this
list recently.

To give a practical problem; when an I-D adds new entries to an existing
registry, is that an 'Updates'?  I have seen ADs firmly tell WG Chairs,
holding the contrary opinion, that it is not, and I thought that that
was settled, but applying this statement to that situation leaves me in
ignorance.

Tom Petch


----- Original Message -----
From: "Ben Campbell" <[e-mail]>
To: <[e-mail]>
Cc: "The IESG" <[e-mail]>
Sent: Tuesday, September 11, 2018 4:55 PM

Hi Everyone,

There have been several discussions lately about the use and meaning of
the “Updates” header in RFCs, and the resulting “Updates”/“Updated by”
relationships. The IESG is thinking about making the following
statement, and solicits feedback.

Thanks!

Ben.
--------------------------------------------

There has been considerable confusion among the IETF community about the
formal meaning of the “Updates” / "Updated by" relationship in IETF
stream RFCs. The “Updates” header has been historically used for number
of reasons of various strength. For example, the “Updates” header may be
used to indicate critical normative updates (i.e. bug fixes), optional
extensions, and even “additional information”.

The IESG intends these headers to be used to inform readers of an
updated RFC that they need to be aware of the RFC that updates it. The
headers have no formal meaning beyond that. In particular, the headers
do not, by themselves, imply a normative change to the updated RFC, nor
do they, by themselves, imply that implementers must implement the
updating RFC to continue to comply with the updated one.

The specific reasons that a given RFC updates another should be
described in the abstract and body of the new RFC. The level of detail
may differ between the abstract and the body; typically an abstract
should contain enough detail to help readers decide if they need to read
the rest of the RFC. The body should contain enough detail for readers
to fully understand the nature of the update.

The importance of including an “Updates” header depends on the nature of
the update. Normative updates that do not use a known extension point
should always include an “Updates” header. Extensions that do use known
extension points do not typically need to include the “Updates” header,
but may in cases where it’s important to make the extension known to
readers of the original RFC. Other uses of “Updates” may be appropriate
when it’s important for readers to know about them; for example a new
RFC may expand security or operational considerations in a way that is
not normative, but still important.

RFCs that fully replace other RFCs should typically use the “Obsoletes”
header rather than the “Updates” header. The “Updates” header should be
used to flag updates to published RFCs; it is not appropriate to
 “Update” an Internet-Draft.