Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
draft-ietf-lamps-rfc6712bis-10

# Gunter Van de Velde, RTG AD, comments for draft-ietf-lamps-rfc6712bis-09

# idnits indicates warnings/obsoleted refs

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[[RFC2818], [draft-ietf-anima-brski-ae],
[draft-ietf-lamps-rfc4210bis-12], and [RFC2616].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Reference [RFC5246] to RFC5246, which was obsoleted by RFC8446 (this may be on
purpose).

Reference [RFC2510] to RFC2510, which was obsoleted by RFC4210 (this may be on
purpose).

Section 1, paragraph 6
>  can benefit from utilizing a reliable transport as CMP requires connection a
>                             ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

Section 1, paragraph 7
> ng from the transfer protocol. All theses features are covered by HTTP. Addi
>                                    ^^^^^^
Did you mean "these"?

Section 1.1, paragraph 1
> in Section 1.1 of this document. Additionally it adds the following changes: 
>                                  ^^^^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Additionally".

Thanks to Claudio Allocchio for the ARTART review, and to the authors for addressing the feedback.

I still wonder if section 3.4 should more strongly encourage the use of HTTPS through examples, why not:

```
https://www.example.com/.well-known/cmp

https://www.example.com/.well-known/cmp/<operation>

https://www.example.com/.well-known/cmp/p/<name>

https://www.example.com/.well-known/cmp/p/<name>/<operation>

Note that http can also be used instead of https, see item 5 in the Security Considerations (Section 5).

```

Thank you to Meral Shirazipour for the GENART review.

Many thanks to Lucas Pardue for his HTTPDIR review: https://mailarchive.ietf.org/arch/msg/spasm/YZDm6rcWT_kFNw7gbuqfIgvAtzk/, and thank you to the authors for working with Lucas on addressing his comments.

Again, thanks for the RFC 9480 cleanup!

Thanks for working on this specification. Thanks to Lucas for HTTPDir review which has improved the document.

Now that the rfc4210-bis says the transport protocols MUST be reliable, I think we need to update the text in section 3. Currently it says -

  For direct interaction between two entities, where a reliable transport protocol like TCP [RFC9293] is available, HTTP [RFC9110] SHOULD be utilized for conveying CMP messages. 

If rfc4210-bis is followed the there should not be any unreliale transport to carry CMP message. The current text is written as if the could be unreable transport to carry CMP message.