Re: [netmod] upcoming adoptions

Robert Wilton <rwilton@cisco.com> Fri, 08 September 2017 15:22 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2CC132EE9 for <netmod@ietfa.amsl.com>; Fri, 8 Sep 2017 08:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 alZr93EKxgTV for <netmod@ietfa.amsl.com>; Fri, 8 Sep 2017 08:22:36 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDAE13292E for <netmod@ietf.org>; Fri, 8 Sep 2017 08:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4776; q=dns/txt; s=iport; t=1504884156; x=1506093756; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=1UC7QaPuCMpVScuUV/f1l5Ad3enq9mqPe6KLG30jdv0=; b=QaTxQ0sG3OOgFSsU3lZNdCR0A3q8tW4V3DNJY9qkAilneXtQhQctxdpd 74bXDDqmCD1BafR3ISIqBvOoI3fopQ9+WhKjYcQbhR60ztn5DHeoMSjyD tQ7XtwBBAbX4MrqbUaKu7Q78uBL5J+g7zoBe/ooT/aRrUjdtonvuW80yB c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AwB8tLJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+gX+EHosVkHMrkGmHUQqFPgKEThQBAgEBAQEBAQFrKIUZAQU?= =?us-ascii?q?jZgkCGCoCAlcGAQwIAQGKLY1EnWaCJyeLFAEBAQEBAQEBAQEBAQEBAQEBAQEfg?= =?us-ascii?q?yqDUIIOgn2ICIJhBaB0lFGLVIcdjVeHVIE5NiGBDTIhCBwVh2U/ilQBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,362,1500940800"; d="scan'208,217";a="654481596"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2017 15:22:31 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v88FMVSo005222; Fri, 8 Sep 2017 15:22:31 GMT
To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> <c5a6cbed-34d7-a49f-127c-82f0c20f0061@cisco.com> <20170908123853.4jmy24gvbe2agiif@elstar.local> <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com> <1504880639.21276.72.camel@nic.cz>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <6851ec11-5abf-bbca-de5a-f5fc422df9aa@cisco.com>
Date: Fri, 8 Sep 2017 16:22:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1504880639.21276.72.camel@nic.cz>
Content-Type: multipart/alternative; boundary="------------7116347E38319F74D0A06125"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SYzSG0yd5rvk33q8unYzcd-Uzb8>
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Sep 2017 15:22:37 -0000

Pulling out this particular question to see if others have an opinion on 
this.

Should we change 6087bis to reduce it reliance on RFC 2119 language?

The reasoning for proposing this change is to avoid accidentally 
creating future CLRs, because tool implementations might regard the RFC 
2119 language in 6087bis as defining rules rather than just offering 
guidance.

An example change:

Before:

    Prefix values SHOULD be short, but also likely to be unique.  Prefix
    values SHOULD NOT conflict with known modules that have been
    previously published.

After:

    Prefix values should be short, but also likely to be unique.  Prefix
    values SHOULD NOT conflict with known modules that have been
    previously published.


Thanks,
Rob


On 08/09/2017 15:23, Ladislav Lhotka wrote:
> Robert Wilton píše v Pá 08. 09. 2017 v 14:41 +0100:
>
>> It might be better if a lot of the guidance in 6087bis is changed to avoid
>> using RFC 2119 language precisely so that it can't be subsequently interpreted
>> as a formal rule.
> I very much agree with this, the use of 2119 keywords sometimes makes things
> confusing.
>
> Lada
>