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

[Warren Kumari <[e-mail]>]

Warren Kumari 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:
----------------------------------------------------------------------

This is (IMO) easily addressed -- I like the document, this DISCUSS is simply
to improve it and help prevent foot-shooting. I'd be a YES or NoObj once
addressed.

There are a number of places where the non-LDH names may be configured on a
"normal" DNS server. An example of this is in Section 5.2.1.  Domain
Enumeration via Unicast Queries: "db._dns-sd._udp.example.com.   PTR   Building
1.example.com."

Putting this in a zonefile and trying to hand it to e.g BIND makes things sad:
dns_rdata_fromtext: example.com:18: near '1.example.com.': extra input text
zone example.com/IN: loading from master file example.com failed: extra input
text zone example.com/IN: not loaded due to errors.

Another example is in Section 5.3.  Delegated Subdomain for LDH Host Names
"For example, a Discovery Proxy could have the two subdomains "Building
1.example.com" and "bldg1.example.com" delegated to it."

I think that the document needs to do a better job of explaining that you
cannot just include non-LDH in a zonefile without escaping -- Section 5.1.
(Format) of RFC1035 may be a good pointer.  It may even be a good idea to
repeat this (or at least mention the case) whenever there is an example  -
readers are likely to just cut and paste without reading the full document,
leading to unexpected failures (and then gnashing of teeth on forums)


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

Please also see Joel's OpsDir review - it is relevant.

Questions:
Section 3 - Conventions and Terminology Used in this Document
 "A set of hosts is considered to be "on the same link" if: ..."
  I'd suggest "For the purposes of this document a set of hosts..." -- it feels
  a bit dangerous to be defining what being on a link is more globally, and
  this probably misses some corner cases and / or conflicts with some other
  definition.

Section 5.1.  Delegated Subdomain for Service Discovery Records
"In the parent domain, NS records are used to delegate ownership of each
defined link name (e.g., "Building 1.example.com")" - can you please provide a
pointer here to (I think!) Section 5.5.4.  No Text Encoding Translation?

Section 5.2.1.  Domain Enumeration via Unicast Queries
"The "b" ("browse") records tell the client device the list of browsing domains
to display for the user to select from and the "db" ("default browse") record
tells the client device which domain in that list should be selected by
default." What if b.[...] contains "foo" and "bar", and db.[...] contains "baz"
(i.e the default browse is not in b)? Should "baz" be automagically added to b,
or should it be ignored? The decision is likely implemented on the client, but
I think worth noting here - I could see a lazy admin relying on the former and
then later getting bitten if this changes.

Section 5.4.  Delegated Subdomain for Reverse Mapping
"For example, in the "/usr/include/dns_sd.h" APIs (available on macOS, iOS,
Bonjour for Windows, Linux and Android), ..." Is the API really at
/usr/include/dns_sd.h" on Windows? (No idea, and I'm not inclined to go find a
Windows box to test, but it sounded wrong so I flagged it!)

Section 5.5.2.  Suppressing Unusable Records
I don't really understand the "MUST NOT" when a Proxy can determine if there
are multiple address realms - I get why this is desirable, but if it is
important enough to require a MUST NOT, then surely it should be a requirement
that all proxies are able to do this (AFAICT, though manual config)? Also, if
this is MUST NOT for v4, why is it only SHOULD NOT for v6 ULAs? (please educate
me).

Section 5.5.3.  NSEC and NSEC3 queries
"Since a Discovery Proxy only knows what names exist on the local link by
issuing queries for them, ..." (specifically the "only") This may be a nit, but
couldn't a DP also know that a name exists because a device advertised it?

Nits:
Section 5.2.2.  Domain Enumeration via Multicast Queries
"Since a Discovery Proxy exists on many, if not all, the links in an
enterprise, it offers an additional way to provide Domain Enumeration data for
clients." I think that this should be "many, if not all, *of* the links ..." --
but I'm not sure.