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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 14 September 2018 00:53 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AE3130DD7; Thu, 13 Sep 2018 17:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkJs2YC7n7Q4; Thu, 13 Sep 2018 17:52:59 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257261277D2; Thu, 13 Sep 2018 17:52:59 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id s7-v6so3548947pgc.0; Thu, 13 Sep 2018 17:52:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iuI4Q+6oryhLQO9wKWnZPAaCrjzPsz0WIVnL4utRr/o=; b=G+DnY468VhQud7J+Y479KRcTP5fyPFVGJp9q05JD4X+jpv/0RcKSRRY6nY+OcCEGR6 twGJQ1ekjOvDkM+L8IVSuubxN3Bzg60CNEgrqW52B82cF68Y62kxdAd5AA9pC6hNj1AE JBIxCtFQzO1ljPGsykEPFcazwj2rGDDYllILtyUgDdnY4txX7iS0DPnrPDGd69OzUWN7 IMysbVpHPxxnmjXmzvc87t/1DjEHBIvBuv+ZVQLByPikN9y5w+jsbQs0wGfel3IqLdgV aJG3pzMYs4gJ3FmPy7fv2sn08XinZmVBRcI7WhJdGTgefmwug+Iyh8cdeVEYOtoD4SdA vKWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iuI4Q+6oryhLQO9wKWnZPAaCrjzPsz0WIVnL4utRr/o=; b=GdDHwmIHpGV1teiK8OHtQWjN+RUqPuRmyVPJI1Th/8I2PTDq0AgbFsc83xpcwYgib+ lSa2rh/V0park47ncRLjJzBQC/xvWSmuI2bILXm1Z2ynBig2FnLX4DgJt6DVDLtfJhWk y/PA7wcflGMTO6UVpb0o2M1WcfQGB5xXnNWZlSzRrYrleEDsqgAmxCYsyryyb1IsYmzV xduUAYdMXwh9IdBDtmdYueVSt986ujzAiGQZU1dNqx84swf65LEVRorcyILYIoYBDfn3 zD9xBRdM65G/GRpvtLNgsGaMLI6duGIgtZ27E86VU4Rg88CvkGF4hpcD/kvcEfbz8Bk3 b57g==
X-Gm-Message-State: APzg51AjwdiMo34fFLevQLFkmc0IZICJ7BSc1pagWKpTZalKkc227rsN OIZbkOO/ijQOVVUqczaoe1Ck54eV
X-Google-Smtp-Source: ANB0VdY7ykm/j6q/l008xyVo1zvIMRxy3QI7IgLjs1xELWv3TSNUQvW4TBW0iIU01gElVZ7ho7HcDA==
X-Received: by 2002:a62:20f:: with SMTP id 15-v6mr9824515pfc.100.1536886378094; Thu, 13 Sep 2018 17:52:58 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id t123-v6sm6412884pfd.51.2018.09.13.17.52.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 17:52:57 -0700 (PDT)
Subject: =?UTF-8?Q?Re:_Proposed_IESG_Statement_on_the_use_of_the_=e2=80=9cUp?= =?UTF-8?B?ZGF0ZXPigJ0gaGVhZGVy?=
To: Robert Sparks <rjsparks@nostrum.com>, Ben Campbell <ben@nostrum.com>
Cc: ietf@ietf.org, The IESG <iesg@ietf.org>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <9a505c33-3327-a13f-f5ce-4fac360169b1@nostrum.com> <74DA1D55-6000-4352-9FED-65559CFEE750@nostrum.com> <80bc8b72-a1c6-c0e1-fac2-514f34b7795f@nostrum.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c007bde0-f75b-9cde-1c6d-90da8076c6da@gmail.com>
Date: Fri, 14 Sep 2018 12:52:51 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <80bc8b72-a1c6-c0e1-fac2-514f34b7795f@nostrum.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/p5xSMYcSgUwVh6eNGVkqG6GvDY0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2018 00:53:02 -0000

On 2018-09-14 10:28, Robert Sparks wrote:
> 
> 
> On 9/13/18 5:09 PM, Ben Campbell wrote:
>>> On Sep 11, 2018, at 1:08 PM, Robert Sparks <rjsparks@nostrum.com>; 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 use of extension points doesn't cross that bar. So, count me as against everything in the second paragraph beyond the first sentence.
>> I note that several people have agreed with this point or made similar points. I’d like to test what counts as “updating a document in an essential way”. Consider the following scenarios:
>>
>> A) Critical bug fixes that impact all implementations of a protocol.
>> B) Critical bug fixes to an optional feature from the original RFC. It does not impact code that didn’t implement the option in the first place.
>> C) A modular extension that mitigates a security or network congestion issue in the base protocol. We really want people to implement it, but introduce it as a negotiated extension to avoid a fork-lift change.
>> D) A change to security considerations and/or operational considerations that, while not changing the protocol, significantly changes the environment it can be safely used in.

All of those, because a developer supporting an implementation of the
base protocol might need to touch their code.

>> E) A modular extension that adds a new, optional feature.>>
>> Which of these needs an “Updates” header? I imagine most people agree that A does and that E does not. 

I'm not so sure. Again, the developer might *want* to touch their code. So
absent a "See also:" or "Extends:" tag, some people might think this merits
"Updates:".

Look at RFC3461, updated by RFC8098, which clearly extends it in a fairly
explicit way. Wouldn't an implementor of  Delivery Status Notifications
want to know?

> What about the ones in between?
> Skipping this for now so I can make a quick reply to what's below.
>>
>>> 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?
>> It has come up in conversation, yes :-)
>>
>> Would you see a “see also” relationship as meaning “you really, really need to read this” or “this contains supplementary information”? Or something in between?
> I don't think I care.
> 
> I see it as an outlet to release pressure for those folks that want to 
> put numbers on the first page that really should just be references with 
> explanatory text making the references natural.
> 
> I might care more if we reset the conversation completely and stopped 
> talking in terms of "stuff on the first page" and spoke more about 
> "metadata about the documents that's curated enough for software to 
> use". I think going there will be a bigger, longer, but more useful to 
> the world in the long run, conversation. I suspect somewhere along that 
> path, we'll be staring at yang models...

Maybe. But at the risk (no, certainty) of repeating myself, see draft-klensin-isdbis.

   Brian

>>
>> Thanks!
>>
>> Ben.
>>
>>
>>> 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.
>>>>
>>>>
> 
>