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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Thu, 02 April 2020 18:21 UTC

Return-Path: <rrahman@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 D6B063A1039 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2020 11:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=flZyFqFQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GlAK8QRw
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 ztMZs2jBba6O for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2020 11:21:15 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16013A0FE8 for <netmod@ietf.org>; Thu, 2 Apr 2020 11:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113587; q=dns/txt; s=iport; t=1585851674; x=1587061274; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jlQ7EJ3wJiVgNBNFpgDHgTjJVMy88xj5uT3PDIfp+0U=; b=flZyFqFQF1CWwDjGjca9lL/ptYcwnkYCWmKq9KIEyHeuXcYarmV5JxQx U7MqX1BiAzAw1Vp/8ZTt4DcP3ge9prru4agZXNMW/xLld5tYAjq483VFL icz2zhAZl/untSN8m80rxuSMW4y7zc+DTo/ewey3mxymZWzLu8DV8UA43 E=;
X-Files: image001.png : 38864
IronPort-PHdr: =?us-ascii?q?9a23=3Ad8woEhXjq6NotdytMY5laAjsk87V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankgBs1CUVZj13q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAgDiLIZe/4sNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4ElLyknBWxYIAQLKgqEEYNFA4pogjolh0qQU4FCgRA?= =?us-ascii?q?DVAMHAQEBCQECAQEjCgIEAQGERAIXgiokOBMCAwEBCwEBBQEBAQIBBQRthVY?= =?us-ascii?q?MhXABAQEBAgEFAQwRAggBEgEBMAcBBAsCAQgRAwEBAQEFAQEBGAEGAwICAgU?= =?us-ascii?q?QAQ4MFAkIAgQOBAEGCBEDgwQBgksDDiABDqRsAoE5iGJ1gTKCfwEBBYUqGII?= =?us-ascii?q?FBwMGgTiDDIQqg1yBHxqBQT8mgRIMEIJNPoJnAoEwAQsHAQkmCQkMAQkCglo?= =?us-ascii?q?ygiyNcEmCSoV9gSqJBoUwgnOHNQqCPYY/AoEqjzQdgkyIN5B1jWeKZZJ4AgQ?= =?us-ascii?q?CBAUCDgEBBYFpIio9cHAVZQGCPlAYDYs/gl4MF4EEAQKCSYpVdIEpi0iBMwG?= =?us-ascii?q?BDwEB?=
X-IronPort-AV: E=Sophos;i="5.72,336,1580774400"; d="png'150?scan'150,208,217,150";a="659776461"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2020 18:21:12 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 032ILCmr024698 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Apr 2020 18:21:12 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 13:21:11 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 13:21:11 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 2 Apr 2020 13:21:11 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eMvJ80uwcPnYOfqPVLggKhf+11J32sGMeqs7pHKhbE5b22ai4aFqVKGufHSr2jWPIesf9gJwwbK0XtSWcdrAqKvisauMDP7vM3NFmArnDRUJjrEzo0OvN56AfDS+yKIQSgiCR4MAj65GFYa4844/gSfaO5PRo//BhrBwiMAVSO7H8Y463Gin6NH9+02j7eMJmkze1Linm6hdSJYq+K8xIM09AxP0u3/l7yI9HYEoXyEAUbxAJYvfXzR7iyXhF0FuxbkDAchOI9VDYPmQpkt6XC6L6I35/hdtakRxViRTRViDG6hojk6btnfRWn89yKNircpJSfnkEiEbi88/iRGJFQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z0qz4AC0emMFVwuVrZnANDqSlNfksqPvVRe3CM22cIk=; b=NHtNE9Bsv6KD1BnitzVnp3+IvtJgCFKRL0Jjb77yyE3ghMfXP62zm1gfRwZgwzss+LkUYRQVIl5SBYrnL3UwpYtZdBModZawS1GH8yP2b/O6WAzZ09+SLTiv5DmqutMx4zt3nV00Ne0HnEHzPCnhegcFGtGDDid8CG4pgHs+bKh7kCuLhN0GyCuKxAsggw2+SWmX2k8W0wDfmTKI987A7rISxPcMUFJvMhu8mFyd+aRXpjvdsNV1r3p7DDdgacal7UQ8dCDF2B5ApmbnBtSdyI07SWNKOhBzGxwXtRJzDGk2HLgtgEZsMoYYba15DTZzJplBNF9FCxp1t7CBWfPS6A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z0qz4AC0emMFVwuVrZnANDqSlNfksqPvVRe3CM22cIk=; b=GlAK8QRwNgM+jZSnd4cYwcvGoLvZyY4HjFwrfKv2HGI1ymUfNlPg6P4qo+d/cEofocl1W7ZjYn+RCK2yrhoZfArg+764FDAVQiod51pWDOPkdXxU8xuGJk2iSJsfQ7X3oHuv59Knp/vtFI9EP05B5A1tY5hVxCbXWSUKvrEZhLg=
Received: from BN6PR11MB1748.namprd11.prod.outlook.com (2603:10b6:404:101::12) by BN6PR11MB4001.namprd11.prod.outlook.com (2603:10b6:405:7f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Thu, 2 Apr 2020 18:21:07 +0000
Received: from BN6PR11MB1748.namprd11.prod.outlook.com ([fe80::d1f9:733e:e200:f972]) by BN6PR11MB1748.namprd11.prod.outlook.com ([fe80::d1f9:733e:e200:f972%6]) with mapi id 15.20.2878.016; Thu, 2 Apr 2020 18:21:07 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Andy Bierman <andy@yumaworks.com>
CC: Italo Busi <Italo.Busi@huawei.com>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] versioning procedures (RFC vs. I-D)
Thread-Index: AQHWCEsdhK7pv7UtbUSphpF+AjGnn6hkiBIAgAAIEID//76sAIABPIGA///gAQCAAHlfAP//wp+AAAsB24D//+PvAA==
Date: Thu, 2 Apr 2020 18:21:07 +0000
Message-ID: <4808B6F0-9771-449C-88B8-23814EE21267@cisco.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> <b688d8372a1a49e8828c74b5366458c0@huawei.com> <1DE96CAC-43BC-4638-AE96-2E770CA7CE20@cisco.com> <CABCOCHRDKKmU1+BL_4RPkn4sMhjN8w20_5rHWOoBCm8PCTTi1Q@mail.gmail.com> <B9DDE091-36C7-4E83-B20C-352E3C111151@cisco.com> <CABCOCHQYhqt3Zt80-BOvMh2yTpStMxXKYKQbq+mmEJMmHoMcLg@mail.gmail.com>
In-Reply-To: <CABCOCHQYhqt3Zt80-BOvMh2yTpStMxXKYKQbq+mmEJMmHoMcLg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com;
x-originating-ip: [70.31.50.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cccb0884-db46-4874-04aa-08d7d7329d05
x-ms-traffictypediagnostic: BN6PR11MB4001:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN6PR11MB4001C6313C98BC9332471FC9ABC60@BN6PR11MB4001.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 0361212EA8
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1748.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(346002)(136003)(39860400002)(366004)(4326008)(53546011)(186003)(6916009)(71200400001)(6506007)(8936002)(2906002)(5660300002)(2616005)(81166006)(81156014)(6486002)(8676002)(64756008)(66446008)(66946007)(76116006)(26005)(86362001)(966005)(478600001)(99936003)(316002)(66616009)(66556008)(66574012)(36756003)(6512007)(33656002)(91956017)(54906003)(66476007); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yUzsyZo8sWr7x5D1kSsG0OkMFYrbAXzZd/oWjhFDGmc9Q9ChSCDf7xh4pTyk2p7oZQAmMcHVHX5j6vhhHGeYf/1haG3pmpqvVbxznHvzi7uHHPzvtI59+9F+JXi4w2bRSUbVAz1220rse66US7s9msXXUk9PCdUsGfEEzLJWG42ZpqB0w4A4aN/gGJ1nXgXrlM3damBPHwz2Fuf8ce47vxcp81qmxHxvsGY0RW3mKSXsRTL7LqOGzM0mdW7N8WQcPKF2gqaUIsUDF9hCJt2NlUkI/j6jKrChrTU75pNEs2LKcAekKT6kV81jW/+RBrxuKojmB2P48/EnX6IxQjgZDOLIx5RXfxAJaiDXIyNu02JYCqA02tzJIeZ+dg1WpwLmHY/UIXfxozTZaPj5hN5f5+jd33dB1+ll7oHkr1wUEIyc7+l6fwrUPpfjEFTJ0agCo+b9hbTtpOKBriuF1piclJNGpfC1drxKRiO31WNNQSpZIgMnV6P5bAah5IhR8pVrSN1WE9p0tle4b8gvNQYrlA==
x-ms-exchange-antispam-messagedata: 0KGjHay2qVGOE6rNFFucnrTp1l8Wfz+wwvT6YHkRSR6D6HcCkKdyBko7Cwi1orpev2djRC+S1Gjmhhr2YNYovRAsoZzNDlxBspfJHh7ZMA1QTcWkVSvtesuWa8QpjHvEIq//IK5WYdy8TroNues4Hw==
Content-Type: multipart/related; boundary="_004_4808B6F09771449C88B823814EE21267ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cccb0884-db46-4874-04aa-08d7d7329d05
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 18:21:07.6943 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: diqdSS+QxICefJh9vRCpAAxAh8+3rz3xI1OJ3eVnq+exXGRDFbAgUipo4cSoDE/HWXn0kZhMoq69+2GDYW3JwQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4001
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/DQAMr88_7uFUpIuuewGj3UKrTdM>
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 18:21:21 -0000

This is being tracked via https://github.com/netmod-wg/yang-ver-dt/issues/56

Regarding this:
The BC vs. NBC distinction is not relevant for a work-in-progress.
We have seen many times in this WG where a NBC change was made
and then later undone.  There is no value in tracking the module during development.

It might not be relevant/important during the multiple initial revisions. But when we reach (WG)LC, I think it’s an important piece of information.

Regards,
Reshad.

From: 'Andy Bierman' <andy@yumaworks.com>
Date: Thursday, April 2, 2020 at 12:02 PM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: Italo Busi <Italo.Busi@huawei.com>om>, "Joe Clarke (jclarke)" <jclarke@cisco.com>om>, NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

Hi,

I agree that a revision-label could be useful in an I-D but not to indicate NBC changes (because it doesn't).
The rules need to be clear and simple with no exceptions.

 1) Special version 0.x.y contains NO NBC information
     Major version = 0 means the module has no published version

 2) First published version is 1.0.0

 3) The revision-label in an unpublished module has a special form which simply identifies
      the source of the development and the iteration of the work-in-progress.
      You can't really pick the next published label until the module is ready.

From my example:

draft-00:   0.1.0
draft-01:   0.2.0
draft-02:   0.3.0
RFC-1:    1.0.0
bis-draft-00:   1.0.0+1
bis-draft-01:   1.0.0+2
bis-draft-02:   1.0.0+3
[repeat NBC step bis-draft-02 10 times]  1.0.0+4 .. 1.0.0+13
RFC-2:  2.0.0   (in general: 1.0.1 or 1.1.0 or 2.0.0)

The BC vs. NBC distinction is not relevant for a work-in-progress.
We have seen many times in this WG where a NBC change was made
and then later undone.  There is no value in tracking the module during development.


Andy


On Thu, Apr 2, 2020 at 7:46 AM Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>> wrote:


From: 'Andy Bierman' <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Date: Thursday, April 2, 2020 at 10:26 AM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>, "Joe Clarke (jclarke)" <jclarke@cisco.com<mailto:jclarke@cisco.com>>, NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>> wrote:
Hi,

From: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, 'Andy Bierman' <andy@yumaworks.com<mailto:andy@yumaworks.com>>, "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)

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)
<RR> So bis 00 would be 1.1.0 (BC with RFC module).
Bis 01 should be updated according to its relationship to the RFC module (bis 00 doesn’t matter anymore), when RFC bis is published it won’t have the full history.

Hope I correctly understood your question.


This semver plan is not very intuitive and not sure it works.

draft-00

   container the-container;             version 0.1.0      OK

draft-01:
   container my-container;             version 0.2.0;   rules violated; NBC should force 1.0.0

draft-02:

    container my-container {           version 0.3.0; should be 1.1.0
        leaf my-leaf { type int32; }
    }

RFC-1:

    container my-container {           version 1.0.0;  should be 2.0.0 according to NBC rules
        leaf my-leaf { type uint32; }
    }

bis-draft-00:

   container my-container {           version 1.1.0; OK
        leaf my-leaf { type uint32; }
        leaf another-leaf { type int32; }
    }

bis-draft-01:

  container my-container {                  diff against RFC-1:  version 1.1.0 but already used; use 1.2.0?
        leaf my-leaf { type uint32; }
        leaf another-leaf { type uint32; }
    }

bis-draft-02:

  container example-my-container {                  diff against RFC-1:  version 2.0.0 but use 1.3.0 instead?
        leaf my-leaf { type uint32; }
        leaf another-leaf { type uint32; }
    }

[repeat NBC step bis-draft-02 10 times.... now up to version 12.0.0 or is it 1.13.0? something else?

RFC-2:   publish draft-12 as RFC-2: now change the label from 1.13.0 to 2.0.0? or leave it 12.0.0?

IMO it is very confusing that the stated rules are so inconsistent and are violated so many ways.
There should be no revision-label at all in Internet Drafts because these documents are unpublished.
They should only be added to the RFC version.

The semver procedures are not intended to work for unpublished modules that are only
meant for review, not for implementation. The revision-label provides only noise in Internet Drafts.
<RR2> I think it’s useful to have a revision label in a draft because it indicates nature of changes (BC v/s NBC) compared to the previous published revision (RFC).
But you are absolutely right that setting the version based on changes with the previous draft revision is useless and confusing.

Regards,
Reshad.


Regards,
Reshad.

Thanks, Italo


Andy


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

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<mailto:rrahman@cisco.com>]
Sent: mercoledì 1 aprile 2020 20:13
To: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>; 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)


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