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

[Claudio Allocchio <[e-mail]>]

On Tue, 5 Nov 2024, Brockhaus, Hendrik wrote:

> 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.

Hello Hendrik and all,

yes I think with the updates all my comments are addressed !

for me now it is "ready to go" :-)

all the best
>
> 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
>>
>>
>
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [e-mail]
                        Senior Manager and Advisor
tel: [phone]      Italian Academic and       G=Claudio; S=Allocchio;
fax: [phone]        Research Network         P=garr; A=garr; C=it;

      PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys