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: =?UTF-8?B?56We5piO6YGU5ZOJ?= <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, 5 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
>