[Gen-art] review of draft-cheshire-dnsext-dns-sd-07.txt
Francis Dupont <Francis.Dupont@fdupont.fr> Wed, 08 December 2010 14:25 UTC
Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7773A691B for <gen-art@core3.amsl.com>; Wed, 8 Dec 2010 06:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.156
X-Spam-Level:
X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcsf1TONIod0 for <gen-art@core3.amsl.com>; Wed, 8 Dec 2010 06:25:37 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 079F33A6783 for <gen-art@ietf.org>; Wed, 8 Dec 2010 06:25:36 -0800 (PST)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id oB8ER3E0032377; Wed, 8 Dec 2010 14:27:03 GMT (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201012081427.oB8ER3E0032377@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: gen-art@ietf.org
Date: Wed, 08 Dec 2010 15:27:03 +0100
Sender: Francis.Dupont@fdupont.fr
Cc: Stephane Bortzmeyer <Stephane.Bortzmeyer@nic.fr>, draft-cheshire-dnsext-dns-sd.all@tools.ietf.org
Subject: [Gen-art] review of draft-cheshire-dnsext-dns-sd-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2010 14:25:40 -0000
I asked Stephane to review this document... ------------------------------------------------------------------------ I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-cheshire-dnsext-dns-sd-07.txt Reviewer: Stephane Bortzmeyer <bortzmeyer@nic.fr> Review Date: 2010-12-06 IETF LC End Date: 2010-11-23 IESG Telechat date: Unknown Summary: The draft is long, containing a lot of interesting material, but not always well organized. As a general rule, I am a big fan of "rationale" sections, which let you know why a MUST or a SHOULD was used. But, here, they are intermixed with the normative content and it is often difficult to know when standard stops and background material begins. Examples are sections 4.4 TODO. In the same way, user interface discussions are very interesting and useful but should be more clearly separated (may be in a distinct document). It also raises a major issue when you put it in perspective with other DNS-related documents: non-standard terminology and strange ways to describe the rest of the DNS world. It does not seem suitable for a Standards-Track document. Major issues: There are non-standard terms which may create confusion with existing technologies. My main concern is with "unicast DNS". There is no such thing as unicast DNS, there is the DNS and there are other protocols (like LLMNR or Apple Bonjour name protocol) which are not DNS. Even worse is "unicast DNS domain name" (unicast refers to a name resolution method, but a name exists independently of a resolution method). Using "local", outside of the procedures of RFC 2606 and 2826 and similar is a bad idea. I do not elaborate here since the problem is actually in draft-cheshire-dnsext-multicastdns-12.txt. TODO: SRV _udp (section 7) TODO: IANA secret registrations Minor issues: For name resolution on the local network, only mDNS (a misnomer since it is not DNS) is mentioned, not LLMNR (RFC 4795) which seems it would work as well. Section 4.1 says that the name must be in NFC. Why not referring to its subset defined in RFC 5198? Among the practical differences are the fact that RFC 5198 handles the case of end-of-lines, which is ignored by the draft. "commonly-used 16-bit Unicode space" is a misnomer. If one wants to talk about the Basic Multilingual Plane (which stores only a minority of Unicode code points), it should use the standard term <http://unicode.org/glossary/>. The "standard DNS message size" is no longer 512 bytes since RFC 2671 (section 6.1). Yes, EDNS0 sometimes is blocked by broken middleboxes but for a technique used only in local networks, this is not a too serious issue. TODO: several TXT ina RRset The advice of section 13.1 to stuff several other records (which may be in different bailiwicks) in the DNS answer is at odds with security practices (RFC 2181, section 5.4.1 and RFC 5452, section 6). Nits/editorial comments: Long quotes of existing RFCs (section 4.1) are unecessary since the other RFCs are available elsewhere. ------------------------------------------------------------------------ IMHO the summary keyword is near to a "Not Ready". BTW there are unresolved comments from a previous review and of course last call comments... Personal comment: a document describing a defacto standard should not include "rationale" in the standardizing part. Regards Francis.Dupont@fdupont.fr
- [Gen-art] review of draft-cheshire-dnsext-dns-sd-… Francis Dupont
- [Gen-art] review of draft-cheshire-dnsext-dns-sd-… Francis Dupont
- Re: [Gen-art] review of draft-cheshire-dnsext-dns… Stephane Bortzmeyer