Re: [nfsv4] Use of RFC 8174 in RFC-to-be draft-ietf-nfsv4-rfc5661sesqui-msns-04

David Noveck <> Fri, 31 July 2020 11:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AABD33A12F5; Fri, 31 Jul 2020 04:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xDUnQiOPUELh; Fri, 31 Jul 2020 04:24:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C516F3A12F4; Fri, 31 Jul 2020 04:24:58 -0700 (PDT)
Received: by with SMTP id df16so5780370edb.9; Fri, 31 Jul 2020 04:24:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0vD9h8XyxW5fdk0zbvS5SoYS/KJrdePqOj0oDGSC3b4=; b=gGUSMcRaerKSFCYRNO0tJmFzJVUJa7Tny3eLSju5wc/b68X5moXI9Nvdlop+x+at0y Hd5j02HNyIX999asKddL2cGBy0qLEJ9PLMldZIPY7qpdYoCfHWf5MKR5nyfsVUkEP61x AnxdB+L5BFXIP1xum4BNLzvuU2HH1tvL2zQNbCrSVQbIHwNHLFfXzK5/gjcNBCi25Tf1 HhJgAQP3nb2ZF1JdNZVu+F+F9W2RPiUt+RIOl2EEVWceNaMWHKbiwI6TZEiAzNI/EGvl kbjIGW8YoaMM9mjNsmMcwlcfqivlJ8Hwr4bcOSs6eniltAHkmDu9dl3t4jpe93VUGxtu Vqhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0vD9h8XyxW5fdk0zbvS5SoYS/KJrdePqOj0oDGSC3b4=; b=Ic0QaQMF3DWT+zfXLRaPnhcsrkTKQQY19MjnUly1y5C7MvrJddCYXpMfpRFSKExaTf DRBBa5M+lmuEQBhX6z+E56ZtjxdPT2MMGIqfAiUiWslvUFkUMXZ1858VDXmpjeK4s+hs X1rPVJ5C+5i9I9oyEUsRFfrTuUDlpBaJr3mshuXQ6hAmy6A7K0mZ+37Jx0ZkC/ywyoI9 mixrd0Cy4cjjM0Hg6PwP1snI0EHeoB6rCy0EMVNyyMjuP1/DbU4/jsbwU5hExpWRq9ZQ XU7HhPYUMe7uKzPwmnNeX58mmmXiVMDXl3IVO4xe8tuoh/9ohdyDWc0eKaSSD0RraGsX WaTg==
X-Gm-Message-State: AOAM533kGTP9sqFVD92lBzVj9rSoJs5mBEkkH1zEYcQeLaJNulTqza18 5nyRgZYeLHpK0u3Y3k3OCxaCfp66Ov0zBUsRJs0=
X-Google-Smtp-Source: ABdhPJx/ATLGLebYB6fOK/sB0W9vVglKwmKCNho4lSKPlUbMpytop8iuPOAXs2iT7wcSBlUn0up3+0Rv2EITgnIwcqc=
X-Received: by 2002:a05:6402:74a:: with SMTP id p10mr3416692edy.348.1596194697098; Fri, 31 Jul 2020 04:24:57 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Noveck <>
Date: Fri, 31 Jul 2020 07:24:45 -0400
Message-ID: <>
To: Magnus Westerlund <>
Cc:, NFSv4 <>
Content-Type: multipart/alternative; boundary="000000000000e9b90e05abbb09de"
Archived-At: <>
Subject: Re: [nfsv4] Use of RFC 8174 in RFC-to-be draft-ietf-nfsv4-rfc5661sesqui-msns-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jul 2020 11:25:02 -0000

On Fri, Jul 31, 2020, 6:24 AM Magnus Westerlund <> wrote:

> WG and Authors,
> The RFC-editor asked in the AUTH48 of
> draft-ietf-nfsv4-rfc5661sesqui-msns-04 if
> the use of RFC 2119 language template should be updated to the one that
> includes
> RFC 8174 ( In other words
> changing
> Section 1.3 from:
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    document are to be interpreted as described in RFC 2119 [1].
> To:
>       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>       "MAY", and "OPTIONAL" in this document are to be interpreted as
>       described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>       appear in all capitals, as shown here.
> David and I have opposite views here. So attached are a file with all
> lines from
> -04 that contains a lower case RFC 2119 term. There are 1493 occurrences
> in the
> file.
> My current position is that this should not be changed. My main reason is
> that
> the document using the RFC 2119 terms and definition was how it went
> through the
> consensus and approval process.

That's true but the authors did not treat "must" and "MUST" as synonymous.

Based on the large number of occurrences of the
> terms that needs to be determined if any of these really should be
> capatilized
> if the RFC 8174 definition is applied.
> I will provide what I think is a strong example of why such investigation
> would
> need to be done and considered.
>  If the client requests
>    OPEN4_SHARE_ACCESS_WANT_READ_DELEG on an object with one of the
>    aforementioned file types, the server must set
>    wdr_resok4.od_whynone.ond_why to WND4_WRITE_DELEG_NOT_SUPP_FTYPE.
> I think that matches the 2119 definition of MUST:
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.

It also matches the definition of the English word "must".

> Lets also review Section 6 of RFC 2119:
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST

only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    Interoperability.

This paragraph is explaining where such term should not be used. It should
not be read as implying that they need to be used in any particular case.

> What would happen if one did not follow the MUST in the above sentence? I
> assume
> interoperability issues or protocol failures. I just picked a sentence that
> appeared to have potentially implications if they are not followed for the
> protocol operation.

Exactly, but I have heard IESG members object to the use of "MUST" in
situations like this saying "that's just explaining how the protocol works".

> The point I am trying to make is that if we go with RFC8174 the WG would be
> forced to review all these 1493 occurrences and decided if they really all
> are
> lower case or if actually some of them should be promoted to upper case.

That would be a drag.

> Then we have the next issue, which is me as responsible AD having to judge
> if
> the result of this change still represent what was approved by the IESG
> and has
> IETF consensus for publication. Currently I do significantly struggle with
> making such a determination, or if I think the document would need to go
> back
> and redo the WG, and IETF last call. The document as it stands using RFC
> 2119
> have established consensus. So I argue for the path of least resistance by
> not
> changing here to get these updates published.

Ok. I surrender.   Although I think adding a reference to RFC 8174 would
make things clearer, I am prepared, if the wg concurs, to ask the rfc
editor to leave that out.

> Updating to RFC 8174 is definitely the proper bis version should do. But by
> doing that early as all the other changes are folded in the WG will have
> time to
> consider the usage and maybe also use a writing style that avoids using the
> lower case version of the RFC2119 terms.

I don't think we want to rewrite all this text or eliminate these English
words which have an established meaning.

> This is my view and you should not jump in on this until David have had a
> chance
> to provide his view, but although I understand his high level reasoning, he
> hasn't seen my arguments for my position either.
> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:
> ----------------------------------------------------------------------