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.

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

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

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

# "http" scheme in examples

The examples in Section 3.6 use "http" scheme. I think it is preferable to use "https" here.

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

# Broken citation

CURRENT:
 ..Section 8.2.3 of [RFC9112].

There is no such section in 9112.

# 

More detailed comments can be found here: 

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-lamps-rfc6712bis-07-rev%20Med.pdf
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/refs/heads/master/2024/draft-ietf-lamps-rfc6712bis-07-rev%20Med.docx

Hope this helps.

Cheers,
Med