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.
> # 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
> # 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.
> 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.
> 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.
> ----------------------------------------------------------------------
> 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.
> - 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.
{
Note that we avoided 418. We really wanted to :-)
Well, technically it would have been: "You are teapot"
}
--
] 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
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
