Re: [netmod] Revision label in filename
tom petch <ietfc@btconnect.com> Sat, 09 May 2020 11:06 UTC
Return-Path: <ietfc@btconnect.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 D51A23A09E8 for <netmod@ietfa.amsl.com>; Sat, 9 May 2020 04:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 invj2BYUV3nk for <netmod@ietfa.amsl.com>; Sat, 9 May 2020 04:06:46 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140098.outbound.protection.outlook.com [40.107.14.98]) (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 4432B3A09E9 for <netmod@ietf.org>; Sat, 9 May 2020 04:06:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oF7ShoY1A14nlCDUKpwpQ3CLWkMid37Eh++WELgQNqqeysvYez96GS9GiAs6iH2vU/UHwyjOfdi6Yw0kC04wfivq/TBe/rlw2Rl7Q6VDHPxO+eK0Vmjjr7XAs+DOMV5LD+ZAadkGgQwGSdb0OIpqNB2B+PU2tyXKpoaZw0pmclwOo/2Nlribb//M0ULKbQCKwQd1Om1MehEDfr1Hkful7o2fKm1V7sg6SlKk8WoSWVXnJs4tP2FsdpU7+OPfi1zn6fwqB3+HGY6JT84uSNDglSp8b19jGsnZrmD0+90sDa+QWydyNQzKcVj4Rc2FzRQ56iwAu5Utzlt4CzYLn0lmOg==
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=a75zFXK0l7acX6rq4FWaaqplf7lwZfNXFQ4zyxWUpfI=; b=j3zTLmerzdumSt3iZHgmmWk4iRy4hw8L/7mmmD+zJBrFYpusS09JIpa0yKn1JjFqEEzo+ofADq2tF8wUwBxjAO8Q2Qbm2TStcUPvb5sI5T+QhZWedUB85p23ED+MoQxYs7aCstY+GKE1HVmzd0hRenlc5+2huRROq6iWe7q6dCUF0S3e5SCZdSXs1zNMa2Kaym68WFMt5wSX48RDl/Fa9UsR6V40kd4XAO/mnlzQXncfuZVfF3Bazd+5ciikabsDruF2c3YrdzFLhCDjMva1dtsj0AsgCGFzrE/rVmfi0EUmNRp8vS5stxfoQQC5JoOx1NYC9CsohaDE/hFtwTgSig==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a75zFXK0l7acX6rq4FWaaqplf7lwZfNXFQ4zyxWUpfI=; b=BKPbndu4a7d31f7IPmKlxGVYMEERkefXuNSr6Cepg6N/6ypqKmiTG5oi1e8Y/ld17FRw4Qpl3yXbmRAUtoVJ/Ae8XOj6KNP937iSCIm5GLpUYKkFvZC2CY1w7wW6LECcnI773vhX5fp0xbjjNKspoMNpPxbsJqUyujOtqk9kq+s=
Received: from AM6PR07MB4520.eurprd07.prod.outlook.com (2603:10a6:20b:26::13) by AM6PR07MB5511.eurprd07.prod.outlook.com (2603:10a6:20b:82::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.14; Sat, 9 May 2020 11:06:37 +0000
Received: from AM6PR07MB4520.eurprd07.prod.outlook.com ([fe80::347d:c6fa:f973:e684]) by AM6PR07MB4520.eurprd07.prod.outlook.com ([fe80::347d:c6fa:f973:e684%7]) with mapi id 15.20.2979.033; Sat, 9 May 2020 11:06:37 +0000
From: tom petch <ietfc@btconnect.com>
To: "Reshad Rahman (rrahman)" <rrahman=40cisco.com@dmarc.ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, Martin Björklund <mbj+ietf@4668.se>
Thread-Topic: [netmod] Revision label in filename
Thread-Index: AQHWJULlaerHh/MFR0md3UduRBBcTKiflrKB
Date: Sat, 09 May 2020 11:06:37 +0000
Message-ID: <AM6PR07MB4520D033C8F8F32FD72F464DA0A30@AM6PR07MB4520.eurprd07.prod.outlook.com>
References: <E42934AA-A95D-4BC3-A9F9-F940734EA84F@cisco.com>
In-Reply-To: <E42934AA-A95D-4BC3-A9F9-F940734EA84F@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [81.131.229.19]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 36d2004b-5fbc-43b9-6ce9-08d7f4090b24
x-ms-traffictypediagnostic: AM6PR07MB5511:
x-microsoft-antispam-prvs: <AM6PR07MB551118362FDBC7506EB6ED16A0A30@AM6PR07MB5511.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03982FDC1D
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pIphDU7tz3qDDxrYupcUyOzTAhN5XAEA3CkwysktW8A47EXk3vvw/uAVgggdktwtplb2GlEuxSF7oRmJ1YBLz9nWog3hGlqvWzDqSZc4A0B357xWqwat0v9fjOHY2wgCjSpwwYobe05nJM1nI63bC4RlDQ4E8q9XGi5fMAt8fBSBKdiStepnrNubefHrs1xzztvi9y20wem11xXKmsTKUdshmLc85JFhdkQH+XT3S1kvx9KXSNVDVeUeQOJw6wyswz/f1FNOM9Ga54RsABhiw+DzlkJf5vIBHuFfsYbpRp8bZSVC0Zhc1eNI7NLcU4aNpxEbbhcrldsRcZHnxT1+x8gCKQvIx2e1miVUEwhUzNmLDaWKdFvKXT4E4ItcpnB1W7bxeGbQZWKdaP15xjoHiYge74lNbYYwwgwEOXpp7xhMnyB5RoENPo88WTRNX/+VSbg3WYT1WBu5xjzvi98c+lGaAPMeRtE41FhKwVxKc32Xj1wHGoVw/5+bUQPS3NDQi6tLR0AjrefzpUQmbBViqC5Gt85gZAIZKPttS9WkVEFPzGsVe/yMMq5PIarXjj4ye2suXXBwATE7VGNhuOmqSrxsYiK84Gn40MCHWg85+u4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4520.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(376002)(346002)(396003)(39860400002)(136003)(33430700001)(478600001)(71200400001)(2906002)(55016002)(66574014)(9686003)(8936002)(33440700001)(6506007)(316002)(8676002)(86362001)(33656002)(76116006)(110136005)(966005)(26005)(66946007)(53546011)(91956017)(52536014)(186003)(7696005)(66556008)(5660300002)(66476007)(64756008)(66446008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: +kweqmHyGYoF2uJNViaLoiYv1aaAOQJNvb8Snw0jh+JYhXq984gBz+eoYj6ph13+1OS4tuvjjM79nFEI5qjBqTucj37NefS5BBz8r+txp6+XTeIPQonhwKVLFHW7Lg8ZEwCaUB4DGw2hr7bqS4oh+nrsGCGAWT9RiLMiyu1t22/mBc9jHNCgc3vKGw4f/Sgo/7lK9Y1nuvU5tlIIV+3yPuePicBkcmoe4kzefX3GjbkD8EiaA9AV/Ujuh8ZovaIp9b3cUGwN7+MANWKnuXDQOEheteiBG4jrsk+P5srGn+Gqas6XfIfx5iexN7G3k2hJnyRu4I/xKQwX4eCahl/E6nc7fiURmj73oPsWKQ7cfvg+MBuzy6yfEJrFZMhcjKhUTL4dauhHYxLPvk4KinSKSGqvgY/hd5KqxKCWr53rTzxu/anHe81Z/Jo919rX9PQdVAum77MGMUz3mOA8dyc3YYCY7uEsS63nwI8ZOufclUY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 36d2004b-5fbc-43b9-6ce9-08d7f4090b24
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2020 11:06:37.3524 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zH3/ekf1fz31TZZs0TlhPXDYnhlCTnFxKQ3MNfhrrXoCkSOe7Fp8Y+MdlP6kSH7ssh3sA4oAEXvx0JiRU2sWuA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5511
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/tt5fBQfwvvd8uakUEQGPEtYk-Do>
Subject: Re: [netmod] Revision label in filename
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: Sat, 09 May 2020 11:06:49 -0000
From: netmod <netmod-bounces@ietf.org> on behalf of Reshad Rahman (rrahman) <rrahman=40cisco.com@dmarc.ietf.org> Sent: 08 May 2020 15:13 Hi, We discussed using something along the lines of module-or-submodule-name['@'date]['#'revision-label].yang. Questions to the WG: 1) Is there a need for both date and revision-label or is one of them enough? <tp> One of them is quite enough and since the date is embedded in many systems it would be wrong to change it. The module name is the primary identifier of this bundle of definitions but it was decided that as and when there was a change therein then the date would provide a unique identifier for a particular version; nothing more is needed. Arguably the date is more complex than is warranted but it has worked. Indeed that format is now used and understood by such as IANA and the RFC Editor. If you want to record more detailed semantics of the relationships between different versions, then put it somewhere else and leave the identifier alone, let the identifier be an identifier and not be overloaded with semantics. Tom Petch 2) If we have both, what's the impact of having "#revision-label" on implementations which search by date? Regards, Reshad. On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)" <netmod-bounces@ietf.org on behalf of rrahman=40cisco.com@dmarc.ietf.org> wrote: Hi, https://github.com/netmod-wg/yang-ver-dt/issues/50 o 3.3 In the filename of a YANG module, where it takes the form: module- or-submodule-name ['@' revision-label] ( '.yang' / '.yin' ) Should this section update 5.2 of RFC 7950? I know that 5.2 just says "SHOULD". But existing tools implement this SHOULD, and they need to be updated to handle this new convention. But I wonder if this a good idea. It means that a tool that looks for a module with a certain revision date cannot simply check the filenames, but need to parse all available modules (wijust to find the We agree that there is an impact on searching by date. We put this in to have the ability to search by revision-label, otherwise we can search just by date for a module which uses revision-label. We had also discussed using different limiter for the label and have something along the lines of: module-or-submodule-name['@'date]['#'revision-label].yang It'd seem that updating 7950 would be a good idea whichever way we go. Regards, Reshad. On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" <netmod-bounces@ietf.org on behalf of rrahman=40cisco.com@dmarc.ietf.org> wrote: Hi Martin, We've opened issues to track your review comments (see below). Will kick off separate therads for each issue. https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling Regards, Reshad. On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" <netmod-bounces@ietf.org on behalf of mbj+ietf@4668.se> wrote: Hi, Here are my review comments of draft-verdt-netmod-yang-module-versioning-01. o 3.1.1 o In statements that have any data definition statements as substatements, those data definition substatements MAY be reordered, as long as they do not change the ordering or any "rpc" "input" substatements. I think this needs to capture that no descendant statements to "input" can be reordered. Same for "output" (note, "input" and "output" in both "rpc" and "action"). o 3.3 All revision labels that match the pattern for the "version" typedef in the ietf-yang-semver YANG module MUST be interpreted as YANG semantic version numbers. I don't think this is a good idea. Seems like a layer violation. What if my project use another dialect of semver, that wouldn't be possible with this rule. I think this needs to be removed. o 3.3 Submodules MUST NOT use revision label schemes that could be confused with the including module's revision label scheme. Hmm, how do I ensure that this MUST NOT is handled correctly? What exactly does "could be confused with" mean? o 3.3 In the filename of a YANG module, where it takes the form: module- or-submodule-name ['@' revision-label] ( '.yang' / '.yin' ) Should this section update 5.2 of RFC 7950? I know that 5.2 just says "SHOULD". But existing tools implement this SHOULD, and they need to be updated to handle this new convention. But I wonder if this a good idea. It means that a tool that looks for a module with a certain revision date cannot simply check the filenames, but need to parse all available modules (wijust to find the o 3.4 leaf imperial-temperature { type int64; units "degrees Fahrenheit"; status deprecated { rev:status-description "Imperial measurements are being phased out in favor of their metric equivalents. Use metric-temperature instead."; } description "Temperature in degrees Fahrenheit."; } I don't think rev:status-description is necessary / worth it. This can easily be written with the normal description statement instead: leaf imperial-temperature { type int64; units "degrees Fahrenheit"; status deprecated; description "Imperial measurements are being phased out in favor of their metric equivalents. Use metric-temperature instead. Temperature in degrees Fahrenheit."; } o 3.5 The example modules should be legal YANG modules. Use e.g. "urn:example:module" as namespace. Also, the modules are missing the last "}", which confuses the "rfcstrip" tool. o 4.1.1 Alternatively, the first example could have used the revision label "1.0.0" instead, which selects the same set of revisions/versions. import example-module { rev:revision-or-derived 1.0.0; } Shouldn't this be s/1.0.0/2.0.0/g ? o 5 I think the module name "ietf-yl-revisions" should be changed to "ietf-yang-library-revisions". "yl" is not a well-known acronym. o 5.2.2 Wouldn't it be better if the leaf "deprecated-nodes-implemented" and "obsolete-nodes-absent" were of type "boolean" rather than type "empty"? o 7.1 The text says: All IETF YANG modules MUST include revision-label statements for all newly published YANG modules, and all newly published revisions of existing YANG modules. The revision-label MUST take the form of a YANG semantic version number [I-D.verdt-netmod-yang-semver]. I strongly disagree with this new rule. IETF modules use a linear history, so there are no reasons to use "modified semver". It is ok to use rev:nbc-changes if needed, though. o 7.1.1 There is a missing " in: 4. For status "obsolete", it is RECOMMENDED to keep the "status- description" information, from when the node had status "deprecated, which is still relevant. HERE -----------^ o 8 s/CODE ENDS>/<CODE ENDS>/ o Both YANG modules All extensions should specify the grammar; i.e., in which statements they can be present and which substatements they can have. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
- Re: [netmod] Revision label in filename Reshad Rahman (rrahman)
- Re: [netmod] Revision label in filename tom petch
- Re: [netmod] Revision label in filename Andy Bierman
- Re: [netmod] Revision label in filename Reshad Rahman (rrahman)
- Re: [netmod] Revision label in filename Joe Clarke (jclarke)
- Re: [netmod] Revision label in filename Jan Lindblad
- Re: [netmod] Revision label in filename Reshad Rahman (rrahman)