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

[Michael Richardson <[e-mail]>]

Donald Eastlake <[e-mail]> wrote:
    > This does document a change that has occurred. In the past, it was
    > common for important extension RFCs to have an Updates header pointing
    > to the RFC that they extended.

I don't think that the IESG proposes to remove this use.
I think that they intend to explicitely support it.
However, not every allocation by document Y of a registry from document X, is
an Updates: to X.

    > I don't object to the change in Updates but I do object to the loss of
    > the ability to have a simple title page pointer on a RFC to RFCs it
    > updates in a important way. Please add an optional "Extends:" header to
    > the title page to preserve the previous functionality.

    > Thanks, Donald =============================== Donald E. Eastlake 3rd
    > [phone] (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA
    > [e-mail]

    > On Tue, Sep 11, 2018 at 4:57 PM Brian E Carpenter
    > <[e-mail]> wrote:
    >>
    >> On 2018-09-12 06:08, Robert Sparks wrote: > I can live with this
    >> statement, but I don't like it.
    >> >
    >> > I'm in the camp that prefers the more specific "This changes the
    >> code > you need to write" camp - I would prefer Update be restricted
    >> to the > cases where you are changing the protocol defined in the
    >> updated > document in an essential way.
    >>
    >> The IAB already opined indirectly on this topic.
    >> https://tools.ietf.org/html/rfc6709#page-5 says:
    >>
    >> >>> Extension designers should examine their design for the following
    >> >>> issues:
    >> >>>
    >> >>> 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.
    >>
    >> (followed by more detailed discussion).
    >>
    >> I'm not sure the IESG text is 100% compatible with this.
    >>
    >> > nor do they, by themselves, imply that implementers must implement
    >> the updating RFC to continue to comply with the updated one.
    >>
    >> seems to be going to far. It may be the intent of the update that
    >> implementations *need* to be updated, because the update fixes a bug.
    >> In that case, "updates" really means "partially obsoletes".
    >>
    >> Another point: the statement is scoped to the IETF stream. But it
    >> would be much better if all RFC streams use the same semantics. I'd
    >> like to hear from the RFC Series Editor on this.
    >>
    >> Brian
    >>
    >> > The use of extension points doesn't cross > that bar. So, count me
    >> as against everything in the second paragraph > beyond the first
    >> sentence.
    >> >
    >> > That said, I again note that I can live with what's proposed.
    >> >
    >> > RjS
    >> >
    >> > p.s. I assume you've rehashed previous IESGs discussions of adding a
    >> > "See Also" relationship?
    >> >
    >> > On 9/11/18 10:55 AM, Ben Campbell wrote: >> 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.
    >> >>
    >> >>
    >> >
    >> >
    >>