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 your review and for your comments.
I will need to discuss your generic comment on the usage of SHOULD with the co-authors and will come back to you with a response.
Maybe the scope of the document must be explained a bit more. This profile on the one hand intends to reduce the flexibility of CMP to the generic needs of automated certificate management of machine end entities. On the other hand, it is still a framework that is supposed to be further profiled by those having a specific use case or scenario in mind, for example like by 3GPP/ETSI or UNISIG. Therefore, there is still some freedom to serve the needs of the final target environment. 

Hendrik 

> Von: Murray Kucherawy via Datatracker <[e-mail]>
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1.7 uses a SHOULD NOT before that expression is defined in Section
> 1.9.
> 
> The bulk of the SHOULDs in this document would benefit from review and
> possible
> tuning.  SHOULD presents a choice for the implementer; it would be helpful
> to
> include with that choice some guidance about when one might legitimately
> deviate from what's stated.  If SHOULD is being used as "you really oughta do
> this, but you don't really have to and things will interoperate just fine", it
> doesn't deserve SHOULD; if what you mean is "yes you have to do this from
> now
> on, but we're retaining backward compatibility here" then it should say that
> explicitly.  In other cases, I wonder if you don't really mean MUST.
> 
> For instance, in 3.1, you have this:
> 
>     -- SHOULD contain a name representing the originator of the
>     --   message; otherwise, the NULL-DN (a zero-length
>     --   SEQUENCE OF RelativeDistinguishedNames) MUST be used
> 
> Looks great; I have no wiggle room.  Then you have this:
> 
>     -- SHOULD be the subject of the CMP protection certificate, i.e.,
>     --   the certificate corresponding to the private key used to
>     --   sign the message
> 
> Well, what if I don't do that?  Does anything break?  Can I just put whatever
> in there and everything still works?  If nothing breaks, why isn't this "MAY"
> or something that doesn't use a BCP 14 keyword?  If something breaks, why
> isn't
> this a MUST?
> 
> In 3.4:
> 
> "Each EE SHOULD know its own identity to fill the sender field."
> 
> What happens if I don't?  And what interoperability aspect fails if I don't
> know my own identity?  Should this be better expressed as "Each EE SHOULD
> fill
> the sender field with its own identity?"  Why isn't that a MUST?
> 
> The two SHOULDs at the bottom of 3.5 seem suspect too.  Since you're giving
> me
> a choice, I'm within specifications to consider the input valid if all of those
> tests fail.  Is that what's intended?
> 
> I'm not going to get into any of them past the bottom of Section 3, but
> hopefully you can see what I'm getting at.  I would typically DISCUSS this
> pattern, but since I'm so late to the party, I'll leave it to Roman to decide
> how much this observation weighs on the strength of the document.
> 
>