Httpdir last call review of draft-ietf-anima-brski-cloud-11

Reviewer: Mike Bishop
Review result: On the Right Track

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?

Received on Tuesday, 3 December 2024 22:11:42 UTC