Re: I-D Action: draft-wilde-updating-rfcs-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 21 September 2016 02:09 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 C1D0012B16B; Tue, 20 Sep 2016 19:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 wT_ItqCQdeCa; Tue, 20 Sep 2016 19:09:53 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 570F0127078; Tue, 20 Sep 2016 19:09:50 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id q2so13361560pfj.3; Tue, 20 Sep 2016 19:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+FxSnTjHuvdA4SXiXx7vkPEgvxUVUOuguJ2r8JvTSbg=; b=HevsmROdd0m48PQFW550sGo/O2+99NxNVqfXEuXJd3FDyM3FVzEzMUAHQfp6kq4EAa 6RQq+ICibmxi6+3+TvKMG250Jp3Ysskbc0R52b+2UDiWiFx8owBf1qdQE0xlOofUBn8p 9ydGucb31IWd7cD0Kz1lgXSEExlmIw1nxMACRj2LIN6q45BA79UPqB5h68UU3g6wu8R4 RiZQZs7pSdIyUTLzRQVMGXBkSbXi4N4BMjl/ho2I5YmAfq5RknHTqKj0jYncoBi47pIQ z1ApDIueHQQS8Ra+CiaFDoxKXjKolfMF/TchHjV9gsbcU7k36q8nlbC50qRMI2gyvLic t43w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+FxSnTjHuvdA4SXiXx7vkPEgvxUVUOuguJ2r8JvTSbg=; b=RhewkHmfJG5ls9DJlHPeLlHx5A1m+dLQFg+3ksQmXY5HN/QDoFL80LrdgNl9Wovno5 ogFUderg/vKGlp57iQYv6sfFsoARfJwoDCkOLBqt/+zFOGR9lJQGVu0SY3UEngkpJmdS vOjnVarmnb7zveJ6cYnznVTCGUTxu8D4iWHk/ctvDjqGHeVA8HAAuLbuWud2hJmF3sb9 jL1IdcvSagAv8nEbp2fJH3z6zvtmq7Y//OgB4BuhmIJgOSejL0eLlz7oFPIDv4WBtsqI mWkbCUFwgSFyg6ICn8RTDcT5QdGPIgPbzEo7a5iJNXRqP2nJe6qBv23pd2xs1Kfl71Z4 UexA==
X-Gm-Message-State: AE9vXwO/cxFt90mC0Rjxp85QcNHF9WAGZDEq2kooUMxJdDOZGzA2aV3gTvMqoZKs/8hABg==
X-Received: by 10.98.69.73 with SMTP id s70mr59996428pfa.115.1474423789746; Tue, 20 Sep 2016 19:09:49 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id u1sm79946722pfb.62.2016.09.20.19.09.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Sep 2016 19:09:48 -0700 (PDT)
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
To: IETF discussion list <ietf@ietf.org>
References: <147389550726.29872.13885747896056913688.idtracker@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <e66c7d14-1903-09bd-23f0-396d9690a178@gmail.com>
Date: Wed, 21 Sep 2016 14:09:50 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <147389550726.29872.13885747896056913688.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/xWg0fbNfYZeXgzETM3BBRLvdKKY>
Cc: draft-wilde-updating-rfcs@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 21 Sep 2016 02:09:55 -0000

Hi,

First two general comments:

1. I do think we need to clarify this topic. However, I want to
repeat my earlier comment: IMHO the *generic* explanation of
what "Updates:" means should come from the RFC Editor. It can
be quite short, and there should be some community discussion.

So I will treat this draft as describing how the IETF stream
interprets "Updates:", within that generic explanation, and the
other RFC streams are free to make their own interpretations
(or adopt this one, if they want).

2. John Klensin, at
https://mailarchive.ietf.org/arch/msg/ietf/qdDAtDC0jIKoUgZUFwGUuQSDQyo
referred to earlier discussions, including in NEWTRK. Indeed we have
some unfinished business - how on earth is a consumer of RFCs supposed
to know which bits of which RFCs she needs to implement, and which bits
*not* to implement, to produce interoperable code? If A claims to
be the standard, but B updates it, while C obsoletes A without mentioning
B, etc. etc., what is a poor programmer to do?

If you don't appreciate the complexity of this question, here are
two illustrations, one of which is close to home for the IETF itself:
https://tools.ietf.org/html/rfc6434
https://www.ietf.org/about/process-docs.html
They are both out of date, of course.

I suggest that this complicated question still needs to be answered,
but this draft is not the place to do it.

Now for my specific comments:

>    RFC authors that use "Updates" in their document should include
>    individual "Reasons for updating ..." sections for each updated RFC.
>    These sections should be placed relatively early in the document.  In
>    each of these sections, there should be a short description of the
>    nature of the update.

IMHO this is too bureaucratic and will make the result noisy and awkward
to read. I believe it is reasonable to require that the changes are easy
to find, but that doesn't require separate sections. For example, in
https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host
which updates RFC 4861, searching for the text string 4861 will do the
trick, and you will see the changes in context.

So I would advocate something more like:

RFC authors that use "Updates" in their document should ensure that
the specific updates are easy to identify, preferably by citing the
specific section of the updated RFC in the updating text. A general
rationale for the updates should be prominent in the document's
Introduction.

(Then the word "sections" in the following two paragraphs could
be changed to "updating text".)

An organizational comment: The three paragraphs starting with
"Generally speaking,..." would be much better moved to the beginning
of section 3, since they motivate what follows.

>    The second motivation is that the updating RFC is a backwards
>    compatible extension, which means that strictly speaking, it does not
>    even need to mention the updated RFC.  

I disagree. If I maintain the code for foobar, I'd really like to
receive a ping when the RFC extending it to foobar+ comes out. So unless
we introduce a new metadatum "Extends:", I think that we really should
use "Updates:" for extensions. At the minimum, I need to check that
incoming foobar+ extensions won't break anything.

You might want to review RFC6709, in which the IAB uttered:
"  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."
(https://tools.ietf.org/html/rfc6709#page-5)

By the way, a can of worms that you don't mention is updates by other
SDOs. There's a BCP for that: https://tools.ietf.org/html/rfc4775

Regards
   Brian Carpenter