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

["Murray S. Kucherawy" <[e-mail]>]

On Mon, Jan 9, 2023 at 8:07 AM Brockhaus, Hendrik <
[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