(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
Status: Informational, indicated in the draft and the datatracker
The document provides guidance on the selection of labels to support
interoperation among different name resolution systems. It doesn't
specify any protocol, just proposes advice for use in specifying
naming conventions and protocols, particularly those that need to be
compatible with, but not limited to, DNS conventions and
protocol. It's intended for application designers and service
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary (from the Abstract of the document):
Despite its name, DNS-Based Service Discovery can use naming systems
other than the Domain Name System when looking for services.
Moreover, when it uses the DNS, DNS-Based Service Discovery uses the
full capability of DNS, rather than using a subset of available
octets. In order for DNS-SD to be used effectively in environments
where multiple different name systems and conventions for their
operation are in use, it is important to attend to differences in the
underlying technology and operational environment. This memo
presents an outline of the requirements for selection of labels for
conventional DNS and other resolution systems when they are expected
to interoperate in this manner.
Working Group Summary:
Early in the life of the draft there was extensive discussion (with
a very few people supplying most of the bits) on clarifying the
scope of the draft and sometimes-diverging terminology, since DNS
operators and implementers think of interoperability issues between
name resolution protocols differently than operators and
implementers of mDNS or other such protocols. Those confusions
appear to have been resolved in the final draft.
The primary difference between the individual -00 version and the
current one is extensive explanatory text on the nature of the
problem being addressed and some of those divergent uses of
The current draft appears to address WGLC comments.
This document is intended as advice to implementers, to promote
interoperability among multiple protocols. Review in DNSOP was
requested, as it discusses operational conventions about the public
Shepherd: Suzanne Woolf
AD: Terry Manderson
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
The shepherd has read multiple versions of the document and took
part in WG discussion on it. It seems to be ready to go.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The topic is somewhat arcane so it's hard to tell if it's had enough
review, but there was extensive discussion of the basic abstractions
in the WG, and the document is clear on both why there might be a
problem and providing guidelines for implementers in managing it.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
The subject of the document is cross-area between the dnssd and
dnsop WGs. The dnssd chairs requested review by the dnsop WG during
the dnssd WG last call on the document and there are several DNS
experts who regularly participate in the dnssd WG. In the chairs'
opinion, this document has received sufficient from the DNS
(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
None. Early confusion over terminology and expectations about the
behavior of DNS tends to strengthen the case for having the
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?
No IPR disclosures found in the datatracker or in WG discussion.
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
No IPR disclosures found in the datatracker or in WG discussion.
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?
This is a "niche" document, covering a corner of the problem space
the WG was chartered to deal with. However, the WG explicitly agreed
several times that it was a useful thing to put in that niche, to
promote proper handling of a problem many implementers won't
otherwise think about. In particular, it flags assumptions about DNS
names and specific advice in an earlier RFC as possibly having
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Not so far as I'm aware, or found in the archives.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
Nits is clean.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
(13) Have all references within this document been identified as either
normative or informative?
All references are Informative.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.
This document does not change the formal status of any RFC. It
offers some advice on implementation considerations around specific
sections of some of the RFCs in the references.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.