DNS Push Notifications
draft-ietf-dnssd-push-25
Yes
Éric Vyncke
(Suresh Krishnan)
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
Note: This ballot was opened for revision 21 and is now closed.
Éric Vyncke
Yes
Roman Danyliw
No Objection
Comment
(2019-08-07 for -23)
Sent
Reference Nits: -- Section 6.2.1. Please add a citation for “US-ASCII” -- Section 6.5. Please add a citation for “apple dns_sd.h API” Editorial Nits: -- Section 2. Editorial. s/poor imitations/imitation/ -- Section 6. Typo. s/the the/the/
Alexey Melnikov Former IESG member
Yes
Yes
(2019-08-05 for -23)
Sent
This comment is for RFC Editor: On page 21, HTML and text version has "TTL⩾0", which gets mangled in PDF version.
Barry Leiba Former IESG member
Yes
Yes
(2019-08-07 for -24)
Sent
— Section 6.7 — When a client terminates an individual subscription (via UNSUBSCRIBE) or all subscriptions on that DSO session (by ending the session) it is signaling to the server that it is longer interested in receiving those particular updates. Typo: It shoud be “it is no longer interested”.
Suresh Krishnan Former IESG member
Yes
Yes
(for -24)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(for -23)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -23)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2019-08-08 for -24)
Sent
Thanks for this well-written document! What are the privacy considerations to zone content owners (e.g., machine owners listed in a zone) about the availability of near-realtime information tracking their changes? Can we have a discussion of padding policy to attempt to preserve the privacy of push transactions? Section 1.2 Do we need to give a reference for the BSD Sockets API? (I honestly forget what we did for other documents referencing it.) Section 3 Perhaps we should put quotation marks around statements taken from RFC 8490 (so as to avoid the appearance that we are duplicating normative requirements made in that document). Section 5 server in this protocol specification. Additional security measures such as client authentication during TLS negotiation MAY also be employed to increase the trust relationship between client and server. Do we want to say anything about the validation procedures for that client authentication, maybe RFC 6125 with a DNS-ID check, or would that be too restrictive? Section 6.1 In many contexts, the recursive resolver will be able to handle Push Notifications for all names that the client may need to follow. Use of VPN tunnels and split-view DNS can create some additional complexity in the client software here; the techniques to handle VPN tunnels and split-view DNS for DNS Push Notifications are the same as those already used to handle this for normal DNS queries. Is there a good reference discussing these techniques? Section 6.2.1 The MESSAGE ID field MUST be set to a unique value, that the client is not using for any other active operation on this DSO session. For Isn't this already mandated by 8490? (Hmm, the interaction of TLS early data's replayability and MESSAGE ID uniqueness might require some thought. But the MESSAGE ID uniqueness is within a DSO session, not global, so that may not make a difference.) Section 6.3.1 The other header fields MUST be set as described in the DSO spec- ification [RFC8490]. The DNS OPCODE field contains the OPCODE value for DNS Stateful Operations (6). The four count fields MUST be zero, and the corresponding four sections MUST be empty (i.e., absent). We may not need the 2119 terms for the requirements duplicated from 8490. For collective remove notifications, if CLASS is not 255 (ANY) and TYPE is not 255 (ANY) then for the given name this deletes all records of the specified type in the specified class. (et seq) What does it mean to "delete a record", from the recipient's point of view? (How does the server communicate that the RRset's contents have changed to a completely disjoint value -- delete plus add?) a SUBSCRIBE request, subject to the usual established DNS case- insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE request was not ANY (255) then the TYPE of the record must match the TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE nit: we switch from using the indefinite article to the definite article with "SUBSCRIBE request", which is a bit jarring since we don't give a great indication of what distinguishes the definite case. Section 6.5 It's not entirely clear to me that we need quite this much detail about discovery proxy operations, in order to motivate RECONFIRM. If we're going to talka bout Apple's dns_sd.h API (which I have somewhat mixed feelings about to begin with), we should have a reference for it. Section 7.1 Deployment recommendations on the appropriate key lengths and cypher suites are beyond the scope of this document. Please refer to TLS Recommendations [RFC7525] for the best current practices. Keep in Please cite this as BCP 195. Section 7.4 servers. The server may keep TLS state with Session IDs [RFC8446] or operate in stateless mode by sending a Session Ticket [RFC5077] to 5077 was made obsolete by 8446; from the practical side of tings there is no wire-visible distinction between stateful session IDs and stateless session tickets. Section 10.2 I think RFC 7858 needs to be normative. Likewise, RFC 8310.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -23)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -23)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2019-08-05 for -23)
Sent
Thanks for this well-written document! One small comment on the idle handling: The DSO idle timeout does not "apply" as long as there is at least one active subscription. That mean the connection can be idle for a long time if not change appears. Should this document say something about use of keep-alives in this situation? RFC8490 specifies keep-alives handling as well but it could be good to mention this explicitly in this document as well. Further I was wondering if actually DSO keep-alives should be used or if the lower layer TCP keep-alives would be more efficient/appropriate. Other, smaller comments: 1) Minor comment on normative language in section 3: "Generally, as described in the DNS Stateful Operations specification [RFC8490], a client must not keep a session to a server open indefinitely if it has no subscriptions (or other operations) active on that session. A client MAY close a session as soon as it becomes idle, and then if needed in the future, open a new session when required. Alternatively, a client MAY speculatively keep an idle session open for some time, subject to the constraint that it MUST NOT keep a session open that has been idle for more than the session's idle timeout (15 seconds by default) [RFC8490]." I assume the first "must" is not normative because this is normatively specified in RCC8490. However, if this is reason the last "MUST NOT" should also be lower case. 2) Section 5: Tail Loss Probe (TLP) [I-D.dukkipati-tcpm-tcp-loss-probe]" dukkipati-tcpm-tcp-loss-probe was merged into draft-ietf-tcpm-rack-05. Maybe mention TCP RACK instead of TLP anyway. 3) Section 6.7: "If the session is forcibly closed at the TCP level by sending a RST from either end of the connection, data may be lost and TLS session resumption of this session will not be possible." I would think that TLS session resumption might still be possible even if a RST is received (as long as the TLS handshake was completed and the client received a session ticket). Or what's the assumption here? 4) Section 6.8: "The interval between successive DNS queries for the same name, type and class SHOULD be at least the minimum of: 900 seconds (15 minutes), or two seconds more than the TTL of the answer RRset." Would it maybe make sense to specify also a hard limit, e.g. "MUST NOT be less than 3 seconds (see RFC8085)", or would that maybe give a wrong impression that 3 seconds seems to be an acceptable value...? 5) One minor comment/question on the references: And why is draft-ietf-dnssd-hybrid not cited by draft name but as [DisProx] instead?