dnssd WG meeting minutes IETF 88, Vancouver, BC November 8, 2013 The co-chairs, Tim Chown and Ralph Droms, called the meeting to order at 1120 and kicked off the meeting with reminder about the NoteWell. The co-chairs announced that the dnssd WG had been formally chartered and briefly reviewed the charter. Interaction with homenet WG --------------------------- The co-chairs noted that the dnssd and homenet WGs will need to coordinate work on naming and service discovery in home networks. It is expect that dnssd can draw on requirements already determined from homenet for their scenario, focusing on the service discovery requirement. Requesting a TLD for scalable DNS (Ralph) ----------------------------------------- Do we know enough to determine whether we want to ask ICANN for a TLD for wider area SD as envisaged by this WG? If so, what TLD? Q: Why not .local? A: .local is reserved as a switch for invoking a different resolution mechanism Stuart: reviewing argument from RFC 6761; scope of ICANN, we need a name for vendors to use out of the box Michael Richardson: DNSSEC? Also, we don't need to ask ICANN for anything, just tell them what we're using Ralph: we're trying to work together with ICANN on a name Russ Mundy: caution re: setting up a TLD as such, with DNSSEC etc. Francisco Arias: I'm from ICANN and I'm here to help Ralph: what further requirements are there on a TLD? DISCUSS Olaf Kolkman: do we really need a TLD? substitute "special use domain name" and then decide whether it's enough Peter Koch: Doesn't need to be TLD. Something under arpa TLD could also work. Olaf Kolkman: Agree with Peter. Doesn’t need to be TLD. Tim: Agree the term to use here is special use domain name rather than TLD, as per RFC 6761. Section 5 of that RFC is then relevant regarding making a new reservation. Marc Blanchet: IAB has no conclusion on this. Also, is there a WG document that describes requirements for this before deciding the process for getting it? We're putting the carriage before the horse. We need a document describing the technical requirements. Daniel Migault: We should not ask ICANN to reserve a name; we should ask ICANN to not allocate a name. Geoff Huston: English/ASCII is the minority; any "user-friendly name" constraint is undefinable and silly Dave Thaler: zero/default requirement missing? And can you have human-friendly, unique-local, and zero conf all at once? Human-friendly not a strict requirement; "not burned in" compatible with "zero conf"? (Stuart and Ralph: can be compatible, depends on where burned in.) Dave: may be others to designate, including possible 2LD Kerry Lynn: is this issue ours or homenet's? we're not dealing with naming issues by charter. Dave: requirements in the charter that we define this problem, not solve it (side note: dnssd *is* chartered to document problems or issues arising from SD solutions that affect naming) Ralph: we may have requirements mostly cooked but does anyone think we need to move quickly now ? WG consensus: NO dnssd requirements document draft-lynn-dnssd-requirements-00.txt www.ietf.org/proceedings/88/slides/slides-88-dnssd-0.pdf -------------------------------------------------------- Has not changed dramatically in a year or so Tussle space: Usability, Scalability, Deployability Stuart moderates discussion speaker: scalability of clients; Stuart: makes sense to note scalability comparable to DNS is desirable Samita Chakrabarti: specific requirements for IoT? Stuart: worth adding a few words to that effect, don't see it as major difference; Kerry: previously brought up M2M as explicit requirement, may not be in scope (Co-chairs' observation - it should be in scope) Pete Resnick: interaction of REQ2 and REQ3? Discussion: yes in scope here, yes implies zero conf by default but also configurability as desired Dave Thaler: REQ6 expand a little to "enumerate stuff not in scope..." per charter language DISCUSSION Dave Thaler: some clarification on requirements for attributes like reliability, availability, and liveness. Discussion: there's some tussle about what this means, but should be included MIF profile http://www.ietf.org/proceedings/88/slides/slides-88-dnssd-5.pdf draft is out of scope because it presents a solution, but problem description probably useful Stuart: can't support arbitrary unicode in DNS by convention, not inband; mDNS labels get into DNS as opaque blobs, read/write as UTF-8 Andrew: this has been true until now, but we're now proposing to use these labels on the Internet, i.e. the DNS. Some compatibility will be required. Marc Blanchet: add to requirements document: differentiate 2 namespaces or similar Keith Moore: DNS names vs. other naming rules: applications need to know what things mean Dave Thaler: clarify interpretation rules per label: A-, U-, or "blob" Stuart: RFC 6763, optimization but the process terminates without it Andrew: concern about scalability of this, walks the tree lots Keith: "DNS is sacrosanct" DISCUSSION: IDNA instead of UTF8 in the public internet for i18n; interoperability problem, need to clarify which are A-labels and which are U-labels and which are opaque blobs for client parsing purposes. Tim: we have a charter item to clarify these issues and document them; solving them is elsewhere. Andrew: problem statement document is easy to write separately OUTCOME: requirements caution re: "don't break stuff" needs some refinement; more applications insight; draft problem statement portion to be separated. Initial DNS-SD Architecture Thoughts www.ietf.org/proceedings/88/slides/slides-88-dnssd-2.pdf -------------------------------------------------------- DISCUSSION: Dave Thaler: Should include discussion of how clients are auto-configured Kerry: New document, additional naming requirements from SEP2.0 Andrew: Clarification of concerns about colliding namespaces, esp. security Erik Nordmark: What about a printer that’s shared between the art department and the history department? (observation: such a device could have an entry in both the relevant subdomains) Burton Kaliski: Queries may leak out accidentally (observation: so we should specify correct behaviour to avoid this) Organization and responsibility for documents --------------------------------------------- deliverables as chartered, primarily requirements Doug Otis: issues tracker/issues document adopt requirements document as WG item? Hum: yes Meeting ended on time.