Inline with [MB]. ________________________________ From: Michael Richardson Sent: Friday, August 1, 2025 11:48 PM To: Mike Bishop Cc: The IESG; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Anima] Mike Bishop's Discuss on draft-ietf-anima-brski-clou d-16: (with DISCUSS and COMMENT)
Mike Bishop via Datatracker <[email protected]> wrote: > ---------------------------------------------------------------------- > 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. Hi Mike, I'm not sure how we missed that review. My appologies. [MB] No worries — it happens! > # Updates metadata > The draft says it updates RFC 8995, but this is not mentioned in the > Abstract. already fixed. > # HTTP Reference > The draft makes several references to HTTP status codes and headers, > but does not have a reference to RFC9110 to define these. Okay. Didn't know about that document. Is this what you had in mind: https://github.com/anima-wg/brski-cloud/pull/247/commits/3e721e8ce55226a3a97cfadfba04d0670a62b11f [MB] I don't know that you need a section reference every time you mention a status code, though you certainly can. I was thinking more of the places you say "as defined by [BRSKI] and HTTP" but HTTP isn't a reference to 9110. Turning that into [HTTP] would make sense. > # 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. We write: The Pledge MUST restart its bootstrapping process by sending a new voucher request message (with a fresh nonce) using the location provided in the HTTP redirect. Except for the nonce, the content is intended to be the same. [MB] Okay, if the payload is otherwise the same, that's fine. (15.4 of RFC9110 does say to consider removing things "where there are security implications," which I presume a reused nonce would have.) > A response type or Link relation might > be a more appropriate means of communicating this. I don't know what you mean here. I think that "Link relation" involves RDF or HTML stuff, and we are not using either. [MB] Link relations are defined in RFC8288, and allow an HTTP header to describe the relationship of other resources to the one being accessed. However, if the redirect payload is the same, redirects will work. > 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. Any other 3xx that redirected to a different origin would have to be rejected outright. 303 with Location: header seems similar to 201+Location: header, which we explicitely allow in the Registrar<->MASA interaction in RFC8995. I can add text explaining why the rest of 3xx are all probably wrong, but I'm not sure about 303 yet. [MB] Yes, it's similar, and a 201 is probably even more appropriate given that the response will need to be unique to the request rather than being an existing resource that satisfies the client's request. The more general point is that just after the section of RFC 9205 you cite below, it says: Because the set of registered HTTP status codes can expand, applications using HTTP should explicitly point out that clients ought to be able to handle all applicable status codes gracefully (i.e., falling back to the generic n00 semantics of a given status code; e.g., 499 can be safely handled as 400 (Bad Request) by clients that don't recognise it). This is preferable to creating a "laundry list" of potential status codes since such a list won't be complete in the foreseeable future. You've defined that the server is expected to return a 307 in most cases, but the client needs to know what to do with other redirects as well. "Fail" is certainly a potential option. > ---------------------------------------------------------------------- > 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. RFC8995's MASA URI Extension (section 2.3.2, and Appendix B) is defined to either be just authority, or the entire URI. I guess we get a bit lose here. The point was to connect to what's in RFC8995 Appendix B. I will change this. How about: -The details of the URI are Manufacturer specific, with BRSKI giving the example "brski-registrar.manufacturer.example.com". - -The Pledge SHOULD be provided with the entire URI of the Cloud Registrar, including the protocol and path components, which are typically "https://"; and "/.well-known/brski", respectively. +The details of the URI are Manufacturer specific. +For example, https://brski-registrar.manufacturer.example.com/.well-known/brski. [MB] Okay, I see the definition in 8995. It's fine to parallel that construction here — copying the language about assuming the scheme and path components if they're omitted, for example. But saying it's manufacturer-specific and leaving them to deal with it works, too. > - 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. Validation Failed from a registrar usually means that the Registrar can not find the Pledge's identity in it's database, does not trust *that* manufacturer, or is not willing to onboard devices that the supply chain process did not mention. 9205 says: Instead, applications using HTTP should define their errors to use the most applicable status code, making generous use of the general status codes (200, 400, and 500) when in doubt. Importantly, they should not specify a one-to-one relationship between status codes and application errors, thereby avoiding the exhaustion issue outlined above. I think that we've tried to do this, and I think that we haven't tried to jump on wrong codes, nor make a one-to-one relationship. We have identified some errors that map to specific codes (so many-to-one). [PROBLEM-DETAILS] could be useful, but who would the pledge tell given that it has no UI or user. Not telling people not to use it. [MB] Ah, so it's a matter of the requested identity/manufacturer not being found on the server. That mapping makes sense with context, thanks. { Note that we avoided 418. We really wanted to :-) Well, technically it would have been: "You are teapot" } [MB] Maybe the pledge could use it from its management interface. One of the few areas of the IETF that could realistically specify a use for 418! -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
