Mike Bishop has entered the following ballot position for draft-ietf-anima-brski-cloud-16: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I previously reviewed draft -11 of this document for the HTTP Directorate; see https://mailarchive.ietf.org/arch/msg/httpbisa/Ny1EanWGyy4IyItpYxHDW8sImiw/. Most of those comments do not appear to have been addressed, so I reiterate them here. # Updates metadata The draft says it updates RFC 8995, but this is not mentioned in the Abstract. # HTTP Reference The draft makes several references to HTTP status codes and headers, but does not have a reference to RFC9110 to define these. # Redirect handling 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 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. ===NITS FOLLOW=== - 2. "Sections Section 7.2 and 8.3." _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
