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

Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> Wed, 08 March 2017 12:24 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 F41E812965A; Wed, 8 Mar 2017 04:24:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= <j.schoenwaelder@jacobs-university.de>
To: <ops-dir@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.47.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148897586598.20191.8422735308130046248@ietfa.amsl.com>
Date: Wed, 08 Mar 2017 04:24:25 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/425tvSdBxOA9-MLtF-3mCCuZhFQ>
Cc: dnssd@ietf.org, draft-ietf-dnssd-mdns-dns-interop.all@ietf.org
Subject: [dnssd] Partial review of draft-ietf-dnssd-mdns-dns-interop-04
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 08 Mar 2017 12:24:26 -0000

Review is partially done. Another review request has been registered
for completing it.

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Disclaimer: I regret that DNS does not use UTF-8 in its labels, to me
, as an outside observer, it seems IDNA was a big mistake. But given
the IETF standards we have, it seems one has to properly IDNA encode
UTF-8 in DNS labels. (As an outsider, I am puzzled by documents that
say that for some portions of the DNS name hierarchy this is not true
and it is left vague how to precisely determine where in the
IDNA has to be used and where not.)  So now that you understand my
ignorance, I hope you understand what follows below may just be plain

In section 2, I do not understand this statement:

   The greater problem is that the "infrastructure" types of DNS
   -- the root zone, the top-level domains, and so on -- have
   IDNA and refuse registration of raw UTF-8 into their zones. As of
   this writing there is (perhaps unfortunately) no reliable way to
   discover where these sorts of DNS services end.

Not sure what this is trying to convey. Are you saying that using
plain UTF in DNS labels is OK if it is far enough from the root?  Why
would that be? I looked up RFC 6055 and I am surprised to read text
about 'intelligent (stub) resolver' there as this seems to be asking
for trouble. To me, it sounds like you are saying 'some portions of
the name hierarchy may use raw UTF-8 labels while other portions may
not and we do not tell you how to set them appart in a reliable
way'. If this is the approach, then the approach is in my personal
view broken. (And please recall the disclaimer above.)

In section 3, what does the term 'implicated' mean?

What I do not understand: Why is it desirable to treat DNS labels
carry DNS-SD Service Instance Names different than any other labels
that may contain UTF-8 characters? If the IETF believes IDNA is the
solution for the DNS, why do we then not also use IDNA for UTF-8
DNS-SD Service Instance Names? Yes, there will be some names that
be impossible to use but then services in the DNS (as opposed to
are likely more infrastructure services and less so end use provided
services. And at the end, the limitation is the result of the DNS /
IDNA approach, so you get what you asked for. (Again, please recall
the disclaimer).

Back to my role as ops-dir reviewer: This document is more a kind of
problem statement document, I do not see direct operational impact.
The trouble with DNS labels is more likely a user facing issues than
it is a network operational issue (except perhaps for helpdesk
functions, in particular in enterprise networks).

Bottom line: I am the wrong reviewer for this document. I think the
authors should specifically seek reviews and comments from people
active in the DNSOP working group.