Last Call Review of draft-ietf-dnssd-push-20
review-ietf-dnssd-push-20-genart-lc-sparks-2019-06-28-00

Request Review of draft-ietf-dnssd-push
Requested rev. no specific revision (document currently at 25)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-07-05
Requested 2019-06-21
Authors Tom Pusateri, Stuart Cheshire
Draft last updated 2019-06-28
Completed reviews Secdir Telechat review of -19 by Liang Xia (diff)
Tsvart Early review of -19 by Brian Trammell (diff)
Secdir Last Call review of -20 by Liang Xia (diff)
Genart Last Call review of -20 by Robert Sparks (diff)
Genart Telechat review of -23 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-dnssd-push-20-genart-lc-sparks-2019-06-28
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/z55Fjfw--n6Wfyk9oQYrLn05kqY
Reviewed rev. 20 (document currently at 25)
Review result Ready with Issues
Review completed: 2019-06-28

Review
review-ietf-dnssd-push-20-genart-lc-sparks-2019-06-28

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dnssd-push-20
Reviewer: Robert Sparks
Review Date: 2019-06-28
IETF LC End Date: 2019-07-05
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard but with an Issue to consider before publication,

Issue:

The discussion of recursive resolvers in section 6.1 may need additional consideration. In particular, the recommendation to pass a received error code along to a client has, I think, some unintended consequences for the client. If the recursive server receives a NOTIMP, for example, passing that to the client tells the client the wrong thing about the server it is connected to. Perhaps it would be better for the recursive server to return SERVFAIL in this circumstance? (Similar to what it would do if it couldn't connect to the next server as described at the bottom of page 10).

Nits:

Page 5, Section 3, 3rd paragraph, last sentence: NOT REQUIRED is not a 2119/8174 keyword. I suggest using lowercase 'not required' in this sentence.

Page 7, Section 4, 3rd paragraph: The first sentence alludes to concerns about anonymous subscriptions, saying TCP alleviates those concerns. As written this is pretty vague. Can you expand on what you mean by an anonymous subscription in this context?

Page 10, Section 6.1, first sentence: Suggest s/first step in DNS Push/first step in a DNS Push/

Page 15, last paragraph: Why MUST the server immediately terminate a connection in this situation? Just accepting the request seems safe - having subscription requests show up for the same name seems nearly idempotent, and only one PUSH would result from having multiple such subscriptions. Is this close an attempt to avoid resource denial attacks buy some node subscribing many times to the same thing? That feels extreme, especially since tearing down the connection would cancel other subscriptions the client already has established on that connection.

Page 16, second paragraph: I suggest replacing the second sentence with something like "A name in a SUBSCRIBE message that matches only a literal CNAME in the zone will only receive notifications of changes to the CNAME (assuming the subscription asks for that type), and nothing else."

Page 23, top of page: Since section 4 restricts this protocol to TLS over TCP, the "(or equivalent for other protocols)" phrase should be removed.