Re: [netmod] status-description

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Mon, 04 May 2020 18:07 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 6F7383A0EC2 for <netmod@ietfa.amsl.com>; Mon, 4 May 2020 11:07:53 -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=GsgsUbdC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Uch13Dn9
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 bDF9uCHJcWjZ for <netmod@ietfa.amsl.com>; Mon, 4 May 2020 11:07:47 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530773A0F2D for <netmod@ietf.org>; Mon, 4 May 2020 11:07:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57343; q=dns/txt; s=iport; t=1588615659; x=1589825259; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bLpvBKKgg/W0mmaGUAxhDlekFiDyo1xEvPThth5WdHM=; b=GsgsUbdC3z+rWCeKwTrfOTvl2c2c1DXttAVPq6IM+lhNwAE/wb7BeBTu P/9gtnL/utd0+GeI8Di+Zdpto6G7GjiFR49zwc6nOofOES6bkcp5Rkyaw jtftPtnTMg2v4Ffr/nCl8fr4tyS+ooWEN3ctj2X3kID3Zbd6iwC1PqDCn M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AP9Gb2xbmL8WqvWGySbMVvFT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWTD5TG7vtbjPDVqObrXmlTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBs2C35CEVAB?= =?us-ascii?q?bkcwFyI7e9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAACxWLBe/4UNJK1cChoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAYIHgSUvUQVuWC8qCoQZg0YDjSElmDWBQoE?= =?us-ascii?q?QA1AECwEBAQwBARgBCgoCBAEBg39FAheCHSQ4EwIDAQELAQEFAQEBAgEFBG2?= =?us-ascii?q?FKgYmDIVxAQEBAQIBAQEQCAkdAQEsCwELBAIBCBEDAQEBASABBgMCAgIlCxQ?= =?us-ascii?q?JCAIEAQ0FIoMEAYF+TQMOIAEOqAMCgTmIYXaBMoMAAQEFgkmDABiCDgMGgTi?= =?us-ascii?q?CY4JJDocKGoFBP4ERJwwQgk0+gmcBAQKBNhMXChAJDQkCglqCYI4+AQMuglm?= =?us-ascii?q?GGiSKSJAGCoJIiBiPfh2CW5VShHOQF4FYh3yTSAIEAgQFAg4BAQWBaSIpgS1?= =?us-ascii?q?wFTsqAYI+UBgNiBiIKoNyhRSFQnQCNQIGAQcBAQMJfJA6AYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.73,352,1583193600"; d="scan'208,217";a="508127222"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 May 2020 18:07:36 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 044I7asg004409 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2020 18:07:36 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 May 2020 13:07:35 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 May 2020 13:07:35 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 4 May 2020 13:07:35 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+VM+n0CBAOXYIOVL8ChP23EkK1BdIcfJV3YINuytHmKHGWv0rT9IEobSQbaQb2469yIRAbcILGpBZ3YoLGAsHpyBkZuBt7k5pL3OVfvsOEGxR5saE7u8tNVp0gOdhsNNDA7bM5L34HskKtkgTEAQc2NYNjQDeaGZXGQrD9xWXDmk8jjssgmcfB1kIx+fw+jzx25LrsFHNV7GZtNg5rM3q3fpnPqXGN8Yw2le0CUM/RVpCOD75oSHY6SpEc28aV3X5UmWUJ1HSTYkcAVo77NFuBCpNuWL610cOKWCZJ+U3uhU/wnTHint4NBEjDTjewspTwwC/nJYnMg/rH1Z1zhpQ==
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=bLpvBKKgg/W0mmaGUAxhDlekFiDyo1xEvPThth5WdHM=; b=nhQV79x5sfatUe9iLx7qcrpVBSRUJn2dltzlL2rV33Idbk9hby3y6Fk5pP5eVHRf6K7rY0ir3SEMSp/8NXT7dngaEjVdejJhkBID9qNjJcMqw049ZJmW//BeTzdZA3z1MI7ckaSO0xAJL+XSG7pQubL7vYJbpmRBdfMoKkqqqGWU1n7vIsUWieddVDnSdXBxFh2yxmM9wbKkhtpA06r8D3R2IqXy5scvnk1zFSaVb+0VY3UqmXFI19TrsobeEnl8rAjpU/DERBNEoNc1OfnEuix5tRLTtSkpZb0lt5SdAXJh6kpHSwv4Wr5ONFF2FqUzdbzOV4bDQ1ixukPr/Gvyzw==
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=bLpvBKKgg/W0mmaGUAxhDlekFiDyo1xEvPThth5WdHM=; b=Uch13Dn9Yo01wxSCcdNREmY6V3jjbSfCszHdLKt9GwfeZQKI4+fDpmSjDKlGF+8lFkoEEo2rIBmc1R9OVe0MG4T99qCk9I7UgZRMqXgXSP9XQ24UUDw9BtrAUjYh8XocVqUZQFXwbTB6bBvio79jm2u2jwOqQUD/1ztzjZ1gkNY=
Received: from BN6PR11MB3875.namprd11.prod.outlook.com (2603:10b6:405:80::37) by BN6PR11MB3922.namprd11.prod.outlook.com (2603:10b6:405:7b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Mon, 4 May 2020 18:07:33 +0000
Received: from BN6PR11MB3875.namprd11.prod.outlook.com ([fe80::89ae:b7c9:b936:b2bd]) by BN6PR11MB3875.namprd11.prod.outlook.com ([fe80::89ae:b7c9:b936:b2bd%3]) with mapi id 15.20.2958.030; Mon, 4 May 2020 18:07:33 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>, NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] status-description
Thread-Index: AQHWIjJ2rejWw3dwTE+1kTknUW7VMaiYL3aA///G2QA=
Date: Mon, 4 May 2020 18:07:33 +0000
Message-ID: <60CC3F2E-678E-4266-84C9-01214670981F@cisco.com>
References: <3635DB7C-30F0-4214-BBD4-8A0C03177D0C@cisco.com> <DM5PR08MB263369B99B8F25B4FC383E0B9BAD0@DM5PR08MB2633.namprd08.prod.outlook.com> <AM0PR07MB4004B4273EB535101F1308E4F0A60@AM0PR07MB4004.eurprd07.prod.outlook.com> <20200504.183817.1920254876593446739.id@4668.se> <CABCOCHSbv8pUCJDV2pvN9GvhOnd-qPYsZv4G0r6QVgjiqfpS6Q@mail.gmail.com>
In-Reply-To: <CABCOCHSbv8pUCJDV2pvN9GvhOnd-qPYsZv4G0r6QVgjiqfpS6Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [70.31.50.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3b6a57a4-2a20-4311-f34e-08d7f05604f7
x-ms-traffictypediagnostic: BN6PR11MB3922:
x-microsoft-antispam-prvs: <BN6PR11MB39224542299103988B8F1B79ABA60@BN6PR11MB3922.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 03932714EB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qaI/UyWkUJ2ODkzZLRKSobUSMqAfmYKKe3/rgzzA0uOVymMyfY0t67XWJahMRmO81HmAnk6HakktYbCFsqWeRtiNpZd01I6Gl64WEQqOpaSuSZJruw3qjHk0+YYSore7LBZ8UPfyLvZamsF3P7L9T+4CBOWaAvZfciYNQs53MewcW5AOZrf0cP/PGFi0/IISIWJ0gEDWMDodWCRRssjm571fRMtxlyH1WD5l/rr/rGgC2+YdAHAMro2qPs0U3XAyLPKcKx91MNKli4g2P7nZgI79kWHZKtgie2vVk8aoydxSpBVRTO+XVHTnFmcejREUS1e/EVVUvzHb9xSnP5A5CGAU3rdW9pf31S2LvAnPhCeVSofHtHRD5hYeUKGcbXqFK+XOyEOBTbcNUdg4tzvKTN7Y9werioZLObRTcndlTlgHftc+y/7VkrrDFks0EEqoEydS358YhjFw47tHoFgi4nU0R+nhdwdKrupbbQ9C6Bv7uyHFe7UKMgUrRbmNjMlwu+5KYP6eAjdSbQ/qi/G/TA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB3875.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(376002)(136003)(396003)(346002)(2616005)(110136005)(26005)(64756008)(66556008)(66476007)(66946007)(76116006)(91956017)(66446008)(6506007)(53546011)(316002)(54906003)(86362001)(71200400001)(30864003)(66574012)(478600001)(8676002)(4326008)(2906002)(6486002)(8936002)(186003)(5660300002)(966005)(6512007)(36756003)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 9yV9F0b0iWtY/EEmsuBrTeXxZn4XEp7PcEOqaBSMVL3wTkhnvvecV9OE2ygS0tXcVDxzuwn4cBGVhh0n+KseE1rKAMzdS1zE5TaoYm8UIztzvDRyd9tAJoK5Y1ptopEuZ7+RQsIwp3cDYWznC4jXxcrVbxjxhhYPJo2PBwi+puo0Se5g5IPMDuM7b7fx5T9M09fL6dyZcssMPu/bzb+XmkTK8sK9JJuSD7jMCK59CXx3THed9Xc23/fCLv0fj2zcAsCN9GNuEq3mzH3a3af5zHm2vQl0lV6QXbco2ZIwpqHCIa+J8K13jZPz7y+KBJNLgXLTPyGTUecZmPGYudMiuPAWes7x/ksQesDtkMjfkSb376AOUhLTTlT7wxARLut9tUw+N+rjx4C3CBS4UZZHpXz1PXXXEh8dDeTRDfTGOnRmnY1Xw5saoWy5wuQlIrbDVKtFIkm376WDm6jJvJYw3hYM8vCxEIhSIjoVb6Qt9GMsLN9sFNBlshdIJpm2iDq35NtVsX/FPrugNRp5xSUYL1thpYGkFFdrzh2R1N5ymSPMetVMvvog+/+0QDeFSkr30vuK9fOY3BbhvpuyappxM6yQnKyEJ7OBnTB2bWLt3j+KkZwfQCHWK2Xdjv1i/nX94lraRHZHOcDeS8jA7LEPVdR3TGzjzTHyjlOoBrUTSjr9MDBV/SMgpaEjBBHXRhmISlVEosjZDNmkicAKTP4gRel/Q1vZi0vxjv1nJnM8xo/HgfHLLHsFDNOm9qeFnFxRsdGFQz/t9H97qGJ9NR4QjIciNdQIV2y3+Bro01T+kW0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_60CC3F2E678E426684C901214670981Fciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b6a57a4-2a20-4311-f34e-08d7f05604f7
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 18:07:33.6347 (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: hyVncxqA5AQl7Rr9J37qSmjkRvdwRAdmtlGkhEu8v0/Ndypl2uK7mdTYoxAI+swutpdTkiGGXo85/tDbxzXKpQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3922
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZDiW2-_8GmJBMAnrDuQ0MNUFnoQ>
Subject: Re: [netmod] status-description
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: Mon, 04 May 2020 18:07:59 -0000

What are your thoughts on having description statement under status in yang-next? Is it the same as what you’ve stated on status-description extension?

I believe the extension is useful, although I do see the point made that an extra statement leads to extra complexity. But using description statement in yang-next should not be an issue?

Regards,
Reshad.

From: 'Andy Bierman' <andy@yumaworks.com>
Date: Monday, May 4, 2020 at 1:32 PM
To: Martin Björklund <mbj+ietf@4668.se>
Cc: Balazs Lengyel <balazs.lengyel@ericsson.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] status-description



On Mon, May 4, 2020 at 9:38 AM Martin Björklund <mbj+ietf@4668.se<mailto:mbj%2Bietf@4668.se>> wrote:
Hi,

Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>> wrote:
> Hello,
> While status-description is not a critical part of this work, it is
> still useful, does not harm and is such a small addition, I do not
> understand why Martin objects.

Every additional statement adds to the overall complexity.  As Jason
explained, this particular statement doesn't really help much.


+1

We should not start down the path of specialized description statements.

I was part of a design team many years ago that was trying to
figure out why engineers were having so much trouble writing MIB modules.
One significant finding: people disliked working on MIBs because there were so
many special little rules (CLRs) for every little detail in the module.

IMO we are starting to make the same mistake with YANG.


/martin

Andy


>
> So why is status-description good:
> Sometimes additional information is needed about deprecation,
> obsolescence:
> - is the item still fully functional?
> - when will its functionality be removed?
> - when will the schema node itself be removed?
> - is there a replacement or workaround that could/should be used instead
> - of deprecated/obsolete item?
> The text can be used by tools. Using a separate statement to provide
> this
> information is a method to separate the main description from this
> status specific description.
> In most cases both in the CLI and on NMS GUIs only the description is
> displayed.
> However there is a possibility  to display the status information too.
>
> In a way it is similar why we have separate description, contact,
> reference, organization statements under module.
> All these are just text, they could all be pushed under a single
> description statement. Tools can't act on these automatically, still
> it is good to separate them.
>
> Regards Balazs
>
> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Sterne, Jason
> (Nokia - CA/Ottawa)
> Sent: 2020. április 29., szerda 23:38
> To: Reshad Rahman (rrahman) <rrahman=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>;
> Martin Björklund <mbj+ietf@4668.se<mailto:mbj%2Bietf@4668.se>>; netmod@ietf.org<mailto:netmod@ietf.org>
> Subject: Re: [netmod] status-description (WAS Re: mbj review of
> draft-verdt-netmod-yang-module-versioning-01)
>
> I think we could wait until YANG 2.0 to add a description to the
> status.
>
> Without a status description, an intelligent "YANG diff" of the models
> would produce this:
> a) new status deprecated statement
> b) change to a description
>
> With a status description we'd identify this:
> a) new status deprecated statement
> b) new status description
>
> In both cases it is (a) that identifies the most clear information.
>
> In both cases (b) provides no additional information that can be acted
> upon in an automated fashion. The tool could only flag that (b)
> occurred in both cases and a human would then have to go look at it.
>
> If the only change between two versions of a module was a status
> description change, then again a human would have to take a look. If
> we add some sort of "nbc" tag to the leaf for tooling, then it also
> doesn't matter which description changed.
>
> Jason
>
>
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Reshad Rahman
> > (rrahman)
> > Sent: Friday, March 27, 2020 5:43 PM
> > To: Martin Björklund <mbj+ietf@4668.se<mailto:mbj%2Bietf@4668.se>>; netmod@ietf.org<mailto:netmod@ietf.org>
> > Subject: [netmod] rev:status-description (WAS Re: mbj review of
> > draft-verdt-
> > netmod-yang-module-versioning-01)
> >
> > Hi,
> >
> > https://github.com/netmod-wg/yang-ver-dt/issues/51
> >
> >         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.";
> >              }
> >
> > While rev:status-description isn't strictly necessary, without it we'd
> > have to modify the node's description as you pointed out. That'd make
> > tooling more
> > difficult: is the description change BC or NBC? Also, a user looking
> > at a diff would need to go through the description change. Use of
> > rev:status- description makes this easier to handle.
> >
> > Regards,
> > Reshad.
> >
> >
> >
> > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
> > <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org> on behalf of
> > rrahman=40cisco.com@dmarc.ietf.org<mailto: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<mailto:bounces@ietf.org> on behalf of mbj+ietf@4668.se<mailto:mbj%2Bietf@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<mailto:netmod@ietf.org>
> >         https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >     _______________________________________________
> >     netmod mailing list
> >     netmod@ietf.org<mailto:netmod@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org<mailto:netmod@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod