Ben Campbell has entered the following ballot position for draft-ietf-dnsop-session-signal-12: No Objection
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-dnsop-session-signal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive Comments: §5.1," If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI ([TBA2] tentatively 11), then the client MUST assume that the server does not implement DSO at all. In this case the client is permitted to continue sending DNS messages on that connection, but the client SHOULD NOT issue further DSO messages on that connection." Why is the SHOULD NOT not MUST NOT? Do you envision situations where it might make sense to violate the SHOULD NOT? §5.1.2: Are there security considerations for using zero round trip handshakes? §5.1.3: "In cases where a DSO session is terminated on one side of a middlebox, and then some session is opened on the other side of the middlebox in order to satisfy requests sent over the first DSO session, any such session MUST be treated as a separate session." By what? How would the ultimate endpoints know? §5.2.2.4: " If DSO unacknowledged message is received containing an unrecognized Primary TLV, with a zero MESSAGE ID (indicating that no response is expected), then this is a fatal error and the recipient MUST forcibly abort the connection immediately." Doesn't that make extensibility difficult? What if an extension adds a new unacknowledged message type that uses a new primary TLV? §6.1: "The server MUST act on messages in the order they are transmitted, but responses to those messages SHOULD be sent out of order when appropriate." The SHOULD seems more like a MAY, unless you mean for implementors to go looking for reasons to do things out of order. §6.4.1: Does "consider delinquent" entail any concrete actions beyond resetting the connection? §12.2: It seems like TLS1.3 should be a normative reference, given that it's used to describe the condition for a normative statement. Editorial Comments: - General: Please watch for comma splices. §1: -- " It is likely that future updates to these tools will add the ability to recognize, decode, and display the DSO data." That sentence may not age well. -- " A goal of this approach is to avoid the operational issues that have befallen EDNS(0), particularly relating to middlebox behaviour." Is there something that can be cited to describe the operational issues? §2: There's a fair amount of procedure, including normative statements, described in the terminology section. That would better reserved to the sections that are more about procedure. Some readers only use terminology sections to look up terms on demand; such users may miss the procedure bits. §5.1, "DSO messages MUST be carried in only protocols " "MUST ... only" constructions can be ambiguous. Consider reformulating into a "MUST NOT" construction. §5.1.3: -- 3rd paragraph: Should "stateless" be "stateful"? -- "will have no way to know on which connection to forward a DSO message, and therefore will not be able to behave incorrectly." That seems like famous last words :-) §5.2.3, first paragraph: The MUST NOT seems more like a statement of fact. §5.3: The section has a number of redundant normative keywords. Please consider stating them authoritatively in one place, and making the others descriptive _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
