Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?

Alexander Clemm <alexander.clemm@huawei.com> Tue, 17 October 2017 17:55 UTC

Return-Path: <alexander.clemm@huawei.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 B665213301F for <netmod@ietfa.amsl.com>; Tue, 17 Oct 2017 10:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level:
X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 QkpajYWo1YZz for <netmod@ietfa.amsl.com>; Tue, 17 Oct 2017 10:55:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D8132D4E for <netmod@ietf.org>; Tue, 17 Oct 2017 10:55:18 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQV19770; Tue, 17 Oct 2017 17:55:16 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 18:55:15 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Tue, 17 Oct 2017 10:55:11 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Kent Watsen <kwatsen@juniper.net>, Benoit Claise <bclaise@cisco.com>, NETMOD Working Group <netmod@ietf.org>
Thread-Topic: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
Thread-Index: AQHTKwinz8b16Al03k2EB25gLpBWaaKyCYyAgDZbZ4CAAJm/AP//i9kA
Date: Tue, 17 Oct 2017 17:55:10 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C09@sjceml521-mbx.china.huawei.com>
References: <fd7e4552-4ad1-211a-264b-f493a22ff5a6@cisco.com> <BF141879-A1E4-439F-9AB2-52EC0B63155F@juniper.net> <05f83ee0-4091-4941-e130-b42102521062@cisco.com> <A1EF591A-4459-44B1-82DB-C5C0000AC4C8@juniper.net>
In-Reply-To: <A1EF591A-4459-44B1-82DB-C5C0000AC4C8@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.110]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C09sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59E64405.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7d703a634d23a5eb0bac363d3d4ea5f3
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YkRf0R44KlCTp8Og4fv-B9ZVfCM>
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
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: Tue, 17 Oct 2017 17:55:22 -0000

Intuitively, BCP seems the right choice to me.  Also, I think it is fine to issue an RFC now even if it is clear it will need updating later.  IETF really needs to get better at releasing documents faster, it’s not as if there is a shortage of integers and potential churn is at this point less of a concern than timeliness.   So, on those grounds, yes/support.

--- Alex

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, October 17, 2017 10:45 AM
To: Benoit Claise <bclaise@cisco.com>; NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?

Hi Benoit, et al.,

As a contributor, I support your proposal to move rfc6087bis to BCP, and I know that Lou does as well (I just asked him).  As co-chair, reading Section 6.1.1 of RFC 2026, I feel that we need to formally run the decision past the WG.  So, without further ado:

This is the start of 1-week poll to gauge WG consensus on the proposal to promote rfc6087bis to BCP.  We'd like to hear "yes/support" or "no/don't support", with an explanation for why.  Please respond by Oct 24.   (better, hit the reply-all button now!)

Thanks,
Kent (and Lou)




On 10/17/17, 4:35 AM, "Benoit Claise" <bclaise@cisco.com<mailto:bclaise@cisco.com>> wrote:

Hi Kent,
Hi Benoit,

BCP seems right, but I wonder if there is some sort of stability metric that applies to BCPs.

   The BCP subseries of the RFC series is designed to be a way to

   standardize practices and the results of community deliberations.


https://tools.ietf.org/html/rfc2026#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc2026-23section-2D5&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=dL2SzevPrC4Ak-LYJY77M0cArIHFsM3svOz2X06jytY&s=O_GnXGQDkkAG4hGnmdn6udA0s5orNxjkKYYWDoO-MnM&e=>
YANG still seems to be evolving, so I can only imagine yet another update to this document
in the not too distant future.  Does that disqualify it in any way?
I don't think so. Implicitly, this says:

   The BCP subseries of the RFC series is designed to be a way to

   standardize practices and the results of community current deliberations.

If the YANG use and knowledge spread, this document will evolve in the future.

The problem to be solved, which I faced: "RFC6087 is informational (as opposed to BCP), so I don't feel like I should follow it"

Regards, Benoit

Kent


On 9/11/17, 10:16 AM, "netmod on behalf of Benoit Claise" <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org> on behalf of bclaise@cisco.com<mailto:bclaise@cisco.com>> wrote:

Dear all,

I'm wondering if it's not time to classify draft-ietf-netmod-rfc6087bis as a BCP, as opposed to informational

This text would need to change:

   This document is similar to the Structure of Management

   Information

   version 2 (SMIv2) usage guidelines specification [RFC4181] in intent

   and structure.  However, since that document was written a decade

   after SMIv2 modules had been in use, it was published as a 'Best

   Current Practice' (BCP).  This document is not a BCP, but rather an

   informational reference, intended to promote consistency in documents

   containing YANG modules.


Indeed, it seems to me that the consistency in YANG modules is a pretty important topic.

Feedback?

Regards, Benoit