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

Hi,

On 23 Jul 2014, at 16:15, Dave Thaler <dthaler@microsoft.com> wrote:

> 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.

I think the differentiation you highlight is a very valid point, and we should capture it.
Something like “By stale we mean that either the node is no longer on the network (not just sleeping), or the information is no longer correct."

> 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.”

That works for me. I think the original captures the intent, but the extra reference to split horizon DNS is worth capturing.

> 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.

I think we may get useful further comment on this from Hosnieh’s presentation and discussion.

Thanks for the review and comments Dave.

Tim

> 
> -Dave
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd