Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-session-signal-15: 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-dnsop-session-signal/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for resolving most of my DISCUSS points (the additional clarification about when the one-hour retry does (not) apply in particular is helpful even if not strictly needed). However, it seems that my point about an "application protocol profile" for TLS 1.3 0-RTT was deferred until the resolution of a different thread covering 0-RTT, but that we never picked it back up. I think this document's profile needs to provide greater clarity about what specific messages are (or are not) allowed in 0-RTT data, i.e., listing permitted TLVs and having a column in the registry for whether a TLV is 0-RTT-safe. For example, Retry Delay simply cannot appear in a DSO message that is eligible for 0-RTT, so it accordingly cannot appear in a 0-RTT message, while EncryptionPadding should be safe to appear [as an additional TLV], provided there is a suitable primary TLV to attach it to. On first look [after long absence], the keepalive TLV should be safe to use as a 0-RTT primary TLV, since it elicits a response and only affects the current connection. Anyway, my main point here is that we need to place the burden of analysis on a TLV's safety on the authors of the spec introducing that TLV, and not on implementors or users of the protocol. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [COMMENT section unchanged from original ballot; contents may no longer apply] Six authors exceeds five, so "there is likely to be discussion" about this being too large a number of authors. What is the justification for the author count? Do we need to specify some GREASE (per draft-ietf-tls-grease) for new TLV types in order to ensure the proper handling of unknown types? Section-by-section comments follow. Section 1 A DoH reference seems timely/apt. (But maybe then it is only "Some such transports" that can offer persistent sessions.) Maybe give some examples of advantages of server-initiated messages? Are we talking about letting the server push records with larger TTLs or notifying when the response to a query is changing, or just more mundane keepalive-type things? Section 3 The terms "initiator" and "responder" correspond respectively to the initial sender and subsequent receiver of a DSO request message or unacknowledged message, regardless of which was the "client" and "server" in the usual DNS sense. We just defined "client" and "server" explictly (without reference to the "usual DNS sense"), so probably it's best to have this definition refer to the previous client/server definitions or clarify that the above definitions match the "usual DNS sense". When an anycast service is configured on a particular IP address and port, it must be the case that although there is more than one physical server responding on that IP address, each such server can be treated as equivalent. If a change in network topology causes packets in a particular TCP connection to be sent to an anycast server instance that does not know about the connection, the normal keepalive and TCP connection timeout process will allow for recovery. If after the connection is re-established, [...] Perhaps clarifying that "recovery" means "detecting the broken session and starting a new one" would be useful? (I guess Spencer's DISCUSS takes this a different direction.) DSO unacknowledged messages are unidirectional messages and do not generate any response. "Do not generate any response" at the DNS layer; any reason to mention that TCP will still ACK the bytes (or rather, that the "reliable" part of the data stream will need to do so)? Section 5.1 DSO messages MUST be carried in only protocols and in environments where a session may be established according to the definition given above in the Terminology section (Section 3). nit: is this "in only" or "only in" 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. I'm confused how the server would still have proper framing for subsequent DNS messages, since the DSO TLVs would be "spurious extra data" after a request header and potentially subject to misinterpretation as the start of another DNS message header. Section 5.1.3 It is probably worth explicitly noting that a middlebox MUST NOT make/forward a DSO request with TLVs that it does not implement. Section 5.2 If a DSO message is received where any of the count fields are not zero, then a FORMERR MUST be returned, unless a future IETF Standard specifies otherwise. This seems like ... not the conventional wording for this behavior, and subject to large debates about the meaning of "IETF Standard". (Similar language is used elsewhere, too.) Section 5.2.2 The start of this section seems to duplicate a lot of Section 3 -- e.g., the specification of the "Primary TLV"; request/response/unacknowledged as the types of messages; etc. It's unclear to me that this duplication of content is helpful to the reader. Unacknowledged messages MUST NOT be used "speculatively" in cases where the sender doesn't know if the receiver supports the Primary TLV in the message, because there is no way to receive any response to indicate success or failure of the request message (the request message does not contain a unique MESSAGE ID with which to associate a response with its corresponding request). Unacknowledged messages are only appropriate in cases where the sender already knows that the receiver supports, and wishes to receive, these messages. Having gone to the trouble to explicitly define (twice!) "request", "response" and "unacknowledged", it's pretty confusing to then use the English word "request" to refer to an "unacknowledged" message. Section 5.2.2.1 The specification for a TLV states whether that DSO-TYPE may be used in "Primary", "Additional", "Response Primary", or "Response Additional" TLVs. Perhaps this could be wordsmithed to avoid accidental misreading as exclusive-or? Section 5.3.1 When a DSO unacknowledged message is unsuccessful for some reason, the responder immediately aborts the connection. Doesn't this kill the client/server pairing for an hour? "For some reason" is very vague to induce such behavior, and could include transient internal errors. Section 6.1 When would it be appropriate for the server to send responses out of order? Section 6.6.1.1 nit: "RECONNECT DELAY" is used with inconsistent capitalization. Section 7.1 The description of the two timeout fields is predicated on understanding that it is only the response's incarnation of them that is authoritative; as an editorial matter, it might be nice to introduce this fact earlier. Section 7.1.1 It seems like we could consolidate the "equal to" and "greater than" cases into "greater than or equal to". Section 7.2.1 A client MUST NOT send a Retry Delay DSO request message or DSO unacknowledged message to a server. [...] nit: it must not send it as a response, either, so perhaps "MUST NOT send a Retry Delay DSO message to a server" is shorter and better. Section 9.3 I thought IANA liked to see a "registration template" for what subsequent registrations in a registry being created will need to specify. (That said, the IANA state is "IANA OK - Actions Needed", and one might expect that they know better than I do...) Section 10 I'm a little surprised to not see some discussion that this mechanism encourages the maintenance of persistent connections on DNS servers, which encourages the maintenance of persistent connections on DNS servers, which has impact on resource consumption/load, but is not expected to be problematic because the server can tell the clients to go away if needed. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
