Magnus Westerlund has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, A. This is really a discuss discuss. With to little time to dig into the details it appears that this protocol is making i hack of its interface towards the its transport. It appears to attempt to use an HTTP rest interface, but then it is also have a lot of talking about requirement for the TLS connection underlying the HTTP. So to illustrate the issue I see here is what happens if one like to use QUIC as the underlying transport for the rest interface rather than TCP/TLS? So can this document achieve a clearer interface to the lower layers so that it will be simpler to move the protocol to another underlying version of the HTTP "transport"? B. Section 5.6: The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. Referencing RFC 2616 that has been obsolete by RFC 7230 and companions. I do note that there are no normative reference for that part in this document. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
