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

[David Noveck <[e-mail]>]

On Fri, Jul 31, 2020, 6:24 AM Magnus Westerlund <
[e-mail]> 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 (https://datatracker.ietf.org/doc/rfc8174/) In other words
> changing
> Section 1.3 from:
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [1].
>
> To:
>
>       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>       "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_WRITE_DELEG without
>    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  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>