[dnssd] Artart telechat review of draft-ietf-dnssd-mdns-dns-interop-04

Eliot Lear <lear@ofcourseimright.com> Mon, 01 May 2017 14:37 UTC

Return-Path: <lear@ofcourseimright.com>
X-Original-To: dnssd@ietf.org
Delivered-To: dnssd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A22BC129C35; Mon, 1 May 2017 07:37:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eliot Lear <lear@ofcourseimright.com>
To: <art@ietf.org>
Cc: dnssd@ietf.org, ietf@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149364945162.9895.14720756538747663998@ietfa.amsl.com>
Date: Mon, 01 May 2017 07:37:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/XNSvXUgjDTCdivBiVTOyzH1Verk>
Subject: [dnssd] Artart telechat review of draft-ietf-dnssd-mdns-dns-interop-04
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 May 2017 14:37:32 -0000

Reviewer: Eliot Lear
Review result: Ready with Issues

Well written and comprehensive.  Just a few comments.

First, the use of "rejected" several times in the document leads one
to conclude that the WG is making design decisions at this time for
input into the next document. Combined with when the profile is
applicable, and its rough outline, one gets the impression of a first
step towards its writing.  Stating the audience and next steps would
help the reader.

Second, in Section 4.3, ppg 7-8, the following sentence:

   ... DNS-SD
   implementations ought somehow to identify the <Domain> portion of
   the Service Instance Name and treat it subject to IDNA2008 in case
   the domain is to be queried from the global DNS.

The sentence implies that it will not be easy to separate <Domain>
from <Instance> and <Service>, when the previous paragraphs seem to
make it clear that one can clearly identify <Service>.  Is this
because one might envision naked octets that begin with underscore in
either the <Domain> or <Instance> sections?  If so, it might be worth
reiterating that.

Third, while one might say that the fundamental issue has to do with
processing of labels in some form versus not doing so, most of the
document is spent on the case of IDNA2008 v. LDH v. naked UTF8.  The
abstract really should probably state that up front.  Similarly, the
impact to both deployments and implementations should be tersely

The key callouts to me are suggestions as to when to perform IDNA2008
processing and when to not do so, potential restriction of character
sets, etc.

Fourth: the following sentence leads to a question:

   A practical consequence of this is that zone operators need to be
   prepared not to apply the LDH rule to all labels.

The implication here is that zone operators make this decision.  I
*think* what we are talking about here are user interfaces, no?  BIND
handles this just fine, right?[1]

Finally one nit: expand LDH on first use.

[1] http://www.dns-sd.org/servertestsetup.html