Extensions for Scalable DNS Service Discovery Ralph Droms Tim Chown 1300-1500 Monday 3rd March 2014 Focus is on what needs to be standardised for each of the various proposals Meeting materials: https://datatracker.ietf.org/meeting/89/materials.html#dnssd -- 1307 Requirements draft, part 1, Kerry Lynn Doug Otis: Requirements draft should be about requirements, not solutions, but Section 2.1 talks about DNS records. 1317 Requirements draft, part 2, Stuart Cheshire REQ1 Dave Thaler: Disagrees with wording. 1. Change "devices" to "clients" 2. Change "configured (by selection) in the case of multiple choices" to "selected by users" REQ2 No disagreement. REQ3 Dave Thaler: Change "should be a way to configure the scope" to "should be a way to choose the scope" Dave Robbin: I work on BACnet (building automation), which needs some kind of service directory. Should we create our own server, or can we work with the DNSSD WG? In BACnet there may be thousands of devices, with no natural hierarchical organization. A Target store could have 30,000 devices. Stuart Cheshire: Thanks for bringing your requirements to the working group. The sheer number of devices you're talking about is very different to a typical home network. Ralph Droms: Agreed, a home network with 30 ZigBee devices is very different to a campus with 100,000 devices. REQ4 No disagreement. REQ5 Dave Thaler: Should be split into two requirements: 5a. The new solution must not break any current link scope protocols and deployments. 5b. The new solution should integrate with current link scope DNS-SD/mDNS protocols and deployments. REQ6 Dave Thaler: Saying "spanning multiple hops" suggests contiguous links. Should stress that we also want to support non-contiguous links. Discovery scope need not be aligned with network topology. Kerry Lynn: Does that preclude zero-configuration operation? Dave Thaler: That's a different use case, e.g. C, D, E, but not A and B. Kerry Lynn: The charter includes 6lowpan networks, so we'll need routing solutions. Please submit comments to the working group mailing list. Tom Pusateri: Need to talk about routing loops. Mark Townsley: Will the working group define what constitutes a "set of links"? Maybe this just out of scope for this working group? This sounds like a HomeNet working group problem. Ralph Droms: I agree, this working group should not be defining network boundaries. Mark Townsley: Agreed. Stuart Cheshire: We should reword REQ6 to make this clearer. Bernie Volz: How about "must not be limited to a single link"? Juan Carlos Zuniga: We in the IEEE 802 world think of links as something very specific. Dave Thaler: I also like "not limited to a single link" REQ7 No disagreement. REQ8 Peter Koch: We don't design user interfaces here. What is this requirement? Stuart Cheshire: To provide the right protocols and capabilities so APIs can be offered that enable the creation of a good user interface. We can't design a protocol without knowing what its purpose is. If the protocol doesn't allow spaces or uppercase letters, it would give a poor user experience compared to today's link-local service discovery. Peter Koch: Perhaps the requirement could make this clearer. Kerry Lynn: Users should be able to tell if they discovered a service on the local link, or remotely. Ralph Droms: The distinction between local and remote can be fuzzy. We should discuss this more on the mailing list. Tim Chown: Exactly. Two devices in the same room could be topologically distant. Joe Abley: Clients may discover services that are not reachable by them. Is that out of scope? Stuart Cheshire: Worth mentioning in document. We should seek to minimize reachability problems. Dave Robbin: What is the difference between local and remote? Stuart Cheshire: In the context of REQ8, "local" means "what mDNS does today" and "global" means "the new thing this working group is creating". Perhaps it ought to say "old stuff" and "new stuff" instead. John Klensin: User need to understand spheres of local-ness and global-ness. Dave Thaler: What the user thinks of as "local" may not match network "link-local". Being "consistent" with the current situation should not constrain us to be "as bad as" the current situation. REQ9 Dave Thaler: Document is inconsistent: The document talks about sleeping nodes, but REQ9 says that stale information should not persist. Stuart Cheshire: Possibly they're not inconsistent (e.g. a sleeping node may still be responsive and accessible via the network) Plan is to update the requirements document with these changes and then issue a Working Group Last call. -- 1347 What needs to be standardised? Dave Thaler Dave Thaler: We need a new word for "scope" or "zone", because those already have existing meaning in networking. Kerry Lynn: Are you proposing not using DNS? Dave Thaler: No, I'm just trying to clearly state requirements. Stuart Cheshire: The term "zone" has a very specific DNS meaning, which is why a different word may be useful here. Dave Thaler: Right. Here we have the hotel, the IETF, and this room, all different contexts in which we might look for services. [on proxying] Kerry Lynn: The core wg is working on proxying their resource discovery mechanism into DNSSD and vice versa. Discussion: Ralph Droms: What about name conflicts? Dave Thaler: This is a naming problem, not service discovery. Ran Atkinson: I disagree with Dave Thaler. Duplicate names are a problem e.g. I go to lots of customer sites that all have a printer called "HP LaserJet". Dave Thaler: I agree, but that's not a "name conflict" problem, it's a "lack of disambiguation" problem. Outcomes: The authors will publish a revision of the draft that will include several specific changes as agreed to in the meeting. The chairs will then pos a WG last call to the mailing list for consensus on forwarding the document to the IES -- 1400 Extending multicast DNS across local links, Shwetha Bhandari [Informational presentation about Cisco's current product in this area.] Tim Chown: Thanks for the presentation. Stuart Cheshire: The Draft contains some interesting and valid ideas, such as adding additional information about a service. I don't know what the solution might be, but it's a useful requirement to consider. -- 1407 Layer 2 bridging and DNS-SD, Doug Otis [Proposal to build networks using RBridges instead of IP routing.] John Klensin: The Public Suffix List is a kluge. Let's not even consider using that. Kerry Lynn: How would this work with 6lowpan networks? Is every 6lowpan node an RBridge? Ran Atkinson: Several of my clients have very limited bandwidth links. They run raw IP over RF. We need an IP-layer solution, not an 802-layer solution. Ted Lemon: This is far too deep into solution space. It tries to solve a problem by creating a bigger problem. Stuart Cheshire: RBridges are a useful way to make a big flat network, and multicasting a big flat network is not desirable. Chris Liljenstolpe: I don't want to have to change my entire infrastructure to make discovery work. I currently have a routed network, and I want to keep a routed network. I don't want to have to convert to a flat RBridge network to get service discovery. -- 1423 Hybrid Unicast/Multicast DNS-Based Service Discovery, Stuart Cheshire Markus Stenberg: Would like a way to show clients only services they are able to access, e.g. using a new mechanism in the new LLQv2 protocol. Stuart Cheshire: A desirable goal, but may be hard to do in all cases. The software on my machine may not know which file server passwords I happen to know. And the software may not know that I can pick up the telephone and ask for an account on a machine once I've discovered its name. So it can be useful to discover services you don't (currently) have access to. Dave Täht: Have you considered using QUIC? Stuart Cheshire: I had not thought about QUIC, but nothing is off the table at this point. Shwetha Bhandari: Is there a need to map unicast names into the multicast space, for clients that only do multicast DNS and not unicast DNS service discovery? Stuart Cheshire: My hope is that this will not be necessary. There should be no clients that can't do unicast DNS service discovery. Unicast DNS is both more efficient, and more selective. Shwetha Bhandari: What about AirPlay? Evidence seems to be that it does not support unicast DNS service discovery. Stuart Cheshire: No simple answer; can talk off-line about the issue. Chris Wright: 802.1X is device-level access control. A virus-infected PC could advertise itself as a printer. Stuart Cheshire: Yes, that's a good point. Dave Robbin: DNS doesn't know who is asking the question. In BACnet we do know who is asking the question. We have a "no taunting" rule. We only show devices you can access. Stuart Cheshire: Yes, we could consider that for LLQv2. Outcomes: The WG was generally in agreement with the list as presented by Dave Thaler. The conclusions of these three presentations will be consolidated with Dave's list. -- 1450 mDNS/DNS-SD interoperability, Andrew Sullivan John Klensin: I think this is dandy. Let's have safety and simplicity. This is going to fail fairly often as a consequence of bad implementations, confused users, etc. The reality is that identifiers had better stick to plain ASCII. Andrew Sullivan: Which parts of the name are you talking about? John Klensin: Everything. The people who want to use spaces in names will learn to stop doing that. Names with spaces are perfectly valid and legitimate, and often don't work. Stuart Cheshire: I disagree with John that it "just won't work". Problems happen when there are multiple ways to represent the same thing. Instead of using UTF-8, DNS uses "xn--" encoding because of a fear of eight bits in a byte. Instead of using UTF-8, email uses equals-hex-hex escaping because of a fear of eight bits in a byte. Instead of using UTF-8, HTML uses ampersand-hash-semicolon escaping because of a fear of eight bits in a byte. When every application layer invents its own different way of representing Unicode text, of course there will be problems. For a prime example, take a look at , a draft which is *about* using non-ASCII characters in Internet Drafts and RFCs. The bottom of page 4 talks about "Use of the actual UTF-8 character (e.g., Δ)" but in the actual document, instead of an delta character, you see ampersand hash 916 semicolon. Having multiple representations for Unicode text is why we saw "xn--" on Ralph's screen. Andrew Sullivan: We're going to have to cope with it. Kerry Lynn: Could DNAME records help? Andrew Sullivan: In principle yes, but ICANN's Security and Stability Panel say that DNAMEs must never appear in the root zone. Doug Otis: Some characters are visually confusable. Dave Thaler: The solution here should be the same as whatever we do for name resolution, and hence is outside the scope of this working group. Outcomes: The WG was reminded to keep in mind that it is chartered to document issues in naming interoperability and solutions are currently beyond the scope of the charter. The chairs asked if Stuart Cheshire would join Andrew Sullivan as a co-author of this document. -- Tim Chown: Time to wrap up the requirements document. -- END