¶ UDP and TCP or TCP only?
- Standardize existing UDP draft draft-sekar-dns-llq and add TCP support
- Deprecate UDP and only standardize TCP
- Use existing DNS packet format with LLQ option but drop setup and possibly refresh
- Create new protocol for connection oriented LLQ only, not bound by existing DNS packet format
- Require TLS for TCP and DTLS for UDP?
- If we require TLS, do we need to support STARTTLS?
- require TSIG and/or SIG0?
- Simplify the protocol by just using TCP
- Require TLS but don't support STARTTLS (may need a new default port number)
- DNSSEC is optional
- Using existing packet format would be easier for DNSSEC support (Sullivan only vocal advocate for new format). We could poll the list.
¶ What should dnssd WG standardize?
(from WG meeting discussion, IETF 90, 7/2014; http://www.ietf.org/proceedings/90/slides/slides-90-dnssd-5.pdf)
-
Proxying mDNS/DNS
-
Service discovery zone enumeration
- We use the word ‘zone’ here in the absence of anything better – probably unrelated to “DNSzone”
- "Scope" isn't a good choice, either, because of confusion with multicast scopes
- How do clients (people, devices) and advertisers (services) discover what zones are available?
- A zone could be based on various attributes:
- Network topology
- Physical location
- Organizational group
- ???
- One attribute can be expressed in FQDN hierarchy
- Challenge: handling/enumerating physical locations, e.g. “this room”, or “this hotel”, or administraLve operaLon, e.g. “IETF”
-
Change notification
- Service Discovery can be an interactive process - for example, a service browsing window
- New services need to be displayed as they become available
- Services need to be retracted when no longer available
- Likely will lose some immediacy in responses when extending dns-sd
- How do proxies fit into the architecture
- What is ‘stale’ information?
- Should we push ahead with a form of DNS-LLQ here (see above)?
The content of this page was last updated on 2015-07-22. It was migrated from the old Trac wiki on 2023-01-24.