Re: An observation on draft-leiba-rfc2119-update-01

Stewart Bryant <stewart.bryant@gmail.com> Tue, 07 February 2017 16:10 UTC

Return-Path: <stewart.bryant@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 4D2C9129D00 for <ietf@ietfa.amsl.com>; Tue, 7 Feb 2017 08:10:30 -0800 (PST)
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 YcUYnj2y9TwZ for <ietf@ietfa.amsl.com>; Tue, 7 Feb 2017 08:10:29 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 93FA1129CFE for <ietf@ietf.org>; Tue, 7 Feb 2017 08:10:27 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id r141so158246315wmg.1 for <ietf@ietf.org>; Tue, 07 Feb 2017 08:10:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tYBO44AsTuWUBkXHH0qw84NHB9e/riQ/OMhVqyAG0jE=; b=mZbZlZxlM92C9PfJmJ7p4mN6SEkqy/dievgfGK+COr+ktnFBEadwsE2RcacSJ1OqUY QU3kPvG1lNt5Xnnj+F8fSf1yXe5MxQD6cYH1zKktnuGod3GlBz1896Bm0yuMhmQgAvvF 2zB99aJtQR5BwUJDnxoN29HqZzJXWT9LQM1Krdc3SpXDmpNxbQdJZP20v8vjR4mWa7zX DxLgJHsV2nOTNTWpXMmXvAIL5eFcgUAnX5NJYjnnRICEkJWHm/L7byoWKQ0LQQMsSaE7 dWwzMD1ZE96Uhk/Y5gEtVMNC8OjLLuoYxT0AJHVwD6kdOPqrjkrbaRcZGe1UdPyyKYl7 2GTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tYBO44AsTuWUBkXHH0qw84NHB9e/riQ/OMhVqyAG0jE=; b=lgg9yKueJ4OAgskvRYy0NfGNwvbK64zf8lyebYlNbMCtRUanlH8CatQ8k5UaYnG8qz pJJRngN64N2h+ZZ8rb0G4knxy1e/9aALO2XAqSCJEnfhLgE9vTXgupGqGQuCM4TwVtZ5 1fF5jIPYjuUBWvlrog1yV3yGzaJgSbh5CZfUCMwv/zPbOfGJpTn27OniotUvXGBVEKS+ yDSIW+HN/SFir0zuRQGCqt+RSqIRJ+PI4p4mVFgByTS7klCi30vrlgWFGHLpdOOpVbZI SGKpY4mrF5MKcJtXVbvITSnCJAVRPDJLUN7CFDtdl7vxCOmJfPBUP2oN1cJfnPoB7DyD y3pg==
X-Gm-Message-State: AMke39lsOl4cr0TOB+XFSc4RlQQzD1zl8449Dji1S42XE9AY4NFktW4fms+T8CooY134VQ==
X-Received: by 10.28.55.199 with SMTP id e190mr12793608wma.92.1486483824545; Tue, 07 Feb 2017 08:10:24 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id e74sm19557344wmd.2.2017.02.07.08.10.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 08:10:24 -0800 (PST)
Subject: Re: An observation on draft-leiba-rfc2119-update-01
To: Barry Leiba <barryleiba@computer.org>
References: <d55a5027-b01a-8891-5e6e-4c519b5b9801@gmail.com> <CALaySJL-kfjQO=P3aVWwu6zEz6y5k7bngqEf0eqShWjAKAZ7Ug@mail.gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <d3d29686-ce17-3cbd-2693-6a1334092f44@gmail.com>
Date: Tue, 7 Feb 2017 16:10:23 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <CALaySJL-kfjQO=P3aVWwu6zEz6y5k7bngqEf0eqShWjAKAZ7Ug@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Q2AEa_A93zS144OreqerXoDXhcs>
Cc: IETF Discussion <ietf@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: Tue, 07 Feb 2017 16:10:30 -0000


On 07/02/2017 15:45, Barry Leiba wrote:
> Hi, Stewart.
>
>> The above text raises an interesting problem. If the update system works
>> then
>> the text should read [RFC2119]. If the update system does not work than
>> the text needs to be [RFC2119],[RFCxxxx] as shown, but we also need to move
>> to a system where we always list the update set at the time of publication,
> It took me a while to get what you mean here, but I think I have it:
> you're saying that because this document (RFC xxxx) UPDATES RFC 2119,
> *any* document that cites RFC 2119 and is published after this one
> must automatically be taken to refer to this one and must follow the
> terms of this one.  So why have the double citation?
>
> You're right, as far as that goes, but if it's important to know for
> sure whether a document is following the terms of RFC xxxx or not (and
> see below about that), then I think it's important to be explicit
> about it.  It's a question of clarity: the reader of another document
> should not have to wonder, should not have to check publication dates,
> should not be uncertain.  Having the citation there explicitly is good
> for clarity.
>
> In fact, we *do* often (though not always) cite update documents when
> we're explicitly talking about a feature that was updated.  I think we
> do it when calling the reader's attention to the update is
> particularly important.

I am afraid I disagree. Either the update system works or it does not. 
If you think
people do not follow through the updates, then we need to always include 
update
list, or we need a system that always gives them the update when they 
request the
base document. So for example someone asking for RFC2119 would find this
automatically but distinctly appended to it.

Ironically in this case the result is no text change to the document 
making the
reference since a MUST is a MUST.

>
> Now, as to the other point:
>
>> I am also somewhat curious about the practical implication of
>> misinterpreting
>> MUST as must, and must as MUST.
>>
>> For example: if A receives a foo packet, it MUST/must reply with a bar
>> packet
>>
>> The interoperability considerations are identical, with but with the
>> advantage
>> that  MUST draws the eye of the reader to  the point and reducing the chance
>> that they will miss it. Similarly with the other keywords. So is there
>> really
>> a problem to be fixed here?
> This did come up in earlier discussion about "MUST".  Sure, it's
> possible that there really isn't a reason to define "MUST" in BCP 14
> because the English meaning is clear enough.  But "SHOULD" and "MAY"
> do need these definitions: the English meanings don't accurately
> convey the BCP 14 meaning.  And even with "MUST", the BCP 14 meaning
> explicitly says that it's a protocol requirement that affects
> interoperability or security, and we do seem to think that making that
> distinction is important.
>
> In any case, the current BCP 14 defines "MUST", and it's specifically
> not a goal of this document to change that older decision.

No, the point is that either type of must is exactly the same 
instruction - "do it or it's broken".

Similarly when should is given it is advisory, and there is no forcing 
how seriously the
individual takes that advice.

So if someone mistakes a MUST for a must, I don't see how the on the 
wire behaviour
can possibly change. Same for the other key words.

- Stewart

>
> Barry