DNS-Based Service Discovery
draft-cheshire-dnsext-dns-sd-11
Yes
(Ralph Droms)
No Objection
(Adrian Farrel)
(Dan Romascanu)
(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Tim Polk)
Note: This ballot was opened for revision 11 and is now closed.
Alexey Melnikov Former IESG member
(was Discuss)
Yes
Yes
(2011-01-17)
Unknown
4.1.1 Instance Names -- Should the document also disallow Unicode Control characters ? 4.1 Structured Instance Names The <Instance> portion of the Service Instance Name is a single DNS label, containing arbitrary precomposed (Unicode Normalization Form C [UAX15]) UTF-8-encoded text [RFC 3629]. It is a user-friendly name. It MUST NOT contain ASCII control characters (byte values 0x00 - 0x1F) but otherwise is allowed to contain any characters, without restriction, including spaces, upper case, lower case, punctuation -- including dots -- accented characters, non-roman text, and anything else that may be represented using UTF-8. How does this interact with draft-ietf-tsvwg-iana-ports? I think it would be worth pointing out here to sections that define more restricted formats. 6.4 Rules for Keys in DNS-SD Key/Value Pairs The characters of "Key" MUST be printable US-ASCII values (0x20-0x7E), excluding '=' (0x3D). This needs a reference to US-ASCII.
Ralph Droms Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Harrington Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2010-11-30)
Unknown
This document has quite a list of ID nits that should be fixed before publication (outdated references, not using example domains/prefixes, etc.)
Peter Saint-Andre Former IESG member
(was Discuss)
No Objection
No Objection
(2010-12-01)
Unknown
1. The User Interface Considerations might be more appropriate as an appendix.
Robert Sparks Former IESG member
(was Discuss)
No Objection
No Objection
(2010-12-15)
Unknown
This document contains several instances of opinion and observation that are not going to be useful for building interoperable implementations of the protocol. Earlier versions of draft-cheshire-dnsext-multicast had similar text that was polished out as it was completed, leaving a better document for implementers. Please consider a similar editorial pass for this document.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2010-12-02)
Unknown
I do not want to hold up publication of this document, so I am entering this as a comment, but hope the authors will take the time to review the use of non-example domain names in sections 4.1 and the various subsections of 14. I am not sure that the use of non-example domains in section 4.1 adds anything that "example.com" wouldn't provide: a conventional unicast DNS domain name, such as "ietf.org.", "cs.stanford.edu.", or "eng.us.ibm.com." Since section 14 is a worked example, I expect that no revisions are possible, but the authors should consider the ramifications of readers playing along at home...