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

[Magnus Westerlund <[e-mail]>]

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. 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.

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.

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. 

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. 

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. 

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. 

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]
----------------------------------------------------------------------