[dnssd] Comments on draft-ietf-dnssd-requirements-03

[Dave Thaler <[e-mail]>]

Kerry Lynn wrote:
> Re: your feedback of 3 March, I believe I fixed most issues except DT14, 15, & 16.
> In those cases, I either didn't know if a fix was necessary or how to fix it.  Can you
> provide suggested text if you still consider the current draft to be broken?

I agree that all other issues I raised have been addressed in the doc, thanks. 

For DT14, the text says
“That is, new information should be available in a timely
fashion and stale information should not persist.”

My comment was that "stale information should not persist" is ambiguous
and could be read as being in conflict with REQ10 (be considerate
of nodes in a sleeping state).  For example, if a node is sleeping, do you
consider its information "stale"? (I would say no.)   If the sleeping node
then disappears from the network, would you then consider it stale?
(I would say yes.)   So I would suggest being clearer as to what "stale"
means.  For example, I think NON-stale means that the node is still on
the network (but may be sleeping), and the information is still correct.
So "stale" means to me that either the node is no longer on the 
network (not just sleeping), OR the information is no longer correct.
Maybe you have a different interpretation of stale, my main point is
that it needs to be clearer what we mean.

For DT15 the text says 
"The unicast DNS namespace contains globally unique names.  The mDNS
namespace contains locally unique names.  Clients discovering
services may need to differentiate between local and global names or
to determine that names in different namespaces identify the same
service."

I said, on the first sentence, "This statement repeats the usual myth that
there is no two-faced / split-horizon DNS."  That is, it refers to "the" unicast
DNS namespace.  And non-global unicast DNS namespaces do not
necessarily contain _globally_ unique names (RFC 7050 is one example.
Another example is *.10.in-addr.arpa.  And then there's historical 
uses of .local in private DNS in the past.  Etc.)  Furthermore, the second
sentence implies that there is only one mdns namespace, where in fact 
there can be one per network.

Suggest something along the lines of:
"Between the global DNS, the possible presence of split horizon DNS,
and various networks running mDNS, there are different namespaces, among
them containing globally unique names and locally unique names.
Clients discovering services may need to differentiate between local 
and global names or to determine that names in different namespaces
identify the same service."

For DT16, the text currently says this:
"   As mDNS is currently restricted to a single link, the scope of the
   advertisement is limited, by design, to the shared link between
   client and server.  In a multi-link scenario, the owner of the
   advertised service may not have a clear indication of the scope of
   its advertisement.

   If the advertisement propagates to a larger set of links than
   expected, this may result in unauthorized clients (from the
   perspective of the owner) discovering and then potentially attempting
   to connect to the advertised service.  ..."

My comment was "The multi-link scenario is just one case of this.
This statement is actually a general statement of the issue.  It should be
phrased as such, with the multi-link scenario just being an example."

Suggest something along the lines of:
"In some scenarios, the owner of the advertised service may not have
a clear indication of the scope of its advertisement. 

For example, since mDNS is currently restricted to a single link, the
scope of the advertisement is limited, by design, to the shared link
between client and server.  If the advertisement propagates to a
larger set of links than expected, this may result in unauthorized 
clients (from the perspective of the owner) discovering and then
potentially attempting to connect to the advertised service. ..."

The proposed change above is reordering the sentences and where
the paragraph break is, and the insertion of "for example" to transition.

-Dave