Mohamed 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: Mohamed Boucadair via Datatracker <noreply@xxxxxxxx> > Gesendet: Freitag, 11. Oktober 2024 14:39 > > Reviewer: Mohamed Boucadair > Review result: Has Issues > > Hi all, > > This bis is straightforward as it inherits the updates in RFC9480. However, there are > some few items that need further tweaking (listed below in the order they appear in > the text). Nits and editorial suggestions are not echoed here but are provided in the > detailed review (see the links below). > > Overall, the operational considerations are not that distinct vs 6710 except the use > of well-know URI. The authors adequately discuss some required configuration > matters at the client side. That's OK. > > # Obsolete RFC9480 > > Might be wroth to explain that this RFC is obsoleted by this draft **AND ** > rfc4210bis because otherwise it is not evident for readers why other parts of > 9480 is being obsoleted. [HB] I suggest the following change in the Abstract: OLD It includes the updates on RFC 6712 specified in CMP Updates RFC 9480 Section 3 and obsoleted both documents. 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. > > # Back "..generally considered bad practice.." with a reference > > I know this text was in 6712, however I think adding a pointer such as RFC9205 > would be useful for readers to digest what is BCP for these matters. [HB] I propose the following change to Section 1 OLD The usage of HTTP for transferring CMP messages exclusively uses the POST method for requests, effectively tunneling CMP over HTTP. While this is generally considered bad practice and should not be emulated, there are good reasons to do so for transferring CMP. NEW The usage of HTTP for transferring CMP messages exclusively uses the POST method for requests, effectively tunneling CMP over HTTP. While this is generally considered bad practice (see BCP 56 [RFC9205] for best current practice on building protocols with HTTP) and should not be emulated, there are good reasons to do so for transferring CMP. > > # Conflict with RFC 9205? > > CURRENT: > Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support > HTTP/1.1 [RFC9112]. > > This text seems to to conflict with this part in RFC9205: > > <Therefore, it is NOT RECOMMENDED that applications using HTTP specify a > minimum version of HTTP to be used.> > > May be worth to have some words to fall under the following (9205): > > <However, if an application's deployment benefits from the use of a particular > version of HTTP (for example, HTTP/2's multiplexing), this ought be noted.> [HB] We removed the requirement to support HTTP/1.0 OLD Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support HTTP/1.1 [RFC9112]. NEW This draft requires uses of the POST method (Section 3.3) and the "Content- Type" header field (Section 3.4) which are available since HTTP/1.0 [RFC1945]. This specification also specifies use of persistent connections (Section 3.2). This document refers to HTTP/1.1 as specified in [RFC9110] and [RFC9112] for further details. > > # Redundant with RFC 9110 > > CURRENT: > The Content Length header field SHOULD be provided, giving the length of the > ASN.1 encoded PKIMessage. > > The use of normative language seems to be redundant with this part in RFC 9110: > > "A user agent SHOULD send Content-Length in a request when the method defines > a meaning for enclosed content and it is not sending Transfer-Encoding." [HB] Thank you for pointing us at this. We dropped the paragraph on the "Content-Length". > > # "http" scheme in examples > > The examples in Section 3.6 use "http" scheme. I think it is preferable to use "https" > here. [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). > > # Not sure how the following can be assessed > > CURRENT: > While all defined features of the HTTP protocol are available to > implementations, they SHOULD keep the protocol utilization as simple > as possible. > > May simply avoid the normative language here. [HB] Thank you for pointing this out. We dropped the complete Section 3.8. > > # Broken citation > > CURRENT: > ..Section 8.2.3 of [RFC9112]. > > There is no such section in 9112. [HB] Thank you for pointing this out. We dropped the complete Section 3.8. > > # > > More detailed comments can be found here: [HB] Thank you for all further editorial issues. I will incorporate most of them. > > * pdf: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2 > Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2F2024%2Fdraft-ietf- > lamps-rfc6712bis-07- > rev%2520Med.pdf&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Ce2 > d33c7591d541adf88908dce9fa0ef5%7C38ae3bcd95794fd4addab42e1495d55a%7C > 1%7C0%7C638642508222110782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C > %7C&sdata=N3TsqJ%2FO0y%2BDYxVsREm1QPcOMpa0A1O8YQvlIo7ZifE%3D&r > eserved=0 > * doc: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2 > Fboucadair%2FIETF-Drafts- > Reviews%2Fraw%2Frefs%2Fheads%2Fmaster%2F2024%2Fdraft-ietf-lamps- > rfc6712bis-07- > rev%2520Med.docx&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Ce > 2d33c7591d541adf88908dce9fa0ef5%7C38ae3bcd95794fd4addab42e1495d55a%7 > C1%7C0%7C638642508222160319%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=BZ%2FNV6l60kjmIiOo1Lyftyl8TH7Tr43U3bU1QHF8QIg%3D&reserv > ed=0 > > Hope this helps. > > Cheers, > Med > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
