Re: [lamps] Murray Kucherawy's No Objection on draft-ietf-lamps-lightweight-cmp-profile-18: (with COMMENT)

["Brockhaus, Hendrik" <[e-mail]>]

Murray

Thank you for commenting again on our approach addressing your feedback from December.
Thank you for providing the quote from RFC 2119. This makes it much clearer to us and shows that we tried to kind of redefine the usage of “SHOULD” which seams not appropriate.

We offer to revise the SHOULDs and decide to either add explanatory text, change to “MUST” or “MAY”, or use “should” instead.
This will take some time, but the authors are willing to do this. :-)

@Roman, if you think this is not the right way forward, please let us know.

Hendrik

Von: Murray S. Kucherawy <[e-mail]>
Gesendet: Donnerstag, 12. Januar 2023 19:03
An: Brockhaus, Hendrik (T CST SEA-DE) <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: Re: Murray Kucherawy's No Objection on draft-ietf-lamps-lightweight-cmp-profile-18: (with COMMENT)

On Mon, Jan 9, 2023 at 8:07 AM Brockhaus, Hendrik <[e-mail]<mailto:[e-mail]>> wrote:
Murray

Last week the co-authors and I managed to align on how to address your
comments. Please see our proposal for an updated version of the draft below.
I hope these generic changes sufficiently addresses your comment
sufficiently. Changing the entire document instead, will be a mayor effort.

@Roman, I hope these changes are appropriate after IESG review. If you have
any concerns, please let me know.

[...]

Hi Hendrik,

I appreciate the attention you're giving to this, especially since this isn't a DISCUSS position.

Succinctly, it seems like you're trying to widen the definition of SHOULD as defined in BCP 14, and I'm having trouble understanding what you're seeking to achieve by doing so.  It seems to me like it might be simpler to just say "should" instead of "SHOULD"; that would be an easy way to avoid this sort of friction.

Section 6 of RFC 2119 says in its entirety:

   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.
We have come to also allow use of BCP 14 key words around security and operations.  For instance, "you MUST encrypt data in transit" has become a security best practice generally; "you SHOULD log this when it happens" is sound operational advice.  However, the text of your abstract reads a lot like an Applicability Statement (Section 3.2 of RFC 2026), though, so I don't feel that it falls under those sorts of exceptions.

SHOULD isn't intended to allow general mush around the requirement to do something; it's meant to say, in effect, "You really need to do this.  Doing anything else threatens interoperability, so you need to be sure of what you're doing if you deviate."  This is why we encourage, along with SHOULD, some kind of guidance around when one might decide not to do what the SHOULD says.

I think your best options are either to revisit the SHOULDs you have and see about either adding some of the supporting text I'm suggesting, change them to MUSTs or MAYs, or just use "should" instead of "SHOULD".

Again, I'm not holding a DISCUSS on this, and hence not making a demand.  It's up to you and your AD to decide where you go from here.

Thanks again for your consideration.

-MSK