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

[Tom Talpey <[e-mail]>]

On 7/31/2020 8:03 AM, Magnus Westerlund wrote:
> Hi,
> 
> 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.

> On Fri, 2020-07-31 at 07:24 -0400, David Noveck wrote:
>>
>>
>> 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.
> 
> 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.
> 
>>
>>
>>> 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".
> 
> 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.
> 
>>
>>> 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.
> 
> Yes, it does take some work.
> 
>>
>>> 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.
> 
> 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.
> 
>>
>>> 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.
> 
> Fine, and with RFC8174 that need may be significantly reduced. It has been a way
> to avoid the confusion.
> 
>>
>>>
>>> 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]
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
>