Re: [DNSOP] Working Group Last Call
Matthijs Mekking <matthijs@pletterpet.nl> Wed, 05 October 2016 07:40 UTC
Return-Path: <matthijs@pletterpet.nl>
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 BA8F412954D for <dnsop@ietfa.amsl.com>; Wed, 5 Oct 2016 00:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 08FMS13YrU6b for <dnsop@ietfa.amsl.com>; Wed, 5 Oct 2016 00:40:08 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA2E12955E for <dnsop@ietf.org>; Wed, 5 Oct 2016 00:40:07 -0700 (PDT)
Received: from [172.19.128.42] (vpn-10-mht.dyndns.com [216.146.45.33]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 725A8B97D; Wed, 5 Oct 2016 09:40:04 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl
To: 神明達哉 <jinmei@wide.ad.jp>
References: <40d5f4b1-3019-7f8a-ecc0-2f4d13e3eadf@gmail.com> <eda9f6f0-6ecc-9fcf-d961-d60d20831549@pletterpet.nl> <CAJE_bqdmF8PYQomcH80RdOgO_VPy=3+pTK7H1VYKB+6ND-_GOw@mail.gmail.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <2174ce1f-5ef7-0578-a201-e2c04c463df6@pletterpet.nl>
Date: Wed, 05 Oct 2016 09:40:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAJE_bqdmF8PYQomcH80RdOgO_VPy=3+pTK7H1VYKB+6ND-_GOw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_MYNEQl9LKl5fKGRPf_f5rZs2zU>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call
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: Wed, 05 Oct 2016 07:40:10 -0000
On 04-10-16 18:34, 神明達哉 wrote: > At Tue, 4 Oct 2016 14:06:54 +0200, > Matthijs Mekking <matthijs@pletterpet.nl> wrote: > >> 2. In addition to the first point, I don't think it is appropriate to >> use RFC 2119 keywords to dictate name server configuration. Mentioning >> it would be useful to have configuration options for enabling and >> disabling this functionality seems okay, but drop the RFC 2119 formalities. > > I don't have a strong opinion on your suggestion (dropping RFC2119 > keywords for configuration) itself. But I thought this type of text > was pretty common in RFCs. A quick google pointed to section 4.2.3.6 > of RFC1122: > > This interval MUST be > configurable and MUST default to no less than two hours. > > I believe there are more recent precedents, too. So the draft text > didn't necessarily look inappropriate to me (whether the requirement > level is appropriate is a different question). RFC 2119 has a section on guidance in using these imperatives: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. According to this guidance, I think configuration options should not be subject to these imperatives. Best regards, Matthijs > > -- > JINMEI, Tatuya >
- [DNSOP] Working Group Last Call Tim Wicinski
- Re: [DNSOP] Working Group Last Call Warren Kumari
- Re: [DNSOP] Working Group Last Call on "Aggressiv… John Levine
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Stephane Bortzmeyer
- Re: [DNSOP] Working Group Last Call 神明達哉
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Matthijs Mekking
- Re: [DNSOP] Working Group Last Call Matthijs Mekking
- Re: [DNSOP] Working Group Last Call 神明達哉
- Re: [DNSOP] Working Group Last Call on "Aggressiv… Warren Kumari
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Warren Kumari
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… John Levine
- Re: [DNSOP] Working Group Last Call Warren Kumari
- Re: [DNSOP] Working Group Last Call Matthijs Mekking
- Re: [DNSOP] Working Group Last Call 神明達哉
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Bob Harold
- Re: [DNSOP] Working Group Last Call Tim Wicinski
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Stephane Bortzmeyer
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… John R Levine
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Stephane Bortzmeyer
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Tim Wicinski
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Warren Kumari
- Re: [DNSOP] Working Group Last Call 神明達哉
- Re: [DNSOP] Working Group Last Call on "Aggressiv… Matthijs Mekking
- Re: [DNSOP] Working Group Last Call Warren Kumari
- Re: [DNSOP] Working Group Last Call Warren Kumari
- Re: [DNSOP] Working Group Last Call Warren Kumari
- Re: [DNSOP] Working Group Last Call Tim Wicinski
- Re: [DNSOP] Working Group Last Call [draft-ietf-d… Warren Kumari
- Re: [DNSOP] Working Group Last Call Matthijs Mekking
- Re: [DNSOP] Working Group Last Call Warren Kumari
- Re: [DNSOP] Working Group Last Call Warren Kumari