Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-ecn-encap-guidelines-21: (with COMMENT)

[Bob Briscoe <[e-mail]>]

Rob, pls see [BB2]

On 01/12/2023 09:55, Rob Wilton (rwilton) wrote:
> Hi Bob,
>
>> -----Original Message-----
>> From: Bob Briscoe<[e-mail]>
>> Sent: Friday, December 1, 2023 12:55 AM
>> To: Rob Wilton (rwilton)<[e-mail]>; The IESG<[e-mail]>
>> Cc:[e-mail];[e-mail];
>> [e-mail]; David Black<[e-mail]>;[e-mail]
>> Subject: Re: Robert Wilton's No Objection on draft-ietf-tsvwg-ecn-encap-
>> guidelines-21: (with COMMENT)
>>
>> Robert, Thank you for your review. See [BB]
>>
>> On 28/11/2023 13:29, Robert Wilton via Datatracker wrote:
>>> Robert Wilton has entered the following ballot position for
>>> draft-ietf-tsvwg-ecn-encap-guidelines-21: No Objection
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
>> positions/
>>> for more information about how to handle DISCUSS and COMMENT
>> positions.
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> Hi,
>>>
>>> Thanks for this document, it is well written and an interesting read.
>>>
>>> I have just one very minor comment for you to consider please:
>>>
>>> (1) p 4, sec 1.  Introduction
>>>
>>>      Therefore, the capitalized terms 'SHOULD' or 'SHOULD NOT' are often
>>>      used in preference to 'MUST' or 'MUST NOT', because it is difficult
>>>      to know the compromises that will be necessary in each protocol
>>>      design.  If a particular protocol design chooses not to follow a
>>>      'SHOULD (NOT)' given in the advice below, it MUST include a sound
>>>      justification.
>>>
>>> I would suggest "must include a sound justification", i.e., otherwise it is
>>> unclear how the justification affects protocol conformance.
>> [BB] I don't understand. Surely it's very clear... If a protocol spec
>> does not include a sound justification for why it does not follow any of
>> the SHOULD (NOT)s given in this BCP, it does not comply with this BCP-to-be.
>>
>> To my mind, conformance is only unclear without the 'MUST' in caps?
> [Rob Wilton (rwilton)]
>
> I mostly think of RFC 2199 language as helping protocol conformance, i.e., will two implementations of a protocol successfully interoperate together.  Hence, I'm struggling to see why, on the wire, whether or not a justification is stated in a document will affect whether two implementations successfully interoperate.
>
> Writing must instead of MUST still requires that they do it, and section 6 of RFC 2119 states:
>
> 6. Guidance in the use of these Imperatives
>
>     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.
>
> Also RFC 8174, that updates 2119 states:
>
>     o  These words can be used as defined here, but using them is not
>        required.  Specifically, normative text does not require the use
>        of these key words.  They are used for clarity and consistency
>        when that is what's wanted, but a lot of normative text does not
>        use them and is still normative.
>
>     o  The words have the meanings specified herein only when they are in
>        all capitals.
>
>     o  When these words are not capitalized, they have their normal
>        English meanings and are not affected by this document.

[BB2] OK, so you're not talking about conformance with /this/ BCP, 
you're talking about conformance with the specs that might be written 
following this BCP. The problems here are two fold:

 1. Nearly all the uses of 'SHOULD' in this document are to ensure that
    new L2 protocol designs will interoperate properly. So, ideally most
    of the 'SHOULD's would have been written as 'MUST's. Nonetheless,
    the caveat you've quoted explains why that would have been too
    inflexible, so  'MUST' has been used sparingly.
 2. indeed , in theory, lower case words still have the force of their
    normal English meaning{Note 1}. However, in practice, that subtle
    point flies over the heads of 99% of practitioners.

So, by saying that protocol designers 'MUST' include a sound 
justification (when they don't follow a SHOULD), the draft could well 
improve interop of future protocol designs. And I don't think it could 
ever do any harm (other than looking odd). So, as you've tagged this as 
a minor comment, I think on balance I'm going to leave the text as it is.

But thank you for bringing it up, and explaining it.

{Note 1} (I started a thread on rswg about the automated addition of 
<bcp14> around capitalized keywords, where this point came up)


Bob

>
> However, having said all of this, this is not a blocking comment, and if you wish to keep it as MUST you may do so.  I just think that it looks odd.
>
> Regards,
> Rob
>
>
>
>>
>> Bob
>>
>>> Regards,
>>> Rob
>>>
>>>
>>>
>> --
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/