[dnssd] Adam Roach's Discuss on draft-ietf-dnssd-hybrid-07: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-dnssd-hybrid-07: Discuss

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-hybrid/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

First, I'd like to say thanks for your work on this document. I find this work
exciting, and hope to see it widely deployed in the short term.

I do have one major concern that I believe rises to the level of a DISCUSS,
although I believe it should be trivial to fix. The reason I believe it to be a
barrier to publication is that it makes a broad architectural statement that
has implications for all application protocols; which, beyond being outside the
remit of the working group per its charter, I seriously doubt received the
level of cross-area review appropriate for its scope. The statement of concern
is in section 5.5.5:

   As is the case with NAT ALGs, protocol designers are advised to avoid
   communicating names and addresses in nonstandard locations, because
   those "hidden" names and addresses are at risk of not being
   translated when necessary, resulting in operational failures.

I would expect this statement, if evaluated by the IETF community at large, to
be extremely controversial: it implies application-layer protocol designs that
provide neither confidentiality nor integrity protection for protocol
parameters.

Architecturally, it's important to distinguish between NAT ALGs, which are not
a party to the security context of the protocols they carry, and DNS discovery
proxies, which are. This makes the guidance in here appropriate in the context
of DNS-SD records, while being problematic in the broader NAT ALG case cited. I
would find no problem with a narrowly-scoped statement that pertains to DNS
usage in particular, although I wonder whether designers of DNS TXT record
usage in the future are likely to become aware of such guidance.


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

Minor nit: section five's "four DNS subdomains" seems to be predicated on
network designs that always assign segments with netmasks evenly divisible by
either 8 bits (IPv4) or 4 bits (IPv6). I don't think this is frequently the
case any more (e.g., my home network is split into /17 segments, and I have to
assume most enterprise deployments are more complex than my house). I believe
the reverse delegation records should be described as "one or more per segment."

Substantial comment: the text in section 5.4 seems to assume that all addresses
on a segment will *either* correspond to mDNS-discovered addresses, *or* to
addresses provisioned in a traditional DNS server. If this is the assumption
(and a limitation baked into the design), I think it should be documented. If
there's some clever work-around that allows both kinds of addresses to be on a
single segment, it would be great to describe that in here instead.

Question: Section 5.6, bullet one (starting "Not using LLQ or Push
Notification; no answer in cache") calls for the proxy to return a unicast
result as soon as the first valid mDNS response is received. Unless I've
misunderstood something, this means that (for example) a query for "_ipp._tcp"
on an empty cache will simply return only the single fastest-to-respond printer
to the querying client. Was the tradeoff of "faster response but for only one
device" explicitly discussed by the WG?

Minor suggestion: Section 5.6, bullet three (starting "Using LLQ or Push
Notification; at least one answer in cache") -- this bullet is the only one
that is not explicit about whether an mDNS query should be performed by the
proxy. I think the intention that it is *not* (due to the RRSet TTL
harmonization discussed above), but it would probably help implementors out if
you explicitly repeated that no mDNS queries are performed.

Major issue: Section 10 needs to be removed. See
https://tools.ietf.org/html/rfc8179#section-10