[art] Re: Artart last call review of draft-ietf-lamps-rfc6712bis-07

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

Claudio

Thank you for your review and your comments.
I am sorry for responding so late. The co-authors and I wanted to consolidate the feedback to the different reviews.

Please see my responses to your comments inline below.
The latest version of the draft ready for submission and a diff to the latest version on datatracker are available on github:
- https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.html
- https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-lamps-rfc6712bis&url_2=https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.txt

Please let me know if the proposed changes sufficiently address your comments.

Hendrik

> Von: Claudio Allocchio via Datatracker <[e-mail]>
> Gesendet: Montag, 21. Oktober 2024 08:16
> 
> Reviewer: Claudio Allocchio
> Review result: Almost Ready
> 
> Good morning, I'm the assigned reviewer from the ARTART area.
> This draft is almost ready but I have some suggestions before it is published.
> 
> 1) as any document "updating" a series of previous RFCs, ensuring an easy and
> crystal clear reading of it compared to the other documents being obsoleted or
> updated is tricky. I generally suggest some further detailed wording, or a detailed
> dedicated "updates and obsolets" section where it is clearly listed which sections of
> the previous documents are affected: something like
> 
> * RFCxxxx section x.y.z, <text> is obsoleted
> 
> etc...

[HB] Thank you for pointing this out. I changed the Abstract and Section 1.2 to improve this.
Abstract
OLD
   It includes the updates on RFC 6712 specified in CMP Updates RFC 9480
   Section 3 and obsoleted both documents. These updates introduce CMP
   URIs using a Well-known prefix.
NEW
   It includes the updates to RFC 6712 specified in RFC 9480 Section 3. These
   updates introduce CMP URIs using a Well-known prefix. It obsoletes RFC 6712
   and together with I-D.ietf-lamps-rfc4210bis and it also obsoletes RFC 9480.

Section 1.1
OLD
   CMP Updates [RFC9480] updated [RFC6712], supporting the PKI
   management operations specified in the Lightweight CMP Profile
   [RFC9483], in the following areas:
NEW
   CMP Updates [RFC9480] updated Section 3.6 of [RFC6712],
   supporting the PKI management operations specified in the Lightweight
   CMP Profile [RFC9483], in the following areas:

Section 1.2
OLD
   This document obsoletes RFC 6712 [RFC6712]. It includes the changes
   specified by CMP Updates [RFC9480] Section 3 as described in
   Section 1.1 and added the requirement on providing the Content-Length
   header field in Section 3.4.
NEW
   This document obsoletes [RFC6712]. It includes the changes specified in Section
   3 of [RFC9480] as described in Section 1.1 of this document, removed the
   requirement to support HTTP/1.0 [RFC1945] in accordance with Section 4.1 of
   [RFC9205] and removed Section 3.8 of [RFC6712] as it contains information
   redundant with current HTTP specification.

> 
> 2) clarification about the use of the wide range of HTTP protocol options (section
> 3.8). "SHOULD" is inappropriate normative here --> "should".
> Furthermore, it may be more useful to create a list of suggested HTTP features to
> use or mandatory HTTP features to use, so that all implementation try to stick with
> it, instead of just suggesting not to use the not needed HTTP parts.

[HB] Thank you for pointing this out. We dropped the complete Section 3.8.

> 
> 3) section 3.6 examples: https instead of http ?

[HB] We would prefer keeping "http". The TLS layer is an optional addition, if needed, because
- CMP does not necessarily require transport layer protection if data-origin authentication using MAC-based or signature-based message protection is applied.
- There are cases where an entity initially has no certificate and no trust anchor. In these cases, it would even be unable to perform TLS server authentication.
See also Section 5 Topic 5.

Anyhow, we added the following note to the end of Section 3.6:
NEW
   Note that https can also be used instead of http, see item 5 in the Security
   Considerations (Section 5).

> 
> 4) section 4: shall we suggest also "what to do" (a coherent behaviour) when we hit
> implementations with an old non standard approach in transferring CMP over
> HTTP?

[HB] We updated Section 4 as follows:
OLD
   Implementors should be aware that implementations might exist that
   use a different approach for transferring CMP over HTTP, because
   RFC 6712 [RFC6712] has been under development for more than a
   decade. Further, implementations based on earlier drafts of RFC 6712
   [RFC6712] might use an unregistered "application/pkixcmp-poll" MIME
   type.
NEW
   Implementers should be aware that other implementations might exist that use
   a different approach for transferring CMP over HTTP. Further, implementations
   based on earlier I-Ds the led to [RFC6712] might use an unregistered
   "application/pkixcmp-poll" Media Type. Conforming implementations MAY
   handle this type like "application/pkixcmp".

> 
> all the rest is ok for me.
> 
> all the best
> Claudio
> 
>