Mike Bishop has entered the following ballot position for draft-ietf-anima-brski-prm-18: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for a clear and well-structured document. Two points that I hope are easily addressed, and then I'll update my ballot to No Objection: RFC 8995 predates draft-ietf-uta-require-tls13, obviously, since the latter is also with the IESG now. This document only restates 8995's TLS requirements on the registrar and the MASA, so those don't have to change here. However, in Section 7.3, should the REQUIRED/SHOULD alignment of TLS versions be swapped at least for the Registrar-Agent to match the new guidance? For new protocols, TLS 1.3 ought to be the requirement; TLS 1.2 is permitted. (Non-blocking: Consider whether to make corresponding requirements on the registrar and MASA when BRSKI-PRM is being used. However, without updating 8995, this would effectively make both versions mandatory for servers supporting both BRSKI and BRSKI-PRM.) Can you give me a quick overview of the thinking between when you use the HTTP status codes 401 vs. 403? This document seems to use both 401 and 403 for various forms of failed authentication. In general, 401 means "I don't know who you are" and 403 means "I know who you are, and you don't get to do that." I don't see any language around the WWW-Authenticate response field RFC 9110 requires in a 401 response, for example. There may be BRSKI legacy here as well, but I'd like to understand a little better first. Given that you're passing around self-authenticating objects, there are multiple levels of authentication going on here that make it tricky. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please see https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/ for more details on handling ballot positions. These comments are offered purely to improve the document, and their incorporation is at the discretion of the authors and the responsible AD. ===================== In 5.1, can the contents of the slide be extracted and placed as a figure in the document, or is there a reason we need to deep-link into an old presentation? Section 7.3 appears in neither of the tables in 6.2/6.3; upon further reading, I see that's because the endpoint is already defined in RFC8995. However, as the behavior is modified in this document I suggest noting the existence of behavior changes in 6.3, even if it's not a new endpoint. It helps make Section 6 a more complete roadmap of the forthcoming section. The third paragraph of 6.3.1 seems unclear. Perhaps reword this? Check your usage of the terms "HTTP(S)", "HTTPS", and "HTTP-over-TLS". I assume that the first two are intended to differentiate when TLS is optional and when it's required, but the latter two seem duplicative of each other. Some of the 2119 language in 7.x is unneeded; a few examples: - "MUST begin" could simply be "begins". The Agent is acting in its own time when it wants to begin the process. - "SHALL trigger" could simply be "triggers", and so on. - "MASA ... MUST support the same formats" is simply a statement of a correct deployment, not a protocol conformance issue. If the MASA doesn't support the format, the agent will get the 415 status code described below. The requirements on the formats of the messages are appropriate 2119 targets, however, as is the Pledge's response when a trigger message is received. Given the multiple ways that processing caCerts could fail, it might be worth permitting some optional error detail in 7.7.2 for the Registrar-Agent to log and/or debug. Appendix A.2 defines the culinary term "parboiled" and references its use in RFC 8995. It appears that while 8995 uses it in the filename of one example, it does not use the term to define any portion of the protocol, nor does this document. If its use is widespread among implementers and it is useful/necessary to know, elevate it to a Section 2 definition and use it as appropriate throughout the document. Otherwise, it seems like the term could be dropped entirely without loss of clarity. Nits: - Section 4 has several extraneous commas. - Expand "incl." in 5.1 - Consider expanding/defining CMS on first use or in Terminology, including a reference directly to RFC 5652 - Section 7.6, inconsistent capitalization of R/registrar and "to optimize [this process]"? - Section 7.7, extra comma after "only be done" - Section 11 has bullet points that render as in-line asterisks _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
