[Anima] two EST question/suggestions

[Michael Richardson <[e-mail]>]

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-