Donald Eastlake <d3e3e3@xxxxxxxxx> 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
> +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA
> d3e3e3@xxxxxxxxx
> On Tue, Sep 11, 2018 at 4:57 PM Brian E Carpenter
> <brian.e.carpenter@xxxxxxxxx> 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.
>> >>
>> >>
>> >
>> >
>>
