[Gen-art] Gen-ART Review of draft-ietf-dnsop-edns-client-subnet-04
Russ Housley <housley@vigilsec.com> Fri, 11 December 2015 23:26 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AC71A1A5A; Fri, 11 Dec 2015 15:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7tWucsRwn24; Fri, 11 Dec 2015 15:26:06 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 453E51A1A02; Fri, 11 Dec 2015 15:26:06 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9A4889A4019; Fri, 11 Dec 2015 18:26:05 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id xkbQ4-l0r7zJ; Fri, 11 Dec 2015 18:24:56 -0500 (EST)
Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CC47E9A405D; Fri, 11 Dec 2015 18:26:04 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
Date: Fri, 11 Dec 2015 18:26:04 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <A886238F-FC46-47BD-AD86-B48D8BC42C47@vigilsec.com>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
To: draft-ietf-dnsop-edns-client-subnet.all@ietf.org
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/FywHqGrzieAXOj4d1j3wM3-VrXU>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Subject: [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns-client-subnet-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 11 Dec 2015 23:26:13 -0000
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-dnsop-edns-client-subnet-04 Reviewer: Russ Housley Review Date: 2015-12-11 IETF LC End Date: 2015-12-21 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: In Section 6, the figure includes a line that begins with "7:". This is incorrect. It should begin with "8:". Section 7.2.1 ends with: "Implementations SHOULD document their chosen behavior." I have no objection to such documentation, but some advice about where someone might find it would be useful. I do not think you are asking each implementation to write an Informational RFC. Further, the use of "SHOULD" in this sentence has nothing to do with the normal RFC 2119 usage, which applies to the action taken by an implementation. Section 7.5 says: Intermediate Nameservers supporting ECS MUST forward options with SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such options MUST NOT be replaced with more accurate address information. An Intermediate Nameserver MAY also forward ECS options with actual address information. This information MAY match the source IP address of the incoming query, and MAY have more or fewer address bits than the Nameserver would normally include in a locally originated ECS option. These two paragraphs appear to contradict each other. I cannot figure out what an Intermediate Nameservers that supports forwarding of ECS options ought to do with regard to source address information. Please divide the references into normative and informative. The URIs should be informative references. URIs must be stable references, and I do not think that [4] qualifies. Minor Concerns: The last paragraph of the Introduction provides information that is useful to someone doing a review. However, it is not clear to me that this information belongs in the Informational RFC. I think that it would be sufficient to say: At least a dozen different client and server implementations have been written based on earlier versions of this specification. The protocol is in active production use today. While the implementations interoperate, there is varying behaviour around edge cases that were poorly specified. Known incompatibilities are described in this document, and the authors believe that it is better to describe the system as it is working today, even if not everyone agrees with the details of the original specification [1]. The alternative is an undocumented and proprietary system. If you accept this approach, then you might also look for "original draft" elsewhere in the document ans make a compatible change. In Section 6, I think it would be useful to say that the SCOPE PREFIX-LENGTH in a response MUST be less than or equal to the SOURCE PREFIX-LENGTH. In Section 7.1.1, can you add a sentence or reference to explain "lame delegation"? I recognize that this type of error results when a name server is designated as the authoritative server for a domain name and that server does not have authoritative data. Section 7.4 says: "Several other implementations, however, do not support being able to mix positive and negative answers, and thus interoperability is a problem." Then, the next paragraph says that this topic will be revisited in a future specification. Is there any advice that the authors can share as a step toward interoperability that would be useful for implementers until the future specification comes about? Other Editorial Comments: There are many places in the document where is says: "This draft ...". These should be changed to "This document" or "This specification" in preparation for publication as an Informational RFC. In Section 4, some of the terms being defined are followed by a colon, and others are not. Please be consistent. I prefer the inclusion of the colon. In Section 7.5, it says: It is important that any Intermediate Nameserver that forwards ECS options received from their clients MUST fully implement the caching behaviour described in Section 7.3. To me, "It is important that" and "MUST" are redundant. In Section 11.3, it says: o Recursive Resolvers MUST never send an ECS option with a SOURCE PREFIX-LENGTH providing more bits in the ADDRESS than they are willing to cache responses for. I think it would be netter to reword this as a MUST NOT statement.
- [Gen-art] Gen-ART Review of draft-ietf-trill-pseu… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Sandra Murphy
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Sandra Murphy
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Russ Housley
- [Gen-art] Gen-ART Review of draft-ietf-trill-pseu… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Steve Crocker
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- [Gen-art] Gen-ART Review of draft-ietf-mpls-self-… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-mpls-s… Ronald Bonica
- [Gen-art] Gen-ART Review of draft-ietf-lisp-impac… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-mpls-s… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-i… Luigi Iannone
- Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-i… Jari Arkko
- [Gen-art] Gen-ART Review of draft-ietf-l2vpn-vpls… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jiangyuanlong
- [Gen-art] Gen-ART Review of draft-ietf-eppext-tmc… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… BRUNGARD, DEBORAH A
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jiangyuanlong
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jari Arkko
- [Gen-art] Resolution on comments of draft-ietf-l2… Jiangyuanlong
- [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Warren Kumari
- Re: [Gen-art] Resolution on comments of draft-iet… Ben Campbell
- Re: [Gen-art] Resolution on comments of draft-iet… Jiangyuanlong
- Re: [Gen-art] Resolution on comments of draft-iet… Sheng Jiang
- Re: [Gen-art] Resolution on comments of draft-iet… Jiangyuanlong
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… David C Lawrence
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Warren Kumari
- [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Jari Arkko
- [Gen-art] Gen-ART Review of draft-ietf-eppext-tmc… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Gustavo Lozano
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Gustavo Lozano
- [Gen-art] Gen-ART Review of draft-ietf-rtcweb-aud… Russ Housley