Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery
RFC 8222

Received changes through RFC Editor sync (created alias RFC 8222, changed title to 'Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery', changed abstract to 'Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services.  Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets.  This is of particular relevance where some environments use DNS labels that conform to Internationalized Domain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8).  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 the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner.', changed pages to 11, changed standardization level to Informational, changed state to RFC, added RFC published event at 2017-09-21, changed IESG state to RFC Published)

[Ballot comment]
I do have one comment, and it's only for consideration by the responsible AD.

This document is great, and the shepherd thinks it's received sufficient review for publication as Informational, but I wonder if it might

- make sense to publish as a BCP, which would generate additional review from other communities, OR

- make sense to publish as Experimental, which might signal that this document is probably the right thing to, but the jury is still out, OR

- include "You are not expected to understand this" in the Introduction, crediting Dennis Ritchie for prior art (*)

I'm MOSTLY kidding ...

(*) https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code#.22You_are_not_expected_to_understand_this.22

[Ballot comment]
I think that this is a useful document -- I think that it would be more useful if it A: made DNS-SD be LDH only, or somehow made all DNS deployments be UTF-8 (without any sort of homograph issues), but seeing as both of these would require magic, I'm balloting Yes. :-)

2 nits:
1: ... "the so-called LDH rule" -- I think that it would be useful to expand this - the tone is introductory, and so I think helpful to new readers.
2: "cannot be used in the DNS unless they cleave to the LDH rule." - I would suggest "adhere to" or "follow" - 'cleave to', while cooler, is likely confusing to a: those who don't have English as a first language, or b: were born after 1886. :-)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-dnssd-mdns-dns-interop-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-mdns-dns-interop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf , terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (On Interoperation of Labels Among Conventional DNS and Other Resolution Systems) to Informational RFC


The IESG has received a request from the Extensions for Scalable DNS
Service Discovery  WG (dnssd) to consider the following document:
- 'On Interoperation of Labels Among Conventional DNS and Other
  Resolution Systems'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-04-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-dns-interop/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-dns-interop/ballot/


No IPR declarations have been submitted directly on this I-D.

(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
page header?

    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
    operators.
   

(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
    terminology.
   
    The current draft appears to address WGLC comments.

Document Quality:

    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
    DNS.

Personnel:

    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
IESG.

    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
place.

    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
    perspective.


(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
concerns here.

    None. Early confusion over terminology and expectations about the
    behavior of DNS tends to strengthen the case for having the
    document.

(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
disclosures.

    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
    interoperability limitations.

(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
thorough.

  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.

    N/A
   
(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?

    N/A
   
(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.

    N/A

(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).

    N/A

(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.

    N/A
   
(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.

    N/A