Re: [netmod] versioning procedures (RFC vs. I-D)

Italo Busi <Italo.Busi@huawei.com> Thu, 02 April 2020 09:06 UTC

Return-Path: <Italo.Busi@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 63E7A3A0E09 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2020 02:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZqtEEn5H_3XI for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2020 02:06:13 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CEF473A0E07 for <netmod@ietf.org>; Thu, 2 Apr 2020 02:06:12 -0700 (PDT)
Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A2EE1A54E6AB808CBE34; Thu, 2 Apr 2020 10:06:10 +0100 (IST)
Received: from fraeml718-chm.china.huawei.com (10.206.15.14) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 2 Apr 2020 10:06:10 +0100
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml718-chm.china.huawei.com (10.206.15.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 2 Apr 2020 11:06:09 +0200
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.1913.007; Thu, 2 Apr 2020 11:06:09 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Andy Bierman <andy@yumaworks.com>, "Joe Clarke (jclarke)" <jclarke@cisco.com>
CC: NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] versioning procedures (RFC vs. I-D)
Thread-Index: AQHWCFfTB1C1Y87lGEq1iuQDM3OPs6hliklA
Date: Thu, 2 Apr 2020 09:06:09 +0000
Message-ID: <b688d8372a1a49e8828c74b5366458c0@huawei.com>
References: <CABCOCHQWssUucRvnsi8O8+GhCHb0-xS--swf3R4q-6P3Qfq0TA@mail.gmail.com> <D63416FC-2C33-4015-BF23-51ABCD75A020@cisco.com> <CABCOCHSTnYJbB9ainkmCuBinjRZAi-wEWgQoFCrhs+m8NBAAYQ@mail.gmail.com> <50052092-0380-44C6-8AE0-1AB3C15C30B4@cisco.com>
In-Reply-To: <50052092-0380-44C6-8AE0-1AB3C15C30B4@cisco.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.84.11]
Content-Type: multipart/related; boundary="_004_b688d8372a1a49e8828c74b5366458c0huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_FejHN4WgarvfXnhhlb2LKASoTk>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 02 Apr 2020 09:06:16 -0000

Reshad,

My doubt and, if I understand well also Andy’s question, is about the fact that before publishing an RFC-bis with e.g., 1.1.0, we will have a set of Internet-Drafts updating the RFC with 1.0.0

What versions should be used in the YANG modules published in these Internet-Drafts?

Think about the following scenario: -00 version provide BC changes to the RFC module but the -01 version provide NBC changes to what has been added in the -00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with the -00 version module)

Thanks, Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.busi@huawei.com
[cid:image001.png@01D608DE.BF398C70]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]
Sent: mercoledì 1 aprile 2020 20:13
To: Andy Bierman <andy@yumaworks.com>om>; Joe Clarke (jclarke) <jclarke@cisco.com>
Cc: NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)


From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> on behalf of 'Andy Bierman' <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" <jclarke@cisco.com<mailto:jclarke@cisco.com>>
Cc: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) <jclarke@cisco.com<mailto:jclarke@cisco.com>> wrote:


> On Apr 1, 2020, at 13:28, Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>> wrote:
>
> Hi,
>
> I just want to confirm that all the proposed documentation procedures
> using new extensions are limited in scope to published modules only,
> and not applied to unpublished modules (terms defined in RFC 8407).
>
> IMO it would be harmful to module usability to assign revision-labels or
> include revision-related extensions in unpublished modules (e.g., Internet Drafts).
> Consider how cluttered and confusing the client-server modules would be
> if the 50+ NBC changes and versions were tracked through all the I-Ds.
>
> For IETF modules, the first usage of the revision-label
> should be in the initial RFC, and be set to 1.0.0.
>
> If the RFC is ever republished then one can expect to find an updated
> revision-label and possibly extensions tracking NBC changes.

The semver scheme allocates a major version of 0 for pre-releases where the BC/NBC rules do not apply.  I agree that a first official RFC release should be 1.0.0 (from a semver revision-label standpoint).  From a design team standpoint, I know we mentioned the 0 versioning early on, but I don’t think we spent much time talking about modules under development overall.


IMO it is confusing to ignore the semver rules for the special 0.x.y releases.
There are many NBC changes made at this point which are treated as minor or patch changes.
The procedure is really broken once you consider a WG developing any RFC-bis module.
Now the major version is not 0 and all updates look like real releases.
<RR> I don’t think that’s needed. Initial module in RFC has 1.0.0, module in (released) RFC-bis can go to 1.0.1, 1.1.0 or 2.0.0 depending on the change.

Regards,
Reshad.

My take would align to yours that we wouldn’t clutter a module with development NBC tracking.

Joe

Andy