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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Jul 2020 10:24:10 +0000

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  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: David Noveck <[email-masked]>
Date: Fri, 31 Jul 2020 07:24:45 -0400

On Fri, Jul 31, 2020, 6:24 AM Magnus Westerlund <
[email-masked]> wrote:

> WG and Authors,
>
> The RFC-editor asked in the AUTH48 of
> draft-ietf-nfsv4-rfc5661sesqui-msns-04 if
> 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
>    definition is an absolute requirement of the specification.

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

>    and sparingly.  In particular, they MUST

only be used where it is
>    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.

> appeared to have potentially implications if they are not followed for the

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

> lower case or if actually some of them should be promoted to upper case.

That would be a drag.

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Jul 2020 12:03:56 +0000

Hi,

Please see inline. WG please provide input.

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

Understood, but the larger community may have. And I having seen this discussion
maybe more than some in this WG have and are thus cautious about making any
assumption and have worked with co-authors to actually eliminate lower case
usage to avoid the issue. 

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

So I picked one example and I have to confes that I don't understand what would
occurr in this specific example if you didn't follow it and if there are
options. So if this "must" can be replaced by a "needs" or a "MUST" is not
obvious and would require me to dig significantly into the specification.

> > lower case or if actually some of them should be promoted to upper case. 

Yes, it does take some work.

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

Yes, and I think it is definitely a change to do for the proper bis.  I do agree
it clarifies. But, changing it at this point have impact that I want to avoid.

WG, please provide any views on this. 

> words which have an established meaning.

Fine, and with RFC8174 that need may be significantly reduced. It has been a way
to avoid the confusion. 

Cheers

Magnus Westerlund

---

From: Tom Talpey <[email-masked]>
Date: Fri, 31 Jul 2020 08:32:43 -0400

> Please see inline. WG please provide input.

I feel that it would be risky as heck to change all those "must"s,
to both the document and the existing implementations. At a minimum,
after consuming the WG's bandwidth, it will repeat the process N times
for the latter. It should stick with 2119 as-is.

When and if a non-bis non-sesqui non-ter non-whatever version is done,
obviously it should use 8174 and avoid these non-normative terms.

Tom.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
>