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 <noreply@xxxxxxxx> > 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 > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
