IETF Logo Mail Archive

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

神明達哉 <jinmei@wide.ad.jp> Fri, 02 December 2016 19:55 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 C020B124281 for <dnsop@ietfa.amsl.com>; Fri, 2 Dec 2016 11:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 4mFNmlvfgEBX for <dnsop@ietfa.amsl.com>; Fri, 2 Dec 2016 11:55:17 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 60446126579 for <dnsop@ietf.org>; Fri, 2 Dec 2016 11:55:17 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id x190so290100762qkb.0 for <dnsop@ietf.org>; Fri, 02 Dec 2016 11:55:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=P9r8Q7o9DOh6d0SgQz+2Dz2tV1tc8Xu7CuUBFg71VGM=; b=08s14sli9iqgqyHfbLJml9VAzWYg9tzaNuly4EvnIydV2akGomGG4JqLQYEnj7DWmC hWkQOasvAwLH2hia2y7u+VYxsTQlIyxik3gHy+82iY65Mh5JezTyRsDtKKgYE+K2xloD 68URH6EsiLlvBJ/eraCmtTf/rovOccVtNF+YHINIGVrME7OMONNCqqRXsdeg00HV15YR 4S8cZLDxQpCCrjQYuNv1R35zRBPMWcdKY8mzOEg2bR79/kXrfx0aHSZNJn7QKgL1q++H 6EtVMhN1D7aMUgZfbmgIuNF+2N8siwQsf1G0uIsCxM6iIGIJM/B81+mfygd8GEljVVwZ jkMQ==
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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=P9r8Q7o9DOh6d0SgQz+2Dz2tV1tc8Xu7CuUBFg71VGM=; b=b4x6WVQdTfOUSnrmgQEAwygeZsO5PX6JiHcTR/b/0Jyorz1h10ar5qJEY4vOkcDLTu sy5DUiAmSRDqnQxPh6HT2aJ9DJBs0Wsr7MU4Tli+q1gOkNIrxC13AqNMqO8hOZS1jr6Z dAlshvR5rxp8lb3V1GgxENhszHLkTL5/eHWEiq7qkhy8Io4GvtqmV18BoOZVIUCodA5f 1JVo+0ojMZDR+nFCA2iuTPY0tBnTgJAx7aWluD2ojfFob2jhfQ415i9W7/VhhBReVHRP OdAJiZ6kyJs7B4Nw7s4iRO4g8ixv7ACKz8lpDcoE29TsSSbZKrIqqgUn1nl4vlXlVvgY yJqA==
X-Gm-Message-State: AKaTC03NDMPTY/H2kIgFscWXkA0qWdva5iiQ/32E4omTtUvCuPHkiwktSvO513RQt+ix/eIgw6bi8RKyOrc7qw==
X-Received: by 10.55.20.164 with SMTP id 36mr38528978qku.86.1480708516468; Fri, 02 Dec 2016 11:55:16 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.53.155 with HTTP; Fri, 2 Dec 2016 11:55:15 -0800 (PST)
In-Reply-To: <CADyWQ+FwGf66+HL3W46C2d1BJZoyRxBDPPw8Yuup8k0Haise=g@mail.gmail.com>
References: <CADyWQ+FwGf66+HL3W46C2d1BJZoyRxBDPPw8Yuup8k0Haise=g@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 02 Dec 2016 11:55:15 -0800
X-Google-Sender-Auth: xx2jvpnXFYMqcflU5j6QWp_uUNw
Message-ID: <CAJE_bqeXL9tqs8jf-S=LyEiTT0PG6z_ELTrDAiJW2u065FKARg@mail.gmail.com>
To: tjw ietf <tjw.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CEoIOoF2cP0EFc0xvjJfiBX3JGk>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any
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: Fri, 02 Dec 2016 19:55:21 -0000

At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf <tjw.ietf@gmail.com> wrote:

> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.
>
> *Also*, if you have any opinion on changing the document named from
> 'refuse-any' to 'minimal-any', please speak out.

I've read the 03 version of the document.  I do *not* think this is
ready for publication since I still believe we should not abuse HINFO
for this purpose as I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).

As for renaming the file, I don't have a strong opinion, but we expect
a bigger issue like HINFO can lead to more revisions, it would be good
to rename it at this opportunity in order to avoid confusion for
future readers.

Some specific comments on the text:

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
       the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me, partly because
  'a subset of RRSets' should include 'one of RRSets' and can thus be
  redundant, and partly because 'subset of RRSets" might sound related
  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
  So I'd suggest changing this one of the following:
  - "one or a few of RRSets (but not all of them)"
  - "one or a few of RRSets"
  - "a subset of RRSets"
  I personally prefer the first most although it may be too verbose.

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

- Section 4

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer (or authority if answer is empty) section MUST
   be returned.

  Does this also apply to a synthesized HINFO (if so, by dynamically
  signing it?)?

- Section 6

   In the case where a zone that contains HINFO RRSets is served from an
   authority server that does not provide conventional ANY responses.

  This may be just because of my English literacy, but on my first
  read it was quite confusing to me; I first thought the second 'that'
  was a relative pronoun, which would make this text an incomplete
  sentence.  If there was a comma after 'server' that would be more
  readable for me.

- Section 7: a minor typo, s/implimentations/implementations/

   not return all RRSIGS.  In the wild there are implimentations that

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email