DNS Stateful Operations
draft-ietf-dnsop-session-signal-20
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-03-15
|
20 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-02-11
|
20 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-01-22
|
20 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-12-11
|
20 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-12-10
|
20 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-12-07
|
20 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-12-07
|
20 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2018-12-07
|
20 | (System) | RFC Editor state changed to EDIT |
2018-12-07
|
20 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-12-07
|
20 | (System) | Announcement was received by RFC Editor |
2018-12-07
|
20 | (System) | IANA Action state changed to In Progress |
2018-12-07
|
20 | Amy Vezza | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2018-12-07
|
20 | Amy Vezza | IESG has approved the document |
2018-12-07
|
20 | Amy Vezza | Closed "Approve" ballot |
2018-12-07
|
20 | Amy Vezza | Ballot approval text was generated |
2018-12-06
|
20 | Ted Lemon | New version available: draft-ietf-dnsop-session-signal-20.txt |
2018-12-06
|
20 | (System) | New version approved |
2018-12-06
|
20 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-12-06
|
20 | Ted Lemon | Uploaded new revision |
2018-12-06
|
19 | Mirja Kühlewind | [Ballot comment] Thanks for address my discuss! ------------------------ These are old comments for the record: 1) sec 3: I really find it a bit strange … [Ballot comment] Thanks for address my discuss! ------------------------ These are old comments for the record: 1) sec 3: I really find it a bit strange that there is normative language about error handling (as well as in the "same service instance" definition part) in the terminology section. Maybe move those paragraphs somewhere else...? Also the part about "long-lived operations" and messages types provides far more information than just terminology and I would recommend to also move it into an own section or maybe just have it as part of the intro. 2) Maybe call section 5 "Protocol specification" instead of "Protocol details"...? 3) Sec 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)." I don't get this. Which part of section 3? Given section 3 is on terminology and this is a normative statement, I would recommend to spell out here explicitly what is meant. Do you mean the protocol must be connection-oriented, reliable, and providing in-order delivery? Any thing else? However, given that you say two paragraphs onwards that this spec is only applicable for the use with TCP and TLS/TCP, do you even need to specify these requirements normatively? 4) sec 5.1 "It is a common convention that protocols specified to run over TLS are given IANA service type names ending in "-tls"." Not sure this is true. Isn't it usually just an "s" at the end? Or with registry are you talking about? 5) sec 5.1: "In some environments it may be known in advance by external means that both client and server support DSO, ..." I guess the client and server also need to know if TLS is supported or not. Maybe spell this out as well. 6) sec 5.1: "... therefore either client or server may be the initiator of a message." Maybe s/initiator of a message/initiator of a message exchange/ 7) sec 5.1.2: "Having initiated a connection to a server, possibly using zero round- trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send multiple response-requiring DSO request messages to the server in succession without having to wait for a response to the first request message to confirm successful establishment of a DSO session." Why is the ability to send more than one request related to TCP Fast Open/TLS1.3 0-RTT? These are two independent mechanisms to speed up processing. Mentioning TCP Fast Open/TLS1.3 0-RTT here is rather confusing. Respectively I also don't think that the sentence: "Similarly, DSO supports zero round-trip operation." is describing quite the same. 8) Further please provide references to TCP Fast Open and TLS1.3 and maybe rephrase this paragraph to use normative language: "Caution must be taken to ensure that DSO messages sent before the first round-trip is completed are idempotent, or are otherwise immune to any problems that could be result from the inadvertent replay that can occur with zero round-trip operation." Maybe just: "DSO messages sent with TLS1.3 0-RTT before the TLS handshake is completed or in TCP SYN data with use of TCP Fast Open MUST be idempotent." However, this is actually already required by TLS1.3 and TFO, so there is after all no need to just rephrase this requirement here (at least not normatively). I think it would be more useful for every DSO message type to specify if it can be sent in 0-RTT or not and require this for specification of future TLVs. 9) sec 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." This sentence seems a bit non-sensical, which probably isn't great for a normative sentence. If a session is terminated and open of the other end, doesn't that mean that you have two sessions? 10) sec 5.1.3: "A middlebox that is not doing a strict pass-through will have no way to know on which connection to forward a DSO message, and therefore will not be able to behave incorrectly." I'm not sure I understand this sentence. Can you clarify? 11) As already briefly mentioned by Ben, there is quite some redundant text in sec 5 (with 5.2) for handling of message IDs and TLVs. Given this text is normative, I would really recommend to only specify it clearly once. Please also check the rest of the doc further things that are specified normatively multiple times. It usually makes it must clearer to specify it only once, at least normatively, at the appropriate position in the doc. 12) sec 5.3.1: "When a DSO unacknowledged message is unsuccessful for some reason, .." What does unsuccessful mean here? Can you clarify? 13) sec 6.5.2: "A corporate DNS server that knows it is serving only clients on the internal network, with no intervening NAT gateways or firewalls, can impose a higher keepalive interval, because frequent keepalive traffic is not required." I guess in this scenario it is probably most appropriate to not send any keep-alives… 14) sec 6.6: " o The server application software terminates unexpectedly (perhaps due to a bug that makes it crash)." This bullet point does not really make sense to me because at that time when the app is crashed there is no way for the server anymore to perform any actions. 15) sec 7.1: "When a client is sending its second and subsequent Keepalive DSO requests to the server, the client SHOULD continue to request its preferred values each time. " I don't understand the SHOULD here.. what else should be client put in these field instead...? 16) sec 7.1.2: "Once a DSO Session has been established, if either client or server receives a DNS message over the DSO Session that contains an EDNS(0) TCP Keepalive option, this is a fatal error and the receiver of the EDNS(0) TCP Keepalive option MUST forcibly abort the connection immediately." This is normatively specified multiple time (3?) in the doc. Please consider to only specify it once where most appropriate (probably section 7.1.2) 16) sec 7.1: "The Keepalive TLV is not used as an Additional TLV." This is redundant with the normative sentence in the next paragraph. Maybe just remove this sentence...? 17) +1 to Ben's discuss regarding the reconnection of clients. A TCP RST can be sent for many reasons and waiting for an hour seems not appropriate. I would rather recommend to log an error and directly try to reconnect. |
2018-12-06
|
19 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2018-12-06
|
19 | Ted Lemon | New version available: draft-ietf-dnsop-session-signal-19.txt |
2018-12-06
|
19 | (System) | New version approved |
2018-12-06
|
19 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-12-06
|
19 | Ted Lemon | Uploaded new revision |
2018-10-23
|
18 | Ted Lemon | New version available: draft-ietf-dnsop-session-signal-18.txt |
2018-10-23
|
18 | (System) | New version approved |
2018-10-23
|
18 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-10-23
|
18 | Ted Lemon | Uploaded new revision |
2018-10-23
|
17 | Ted Lemon | New version available: draft-ietf-dnsop-session-signal-17.txt |
2018-10-23
|
17 | (System) | New version approved |
2018-10-23
|
17 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-10-23
|
17 | Ted Lemon | Uploaded new revision |
2018-10-01
|
16 | Benjamin Kaduk | [Ballot comment] Thank you for resolving my Discuss points! [COMMENT section unchanged from original ballot; contents may no longer apply] Six authors exceeds five, so … [Ballot comment] Thank you for resolving my Discuss points! [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. |
2018-10-01
|
16 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2018-09-26
|
16 | Ted Lemon | New version available: draft-ietf-dnsop-session-signal-16.txt |
2018-09-26
|
16 | (System) | New version approved |
2018-09-26
|
16 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-09-26
|
16 | Ted Lemon | Uploaded new revision |
2018-09-17
|
15 | Benjamin Kaduk | [Ballot 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 … [Ballot 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. |
2018-09-17
|
15 | Benjamin Kaduk | [Ballot comment] [COMMENT section unchanged from original ballot; contents may no longer apply] Six authors exceeds five, so "there is likely to be discussion" about … [Ballot 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. |
2018-09-17
|
15 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2018-09-12
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-09-12
|
15 | Ted Lemon | New version available: draft-ietf-dnsop-session-signal-15.txt |
2018-09-12
|
15 | (System) | New version approved |
2018-09-12
|
15 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-09-12
|
15 | Ted Lemon | Uploaded new revision |
2018-08-09
|
14 | Wesley Eddy | Closed request for Telechat review by TSVART with state 'Overtaken by Events' |
2018-08-02
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-08-02
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-08-02
|
14 | Ted Lemon | New version available: draft-ietf-dnsop-session-signal-14.txt |
2018-08-02
|
14 | (System) | New version approved |
2018-08-02
|
14 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-08-02
|
14 | Ted Lemon | Uploaded new revision |
2018-08-02
|
13 | Ignas Bagdonas | [Ballot comment] What is the status of running code for this? Are there any known and interoperable implementations? This is in the context of IETF … [Ballot comment] What is the status of running code for this? Are there any known and interoperable implementations? This is in the context of IETF 102 plenary discussion on implementations and interoperability. |
2018-08-02
|
13 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-08-02
|
13 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-08-02
|
13 | Spencer Dawkins | [Ballot comment] Thanks for addressing my Discuss, and for considering my comments. I'll stick the Discuss text here for ease of archaeology. --- previous Discuss … [Ballot comment] Thanks for addressing my Discuss, and for considering my comments. I'll stick the Discuss text here for ease of archaeology. --- previous Discuss I really like this document, and think it's headed the right direction. Of course I have four pages of comments, because reasons, but the only part I'm really confused about is this one ... I would have thought that if you end up with a different endpoint because your anycast address now resolves differently, the new endpoint would have to have shared a lot of state with the previous endpoint, for this to work: 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. What I would have expected to happen, is that the new endpoint sees a packet arrive that's not on a synchronized TCP connection, and immediately responds with a RST (reset), rather than the normal keepalive and TCP connection timeout process happening. That's also the way I'm reading https://tools.ietf.org/html/rfc7828#section-3.6. Is that not the way it's working for anycast these days? --- end of previous Discuss Everything else is a comment, so non-blocking, and please do the right thing. This is a nit, and your answer could be "no", and that's fine, but in some places this document uses "DSO keepalive", and in other places, "keepalive" with no qualifier. It's likely that less confusion would result if you could consistently call this "DSO keepalive", so that it is clearly NOT a TCP keepalive. Do the right thing, of course. Is the expectation that DSO would also be used in DNS over HTTP? I'm reading At the time of publication, DSO is specified only for DNS over TCP [RFC1035] [RFC7766], and for DNS over TLS over TCP [RFC7858]. Any use of DSO over some other connection technology needs to be specified in an appropriate future document. and noticing that https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-12 is currently in IETF Last Call. This next one is well within the "Spencer wouldn't have done it this way, but Spencer's not the working group, or the IETF" range, but However, in the typical case a server will not know in advance whether a client supports DSO, so in general, unless it is known in advance by other means that a client does support DSO, a server MUST NOT initiate DSO request messages or DSO unacknowledged messages until a DSO Session has been mutually established by at least one successful DSO request/response exchange initiated by the client, as described below. Similarly, unless it is known in advance by other means that a server does support DSO, a client MUST NOT initiate DSO unacknowledged messages until after a DSO Session has been mutually established. seems fragile, especially in environments where clients can come and go, and servers may be addressed using anycast (so I knew in advance that the four servers at that anycast address supported DSO, but somebody installed a fifth server that does not). Is that unlikely to be a problem? I'm sure A single server may support multiple services, including DNS Updates [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and other services, for one or more DNS zones. When a client discovers that the target server for several different operations is the same target hostname and port, the client SHOULD use a single shared DSO Session for all those operations. A client SHOULD NOT open multiple connections to the same target host and port just because the names being operated on are different or happen to fall within different zones. This requirement is to reduce unnecessary connection load on the DNS server. is correct from the server side, but perhaps it's also worth noting that using multiple TCP connections unnecessarily increases the chances that data transfers happen during TCP slow start. If only one or two packets are being exchanged, that doesn't matter, but as more packets are exchanged, the difference increases, because congestion windows will grow more rapidly if fewer connections are used. I appreciate the inclusion of 5.4. DSO Response Generation But I've gotta ask. In the last paragraph of that section, I see o Use a networking API that lets the receiver signal to the TCP implementation that the receiver has received and processed a client request for which it will not be generating any immediate response. This allows the TCP implementation to operate efficiently in both cases; for requests that generate a response, the TCP ACK, window update, and DSO response are transmitted together in a single TCP segment, and for requests that do not generate a response, the application-layer software informs the TCP implementation that it should go ahead and send the TCP ACK and window update immediately, without waiting for the Delayed ACK timer. Unfortunately it is not known at this time which (if any) of the widely-available networking APIs currently include this capability. I would love to know if there are any widely-available network APIs that include this capability, before including this text in a standards-track RFC. Do you need help chasing this down? The text in 6.1. DSO Session Initiation seems rough to me, for a couple of reasons. The client may perform as many DNS operations as it wishes using the newly created DSO Session. Operations SHOULD be pipelined (i.e., the I don't understand why this would be a SHOULD. At least from the client's perspective, it's not needed for interoperation. client doesn't need wait for a response before sending the next message). 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. Is it correct to say that "responses to those messages SHOULD be sent when they become available, even if the responses are sent out of order"? If not, I'm probably missing what "when appropriate" means. I'm a bit mystified by this text in 6.2. DSO Session Timeouts In the usual case where the inactivity timeout is shorter than the keepalive interval, it is only when a client has a very long-lived, low-traffic, operation that the keepalive interval comes into play, to ensure that a sufficient residual amount of traffic is generated to maintain NAT and firewall state and to assure client and server that they still have connectivity to each other. I think the basics are correct - the inactivity timer and (DSO) keepalive interval are independent - but I'm struggling to think of a reason to send (DSO) keepalives that's NOT tied to maintaining NAT/firewall state, and there's a lot of text before the paragraph that mentions NAT/firewall, that talks about why either interval might be longer or shorter than the other, without considering NAT/firewall. Am I missing something here? ... and, now that I keep reading, 6.5.2. Values for the Keepalive Interval does a much better job of explaining how a (DSO) keepalive interval should be selected - I think you could reasonably delete most of the text about (DSO) keepalive intervals in section 6.2, and at most provide a forward pointer to 6.5.2. (As an aside, I think you probably want to cite https://tools.ietf.org/html/bcp142 as the operative recommendation for NAT behaviour toward TCP, since https://tools.ietf.org/html/rfc5382 has been updated) I found this text For long-lived DNS Stateful operations (such as a Push Notification subscription [I-D.ietf-dnssd-push] or a Discovery Relay interface subscription [I-D.ietf-dnssd-mdns-relay]), an operation is considered in progress for as long as the operation is active, until it is cancelled. This means that a DSO Session can exist, with active operations, with no messages flowing in either direction, for far longer than the inactivity timeout, and this is not an error. This is why there are two separate timers: the inactivity timeout, and the keepalive interval. Just because a DSO Session has no traffic for an extended period of time does not automatically make that DSO Session "inactive", if it has an active operation that is awaiting events. to be extremely helpful, but it's 28 pages into the document. Is there a place earlier in the document that describes these timers, where you could place this text? Maybe section 3/Terminology isn't the right place, but maybe there is a right place toward the front of the document. I'm not understanding why the SHOULDs are not MUSTs in this text: If, at any time during the life of the DSO Session, twice the inactivity timeout value (i.e., 30 seconds by default), or five seconds, if twice the inactivity timeout value is less than five seconds, elapses without there being any operation active on the DSO Session, the server SHOULD consider the client delinquent, and SHOULD forcibly abort the DSO Session. Perhaps part of my confusion is that I'm not sure what it means to "consider the client delinquent", but NOT to "forcibly abort the DSO session". But there are several "will forcibly abort"s in section 6.4.2, that sound more like MUST than SHOULD. I don't think the MUST NOT in Normally a server MUST NOT close a DSO Session with a client. A server only causes a DSO Session to be ended in the exceptional circumstances outlined below. is quite right. Given that you have a bulleted list of reasons why a server would violate the MUST not immediately following this sentence, you might want to say "Normally a server does not close" here. |
2018-08-02
|
13 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to Yes from Discuss |
2018-08-02
|
13 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-08-01
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-08-01
|
13 | Ted Lemon | New version available: draft-ietf-dnsop-session-signal-13.txt |
2018-08-01
|
13 | (System) | New version approved |
2018-08-01
|
13 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-08-01
|
13 | Ted Lemon | Uploaded new revision |
2018-08-01
|
12 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-08-01
|
12 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-08-01
|
12 | Ben Campbell | [Ballot comment] Substantive Comments: §5.1," If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI ([TBA2] tentatively 11), then … [Ballot 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 |
2018-08-01
|
12 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-07-31
|
12 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-07-31
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-07-31
|
12 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4358 IMPORTANT S 5.3. > field set to zero, and MUST NOT elicit a response. … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4358 IMPORTANT S 5.3. > field set to zero, and MUST NOT elicit a response. > > Every DSO request message (QR=0) with a nonzero MESSAGE ID field is > an acknowledged DSO request, and MUST elicit a corresponding response > (QR=1), which MUST have the same MESSAGE ID in the DNS message header > as in the corresponding request. How do I handle duplicate message IDs on the responder? Did I miss where you said this? Is this just an error? S 9.3. > > Requests to register additional new DSO Type Codes in the > "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert > Review [RFC8126]. At the time of publication of this document, the > Designated Expert for the newly created DSO Type Code registry is > [*TBD*]. What is the standard for the expert to follow COMMENTS S 1. > is appended to the end of the DNS message header. When displayed > using packet analyzer tools that have not been updated to recognize > the DSO format, this will result in the DSO data being displayed as > unknown additional data after the end of the DNS message. It is > likely that future updates to these tools will add the ability to > recognize, decode, and display the DSO data. I'm sure you will get to this soon, but what are the backward compatibility implications for the two endpoints. S 3. > The unqualified term "session" in the context of this document means > the exchange of DNS messages over a connection where: > > o The connection between client and server is persistent and > relatively long-lived (i.e., minutes or hours, rather than > seconds). This is a surprising taxonomy. I would assume that some of the options you are proposing would be relevant with a 30s connection (very long by HTTP standards!) S 3. > Where this specification says, "close gracefully," that means sending > a TLS close_notify (if TLS is in use) followed by a TCP FIN, or the > equivalents for other protocols. Where this specification requires a > connection to be closed gracefully, the requirement to initiate that > graceful close is placed on the client, to place the burden of TCP's > TIME-WAIT state on the client rather than the server. Does this mean that the server will ask the client to close? S 3. > connection to be closed gracefully, the requirement to initiate that > graceful close is placed on the client, to place the burden of TCP's > TIME-WAIT state on the client rather than the server. > > Where this specification says, "forcibly abort," that means sending a > TCP RST, or the equivalent for other protocols. In the BSD Sockets Because you bother to mention TLS above, what about non-close_notify TLS alerts? S 3. > the server's listening socket. > > 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. Might be helpful to say earlier that this is a request/response protocol S 3. > > DNS Stateful Operations uses three kinds of message: "DSO request > messages", "DSO response messages", and "DSO unacknowledged > messages". A DSO request message elicits a DSO response message. > DSO unacknowledged messages are unidirectional messages and do not > generate any response. This would be useful further up. S 5.1. > > DNS over plain UDP [RFC0768] is not appropriate since it fails on the > requirement for in-order message delivery, and, in the presence of > NAT gateways and firewalls with short UDP timeouts, it fails to > provide a persistent bi-directional communication channel unless an > excessive amount of keepalive traffic is used. Note that this is going to make things not work super-well with DNS- over-QUIC unless you use one stream only. S 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 this a SHOULD and not a MUST? S 5.1.3. > to any problems that could be result from the inadvertent replay that > can occur with zero round-trip operation. > > 5.1.3. Middlebox Considerations > > Where an application-layer middlebox (e.g., a DNS proxy, forwarder, I'm having trouble with this section. Is it a set of requirements on middleboxes or statements of fact? If the latter, it seems like there are a bunch of ways for middleboxes to mess things up, S 5.4. > generate a response, the application-layer software informs the > TCP implementation that it should go ahead and send the TCP ACK > and window update immediately, without waiting for the Delayed ACK > timer. Unfortunately it is not known at this time which (if any) > of the widely-available networking APIs currently include this > capability. Are you going to make a recommendation here? S 6.6.1.2. > client a Retry Delay message, or by forcibly aborting the underlying > transport connection) the client SHOULD try to reconnect, to that > service instance, or to another suitable service instance, if more > than one is available. If reconnecting to the same service instance, > the client MUST respect the indicated delay, if available, before > attempting to reconnect. Do you want to recommend some sort of randomness around this value to avoid avalanche? S 8.2. > The table below indicates, for each of the three TLVs defined in this > document, whether they are valid in each of ten different contexts. > > The first five contexts are requests or unacknowledged messages from > client to server, and the corresponding responses from server back to > client: Nit. This text is a tiny bit hard to read, because you don't list S-P, etc. S 10. > messages are subject to the same constraints as any other DNS-over- > TLS messages and MUST NOT be sent in the clear before the TLS session > is established. > > The data field of the "Encryption Padding" TLV could be used as a > covert channel. Why not require this to be 0, then? |
2018-07-31
|
12 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot discuss] 1) In addition to the bullet point in the 6.2 that was flagged by Spencer, I would like to discuss the content of … [Ballot discuss] 1) In addition to the bullet point in the 6.2 that was flagged by Spencer, I would like to discuss the content of section 5.4. (DSO Response Generation). I understand the desire to optimize for the case where the application knows that no data will be sent as reply to a certain message, however, TCP does not have a notion of message boundaries and therefore cannot and should not act based on the reception of a certain message. Indicating to the TCP that an ACK can be set immediately in an specific situation is also problematic as ACK processing is part of the TCP's internal machinery. However, why it is important at all that an TCP-level ACK is send out fast than the delayed ACK timer? The ACK receiver does not expose the information when an ACK is received to the application and the delayed ACK timer only expires if no further data is received/send by the ACK-receiver, therefore this optimization should not have any impact in the application performance. I would just recommend to remove this section and any additional discussion about delayed ACKs. Please note that the problem described in [NagleDA] only occurs for request-response protocols where no further request can be sent before the response is received. This is not the case in this protocol (as pipelining is supported). 2) Further regarding keep-alives: in sec 6.5.2: "For example, a hypothetical keepalive interval value of 100ms would result in a continuous stream of at least ten messages per second, in both directions, to keep the DSO Session alive." This does not seems correct. There should be at max one keep-alives message in flight. Thus the keep-laives timer should only be restarted after the keep-alive reply was received. Also: "And, in this extreme example, a single packet loss and retransmission over a long path could introduce a momentary pause in the stream of messages, long enough to cause the server to overzealously abort the connection." This doesn't really make sense to me: As I said, TCP will retransmit and the keep-alive timer should not be running until the reply is received. If you want to abort the connection based on keep-alives quickly before the TCP connection indicates you a failure, you need to wait at minimum for an interval that is larger than the TCP RTO (with is uaually 3 RTTs) which means you basically need to know the RTT. Also sec 7.1: "If the client does not generate the mandated keepalive traffic, then after twice this interval the server will forcibly abort the connection." Why must the server terminate the connection at all if the client refuses to send keep-alives? Isn't that what the inactivity timer is meant for? Usually only the endpoint that initiates the keep-alive should terminate the connection if no response is received. 3) There is another contraction regarding the inactive timer: Sec 6.2 say "A shorter inactivity timeout with a longer keepalive interval signals to the client that it should not speculatively keep an inactive DSO Session open for very long without reason, but when it does have an active reason to keep a DSO Session open, it doesn't need to be sending an aggressive level of keepalive traffic to maintain that session." which indicates that the client may leave the session open longer than indicated by the inactive timer of the server. However section 7.1.1 say that the client MUST close the connection when the timer is expired. |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot comment] 1) sec 3: I really find it a bit strange that there is normative language about error handling (as well as in the … [Ballot comment] 1) sec 3: I really find it a bit strange that there is normative language about error handling (as well as in the "same service instance" definition part) in the terminology section. Maybe move those paragraphs somewhere else...? Also the part about "long-lived operations" and messages types provides far more information than just terminology and I would recommend to also move it into an own section or maybe just have it as part of the intro. 2) Maybe call section 5 "Protocol specification" instead of "Protocol details"...? 3) Sec 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)." I don't get this. Which part of section 3? Given section 3 is on terminology and this is a normative statement, I would recommend to spell out here explicitly what is meant. Do you mean the protocol must be connection-oriented, reliable, and providing in-order delivery? Any thing else? However, given that you say two paragraphs onwards that this spec is only applicable for the use with TCP and TLS/TCP, do you even need to specify these requirements normatively? 4) sec 5.1 "It is a common convention that protocols specified to run over TLS are given IANA service type names ending in "-tls"." Not sure this is true. Isn't it usually just an "s" at the end? Or with registry are you talking about? 5) sec 5.1: "In some environments it may be known in advance by external means that both client and server support DSO, ..." I guess the client and server also need to know if TLS is supported or not. Maybe spell this out as well. 6) sec 5.1: "... therefore either client or server may be the initiator of a message." Maybe s/initiator of a message/initiator of a message exchange/ 7) sec 5.1.2: "Having initiated a connection to a server, possibly using zero round- trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send multiple response-requiring DSO request messages to the server in succession without having to wait for a response to the first request message to confirm successful establishment of a DSO session." Why is the ability to send more than one request related to TCP Fast Open/TLS1.3 0-RTT? These are two independent mechanisms to speed up processing. Mentioning TCP Fast Open/TLS1.3 0-RTT here is rather confusing. Respectively I also don't think that the sentence: "Similarly, DSO supports zero round-trip operation." is describing quite the same. 8) Further please provide references to TCP Fast Open and TLS1.3 and maybe rephrase this paragraph to use normative language: "Caution must be taken to ensure that DSO messages sent before the first round-trip is completed are idempotent, or are otherwise immune to any problems that could be result from the inadvertent replay that can occur with zero round-trip operation." Maybe just: "DSO messages sent with TLS1.3 0-RTT before the TLS handshake is completed or in TCP SYN data with use of TCP Fast Open MUST be idempotent." However, this is actually already required by TLS1.3 and TFO, so there is after all no need to just rephrase this requirement here (at least not normatively). I think it would be more useful for every DSO message type to specify if it can be sent in 0-RTT or not and require this for specification of future TLVs. 9) sec 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." This sentence seems a bit non-sensical, which probably isn't great for a normative sentence. If a session is terminated and open of the other end, doesn't that mean that you have two sessions? 10) sec 5.1.3: "A middlebox that is not doing a strict pass-through will have no way to know on which connection to forward a DSO message, and therefore will not be able to behave incorrectly." I'm not sure I understand this sentence. Can you clarify? 11) As already briefly mentioned by Ben, there is quite some redundant text in sec 5 (with 5.2) for handling of message IDs and TLVs. Given this text is normative, I would really recommend to only specify it clearly once. Please also check the rest of the doc further things that are specified normatively multiple times. It usually makes it must clearer to specify it only once, at least normatively, at the appropriate position in the doc. 12) sec 5.3.1: "When a DSO unacknowledged message is unsuccessful for some reason, .." What does unsuccessful mean here? Can you clarify? 13) sec 6.5.2: "A corporate DNS server that knows it is serving only clients on the internal network, with no intervening NAT gateways or firewalls, can impose a higher keepalive interval, because frequent keepalive traffic is not required." I guess in this scenario it is probably most appropriate to not send any keep-alives… 14) sec 6.6: " o The server application software terminates unexpectedly (perhaps due to a bug that makes it crash)." This bullet point does not really make sense to me because at that time when the app is crashed there is no way for the server anymore to perform any actions. 15) sec 7.1: "When a client is sending its second and subsequent Keepalive DSO requests to the server, the client SHOULD continue to request its preferred values each time. " I don't understand the SHOULD here.. what else should be client put in these field instead...? 16) sec 7.1.2: "Once a DSO Session has been established, if either client or server receives a DNS message over the DSO Session that contains an EDNS(0) TCP Keepalive option, this is a fatal error and the receiver of the EDNS(0) TCP Keepalive option MUST forcibly abort the connection immediately." This is normatively specified multiple time (3?) in the doc. Please consider to only specify it once where most appropriate (probably section 7.1.2) 16) sec 7.1: "The Keepalive TLV is not used as an Additional TLV." This is redundant with the normative sentence in the next paragraph. Maybe just remove this sentence...? 17) +1 to Ben's discuss regarding the reconnection of clients. A TCP RST can be sent for many reasons and waiting for an hour seems not appropriate. I would rather recommend to log an error and directly try to reconnect. |
2018-07-30
|
12 | Mirja Kühlewind | Ballot comment and discuss text updated for Mirja Kühlewind |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot discuss] 1) In addition to the bullet point in the 6.2 that was flagged by Spencer, I would like to discuss the content of … [Ballot discuss] 1) In addition to the bullet point in the 6.2 that was flagged by Spencer, I would like to discuss the content of secton 5.4. DSO Response Generation. I understand the desire to optmize for the case where the application knows that no data will be sent as reply to a certain message. However, TCP does not have a notion of message boundaries and therfore cannot and should not act based on the reception of a certain message. Indicating to the TCP that an ACK can be set immediately in an specfic situation is also problematic as ACK processing is part of the TCP's internal machinery. However, why it is important at all that an TCP-level ACK is send out fast than the delayed ACK timer? The ACK receiver does not expose the information when an ACK is received to the application and the delayed ACK timer only expires if no further data is received/send by the ACK-receiver, therefore this optimization should not have any impact in the application performance. I would just recomend to remove this section and any additional discussion about delayed ACKs. Please note that the problem described in [NagleDA] only occurs for request-repsonse protocols where not further request can be sent before the response is received. This is not the case in this protocol. 2) Furthe regarding keep-alives in sec 6.5.2: "For example, a hypothetical keepalive interval value of 100ms would result in a continuous stream of at least ten messages per second, in both directions, to keep the DSO Session alive." This does not seems correct. There should be at max one keep-a-lives message in flight. Thus the keep-lives timer should be restarted when the keep-alive reply was receiced. Also: "And, in this extreme example, a single packet loss and retransmission over a long path could introduce a momentary pause in the stream of messages, long enough to cause the server to overzealously abort the connection." This doesn't really make sense to me: As I said, TCP will retransmit and the keep-alives timer should not be running until the reply is receiced. if you want to abort the connection based on keep-alives quickly before the TCP connection indicates you a failure, you need to wait at minimum for an interval that is larger than the TCP RTO (with is uaually 3 RTTs). |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot comment] 1) sec 3: I really find it a bot strange that there is normative language about error handling (as well as in "same … [Ballot comment] 1) sec 3: I really find it a bot strange that there is normative language about error handling (as well as in "same service instance" definition) in the terminology section. Maybe move those paragraphs somewhere else...? Also the part about "long-lived operations" and messages types provides far more information than just terminology and I would recommend to also move it into an own section or maybe just have it as part of the intro. 2) Maybe call section 5 "Protocol specification" instead of "Protocol details"...? 3) Sec 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)." I don't get this. Which part of section 3? Given section 3 is on terminology and this is a normative statement, I would recommend to spell out here explicitly what is meant. Do you mean the protocol must be connection-oriented, reliable, and providing in-order delivery? Any thing else? However, given that you say two paragraphs onwards that this spec is only applicable for the use with TCP and TLS/TCP, do you even need to specify these requirements normatively? 4) sec 5.1 "It is a common convention that protocols specified to run over TLS are given IANA service type names ending in "-tls"." Not sure this is true. Isn't it usually just an "s" at the end? Or with registry are you talking about? 5) sec 5.1: "In some environments it may be known in advance by external means that both client and server support DSO, ..." I guess the client and server also need to know if TLS is supported or not. Maybe spell this out as well. 6) sec 5.1: "... therefore either client or server may be the initiator of a message." Maybe s/initiator of a message/initiator of a message exchange/ 7) sec 5.1.2: "Having initiated a connection to a server, possibly using zero round- trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send multiple response-requiring DSO request messages to the server in succession without having to wait for a response to the first request message to confirm successful establishment of a DSO session." Why is the ability to send more than one request related to TCP Fast Open/TLS1.3 0-RTT? These are two inpedendent mechanisms to speed up processing. Meanting TCP Fast Open/TLS1.3 0-RTT here is rather confusing. Respectively I also don't think that the sentence: "Similarly, DSO supports zero round-trip operation." is descibing quite the same. 8) Further please provide references to TCP Fast Open and TLS1.3 maybe maybe rephrase this paragraph to use normative language: "Caution must be taken to ensure that DSO messages sent before the first round-trip is completed are idempotent, or are otherwise immune to any problems that could be result from the inadvertent replay that can occur with zero round-trip operation." Maybe just: "DSO messages sent with TLS1.3 0-RTT before the TLS handshake is completed or in TCP SYN data with use of TCP Fast Open MUST be idempotent." However, this is actually already required by TLS1.3 and TFO, so there is after all no need to just rephrase this requirement here (at least not normatively). I think it would be more useful for every DSO message type to specify if it can be sent in 0-RTT or not and require this for specification of future TLVs. 9) sec 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." This sentence seems a bit non-sensical, which probably isn't great for a normative sentence. If a session is terminated and open of the other end, doesn't that mean that you have two sessions? 10) sec 5.1.3: "A middlebox that is not doing a strict pass-through will have no way to know on which connection to forward a DSO message, and therefore will not be able to behave incorrectly." I'm not sure I understand this sentence. Can you clarify? 11) As already briefly mentioned by Ben, there is quite some redundant text in sec 5 (with 5.2) for handling of message IDs and TLVs. Given this text is normative, I would really recommend to only specify it clearly once. 12) sec 5.3.1: "When a DSO unacknowledged message is unsuccessful for some reason, .." What does unsuccessful mean here? Can you clarify? 13) sec 6.5.2: "A corporate DNS server that knows it is serving only clients on the internal network, with no intervening NAT gateways or firewalls, can impose a higher keepalive interval, because frequent keepalive traffic is not required." I guess in this scenrios it is probably most appropriate to not send any keepalives... |
2018-07-30
|
12 | Mirja Kühlewind | Ballot comment and discuss text updated for Mirja Kühlewind |
2018-07-30
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot discuss] In addition to the bullet point in the 6.2 that was flagged by Spencer, I would like to discuss the content of secton … [Ballot discuss] In addition to the bullet point in the 6.2 that was flagged by Spencer, I would like to discuss the content of secton 5.4. DSO Response Generation. I understand the desire to optmize for the case where the application knows that no data will be sent as reply to a certain message. However, TCP does not have a notion of message boundaries and therfore cannot and should not act based on the reception of a certain message. Indicating to the TCP that an ACK can be set immediately in an specfic situation is also problematic as ACK processing is part of the TCP's internal machinery. However, why it is important at all that an TCP-level ACK is send out fast than the delayed ACK timer? The ACK receiver does not expose the information when an ACK is received to the application and the delayed ACK timer only expires if no further data is received/send by the ACK-receiver, therefore this optimization should not have any impact in the application performance. I would just recomend to remove this section and any additional discussion about delayed ACKs. Please note that the problem described in [NagleDA] only occurs for request-repsonse protocols where not further request can be sent before the response is received. This is not the case in this protocol. |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to Discuss from No Record |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot comment] 1) sec 3: I really find it a bot strange that there is normative language about error handling (as well as in "same … [Ballot comment] 1) sec 3: I really find it a bot strange that there is normative language about error handling (as well as in "same service instance" definition) in the terminology section. Maybe move those paragraphs somewhere else...? Also the part about "long-lived operations" and messages types provides far more information than just terminology and I would recommend to also move it into an own section or maybe just have it as part of the intro. 2) Maybe call section 5 "Protocol specification" instead of "Protocol details"...? 3) Sec 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)." I don't get this. Which part of section 3? Given section 3 is on terminology and this is a normative statement, I would recommend to spell out here explicitly what is meant. Do you mean the protocol must be connection-oriented, reliable, and providing in-order delivery? Any thing else? However, given that you say two paragraphs onwards that this spec is only applicable for the use with TCP and TLS/TCP, do you even need to specify these requirements normatively? 4) sec 5.1 "It is a common convention that protocols specified to run over TLS are given IANA service type names ending in "-tls"." Not sure this is true. Isn't it usually just an "s" at the end? Or with registry are you talking about? 5) sec 5.1: "In some environments it may be known in advance by external means that both client and server support DSO, ..." I guess the client and server also need to know if TLS is supported or not. Maybe spell this out as well. 6) sec 5.1: "... therefore either client or server may be the initiator of a message." Maybe s/initiator of a message/initiator of a message exchange/ 7) sec 5.1.2: "Having initiated a connection to a server, possibly using zero round- trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send multiple response-requiring DSO request messages to the server in succession without having to wait for a response to the first request message to confirm successful establishment of a DSO session." Why is the ability to send more than one request related to TCP Fast Open/TLS1.3 0-RTT? These are two inpedendent mechanisms to speed up processing. Meanting TCP Fast Open/TLS1.3 0-RTT here is rather confusing. Respectively I also don't think that the sentence: "Similarly, DSO supports zero round-trip operation." is descibing quite the same. 8) Further please provide references to TCP Fast Open and TLS1.3 maybe maybe rephrase this paragraph to use normative language: "Caution must be taken to ensure that DSO messages sent before the first round-trip is completed are idempotent, or are otherwise immune to any problems that could be result from the inadvertent replay that can occur with zero round-trip operation." Maybe just: "DSO messages sent with TLS1.3 0-RTT before the TLS handshake is completed or in TCP SYN data with use of TCP Fast Open MUST be idempotent." However, this is actually already required by TLS1.3 and TFO, so there is after all no need to just rephrase this requirement here (at least not normatively). I think it would be more useful for every DSO message type to specify if it can be sent in 0-RTT or not and require this for specification of future TLVs. 9) sec 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." This sentence seems a bit non-sensical, which probably isn't great for a normative sentence. If a session is terminated and open of the other end, doesn't that mean that you have two sessions? 10) sec 5.1.3: "A middlebox that is not doing a strict pass-through will have no way to know on which connection to forward a DSO message, and therefore will not be able to behave incorrectly." I'm not sure I understand this sentence. Can you clarify? 11) As already briefly mentioned by Ben, there is quite some redundant text in sec 5 (with 5.2) for handling of message IDs and TLVs. Given this text is normative, I would really recommend to only specify it clearly once. 12) sec 5.3.1: "When a DSO unacknowledged message is unsuccessful for some reason, .." What does unsuccessful mean here? Can you clarify? |
2018-07-30
|
12 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot comment] 1) sec 3: I really find it a bot strange that there is normative language about error handling (as well as in "same … [Ballot comment] 1) sec 3: I really find it a bot strange that there is normative language about error handling (as well as in "same service instance" definition) in the terminology section. Maybe move those paragraphs somewhere else...? Also the part about "long-lived operations" and messages types provides far more information than just terminology and I would recommend to also move it into an own section or maybe just have it as part of the intro. 2) Maybe call section 5 "Protocol specification" instead of "Protocol details"...? 3) Sec 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)." I don't get this. Which part of section 3? Given section 3 is on terminology and this is a normative statement, I would recommend to spell out here explicitly what is meant. Do you mean the protocol must be connection-oriented, reliable, and providing in-order delivery? Any thing else? However, given that you say two paragraphs onwards that this spec is only applicable for the use with TCP and TLS/TCP, do you even need to specify these requirements normatively? 4) sec 5.1 "It is a common convention that protocols specified to run over TLS are given IANA service type names ending in "-tls"." Not sure this is true. Isn't it usually just an "s" at the end? Or with registry are you talking about? 5) sec 5.1: "In some environments it may be known in advance by external means that both client and server support DSO, ..." I guess the client and server also need to know if TLS is supported or not. Maybe spell this out as well. 6) sec 5.1: "... therefore either client or server may be the initiator of a message." Maybe s/initiator of a message/initiator of a message exchange/ 7) sec 5.1.2: "Having initiated a connection to a server, possibly using zero round- trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send multiple response-requiring DSO request messages to the server in succession without having to wait for a response to the first request message to confirm successful establishment of a DSO session." Why is the ability to send more than one request related to TCP Fast Open/TLS1.3 0-RTT? These are two inpedendent mechanisms to speed up processing. Meanting TCP Fast Open/TLS1.3 0-RTT here is rather confusing. Respectively I also don't think that the sentence: "Similarly, DSO supports zero round-trip operation." is descibing quite the same. 8) Further please provide references to TCP Fast Open and TLS1.3 maybe maybe rephrase this paragraph to use normative language: "Caution must be taken to ensure that DSO messages sent before the first round-trip is completed are idempotent, or are otherwise immune to any problems that could be result from the inadvertent replay that can occur with zero round-trip operation." Maybe just: "DSO messages sent with TLS1.3 0-RTT before the TLS handshake is completed or in TCP SYN data with use of TCP Fast Open MUST be idempotent." However, this is actually already required by TLS1.3 and TFO, so there is after all no need to just rephrase this requirement here (at least not normatively). I think it would be more useful for every DSO message type to specify if it can be sent in 0-RTT or not and require this for specification of future TLVs. 10) As already briefly mentioned by Ben, there is quite some redundant text in sec 5 for handling of message IDs and TLVs. Given this text is normative, I would really recommend to only specify it clearly once. 9) sec 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." This sentence seems a bit non-sensical, which probably isn't great for a normative sentence. If a session is terminated and open of the other end, doesn't that mean that you have two sessions? 10) sec 5.1.3: "A middlebox that is not doing a strict pass-through will have no way to know on which connection to forward a DSO message, and therefore will not be able to behave incorrectly." I'm not sure I understand this sentence. Can you clarify? |
2018-07-30
|
12 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-07-30
|
12 | Mirja Kühlewind | [Ballot comment] 1) sec 3: I really find it a bot strange that there is normative language about error handling (as well as in "same … [Ballot comment] 1) sec 3: I really find it a bot strange that there is normative language about error handling (as well as in "same service instance" definition) in the terminology section. Maybe move those paragraphs somewhere else...? Also the part about "long-lived operations" and messages types provides far more information than just terminology and I would recommend to also move it into an own section or maybe just have it as part of the intro. 2) Maybe call section 5 "Protocol specification" instead of "Protocol details"...? 3) Sec 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)." I don't get this. Which part of section 3? Given section 3 is on terminology and this is a normative statement, I would recommend to spell out here explicitly what is meant. Do you mean the protocol must be connection-oriented, reliable, and providing in-order delivery? Any thing else? However, given that you say two paragraphs onwards that this spec is only applicable for the use with TCP and TLS/TCP, do you even need to specify these requirements normatively? 4) sec 5.1 "It is a common convention that protocols specified to run over TLS are given IANA service type names ending in "-tls"." Not sure this is true. Isn't it usually just an "s" at the end? Or with registry are you talking about? 5) sec 5.1: "In some environments it may be known in advance by external means that both client and server support DSO, ..." I guess the client and server also need to know if TLS is supported or not. Maybe spell this out as well. 6) sec 5.1: "... therefore either client or server may be the initiator of a message." Maybe s/initiator of a message/initiator of a message exchange/ 7) sec 5.1.2: "Having initiated a connection to a server, possibly using zero round- trip TCP Fast Open and/or zero round-trip TLS 1.3, a client MAY send multiple response-requiring DSO request messages to the server in succession without having to wait for a response to the first request message to confirm successful establishment of a DSO session." Why is the ability to send more than one request related to TCP Fast Open/TLS1.3 0-RTT? These are two inpedendent mechanisms to speed up processing. Meanting TCP Fast Open/TLS1.3 0-RTT here is rather confusing. Respectively I also don't think that the sentence: "Similarly, DSO supports zero round-trip operation." is descibing quite the same. 8) Further please provide references to TCP Fast Open and TLS1.3 maybe maybe rephrase this paragraph to use normative language: "Caution must be taken to ensure that DSO messages sent before the first round-trip is completed are idempotent, or are otherwise immune to any problems that could be result from the inadvertent replay that can occur with zero round-trip operation." Maybe just: "DSO messages sent with TLS1.3 0-RTT before the TLS handshake is completed or in TCP SYN data with use of TCP Fast Open MUST be idempotent." 9) sec 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." This sentence seems a bit non-sensical, which probably isn't great for a normative sentence. If a session is terminated and open of the other end, doesn't that mean that you have two sessions? 10) sec 5.1.3: "A middlebox that is not doing a strict pass-through will have no way to know on which connection to forward a DSO message, and therefore will not be able to behave incorrectly." I'm not sure I understand this sentence. Can you clarify? |
2018-07-30
|
12 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-07-29
|
12 | Alexey Melnikov | [Ballot comment] Thank you for this document, I find it to be well written and useful. One small nit: In Section 9.3: Requests to … [Ballot comment] Thank you for this document, I find it to be well written and useful. One small nit: In Section 9.3: Requests to register additional new DSO Type Codes in the "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert Review [RFC8126]. At the time of publication of this document, the Designated Expert for the newly created DSO Type Code registry is [*TBD*]. The last sentence is not going to age well (even though it is "TBD"). I think it should be removed from the document and such instructions should be sent separately to IANA in the IESG ballot. |
2018-07-29
|
12 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-07-27
|
12 | Benjamin Kaduk | [Ballot discuss] Hopefully this first point is simple to resolve (whether by changing text or merely un-confusing me). The other ones may require some actual … [Ballot discuss] Hopefully this first point is simple to resolve (whether by changing text or merely un-confusing me). The other ones may require some actual discussion, though. Section 6.6.1.2 has: After a DSO Session is ended by the server (either by sending the client a Retry Delay message, or by forcibly aborting the underlying transport connection) the client SHOULD try to reconnect, to that service instance, or to another suitable service instance, if more than one is available. which seems to contradict the text from Section 3: % [...] Given that these fatal error % conditions signify defective software, and given that defective % software is likely to remain defective for some time until it is % fixed, after forcibly aborting a connection, a client SHOULD refrain % from automatically reconnecting to that same service instance for at % least one hour. Given some other mentions in the document about aborting the connection, it may be that I am just reading the "refrain from reconnecting for an hour" more strongly than I should be. Is Section 5.1.2 expected to be considered an "application protocol profile" that defines the use of TLS 1.3 0-RTT data for DSO? (If so, I do not personally feel that it provides adequate treatment to be considered as such.) I should probably leave this to my (transport-area?) colleagues to discuss further, but I'm not sure that the interaction of this mechanism with high-RTT connections is fully covered -- for example, the inactivity timeout in Section 6.4(.x) could behave poorly when the timeout is set to a smaller value than the RTT, as the server would potentially end up starting the "forcibly abort" process (and potentially causing the client to lose for an hour) because the server's timer starts when it sends the DSO response that initiates its idea of the session, and would not recieve graceful shutdown messages from a properly-behaving client in time. I'm not sure that the behavior specified in Section 7.1.2 is entirely safe. Consider when a client sends a DSO keepalive to try to request a DSO session, but subsequently sends EDNS(0) TCP Keepalive (whether "just in case" or for some other reason). The Server will receive the DSO keepalive and respond, creating a session, but the EDNS(0) TCP Keepalive is already in flight. I don't remember seeing any text that prevents this client behavior explicitly, but that seems like the right sort of thing to do. |
2018-07-27
|
12 | Benjamin Kaduk | [Ballot comment] Six authors exceeds five, so "there is likely to be discussion" about this being too large a number of authors. What is the … [Ballot comment] 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. |
2018-07-27
|
12 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-07-26
|
12 | Spencer Dawkins | [Ballot comment] Everything else is a comment, so non-blocking, and please do the right thing. This is a nit, and your answer could be "no", … [Ballot comment] Everything else is a comment, so non-blocking, and please do the right thing. This is a nit, and your answer could be "no", and that's fine, but in some places this document uses "DSO keepalive", and in other places, "keepalive" with no qualifier. It's likely that less confusion would result if you could consistently call this "DSO keepalive", so that it is clearly NOT a TCP keepalive. Do the right thing, of course. Is the expectation that DSO would also be used in DNS over HTTP? I'm reading At the time of publication, DSO is specified only for DNS over TCP [RFC1035] [RFC7766], and for DNS over TLS over TCP [RFC7858]. Any use of DSO over some other connection technology needs to be specified in an appropriate future document. and noticing that https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-12 is currently in IETF Last Call. This next one is well within the "Spencer wouldn't have done it this way, but Spencer's not the working group, or the IETF" range, but However, in the typical case a server will not know in advance whether a client supports DSO, so in general, unless it is known in advance by other means that a client does support DSO, a server MUST NOT initiate DSO request messages or DSO unacknowledged messages until a DSO Session has been mutually established by at least one successful DSO request/response exchange initiated by the client, as described below. Similarly, unless it is known in advance by other means that a server does support DSO, a client MUST NOT initiate DSO unacknowledged messages until after a DSO Session has been mutually established. seems fragile, especially in environments where clients can come and go, and servers may be addressed using anycast (so I knew in advance that the four servers at that anycast address supported DSO, but somebody installed a fifth server that does not). Is that unlikely to be a problem? I'm sure A single server may support multiple services, including DNS Updates [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and other services, for one or more DNS zones. When a client discovers that the target server for several different operations is the same target hostname and port, the client SHOULD use a single shared DSO Session for all those operations. A client SHOULD NOT open multiple connections to the same target host and port just because the names being operated on are different or happen to fall within different zones. This requirement is to reduce unnecessary connection load on the DNS server. is correct from the server side, but perhaps it's also worth noting that using multiple TCP connections unnecessarily increases the chances that data transfers happen during TCP slow start. If only one or two packets are being exchanged, that doesn't matter, but as more packets are exchanged, the difference increases, because congestion windows will grow more rapidly if fewer connections are used. I appreciate the inclusion of 5.4. DSO Response Generation But I've gotta ask. In the last paragraph of that section, I see o Use a networking API that lets the receiver signal to the TCP implementation that the receiver has received and processed a client request for which it will not be generating any immediate response. This allows the TCP implementation to operate efficiently in both cases; for requests that generate a response, the TCP ACK, window update, and DSO response are transmitted together in a single TCP segment, and for requests that do not generate a response, the application-layer software informs the TCP implementation that it should go ahead and send the TCP ACK and window update immediately, without waiting for the Delayed ACK timer. Unfortunately it is not known at this time which (if any) of the widely-available networking APIs currently include this capability. I would love to know if there are any widely-available network APIs that include this capability, before including this text in a standards-track RFC. Do you need help chasing this down? The text in 6.1. DSO Session Initiation seems rough to me, for a couple of reasons. The client may perform as many DNS operations as it wishes using the newly created DSO Session. Operations SHOULD be pipelined (i.e., the I don't understand why this would be a SHOULD. At least from the client's perspective, it's not needed for interoperation. client doesn't need wait for a response before sending the next message). 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. Is it correct to say that "responses to those messages SHOULD be sent when they become available, even if the responses are sent out of order"? If not, I'm probably missing what "when appropriate" means. I'm a bit mystified by this text in 6.2. DSO Session Timeouts In the usual case where the inactivity timeout is shorter than the keepalive interval, it is only when a client has a very long-lived, low-traffic, operation that the keepalive interval comes into play, to ensure that a sufficient residual amount of traffic is generated to maintain NAT and firewall state and to assure client and server that they still have connectivity to each other. I think the basics are correct - the inactivity timer and (DSO) keepalive interval are independent - but I'm struggling to think of a reason to send (DSO) keepalives that's NOT tied to maintaining NAT/firewall state, and there's a lot of text before the paragraph that mentions NAT/firewall, that talks about why either interval might be longer or shorter than the other, without considering NAT/firewall. Am I missing something here? ... and, now that I keep reading, 6.5.2. Values for the Keepalive Interval does a much better job of explaining how a (DSO) keepalive interval should be selected - I think you could reasonably delete most of the text about (DSO) keepalive intervals in section 6.2, and at most provide a forward pointer to 6.5.2. (As an aside, I think you probably want to cite https://tools.ietf.org/html/bcp142 as the operative recommendation for NAT behaviour toward TCP, since https://tools.ietf.org/html/rfc5382 has been updated) I found this text For long-lived DNS Stateful operations (such as a Push Notification subscription [I-D.ietf-dnssd-push] or a Discovery Relay interface subscription [I-D.ietf-dnssd-mdns-relay]), an operation is considered in progress for as long as the operation is active, until it is cancelled. This means that a DSO Session can exist, with active operations, with no messages flowing in either direction, for far longer than the inactivity timeout, and this is not an error. This is why there are two separate timers: the inactivity timeout, and the keepalive interval. Just because a DSO Session has no traffic for an extended period of time does not automatically make that DSO Session "inactive", if it has an active operation that is awaiting events. to be extremely helpful, but it's 28 pages into the document. Is there a place earlier in the document that describes these timers, where you could place this text? Maybe section 3/Terminology isn't the right place, but maybe there is a right place toward the front of the document. I'm not understanding why the SHOULDs are not MUSTs in this text: If, at any time during the life of the DSO Session, twice the inactivity timeout value (i.e., 30 seconds by default), or five seconds, if twice the inactivity timeout value is less than five seconds, elapses without there being any operation active on the DSO Session, the server SHOULD consider the client delinquent, and SHOULD forcibly abort the DSO Session. Perhaps part of my confusion is that I'm not sure what it means to "consider the client delinquent", but NOT to "forcibly abort the DSO session". But there are several "will forcibly abort"s in section 6.4.2, that sound more like MUST than SHOULD. I don't think the MUST NOT in Normally a server MUST NOT close a DSO Session with a client. A server only causes a DSO Session to be ended in the exceptional circumstances outlined below. is quite right. Given that you have a bulleted list of reasons why a server would violate the MUST not immediately following this sentence, you might want to say "Normally a server does not close" here. |
2018-07-26
|
12 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2018-07-26
|
12 | Spencer Dawkins | [Ballot discuss] I really like this document, and think it's headed the right direction. Of course I have four pages of comments, because reasons, but … [Ballot discuss] I really like this document, and think it's headed the right direction. Of course I have four pages of comments, because reasons, but the only part I'm really confused about is this one ... I would have thought that if you end up with a different endpoint because your anycast address now resolves differently, the new endpoint would have to have shared a lot of state with the previous endpoint, for this to work: 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. What I would have expected to happen, is that the new endpoint sees a packet arrive that's not on a synchronized TCP connection, and immediately responds with a RST (reset), rather than the normal keepalive and TCP connection timeout process happening. That's also the way I'm reading https://tools.ietf.org/html/rfc7828#section-3.6. Is that not the way it's working for anycast these days? |
2018-07-26
|
12 | Spencer Dawkins | [Ballot comment] Everything else is a comment, so non-blocking, and please do the right thing. This is a nit, and your answer could be "no", … [Ballot comment] Everything else is a comment, so non-blocking, and please do the right thing. This is a nit, and your answer could be "no", and that's fine, but in some places this document uses "DSO keepalive", and in other places, "keepalive" with no qualifier. It's likely that less confusion would result if you could consistently call this "DSO keepalive", so that it is clearly NOT a TCP keepalive. Do the right thing, of course. Is the expectation that DSO would also be used in DNS over HTTP? I'm reading At the time of publication, DSO is specified only for DNS over TCP [RFC1035] [RFC7766], and for DNS over TLS over TCP [RFC7858]. Any use of DSO over some other connection technology needs to be specified in an appropriate future document. and noticing that https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-12 is currently in IETF Last Call. This next one is well within the "Spencer wouldn't have done it this way, but Spencer's not the working group, or the IETF" range, but However, in the typical case a server will not know in advance whether a client supports DSO, so in general, unless it is known in advance by other means that a client does support DSO, a server MUST NOT initiate DSO request messages or DSO unacknowledged messages until a DSO Session has been mutually established by at least one successful DSO request/response exchange initiated by the client, as described below. Similarly, unless it is known in advance by other means that a server does support DSO, a client MUST NOT initiate DSO unacknowledged messages until after a DSO Session has been mutually established. seems fragile, especially in environments where clients can come and go, and servers may be addressed using anycast (so I knew in advance that the four servers at that anycast address supported DSO, but somebody installed a fifth server that does not). Is that unlikely to be a problem? I'm sure A single server may support multiple services, including DNS Updates [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and other services, for one or more DNS zones. When a client discovers that the target server for several different operations is the same target hostname and port, the client SHOULD use a single shared DSO Session for all those operations. A client SHOULD NOT open multiple connections to the same target host and port just because the names being operated on are different or happen to fall within different zones. This requirement is to reduce unnecessary connection load on the DNS server. is correct from the server side, but perhaps it's also worth noting that using multiple TCP connections unnecessarily increases the chances that data transfers happen during TCP slow start. If only one or two packets are being exchanged, that doesn't matter, but as more packets are exchanged, the difference increases, because congestion windows will grow more rapidly if fewer connections are used. I appreciate the inclusion of 5.4. DSO Response Generation But I've gotta ask. In the last paragraph of that section, I see o Use a networking API that lets the receiver signal to the TCP implementation that the receiver has received and processed a client request for which it will not be generating any immediate response. This allows the TCP implementation to operate efficiently in both cases; for requests that generate a response, the TCP ACK, window update, and DSO response are transmitted together in a single TCP segment, and for requests that do not generate a response, the application-layer software informs the TCP implementation that it should go ahead and send the TCP ACK and window update immediately, without waiting for the Delayed ACK timer. Unfortunately it is not known at this time which (if any) of the widely-available networking APIs currently include this capability. I would love to know if there are any widely-available network APIs that include this capability, before including this text in a standards-track RFC. Do you need help chasing this down? The text in 6.1. DSO Session Initiation seems rough to me, for a couple of reasons. The client may perform as many DNS operations as it wishes using the newly created DSO Session. Operations SHOULD be pipelined (i.e., the I don't understand why this would be a SHOULD. At least from the client's perspective, it's not needed for interoperation. client doesn't need wait for a response before sending the next message). 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. Is it correct to say that "responses to those messages SHOULD be sent when they become available, even if the responses are sent out of order"? If not, I'm probably missing what "when appropriate" means. I'm a bit mystified by this text in 6.2. DSO Session Timeouts In the usual case where the inactivity timeout is shorter than the keepalive interval, it is only when a client has a very long-lived, low-traffic, operation that the keepalive interval comes into play, to ensure that a sufficient residual amount of traffic is generated to maintain NAT and firewall state and to assure client and server that they still have connectivity to each other. I think the basics are correct - the inactivity timer and (DSO) keepalive interval are independent - but I'm struggling to think of a reason to send (DSO) keepalives that's NOT tied to maintaining NAT/firewall state, and there's a lot of text before the paragraph that mentions NAT/firewall, that talks about why either interval might be longer or shorter than the other, without considering NAT/firewall. Am I missing something here? ... and, now that I keep reading, 6.5.2. Values for the Keepalive Interval does a much better job of explaining how a (DSO) keepalive interval should be selected - I think you could reasonably delete most of the text about (DSO keepalive intervals in section 6.2, and at most provide a forward pointer to 6.5.2. (As an aside, I think you probably want to cite https://tools.ietf.org/html/bcp142 as the operative recommendation for NAT behaviour toward TCP, since https://tools.ietf.org/html/rfc5382 has been updated) I found this text For long-lived DNS Stateful operations (such as a Push Notification subscription [I-D.ietf-dnssd-push] or a Discovery Relay interface subscription [I-D.ietf-dnssd-mdns-relay]), an operation is considered in progress for as long as the operation is active, until it is cancelled. This means that a DSO Session can exist, with active operations, with no messages flowing in either direction, for far longer than the inactivity timeout, and this is not an error. This is why there are two separate timers: the inactivity timeout, and the keepalive interval. Just because a DSO Session has no traffic for an extended period of time does not automatically make that DSO Session "inactive", if it has an active operation that is awaiting events. to be extremely helpful, but it's 28 pages into the document. Is there a place earlier in the document that describes these timers, where you could place this text? Maybe section 3/Terminology isn't the right place, but maybe there is a right place toward the front of the document. I'm not understanding why the SHOULDs are not MUSTs in this text: If, at any time during the life of the DSO Session, twice the inactivity timeout value (i.e., 30 seconds by default), or five seconds, if twice the inactivity timeout value is less than five seconds, elapses without there being any operation active on the DSO Session, the server SHOULD consider the client delinquent, and SHOULD forcibly abort the DSO Session. Perhaps part of my confusion is that I'm not sure what it means to "consider the client delinquent", but NOT to "forcibly abort the DSO session". But there are several "will forcibly abort"s in section 6.4.2, that sound more like MUST than SHOULD. I don't think the MUST NOT in Normally a server MUST NOT close a DSO Session with a client. A server only causes a DSO Session to be ended in the exceptional circumstances outlined below. is quite right. Given that you have a bulleted list of reasons why a server would violate the MUST not immediately following this sentence, you might want to say "Normally a server does not close" here. |
2018-07-26
|
12 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2018-07-26
|
12 | Joel Halpern | Request for Telechat review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list. |
2018-07-26
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2018-07-26
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2018-07-26
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-07-26
|
12 | Tom Pusateri | New version available: draft-ietf-dnsop-session-signal-12.txt |
2018-07-26
|
12 | (System) | New version approved |
2018-07-26
|
12 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-07-26
|
12 | Tom Pusateri | Uploaded new revision |
2018-07-16
|
11 | David Schinazi | Added to session: IETF-102: dnssd Thu-0930 |
2018-07-06
|
11 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Jana Iyengar |
2018-07-06
|
11 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Jana Iyengar |
2018-07-05
|
11 | Joel Halpern | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Joel Halpern. Sent review to list. |
2018-07-05
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2018-07-05
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2018-07-04
|
11 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-07-04
|
11 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-07-03
|
11 | Cindy Morgan | Placed on agenda for telechat - 2018-08-02 |
2018-07-03
|
11 | Warren Kumari | Ballot has been issued |
2018-07-03
|
11 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2018-07-03
|
11 | Warren Kumari | Created "Approve" ballot |
2018-07-03
|
11 | Warren Kumari | Ballot writeup was changed |
2018-07-02
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-07-02
|
11 | Tom Pusateri | New version available: draft-ietf-dnsop-session-signal-11.txt |
2018-07-02
|
11 | (System) | New version approved |
2018-07-02
|
11 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-07-02
|
11 | Tom Pusateri | Uploaded new revision |
2018-06-25
|
10 | Shwetha Bhandari | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Shwetha Bhandari. Sent review to list. |
2018-06-25
|
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-06-21
|
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2018-06-21
|
10 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-session-signal-10. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-session-signal-10. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, DNS OpCodes registry on the Domain Name System (DNS) Parameters registry page located at: https://www.iana.org/assignments/dns-parameters/ a single, new registration is to be made as follows: OpCode: [ TBD-at-Registration ] Name: DNS Stateful Operations Reference: [ RFC-to-be ] We note that the authors have suggested a value of 6 for this registration. Second, in the DNS Rcode registry also on the Domain Name System (DNS) Parameters registry page located at: https://www.iana.org/assignments/dns-parameters/ a single, new registration is to be made as follows: RCODE: [ TBD-at-Registration ] Name: DSO Description: DNS Stateful Operations Reference: [ RFC-to-be ] We note that the authors have suggested a value of 11 for this registration. Third, a new registry is to be created called the DSO Type Code Registry. The new registry will be located on the Domain Name System (DNS) Parameters registry page located at: https://www.iana.org/assignments/dns-parameters/ +-----------+---------------------------+----------+-----------+ | Type | Name | Status | Reference | +-----------+---------------------------+----------+-----------+ | 0000 | Reserved | Standard | RFC-to-be | | | | | | | 0001 | KeepAlive | Standard | RFC-TBD | | | | | | | 0002 | RetryDelay | Standard | RFC-TBD | | | | | | | 0003 | EncryptionPadding | Standard | RFC-TBD | | | | | | | 0004-003F | Unassigned, reserved for | | | | | DSO session-management | | | | | TLVs | | | | | | | | | 0040-F7FF | Unassigned | | | | | | | | | F800-FBFF | Reserved for | | | | | experimental/local use | | | | | | | | | FC00-FFFF | Reserved for future | | | | expansion | | | +----------+----------------------------+----------+-----------+ DSO Type Code zero is reserved and is not currently intended for allocation. Registrations of new DSO Type Codes in the "Reserved for DSO session-management" range 0004-003F and the "Reserved for future expansion" range FC00-FFFF require publication of an IETF Standards Action document as defined in RFC 8126. Requests to register additional new DSO Type Codes in the "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert Review as defined in RFC 8126. DSO Type Codes in the "experimental/local" range F800-FBFF may be used as Experimental Use or Private Use values as defined in RFC 8126 and may be used freely for development purposes, or for other purposes within a single site. The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-06-15
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Gillmor |
2018-06-15
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Gillmor |
2018-06-15
|
10 | Joel Halpern | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list. |
2018-06-14
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2018-06-14
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2018-06-12
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2018-06-12
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2018-06-11
|
10 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-06-11
|
10 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-06-25): From: The IESG To: IETF-Announce CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-session-signal@ietf.org, Tim … The following Last Call announcement was sent out (ends 2018-06-25): From: The IESG To: IETF-Announce CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-session-signal@ietf.org, Tim Wicinski , warren@kumari.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (DNS Stateful Operations) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Stateful Operations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-06-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions, using type-length-value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header opcode and result code which has different message semantics. This document updates RFC 7766 by redefining a session, providing new guidance on connection re-use, and providing a new mechanism for handling session idle timeouts. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-06-11
|
10 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-06-11
|
10 | Warren Kumari | Last call was requested |
2018-06-11
|
10 | Warren Kumari | Last call announcement was generated |
2018-06-11
|
10 | Warren Kumari | Ballot approval text was generated |
2018-06-11
|
10 | Warren Kumari | Ballot writeup was generated |
2018-06-11
|
10 | Warren Kumari | Some known nits: https://mailarchive.ietf.org/arch/msg/dnsop/-QZ-uMlkb6VOboJvKvaZap1BDvw (so they don't get lost) |
2018-06-11
|
10 | Warren Kumari | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-06-07
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-06-07
|
10 | Tom Pusateri | New version available: draft-ietf-dnsop-session-signal-10.txt |
2018-06-07
|
10 | (System) | New version approved |
2018-06-07
|
10 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-06-07
|
10 | Tom Pusateri | Uploaded new revision |
2018-06-02
|
09 | Warren Kumari | "Revised I-D suggested" :-) |
2018-06-02
|
09 | Warren Kumari | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-05-29
|
09 | Warren Kumari | IESG state changed to AD Evaluation from Publication Requested |
2018-05-16
|
09 | Tom Pusateri | New version available: draft-ietf-dnsop-session-signal-09.txt |
2018-05-16
|
09 | (System) | New version approved |
2018-05-16
|
09 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-05-16
|
09 | Tom Pusateri | Uploaded new revision |
2018-05-16
|
08 | Tom Pusateri | New version available: draft-ietf-dnsop-session-signal-08.txt |
2018-05-16
|
08 | (System) | New version approved |
2018-05-16
|
08 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-05-16
|
08 | Tom Pusateri | Uploaded new revision |
2018-05-15
|
07 | Tim Wicinski | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. Shepherd Write up for draft-ietf-dnsop-session-signal (1) The RFC is Proposed Standard, and this is proper as it's adding a new DNS OPCODE. (2) Technical Summary: This document is defining a new DNS OPCODE, for DNS Stateful Operations (DSO). These DSO messages communicate with persistent stateful DNS sessions. Working Group Summary: The Working Group spent an inordinate amount of time on this document, as there was some concern that this was attempting to extend the reach of DNS beyond the scope of the working group. However, after several iterations, the working group came to consensus on the document, and strong consensus to move forward. Document Quality: There are currently no existing implementations of the protocol. However, this work is being leveraged in another working group on DNS Service Discovery. Now that this draft is moving forward, final implementations can begin to emergy. Personnel: Document Shepherd is Tim Wicinski, Area Director is Warren Kumari (3) The Document Shepherd did a detailed review, both for subject matter as well as editorial issues. The document is of high quality, which is also in part due to the iterations the working group committed to this document. (4) The Shepherd has no concerns about the depth of breath of the reviews. (5) The document has had broad DNS review, but there is no feeling additional reviews are mandatory (though all are welcome). (6) The Shepherd has no concerns. (7) There are no IPR disclosures and this has been confirmed. (8) No IPR disclosures. (9) There is solid working group consensus behind this document. (10) No appeals have been threatened. (11) Nits: The Document references older versions of other documents. The authors are planning to update this as it moves forward. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1035, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7766, but the abstract doesn't seem to mention this, which it should. (12) N/A (13) All references within this document have been identified as either normative or informative. (14) There are no normative references which are not ready. (15) There are no downward normative references. (16) This RFC will update 1035 and 7766, and they are listed on the Title page. They are *not* listed in the Abstract, which the authors will address. (17) The IANA considerations section has been reviewed and are consistent. New registries are clearly identified and they contain initial contents, and allocations procedures. (18) The "DSO Type Code Registry" requires Expert Review to register new DS0 Type Codes in the "Unassigned" range. This can be handled by the current DNS Expert Review process. |
2018-05-15
|
07 | Tim Wicinski | Responsible AD changed to Warren Kumari |
2018-05-15
|
07 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2018-05-15
|
07 | Tim Wicinski | IESG state changed to Publication Requested |
2018-05-15
|
07 | Tim Wicinski | IESG process started in state Publication Requested |
2018-05-15
|
07 | Tim Wicinski | Changed document writeup |
2018-03-20
|
07 | Tim Chown | Added to session: IETF-101: dnssd Thu-0930 |
2018-03-19
|
07 | Stuart Cheshire | New version available: draft-ietf-dnsop-session-signal-07.txt |
2018-03-19
|
07 | (System) | New version approved |
2018-03-19
|
07 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Ted Lemon , Stuart Cheshire |
2018-03-19
|
07 | Stuart Cheshire | Uploaded new revision |
2018-03-05
|
06 | Tom Pusateri | New version available: draft-ietf-dnsop-session-signal-06.txt |
2018-03-05
|
06 | (System) | New version approved |
2018-03-05
|
06 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , dnsop-chairs@ietf.org, Ray Bellis , John Dickinson , Allison Mankin , Stuart Cheshire , … Request for posting confirmation emailed to previous authors: Sara Dickinson , dnsop-chairs@ietf.org, Ray Bellis , John Dickinson , Allison Mankin , Stuart Cheshire , Tom Pusateri |
2018-03-05
|
06 | Tom Pusateri | Uploaded new revision |
2018-02-04
|
05 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Document |
2018-01-26
|
05 | Stuart Cheshire | New version available: draft-ietf-dnsop-session-signal-05.txt |
2018-01-26
|
05 | (System) | New version approved |
2018-01-26
|
05 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Allison Mankin , Stuart Cheshire |
2018-01-26
|
05 | Stuart Cheshire | Uploaded new revision |
2017-11-12
|
04 | David Schinazi | Added to session: IETF-100: dnssd Wed-0930 |
2017-09-13
|
04 | Sara Dickinson | New version available: draft-ietf-dnsop-session-signal-04.txt |
2017-09-13
|
04 | (System) | New version approved |
2017-09-13
|
04 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Allison Mankin , Stuart Cheshire |
2017-09-13
|
04 | Sara Dickinson | Uploaded new revision |
2017-07-19
|
03 | Tim Chown | Added to session: IETF-99: dnssd Wed-1520 |
2017-07-03
|
03 | Tom Pusateri | New version available: draft-ietf-dnsop-session-signal-03.txt |
2017-07-03
|
03 | (System) | New version approved |
2017-07-03
|
03 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Allison Mankin , Stuart Cheshire |
2017-07-03
|
03 | Tom Pusateri | Uploaded new revision |
2017-03-28
|
02 | Tim Chown | Added to session: IETF-98: dnssd Tue-1640 |
2017-03-13
|
02 | Stuart Cheshire | New version available: draft-ietf-dnsop-session-signal-02.txt |
2017-03-13
|
02 | (System) | New version approved |
2017-03-13
|
02 | (System) | Request for posting confirmation emailed to previous authors: Sara Dickinson , Tom Pusateri , Ray Bellis , John Dickinson , Allison Mankin , Stuart Cheshire |
2017-03-13
|
02 | Stuart Cheshire | Uploaded new revision |
2016-11-09
|
01 | Tim Chown | Added to session: IETF-97: dnssd Thu-0930 |
2016-10-31
|
01 | Stuart Cheshire | New version available: draft-ietf-dnsop-session-signal-01.txt |
2016-10-31
|
01 | (System) | New version approved |
2016-10-31
|
00 | (System) | Request for posting confirmation emailed to previous authors: "John Dickinson" , "Tom Pusateri" , "Allison Mankin" , "Ray Bellis" , "Sara Dickinson" , "Stuart Cheshire" |
2016-10-31
|
00 | Stuart Cheshire | Uploaded new revision |
2016-08-15
|
00 | Tim Wicinski | Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com> |
2016-08-15
|
00 | Tim Wicinski | Document shepherd changed to Tim Wicinski |
2016-08-15
|
00 | Tim Wicinski | Changed consensus to Yes from Unknown |
2016-08-15
|
00 | Tim Wicinski | Intended Status changed to Proposed Standard from None |
2016-08-15
|
00 | Tim Wicinski | This document now replaces draft-bellis-dnsop-session-signal instead of None |
2016-08-15
|
00 | Tom Pusateri | New version available: draft-ietf-dnsop-session-signal-00.txt |