Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt
Mukund Sivaraman <muks@isc.org> Tue, 22 March 2016 16:05 UTC
Return-Path: <muks@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D9B12DA6C for <dnsop@ietfa.amsl.com>; Tue, 22 Mar 2016 09:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 2WTTngQ0XzKX for <dnsop@ietfa.amsl.com>; Tue, 22 Mar 2016 09:05:09 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 9390A12D6C5 for <dnsop@ietf.org>; Tue, 22 Mar 2016 09:05:09 -0700 (PDT)
Received: from jurassic.l0.malgudi.org (unknown [115.118.48.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id ADC852FA0034; Tue, 22 Mar 2016 16:05:05 +0000 (GMT)
Date: Tue, 22 Mar 2016 21:35:00 +0530
From: Mukund Sivaraman <muks@isc.org>
To: 神明達哉 <jinmei@wide.ad.jp>
Message-ID: <20160322160500.GA14301@jurassic.l0.malgudi.org>
References: <20160321130839.31949.19155.idtracker@ietfa.amsl.com> <20160321135159.GB28581@jurassic.l0.malgudi.org> <CAJE_bqcRbMWS=zVM51uPK-HX2+sy8wtnwB89aZEwxyjO1VjV1w@mail.gmail.com> <20160321194548.GA11460@jurassic.l0.malgudi.org> <CAJE_bqdgHOMU=SxvUFm06-qQuiX4ezZEnBsYRQp56r3XpnXD_w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH"
Content-Disposition: inline
In-Reply-To: <CAJE_bqdgHOMU=SxvUFm06-qQuiX4ezZEnBsYRQp56r3XpnXD_w@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/l9_9CIHIkw3fihfohu4HUnJE8zE>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2016 16:05:10 -0000
On Mon, Mar 21, 2016 at 06:22:52PM -0700, 神明達哉 wrote: > At Tue, 22 Mar 2016 01:15:48 +0530, > Mukund Sivaraman <muks@isc.org> wrote: > > > > > (1) Section 7.2.1. Authoritative Nameserver: > > > > I'm confused about the revised Section 7.2.1 regarding overlapping > > > prefixes. The 07 version of the draft now states: > > > > > > [...] Because it can't be guaranteed that queries for all > > > longer prefix lengths would arrive before one that would be answered > > > by the shorter prefix length, an Authoritative Nameserver MUST NOT > > > overlap prefixes. > > > > > > But the above "trivial example" seems to talk about what an > > > authoritative nameserver would do if it overlaps prefix...doesn't it > > > simply break the MUST NOT in the first place? > > > > When overlapped address prefixes occur in zone data (the configuration > > provided by an administrator to the authoritative nameserver), the > > authoritative server should resolve the overlap by deaggregating > > prefixes such that the prefixes in the Authoritative Nameserver's reply > > messages do not overlap. > > At least to me, "MUST NOT overlap" can't obviously read that way. I > think some more wording clarification is needed. Also, what about > the "warn and continue" behavior of this one? > > 2. Alert the operator that the order of queries will determine which > answers get cached, and either warn and continue or treat this as > an error and refuse to load the configuration. > > If it's not considered a violation of the MUST NOT, I think we need > more explanation here, too. You're right. It should be described more clearly. Mukund
- [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cli… Mukund Sivaraman
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cli… 神明達哉
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cli… Mukund Sivaraman
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cli… 神明達哉
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cli… Mukund Sivaraman