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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 03 April 2020 11:39 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 D99463A17FF for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2020 04:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lV0V4wMb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=G9uU8AIl
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 vsXv3MEFn4it for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2020 04:38:55 -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 CBAEE3A17F7 for <netmod@ietf.org>; Fri, 3 Apr 2020 04:38:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14464; q=dns/txt; s=iport; t=1585913935; x=1587123535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ie4FMsIa6sT87By8UCU85c13nLn9+v2sx3H7qRQkUK8=; b=lV0V4wMbXtn2TP0cebg0ZgJp6w7mNmMpBCGxi2SgZFh6UTJ8uhGuufZw a2viD42Zh7/vXDeckUtjiTS6o4s9pJSmg7a1cnbzSpchbPWHAWH4CyHZb Rt/MxzHS5qzGoUhcMH7ydwUW/aAvnP1+aKfuNlAKlAEedHFkAUzyi2/XK w=;
IronPort-PHdr: =?us-ascii?q?9a23=3ApVm1exO5XDxu8cqibdcl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAADyH4de/5NdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFpAwEBAQELAYFTJAUnBWxYIAQLKgqEEYNFA4p?= =?us-ascii?q?igl+YHoEuFIEQA1QKAQEBDAEBGAsKAgQBAYN/RQIXgi0kNgcOAgMBAQsBAQU?= =?us-ascii?q?BAQECAQUEbYVWDIVwAQEBAQIBAQEQEREMAQEsBAcBCwQCAQgRAwEBAQECAiM?= =?us-ascii?q?DAgICJQsUAQgIAgQBDQUIFwODBYJLAw4gAQMLozYCgTmIYnWBMoJ/AQEFhTU?= =?us-ascii?q?YggwDBoEOKgGLEYEfGoFBPyaBLoJNPoJnAQGBMAELBwEJGgUQFQwCglgygiy?= =?us-ascii?q?NcEmCSqATCoI9l0KCTIg4kHyPMpwdAgQCBAUCDgEBBYFZATFncHAVO4JpUBg?= =?us-ascii?q?Niz+CXoEnAQKCSYUUhUF0gSmLZoEzAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.72,339,1580774400"; d="scan'208";a="483056562"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2020 11:38:41 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 033BcfkL028126 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Apr 2020 11:38:41 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 06:38:41 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 06:38:40 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 3 Apr 2020 07:38:40 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=na7paXNeF8OwsxaX4oJS3Ysjan2PmdSkeK3HWfFO53a8ogas+mXyWBAopG0z9q7x6ie+HsTaFLTczWcPXulWnHSPF4vMyudj5Ke3F14vckE0jt+PUZH1KC/ogyDH8SzDBZXVk5JZPa9oN8ms6hfX9AnaKuWXqSAn3hmVYgZxggTlq4jfTQ+GuV9M3QKPdJasOClOTeeyctfi5sKQv84kydxIiB5qdnJlaenZi7pfPTnLJHae1Li+6BF2DSfiyQ6RNJ+Yr4sooIKBtKlrnTU4Q5z7w/geQ/ftx/aNv0uJ9ee1o0/42d41zzLboSUd/MXHlbO7miEAz7dSknu+hkUWmw==
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=Ie4FMsIa6sT87By8UCU85c13nLn9+v2sx3H7qRQkUK8=; b=ddH6LJJW3XHq0AlovcjaS0ZVb5ac5a/wA7e56onGdX+jDLWaCl5WSHcqvvL1qNCkTaq2ytbyq1CvOPWUjjEU0CRGQcScdjF9DvtLuCwGoTe1MESifpHAuqwkOM2eyhXHPnaKzP7AIwvA2zPLsZxZd1fZyNvpLaIhfHwoiWM4oU/31oy9tRwmOBIklQrdN4sWr+eQglEClvgJXHuszKNtjF9hp/PoeIWP9URayApgz2WwDGMGf9GhRhZN84+aQPJruhYdBi5SqPzcQUpze73cL4dHoZxbKX8PSvnCKL+r0KVZ/GehDFm80NmeU+DjawiKUZ/cxvYgX/rlpr8pna7HkA==
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=Ie4FMsIa6sT87By8UCU85c13nLn9+v2sx3H7qRQkUK8=; b=G9uU8AIlaZD56XSFXTNaFWWeI1PYdsJJCyB+Js9TJo896pazp1kMYCungH/I1Rk3sqYfaD+HWkZC96b29+XdesW6lf4lPfz1RGCh/fO3+/0Hdz7vMKS0VGb03UfguUom6kTJF3cV80DXrqfCIWR9/FUCzEYzvEW2FJ5ATl6i2e0=
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:38:39 +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:38:39 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>, "andy@yumaworks.com" <andy@yumaworks.com>
CC: "netmod@ietf.org" <netmod@ietf.org>, "Italo.Busi@huawei.com" <Italo.Busi@huawei.com>
Thread-Topic: [netmod] versioning procedures (RFC vs. I-D)
Thread-Index: AQHWCEsdsdxhqzReCUKzwNXbrqGCL6hkiBIAgAAIEICAAAHBAIAA+WyAgAAjEgCAADZOAIAABbEAgAAU/ICAAA4FgIABOdBQ
Date: Fri, 3 Apr 2020 11:38:39 +0000
Message-ID: <MN2PR11MB4366EBF4579204298DA14693B5C70@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>
In-Reply-To: <20200402.185141.761854093872914710.id@4668.se>
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: 2fc9a0ca-dd23-4df0-428d-08d7d7c38e0d
x-ms-traffictypediagnostic: MN2PR11MB4510:
x-microsoft-antispam-prvs: <MN2PR11MB45101CD2D6A5302BF64F191AB5C70@MN2PR11MB4510.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5516;
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)(136003)(376002)(366004)(396003)(39860400002)(346002)(110136005)(71200400001)(2906002)(8936002)(316002)(7696005)(66574012)(81166006)(4326008)(9686003)(6506007)(76116006)(81156014)(53546011)(5660300002)(54906003)(8676002)(26005)(55016002)(64756008)(966005)(478600001)(66556008)(33656002)(52536014)(186003)(66446008)(66476007)(66946007)(86362001); 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: LiYWXoQKZx3/K3YfNvsoG2few0Q1+9YY9kXclQi4/lyGmt7C9qfGXlKyhFKPCFolwjoTHw3kGKvEczgDCrT5K+gzooePyhTH2NPUr+u/esaVQigREJ14BvasgXr7zMmL6O0tMzCMceA3xIkLCWob7aXhO1b1bumAM60j4rRp4q5hzwPTG2+r29TMcVURcs9hHmpGjzOl4mPyX8NbCdXFkHhsxFtCnamYvVBPPkkM7bZieq8oftJVivEN2c0/iHQqJlMfnkBierZjU/N87aFNi6eEqKjiRE9h6oGuyDzOw26fOQnczyb8VsNtOyAihVEnJa5wigHDKTM7x8ZlYf0dnp/T2mPUE14Sq8HcKeyhX/IO9TaLDsx6cNQ5anNQQYtvJgfpJIrng+3JOtXCYHKBE7W1oBBZ5Z9P2cMtHtQVQctJvyzg2f/DC3TwW+Qp5MOih3Yq+o+IjUbDbYwFVaEOOFSQCtI3Sl2CBuX0/INuvVzTkFqpFQp8JuI9NiH66MdTAfOpaA0S+jzfFaPF5oQDlA==
x-ms-exchange-antispam-messagedata: UDvtE9i/2hsXBcJ26SJnam+L1yJLY5abd5TlW1DUmwKlTrmQFVL+GQZjxcwY7t3ZfvAl0fISWDF1m0b2jj5U55r4CIC1Ildl6wxl4X1ZFvhotSCEyaUpOGikHoXaXizaGiW383qf+BIrSIuBFC/GlA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2fc9a0ca-dd23-4df0-428d-08d7d7c38e0d
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 11:38:39.6673 (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: rUiRfK1o9ie2UNZipbe5S+xglX4ushj5hTFWz3/Hs0eHDxiPU6+zKcmvqRyHd87iKsfEWjEkMVWTe7M47pbkFw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4510
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dAn3TtZmZfo-AhdZffuXLB_ZXC4>
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:39:02 -0000

[As an individual contributor]


> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Björklund
> Sent: 02 April 2020 17:52
> To: andy@yumaworks.com
> Cc: netmod@ietf.org; Italo.Busi@huawei.com
> Subject: Re: [netmod] versioning procedures (RFC vs. I-D)
> 
> Andy Bierman <andy@yumaworks.com> wrote:
> > Hi,
> >
<snipped>
> 
> I think it quite clear that such a label should not be used in I-Ds.
[RW] 

Currently, it takes IETF a long time to publish YANG modules.  If IETF decides to use Semver labels for YANG modules then I think that giving a pre-release version label to work in progress is helpful for folks who choose to implement pre-release versions of those modules while they wait for the formal versions to be standardized.

Regards,
Rob


> 
> 
> /martin
> 
> 
> >
> > 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>
> > wrote:
> >
> > >
> > >
> > >
> > >
> > > *From: *'Andy Bierman' <andy@yumaworks.com>
> > > *Date: *Thursday, April 2, 2020 at 10:26 AM
> > > *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>
> > > *Cc: *Italo Busi <Italo.Busi@huawei.com>om>, "Joe Clarke (jclarke)" <
> > > jclarke@cisco.com>gt;, NetMod WG <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>
> > > wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > *From: *Italo Busi <Italo.Busi@huawei.com>
> > > *Date: *Thursday, April 2, 2020 at 5:06 AM
> > > *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>om>, 'Andy Bierman'
> > > < andy@yumaworks.com>gt;, "Joe Clarke (jclarke)" <jclarke@cisco.com>
> > > *Cc: *NetMod WG <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
> > >
> > >
> > >
> > > 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> on behalf of 'Andy Bierman'
> > > < andy@yumaworks.com>
> > > *Date: *Wednesday, April 1, 2020 at 2:07 PM
> > > *To: *"Joe Clarke (jclarke)" <jclarke@cisco.com>
> > > *Cc: *NetMod WG <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>
> > > wrote:
> > >
> > >
> > >
> > > > On Apr 1, 2020, at 13:28, Andy Bierman <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
> > >
> > >
> > >
> > >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod