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

[tom petch <[e-mail]>]

----- Original Message -----
From: "Ben Campbell" <[e-mail]>
Sent: Tuesday, September 11, 2018 5:40 PM

> On Sep 11, 2018, at 11:31 AM, tom petch <[e-mail]>
wrote:
>
> 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.

A known extension point is any mechanism in the original RFC designed to
allow extensibility without modifying the RFC. IANA registered code
points are a common approach. Feature negotiation mechanisms also come
to mind.

Can you suggest a better term for this?

Ben

No:-(  I understand your explanation and see that concept in many
places, but do not know of any generic term for it.  (Thus I think of
YANG augments, but that term would probably not make sense to those not
versed in YANG). Rather, I would like to see your sentence of
explanation or something like it in the statement.

Tom Petch

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

The intent is that these are usually not “Updates”. But they can be if
there are special circumstances, which I presume would be documented in
the text that describes the nature of the update. An individual AD may
or may not agree with an argument that a particular update is “special”
in this sense, but I believe we all agree that such special cases are in
the realm of possibility.

Thanks!

Ben.

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