Re: [lamps] Paul Wouters' Yes on draft-ietf-lamps-lightweight-cmp-profile-16: (with COMMENT)

[Paul Wouters <[e-mail]>]

works for me, thanks

Paul

On Mon, Dec 5, 2022 at 7:55 AM Brockhaus, Hendrik <
[e-mail]> wrote:

> Paul
>
> Thank you for your feedback. Please see the updated
> paragraph below.
>
> Hendrik
>
> > Von: Paul Wouters <[e-mail]>
> >
> > On Dec 1, 2022, at 11:29, Brockhaus, Hendrik
> > <[e-mail]> wrote:
> > >
> > > Paul
> > >
> > > Thank you for your review and comments.
> > > Please see my responses and proposals below.
> > >
> > > Hendrik
> > >
> > >> Von: Paul Wouters via Datatracker <[e-mail]>
> > >>
> > >> ----------------------------------------------------------------------
> > >> COMMENT:
> > >> ----------------------------------------------------------------------
> > >>
> > >>
> > >> In section 6:
> > >>        HTTP SHOULD be used and CoAP MAY be used
> > >>
> > >>        File-based transfer MAY be used in case offline transfer is
> required.
> > >>
> > >> I find these different levels of usage odd. Clearly devices have no
> real
> > choice
> > >> here. If they can support HTTP, there is no need for CoAP. If they
> cannot
> > do
> > >> HTTP and therefor can only do CoAP, there is no choice either. If
> they are
> > >> offline, clearly they cannot use anything but file based transfer. I
> would
> > set
> > >> all of these to MAY ?
> > >
> > > [HB] This statement does not only address end entities, but also RAs or
> > CAs. For
> > > EEs you are right, the EE has little choice. This is different for an
> RA or CA.
> > An EE
> > > may have an online and an offline mode of operation. In this case the
> EE
> > should
> > > use HTTP or CoAP and not file-based transfer if in the online mode.
> > > As you also said, HTTP is preferred over CoAP. Therefore, we stated
> > 'SHOULD be
> > > used' for HTTP and 'MAY be used' for CoAP. Saying MAY equally to all
> > choices
> > > does not express this preference for HTTP.
> > > File-based transfer is clearly a side-line and less preferred to any
> online
> > transfer.
> > > Therefore, we limited the use to the offline case.
> >
> > >
> > > I am uncertain how to phrase it differently and still expressing what
> we
> > want to
> > > say. Any proposal is welcome.
> >
> > Maybe split it? Say that clients likely only support either HTTP or
> CoAP, and
> > maybe offline. That RA and CA capabilities should match the different
> types
> > of clients used, but would gain interoperability if they support all
> methods?
>
> [HB]  OK. I try to rephrase the paragraph.
>
> OLD
>    CMP messages are designed to be self-contained, such that in
>    principle any reliable transfer mechanism can be used.  HTTP SHOULD
>    be used and CoAP MAY be used for online transfer of CMP messages on
>    application layer.  CMP messages MAY also be piggybacked on any other
>    reliable transfer protocol.  File-based transfer MAY be used in case
>    offline transfer is required.
>
> NEW
>    CMP messages are designed to be self-contained, such that in
>    principle any reliable transfer mechanism can be used.  EEs will
>    typically support only one transfer mechanism.  PKI management
>    entities SHOULD offer HTTP and MAY offer CoAP where required.
>    Piggybacking of CMP messages on any other reliable transfer
>    protocol MAY be used, and file-based transfer MAY be used in case
>    offline transfer is required.
>