Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April)

[Andrew Sullivan <[e-mail]>]

Hi,

This review is late.  It has been an interesting couple of weeks
learning how the new corporate masters do things.  Many apologies for
being late.  If this is too late to be useful, I apologise for that
too.

I hadn't looked carefully at this document in some time.  It's in good
shape.  There are a few nits below that could use addressing, but none
are AFACIT fatal.  In general, I like this document and I've been
looking forward to its publication; it should be published.

The review text below is a little telegraphic in style because I was
running out of battery.

In section 3 there's a reference to RFC 1996.  I wonder whether RFC
7719 might be better, since it appears to be about the terms.

What should a server do if it gets a query over the open TCP
connection with the RD bit set?  What about for a zone outside the
server's bailiwick?  REFUSED?  (In general, there are a bunch of
requirements that create error conditions, where it isn't clear what
the right answer is.  These are perhaps answered in the tables of
RCODEs later, but if so a forward reference would be better.)

SRV records are discussed here but mystifying until you get to 6.1.
Maybe a forward reference?

Classes are included but implementations are permitted not to support
them.  What do you do if you get a query for a class you don't
support?  This seems strange.  (It is possible to leave classes other
than IN undefined, though it seems sticky.  I tried to get DNSOP to
deprecate classes, but I got pushback.)

"DNS Push Notification clients MUST NOT recklessly create an
excessive" I don't know what MUST NOT means there; I think it's
guidance, not protocol spec.  (In general, throughout the draft there
are uses of 2119 language that don't really create protocol rules, so
that might be revisited).

In section 6,

   DNS Push Notification clients and servers MUST support DNS Session
   Signaling, but the server MUST NOT issue any DNS Session Signaling
   operations until after the client has first initiated a DNS Session
   Signaling operation of its own.

Why MUST NOT?  Session signalling only says SHOULD NOT.  I can imagine
a server in a network that is closely managed having the ability to be
certain of what all the clients can do (or, what's the same, not
caring because such clients shoukdn't be there).

I think what item 2 of 6.1 is saying is that you need a NOERROR/NODATA
response with an SOA in the authority section (it's intially a little
confusing, because it seems like you have to put the SOA of the
non-existent zone in the authority, but that doesn't make any sense so
that couldn't be it :).  Maybe a reference to RFC 2308 would be
helpful?

In step 3, does that mean "no SOA in the response message at all, in
any section"?  There sometimes appears to be an ambiguity in what
people mean by "returned" for a DNS query -- it often means the Answer
section, and in that interpretation step 3 would cause an extra
unneeded query, which I'm sure isn't the goal.

In step 5, I'm a little leery of the MUST NOT exist.  Since there's no
way to constrain what people might put in their zones if they don't
implement this specification, that's not really a rule one can make.
Maybe, "For implemneters of this specification, an authoritative
answer for that SRV record, and only such an answer, will determine
whether the zone supports DNS Push Notifications"?  The point is that
you can't control whether a non-implemnter will put such an SRV in a
zone, but you can say what an implementation of this spec will do.

   Each time a client makes a new DNS Push Notification subscription
   connection, it SHOULD repeat the discovery process in order to
   determine the preferred DNS server for subscriptions at that time.

and the following paragraph is a little surprising, because couldn't
you subscribe to the SRV record itself and thereby get notified when a
zone's rules change?  Anyway, if you're going to query for the same
SOA again within the TTL window, you're likely to tickle RRL.  Why
can't you use the cached SOA and SRV record for the length of the TTL?

In 6.2, what should happen if a server does issue a Subscribe request?
Ignore it?

In 6.2.1, do all errors result in TCP RST or just the duplicate
queries?  (Apparently not given 6.2.2.)  Why is this required?  Why
not just ignore the request?

The CNAME handling is a little strange.  CNAME is defined as canonical
name, so formally it means that the owner name just _is_ the target.
I think what is meant here, however, is that a CNAME in the query is
interpreted as matching the CNAME record itself, and on the server
side the CNAME expansion is not performed.  Right?  (This comes up
again later.)

The discussion of ALL vs ANY here is a little surprising to me.  It
seems to me that the semantics in this case are the same, because you
can only get these notifications from a server that is authoritative,
no?  ANY in that case does effectively mean ALL, but that's an
accident.  I'm leery of this document making the QTYPE=255 semantics
even more convoluted than they already are.

In 6.2.2 I'm a little worried about the use of SERVFAIL here.  It
appears to be somewhat at odds with the regular meaning of this
response code.

In 6.4, if a client gets an UNSUBSCRIBE request from a server, what
should it do?

Again, I don't think any of these are fatal, but if they could be
cleaned up it might make the document more useful.

Best regards,

A