[dnssd] Benjamin Kaduk's No Objection on draft-ietf-dnssd-push-24: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnssd-push-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.