[DNSOP] possible inconsistency in draft-ietf-dnsop-edns-client-subnet-07

神明達哉 <jinmei@wide.ad.jp> Tue, 29 March 2016 18:43 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 87DC912E0B1; Tue, 29 Mar 2016 11:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 P8LTEwJ9XaiW; Tue, 29 Mar 2016 11:43:23 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4429612E135; Tue, 29 Mar 2016 11:12:10 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id e3so33933134ioa.1; Tue, 29 Mar 2016 11:12:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=kwHdcWLk/t8aABwQi6nswVd0lI2bPYdRqvUy6BVcSvE=; b=Lfk7Hj8lxhH4gfnEoT/nWEIytzdI0wVqWkVpiKyAnvtf6QvpJMEIh9KxZKw2MwuOdl B7x33pdatbi1V+LZKblaxa2q3evHRwnmxyisOsyrnu3OA7lyggQZgBN0oxn3KQLXXY8C F4Hnkv0s1+ecJYQPeReZRH20WlxPmlWVzV+ZGZUUM5rGfFcB7ZyKDXCihptA7s/P0A4j 8Mkb2+tXVavCYnZnjn0f0O57mJKjMAJ3H4hVU3wFutqesTIeteo+Et+5Z8OdT46l9Gpo 1S5NclZLbAYNTg3VII3NSz17nDQvzKOR1TY2jFJlCpxpEq+P6yWSvoOgJt6/TpSSS1Qf FutQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=kwHdcWLk/t8aABwQi6nswVd0lI2bPYdRqvUy6BVcSvE=; b=gDgQAY8HoEzl2H86XI0t0iyx9lXg8nJ22nIdONaWkLFavA5QAn1wHLlTujJCZLj5p9 zIlWgmXhHW/MaydK/L3aPDm9iqR877EQrCCToQRLHcLHrchJQJWGwIf7yW6rf5IsBkbD DDncV9uXIW/T5wCr0K29NUNFT0NRwU9ng3Gmkx/+V1rCaSwvM4aBux02Alk8V4t4GEoM c6YE4VdaV6dS4jGMQIbTES/R2GmfPaiky0Jx7MSUeCpF6Rcqzky/vLcXdZ5GMtHJU4rq p4ZKMDcNmqzv/8bEjOMZnwH0O9ZRiDphyRoT0YTlzKrYCrLpEH+O+vPGQQBHGkStzabW q5lQ==
X-Gm-Message-State: AD7BkJJENIWJgzyxyBCWi30DxcsUm/i8sje0CmnYMFMxSnZz1771eIbfKqOwsgVboYrwm0fnvvjda15OHR9X+Q==
MIME-Version: 1.0
X-Received: by 10.107.198.147 with SMTP id w141mr4259293iof.178.1459275124457; Tue, 29 Mar 2016 11:12:04 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.143.204 with HTTP; Tue, 29 Mar 2016 11:12:04 -0700 (PDT)
Date: Tue, 29 Mar 2016 11:12:04 -0700
X-Google-Sender-Auth: NEvLHn7Ko8R_yHv7oFOGfztj3kU
Message-ID: <CAJE_bqcCboLag8kQh0uYz8MoA0G7uivFQMRiV2OVFHhcTy=Rjg@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: dnsop <dnsop@ietf.org>, draft-ietf-dnsop-edns-client-subnet.authors@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/8AykpAqDcvLw_7KAmygA8Pr8FaY>
Subject: [DNSOP] possible inconsistency in draft-ietf-dnsop-edns-client-subnet-07
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, 29 Mar 2016 18:43:25 -0000

I know the IESG has already approved it, but I've noticed yet another
(possibly) confusing point in draft-ietf-dnsop-edns-client-subnet-07.
Hopefully it can be addressed as a minor clarification in the AUTH48
stage, so I'm raising it.

Section 7.5 of the draft states:

   If an Intermediate Nameserver receives a query with SOURCE PREFIX-
   LENGTH set to 0 it MUST forward the query as-is and MUST NOT replace
   it with more accurate address information.

On the other hand, Section 7.1.2 states regarding the same case:

   A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT add
   address information of the client to its queries.  The subsequent
   Recursive Resolver query to the Authoritative Nameserver will then
   either not include an ECS option or MAY optionally include its own
   address information, which is what the Authoritative Nameserver will
   almost certainly use to generate any Tailored Response in lieu of an
   option.

These two seem to suggest different behaviors.  On re-reading it, I
found 'forwarded unchanged' or as-is' in Section 7.5 not very clear
(especially because it's seemingly different from what is described in
7.1.2), but I first thought this means the forwarding resolver keeps
the same ECS option (whose source plen is 0) in the query it sends
out.

Is that the actual intent of the authors?  If so, it's almost
impossible for me to interpret Section 7.1.2 that way.  And, whichever
is the authors intended behavior, I believe these sections should be
revised so they will be consistent.

--
JINMEI, Tatuya