MIME-Version: 1.0
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com>
 <9a505c33-3327-a13f-f5ce-4fac360169b1@nostrum.com>
 <5d328d01-1ed6-3d0a-d250-d70fdaad00ff@gmail.com>
In-Reply-To: <5d328d01-1ed6-3d0a-d250-d70fdaad00ff@gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 11 Sep 2018 23:30:45 -0400
Message-ID: <CAF4+nEFi7yOxgNi63ji1A8BeC_Y7qmH5hmep4jUJpJ59b4BPWA@mail.gmail.com>
Subject: =?UTF-8?Q?Re=3A_Proposed_IESG_Statement_on_the_use_of_the_=E2=80=9CUpd?=
 =?UTF-8?Q?ates=E2=80=9D_header?=
To: IETF Discussion <ietf@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pf9KUqYca7X7tZL3TZOdDSh6SJU>
Precedence: list

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 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com

On Tue, Sep 11, 2018 at 4:57 PM Brian E Carpenter
<brian.e.carpenter@gmail.com> 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 underlyi=
ng
> >>>        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 o=
f the =E2=80=9CUpdates=E2=80=9D header in RFCs, and the resulting =E2=80=9C=
Updates=E2=80=9D/=E2=80=9CUpdated by=E2=80=9D relationships. The IESG is th=
inking about making the following statement, and solicits feedback.
> >>
> >> Thanks!
> >>
> >> Ben.
> >> --------------------------------------------
> >>
> >> There has been considerable confusion among the IETF community about t=
he formal meaning of the =E2=80=9CUpdates=E2=80=9D / "Updated by" relations=
hip in IETF stream RFCs. The =E2=80=9CUpdates=E2=80=9D header has been hist=
orically used for number of reasons of various strength. For example, the =
=E2=80=9CUpdates=E2=80=9D header may be used to indicate critical normative=
 updates (i.e. bug fixes), optional extensions, and even =E2=80=9Cadditiona=
l information=E2=80=9D.
> >>
> >> The IESG intends these headers to be used to inform readers of an upda=
ted 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 t=
hemselves, imply a normative change to the updated RFC, nor do they, by the=
mselves, imply that implementers must implement the updating RFC to continu=
e to comply with the updated one.
> >>
> >> The specific reasons that a given RFC updates another should be descri=
bed 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 en=
ough 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 =E2=80=9CUpdates=E2=80=9D header depend=
s on the nature of the update. Normative updates that do not use a known ex=
tension point should always include an =E2=80=9CUpdates=E2=80=9D header. Ex=
tensions that do use known extension points do not typically need to includ=
e the =E2=80=9CUpdates=E2=80=9D header, but may in cases where it=E2=80=99s=
 important to make the extension known to readers of the original RFC. Othe=
r uses of =E2=80=9CUpdates=E2=80=9D may be appropriate when it=E2=80=99s im=
portant for readers to know about them; for example a new RFC may expand se=
curity or operational considerations in a way that is not normative, but st=
ill important.
> >>
> >> RFCs that fully replace other RFCs should typically use the =E2=80=9CO=
bsoletes=E2=80=9D header rather than the =E2=80=9CUpdates=E2=80=9D header. =
The =E2=80=9CUpdates=E2=80=9D header should be used to flag updates to publ=
ished RFCs; it is not appropriate to =E2=80=9CUpdate=E2=80=9D an Internet-D=
raft.
> >>
> >>
> >
> >
>