Max, I suggest that we add some text to section 2 to indicate that BRSKI EST
connections SHOULD be HTTP 1.1 persistent connections.
I wrote:
<t>Establishment of the TLS connection for bootstrapping is as
specified in EST <xref target="RFC7030"/> section 4.1.1 "Bootstrap
Distribution of CA Certificates" <xref target="RFC7030"/>.
While EST section 3.2 does not insist
upon use of HTTP 1.1 persistent
connections, BRSKI connections SHOULD use
persistent connections. This is due to the provisional state
that occurs in the TLS connection.
The following extensions are added for automation:
</t>We may also want to say something about HTTP 2.0's multiplexed request/responses (I think we don't want them). I'm not sure exactly what the list of things we don't want yet, or how to express this. I am sure that we don't want QUIC (or SPDY) or other stuff like that! I don't know if the binary-ness of HTTP2 matters to use at all in the end, and we should just let that upgrade path simply proceeed. The other question is about the use of 102 Processing codes, and 201 Created codes. I think that we discussed making /requestvoucher more RESTful by returning a 201 Created, along with a Location: header, and decided against it. I think that I'm partly re-opening this question. (Shall I make it a ticket) The reason for my question is about Registrar->MASA interactions that need to occur, and timeouts that might occur. Returning a 201 Created pointing to a URL that could be used to retrieve the resulting voucher would provide a nice way to do things. If upon the pledge issuing the GET, the voucher still isn't ready, a 102 Processing code could be returned. I'm particularly concerned that the pledge not set too-short timeouts here, as the only recourse it would have is to close the connection. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
