I'm the assigned HTTPDir reviewer for this document. I have no prior history with ANIMA/BRSKI, but have done some high-level reading of this document's dependencies for context. Take this with a grain of salt if I misunderstood anything about the technologies you've built on top of HTTP.

The underlying protocols are defined in RFCs 8995 and 7030, which already use HTTP for communication between the Pledge (new device) and the Registrar/EST server. This document provides additional detail about a case to which RFC 8995 alludes, in which a Pledge connects over the Internet to a Cloud Registrar rather than a locally discovered one. This Cloud Registrar may then provide the Pledge a voucher for use with an EST server or redirect the Pledge on to other Registrars, one of whom will ultimately provide such a voucher. Both of these are pre-existing flows in BRSKI/EST.

The use of HTTP here is generally good, and some places I have comments mostly appear to be following the conventions of the existing RFCs that this document is not scoped to change.

- The document does not reference any specification for HTTP, despite several instances where the word "HTTP" appears to be intending to point to a specification. Use RFC 9110 here.

- In Section 3.1.1, the document references "brski-registrar.manufacturer.example.com" as an example Registrar URI which is given in RFC 8995, Appendix B. A bare hostname is not a URI; RFC 8995 appears to assume that the URI will have a scheme of "https" and paths of specific resources as described in the protocol. (Similarly, RFC 7030 requires the client to have "sufficient information to form the EST server URI", which can be as little as a bare hostname.) This document attempts to bridge that gap by saying that the client SHOULD be provided a full URI and including typical values for scheme and path. I think this is a good approach, perhaps using similar language to RFC 7030 to describe constructing the URI from provided and typical components.

- In Section 3.2, protocol-specific meanings are attributed to particular status codes in the HTTP response. One of these present in RFC 8995 (404 to mean Validation Failed) seems particularly odd, given that vanilla HTTP would interpret that as the voucher request endpoint not existing, rather than the Pledge's identity not being known to the server. This specification doesn't appear to make the situation any worse, but reviewing Section 4.6 of RFC 9205 may still be useful.

- In Section 3.3, a 307 status code is used to indicate that the client should make a fresh POST with a new payload to the URI indicated in the Location header. The use of 307 as opposed to other 3XX status codes is understandable because the client is intended to make a new POST rather than changing to GET (as would be implied by e.g. a 303). However, generation of a new payload for the new request differs from HTTP redirect handling as described in Section 15.4 of RFC 9110, which says that the same request should be sent to the new URI modulo certain transformations described there. A response type or Link relation might be a more appropriate means of communicating this.

- Similarly, Section 3.3 does not describe the handling for other 3XX responses that a server might legitimately return. For example, it doesn't seem impossible that a server would send a 303 with the location of the requested voucher. This specification should describe generic 3XX handling, unless that is already covered sufficiently in other RFCs.

In the course of reviewing the document, I also had the following non-HTTP comments:

- This document uses the spelling "enrolment" where RFC 8995 uses "enrollment." This appears to be a US/UK spelling variation, but consistency with existing RFCs may be desirable.
- More BRSKI-specific terms are used in this specification than the Terminology section calls out. Consider expanding the list of terms imported from RFC 8995 or simply referencing the whole of its Terminology section.
- Section 1.2.1 doesn't address the case where a local Registrar exists, but the Pledge is intended to use the employer's Registrar instead. Is that in-scope?