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