Subject: [dnssd] Fwd: OPS-DiR review of draft-ietf-dnssd-requirements

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Jan 2015 10:16:55 -0800

I've had some private chat with Sheng, and wanted to relay the outcome of some of that discussion.   I encourage the authors to consider Sheng's review in its entirety as a last-call review more than an ops-dir review, because I think he just did a general review without an operational focus, but with that said, if you find useful information there, I encourage you to apply it.

In terms of specific issues, here are some conclusions from the discussion:

>> In section 2.1, the last (fifth) bullet item of technical issues is actually the summaried requirement. The followed technical requirements are actually the detailed requirements for the required mechanism in this bullet item.

I don't personally think any change is needed here, but Sheng's point is that the fifth bullet item really isn't like the first four, and it might be better expressed as an introduction for the detailed requirements that follow it.   I think his position makes sense, but it's up to you how to address this, or whether to address it.

>> The first paragraph of section 2.3 may need a little bit reorganized. he current form does not clearly describe why the wireless mesh network require mDNS need to support over multiple links in a wireless mesch network.
> 
> The issue, which I think _is_ clearly stated, is that link scope and subnet scope are not the same for LLNs, and that mDNS doesn't work across entire LLN subnets because of this.   If you don't think this is clear, can you suggest text?
> 
> <Sheng>Your above rewording is much more clear. The current text failed to say that mDNS also needs to be spanned multiple links to cover the entire LLN subnet. So, there is a logic break.

So Sheng's point here is that it isn't clear to the non-LLN-literate reader that an LLN subnet contains multiple link scopes, and hence mDNS won't work across an entire LLN subnet.   I think it's worth clarifying the text to make sure that the reader understands this point.   Maybe the following wording change would make it more clear:

OLD:
   Emerging wireless mesh networking technologies such as RPL [RFC6550]
   and 6LoWPAN present several challenges for the current DNS-SD/mDNS
   design.  First, Link-Local multicast scope [RFC4291] is defined as a
   single-hop neighborhood.  A single subnet prefix in a wireless mesh
   network may often span multiple links, therefore a larger multicast
   scope is required to span it [RFC7346].  Multicast DNS is
   intentionally not specified for greater than Link-Local scope,
   because of the additional multicast traffic that would generate.
NEW:
   Emerging wireless mesh networking technologies such as RPL [RFC6550]
   and 6LoWPAN present several challenges for the current DNS-SD/mDNS
   design.  First, while it is normally the case on IPv6 networks that
   the Link-Local multicast scope [RFC4291] and subnet scope are
   identical, this is not the case for LLNs.

   In an LLN, the Link-Local scope is defined as a
   single-hop neighborhood.  A single subnet prefix in a wireless mesh
   network may often span multiple links, therefore a larger multicast
   scope is required to span it [RFC7346].  Multicast DNS is
   intentionally not specified for greater than Link-Local scope,
   because of the additional multicast traffic that would generate.

>> Section 3, use case A, it would be very useful if some adoption status of Zero Configuration Network [ZC] could be given. For now, there may be some concern over whether it is a widely used technology.

I don't think that Sheng's point here is an actual problem that needs to be addressed.   At this point, the PAN use case may be a bit hypothetical, and if it were the only use case for DNSSD, I'd say that we were being premature, but since it's not, I think it's worth keeping in mind, and needn't be removed.

>> Section3, it seems all use cases are assuming the single exit router. But the scerarios of multiple exit routers would be a common use case as well. Is this left out of scope intentionally? If so, some explanation for the reason may helpful.
> 
> Aren't at least (D) and (E) potentially multi-homed?   I think you have a good point here, although it's not an ops-dir point.  I don't actually see a reason for this section to mention whether or not the sites are multi-homed.
> 
> <Sheng>Yes, I certainly believe D and E are potentially multiple-homed, maybe C too. But again, it is the way of expression implies the opposite: C clearly said "behind the single exit router"; then D is "like C but..."; E is "like D but...". The stated differenties in D and E do not include any words regarding to potential multiple exit routers.

I know that there was a desire to have a use case that's specifically for a really simple home network, but the general homenet use case is also a valid use case that we need to address, and the way the text is structured, it implies that all the subsequent use cases are not multi-homed, which I don't think is correct.   So I think that this text needs to be reworked to make it clear that the "single exit router" restriction only applies to the simple home network use case and the simple homenet network use case.   If the multihomed homenet use case is not going to be addressed by DNSSD, it should be explicitly excluded.   Was this in fact the intention of the working group?   I'd be surprised, because I would think there would have been a long argument about it, which I don't remember seeing.

>> Section 4, REQ8 looks a very fundemental requirement for all service discovery mechanism. It does not look like a specific requirement for SSD.

This is true, and doesn't mean that the requirement should be deleted, so I don't think you need to take any action here.

>> Section 4, REQ13 may need reworded. The first sentense said "closely reflection reality". The follow-up explanations are all about real-time or close to real-time.

I think Sheng's objection here stems from the colloquial meaning of "closely reflect reality" within the IETF.   It might be better to say something like "closely reflect the current state of discoverable services on the network."

>> Section 4, REQ14, SSD requests some new functions on network devices. It is a change to the network technology.

So Sheng took "network technology" to include layers above layer 3, and that's the basis of his complaint.   I think the meaning here is fairly clear, but you could address his complaint with the following wording change:

OLD:
   REQ14:  SSD should operate over existing networks (as described by
           use cases A-F above) without requiring changes to the network
           technology or deployment.
NEW:
   REQ14:  SSD should operate over existing layer 2 and layer 3 networks
           (as described by use cases A-F above) without requiring 
           changes to the network technology or deployment.

We didn't talk about the proposed changes to sections 5 and 6, and I don't think the comments are necessarily actionable, although it can be argued that the problems described in section 6 ought to be reflected in requirements specified in section 4, if possible.   Doug Otis also mentioned this.   If you can come up with specific requirements, I think that would improve the document.   If you can't, you should probably say so explicitly.