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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 03 April 2020 11:33 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 688003A17DA for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2020 04:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 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, 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=W2JaX2rE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YRU6iTbb
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 kDZOh96X3ObN for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2020 04:33:26 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC803A17D1 for <netmod@ietf.org>; Fri, 3 Apr 2020 04:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51642; q=dns/txt; s=iport; t=1585913606; x=1587123206; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l7rQVJg2beYLpB1Pecc0QZUEUCzd7pHab61ZltL66oY=; b=W2JaX2rEX/QHptFhOq+rS2jF43QiBgB9mbxalsLAVn04LzrlSGJ2kVSt u2Ge2h1Uwp1NOD+fRShDj9dGj+dswrMxSbjr74owIn48YSSEizgHQKCdy rAFrpjrrnA0aXRD75czue8yX4HyoH5jHYdsDEK92IN01yqj7YMJCp+bUm Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3ASMLE4R3PSUH14vOYsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1L6KOLtaQQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUAAC3HYde/4gNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagMBAQELAYEkLyknBWxYIAQLKgqEEYNFA4pigl+YHoF?= =?us-ascii?q?CgRADVAoBAQEMAQEbEgIEAQGERAIXgi0kNwYOAgMBAQsBAQUBAQECAQUEbYV?= =?us-ascii?q?WDIVwAQEBAQIBEggJChMBATAHAQQLAgEIEQMBAQEBIAEGAwICAjAUCQgCBAE?= =?us-ascii?q?NBQgXA4MFgX5NAw4gAQOjPQKBOYhidYEygn8BAQWFMxiCDAMGgTgBixGBHxq?= =?us-ascii?q?BQT8mgS6CTT6CZwSBLgELBwEJGgwJCQwBCQKCWjKCLI1wSYJKhgOaEAqCPYd?= =?us-ascii?q?vj1OCTIg4kHyPMoFSh1GSegIEAgQFAg4BAQWBaCNncHAVgyRQGA2LP4JegSc?= =?us-ascii?q?BAoJJhRSFQXSBKYtmgTMBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.72,339,1580774400"; d="scan'208,217";a="483053075"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2020 11:33:25 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 033BXOQq031045 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Apr 2020 11:33:24 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 06:33:24 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 06:33:23 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 3 Apr 2020 07:33:23 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U0Q6AfPYljS6Q6s8Je9oqXexa+sAvJRFPIjEVE/ZBmvQfabsDzwO2EPzYVc221tdcA5S9d7Tvpy6yFmSl46dLhR4hZ7WS/jgg4tYummjiZ6NNgloOnWHVyV5Z8GkXDiQ71j+72EqCSP1oTDs89KdEjwdg31t5T81eH+k3lObQDBkbZMihX+I9HagOBuGjoWAi9lNXiR0Bt0hckfr7GOv6DocQZGHnZm4MzGFWz7mz/2SFcdURc/WQqiHdWphqCpBUlpXmj8IwKtmBRKm2ROEhMzB6CDckp0vIJ2biMWEdBli/S5Lca5Bv4ndQsOUg+5srTnHBQXJKSr3pPVEjnGN2w==
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=l7rQVJg2beYLpB1Pecc0QZUEUCzd7pHab61ZltL66oY=; b=Cq22OdvHXVnDiM7I9vt7A4QyALwBucQ6fzPgBRzJCCen9RZlHo5bkMuX4lXZbM7IPoh4EjGps24uiNPstbOm1nSkRmigLSNlHWFlMU4aFB/SoiRBR/7k1Nm0E5l0KAgxJL6DwFv1DSAu+SafMJZ7MX7wBlIaHNtymG+3QFqGh8Wro0ouGkpXPPdqTIldFqLU/A+rkzwpB+/QWOR8wNKqN7tNG6ZCdPN3Fp3uXvgb1g+QO6EpMtrJ70kgTcy9/L69RnNeCJor6HIMaS+7MHc9Ibj+EfM/su3nj2uhzIYPpbSGRioP/3XJUEXbEzAh11KRG2ZlSjA0+QKbOQpXjGKXDA==
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=l7rQVJg2beYLpB1Pecc0QZUEUCzd7pHab61ZltL66oY=; b=YRU6iTbbSUDNWVCC0KhGokFwbPvm3O+QTOWYdpqYvf3Ej4iz2B6Rz1j0FVF6b5z5/SyjnFZjpqBaOUoVu/45Gz3BbxLgmKqHLacRvD2ZsnLU2IIf96eNjFGvPa9QwHe/uYcjsIAuF2d8WNUaLqQ+oP9T4m4Shw87Dw/l/YrwFMw=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4510.namprd11.prod.outlook.com (2603:10b6:208:17b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 11:33:22 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2856.019; Fri, 3 Apr 2020 11:33:22 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>
CC: NetMod WG <netmod@ietf.org>, Italo Busi <Italo.Busi@huawei.com>
Thread-Topic: [netmod] versioning procedures (RFC vs. I-D)
Thread-Index: AQHWCEsdsdxhqzReCUKzwNXbrqGCL6hkiBIAgAAIEICAAAHBAIAA+WyAgAAjEgCAADZOAIAABbEAgAAU/ICAAA4FgIAAGVgAgAEbjPA=
Date: Fri, 3 Apr 2020 11:33:22 +0000
Message-ID: <MN2PR11MB4366F804BA2236F6A407C2D8B5C70@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <CABCOCHRDKKmU1+BL_4RPkn4sMhjN8w20_5rHWOoBCm8PCTTi1Q@mail.gmail.com> <B9DDE091-36C7-4E83-B20C-352E3C111151@cisco.com> <CABCOCHQYhqt3Zt80-BOvMh2yTpStMxXKYKQbq+mmEJMmHoMcLg@mail.gmail.com> <20200402.185141.761854093872914710.id@4668.se> <CABCOCHQPJuhmt+RvC+K59d1rXG--SG3W68ZGa3YyWXbWXorJTQ@mail.gmail.com>
In-Reply-To: <CABCOCHQPJuhmt+RvC+K59d1rXG--SG3W68ZGa3YyWXbWXorJTQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b364a874-75df-4680-9532-08d7d7c2d0d0
x-ms-traffictypediagnostic: MN2PR11MB4510:
x-microsoft-antispam-prvs: <MN2PR11MB45107257BDE29E6765D67CC5B5C70@MN2PR11MB4510.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0362BF9FDB
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(39860400002)(396003)(366004)(376002)(136003)(966005)(66556008)(478600001)(55016002)(64756008)(26005)(30864003)(66446008)(66476007)(66946007)(86362001)(186003)(52536014)(33656002)(81166006)(66574012)(6506007)(9686003)(4326008)(71200400001)(2906002)(8936002)(110136005)(316002)(7696005)(5660300002)(53546011)(8676002)(54906003)(76116006)(81156014); 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: doMpZGruGb3KSW/nN9EFd4iwkKPTvAA4H6OeDf7qwZTBlDuC4XC5K2egbg8drgNP6UPH18GwVY8jTTuOwpZVwvKCgyX0bh5sWaehG1gW3U4boweWzavKzeHsJEnNg2Dx1B3JlHuXhlNDNTEWQ5QweeQG+/zyZveVWLrWABitF2Dc2A3Bzn7KI0zKdyvXxBrEnpd2PIusFDxEnunkY96qkE1zlmFy56EeCDVsZ6imcHWfqti+Ve+fu8WjmJ2zlCEHpaeOnw0R7XN4tkeDD32T8ZexI9Z9tXJc32G/nl1wWkx5gXOr30BHTBDpMZg75HjKPLj4NeKVZWpSJvQ8QbO26ctLUxn5xr27rG2pEA/Fkfe9Pc3oUvzuV4/kyDM5uyiKzk4YRno3qCfsr9xJxKT28J56SlvGQDbPBmc2ThOEuLJaoSfA8s8OzsL9uU1GMU1ogoMGAqRNl73bWALxUjO6sKpeEuJzr/W+xvP3fwS7JWHlyo2GqgKw2OSG/donbqFE/IbB724FXKB564z54PZTSg==
x-ms-exchange-antispam-messagedata: SOatPmpdOKClibujgoBTq/SUuBdKpszirbbnMldB41aslQPnBSuUn9MYIMGw27pt9BdZxfLz+HqlWmwwc8r5oJhhMlZw/FP389h0beblQFGVQxI7pBvPogBKkHZCg6IY3mmxjk2UH/iRDCjO5mRiFA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366F804BA2236F6A407C2D8B5C70MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b364a874-75df-4680-9532-08d7d7c2d0d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 11:33:22.1413 (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: nlleZskPrdMeRSEa9b1v58TkPS7l2bMHRg1yjYorp991aGtCTtpEnLtwwVl6t6mdfMhfZzNV2/5PRhh7uY74zg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4510
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/w40NqKoeWQy_vV0kgB4Vlu76cW4>
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: Fri, 03 Apr 2020 11:33:33 -0000

[As a contributor]


Although, I can see how increasing the number from the starting version makes more logical sense, I think that it is better to conform to the semver rules.

Hence, I would suggest that the process to update the version string could look something like this:

Starting with RFC 6991 version 1.0.0.

Bis version with backwards compatible change: “1.1.0-6991bis-01”

If the next bis version has NBC changes, then it would be : “2.0.0-6991bis-02”

Then the WG decide that an NBC change isn’t required, so the next draft version is: : “1.1.0-6991bis-03”

Once it gets to new RFC, then the version becomes “1.1.0”.

I think that this conforms to the Semver 2.0.0 rules, specifically paragraph 9 at https://semver.org/

Regards,
Rob


From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: 02 April 2020 19:22
To: Martin Björklund <mbj+ietf@4668.se>
Cc: NetMod WG <netmod@ietf.org>rg>; Italo Busi <Italo.Busi@huawei.com>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Thu, Apr 2, 2020 at 9:51 AM Martin Björklund <mbj+ietf@4668.se<mailto:mbj%2Bietf@4668.se>> wrote:
Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>> wrote:
> 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

If this was normal semver, it would be:

bis-draft-00:   2.0.0-1
bis-draft-01:   2.0.0-2

etc.  ("+" and "-" have special meaning in semver)..

One problem though is that when the -bis work starts, it might not be
clear if the end result (published RFC) will be NBC or BC.  And this
might change back and forth during development of the I-D.

What happens if there are multiple release trains in progress?
Seems more useful to base the label on the known starting point
instead of the possible ending point.


I think it quite clear that such a label should not be used in I-Ds.


Agreed


/martin


Andy


>
> 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>
> >
> >
> >
> > 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
> >
> >
> >
> >