DNS-Based Service Discovery
RFC 6763

Note: This ballot was opened for revision 11 and is now closed.

(Ralph Droms) Yes

(Alexey Melnikov) (was Discuss) Yes

Comment (2011-01-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

Lars Eggert (was Discuss) No Objection

Comment (2010-11-30)
No email
send info
  This document has quite a list of ID nits that should be fixed before
  publication (outdated references, not using example domains/prefixes,

(Adrian Farrel) (was Discuss) No Objection

(David Harrington) (was Discuss) No Objection

(Russ Housley) No Objection

(Tim Polk) No Objection

Comment (2010-12-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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...

(Dan Romascanu) No Objection

(Peter Saint-Andre) (was Discuss) No Objection

Comment (2010-12-01)
No email
send info
1. The User Interface Considerations might be more appropriate as an appendix.

(Robert Sparks) (was Discuss) No Objection

Comment (2010-12-15)
No email
send info
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.

(Sean Turner) No Objection