Re: [netmod] Revision labels for submodules
Andy Bierman <andy@yumaworks.com> Wed, 13 May 2020 21:52 UTC
Return-Path: <andy@yumaworks.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 7C58C3A0973 for <netmod@ietfa.amsl.com>; Wed, 13 May 2020 14:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 XQd7rn_rqJRD for <netmod@ietfa.amsl.com>; Wed, 13 May 2020 14:52:03 -0700 (PDT)
Received: from mail-yb1-xb44.google.com (mail-yb1-xb44.google.com [IPv6:2607:f8b0:4864:20::b44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EE43A096E for <netmod@ietf.org>; Wed, 13 May 2020 14:52:02 -0700 (PDT)
Received: by mail-yb1-xb44.google.com with SMTP id q206so493824ybg.1 for <netmod@ietf.org>; Wed, 13 May 2020 14:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yPxNm/+CJsjO+wZgy3BP8VWIsgLxzoCC4xL7J+1lk68=; b=gyjKmrgvfwsqaRlTRhWElS2kzIEXZ4KvsyfVTf1k6IZYcZKEhdDezkNZ5VTYVhJ2IJ 35q/36wcFpCDIFNLvYl3lIEjosF3mk/6e1JGRCxVm3vcYDXi7iVI88rznE3qchxenYWy 3UBbCz9cZVn3DFIj6vZYO7RGDfpE9bpCyog0BioRte0POb66xSp6NoMvlQ0VDw451pT6 rcc18fAoeYOxxUQbycfuqa0cj9mRme4optGozOxWAZU4vINW63PjNIh78T0kant9DMYt AXCgileEnby2bWgOqiWG/bNVmhOfv1Jl045v5wNeumhpErHoZmY1yZJElLl+tEAfSeSn bLiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yPxNm/+CJsjO+wZgy3BP8VWIsgLxzoCC4xL7J+1lk68=; b=W18rWgpCJNWtc4Q+qcB1HGcyQNKyGuY3Ik0h+B1K6To6jzB8S1x3uqF6d13cYiOiYB WaRIPqzBWCZD53PzsEi1F4Vy04a6mzphsLBJ1s6RIp4NrLKJy8a+zNQVx/KA2KbiYFI6 1zLYRIPEk85/k8DSawCwUmzPNyYAGOo0hmzJZszPi6i7ssrVSVlMD1Wr/IbYbOjUGrNs tBI8OO8B34P3dr+j03gmXHIV+OtriROEzTqnrI7rWiavSdyQr61c7slcgQin6V9i7VJS gz/jRAry8IlVOJdL+DRo9IAxfMspBXXZUsaWmgZmGuqloYN31Q1BVQSNeSNwd3oSYSLM 50zQ==
X-Gm-Message-State: AOAM533kl1xBSflbGfwTdRHqSRN+H5GVAUizxwixYlm02ZZ5I5eI3oP5 BcZm+ybaPowZdUH7fEG1gjZJbAMwXkssf9A10U+MvA==
X-Google-Smtp-Source: ABdhPJzPetD9mloxmcaWg9AYIqqhbsgUrY46a2cLWKsUTa2ucTgXQ0XIaIqvBjrLez+f3Nc6b3E/2VuZsibmZ8p4GUg=
X-Received: by 2002:a25:4903:: with SMTP id w3mr1769376yba.107.1589406721488; Wed, 13 May 2020 14:52:01 -0700 (PDT)
MIME-Version: 1.0
References: <8D4A99E4-93D3-495C-9B46-26C61BBABAA7@cisco.com> <20200508.231215.893859438588129498.id@4668.se> <B692BC98-AA66-4E12-9EF5-516FFCF04F33@cisco.com> <20200509.175337.1668899395924812873.id@4668.se> <DM5PR08MB2633E41BFC1C1FBBB8D2C7059BA30@DM5PR08MB2633.namprd08.prod.outlook.com> <75D482FE-2F79-4B39-A7B7-B131510BF039@cisco.com> <DM5PR08MB26334810A88C7F994370156B9BBF0@DM5PR08MB2633.namprd08.prod.outlook.com> <DCA5FE0D-7308-445B-8B97-7174339B04B4@cisco.com> <DM5PR08MB26339A6A842DD724E64B9B1F9BBF0@DM5PR08MB2633.namprd08.prod.outlook.com> <59E710C1-B118-4E35-9A3D-59A17ED4CBB5@cisco.com> <DM5PR08MB2633F88107857EBA4C84DC5F9BBF0@DM5PR08MB2633.namprd08.prod.outlook.com>
In-Reply-To: <DM5PR08MB2633F88107857EBA4C84DC5F9BBF0@DM5PR08MB2633.namprd08.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 13 May 2020 14:51:50 -0700
Message-ID: <CABCOCHRi6t7xmvWuD-23af30HNo=yxYh-X433kr-0KuTdoyhHg@mail.gmail.com>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Martin Björklund <mbj+ietf@4668.se>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000009d33305a58e97e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Zxv61rKHTXiMADToT1FSVG2accs>
Subject: Re: [netmod] Revision labels for submodules
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: Wed, 13 May 2020 21:52:08 -0000
On Wed, May 13, 2020 at 2:25 PM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > The example we've been using to discuss this is an editorial type change > in 2 submodules (moving a leaf between them with no changes to their > definition or the schema). > > But if we consider an example where schema actually changes (in a part > that is defined in a submodule), then it does seem reasonable that the > module version should also change. > > So (A) is probably the right answer here. But it does have a potentially > confusing consequence: two YANG files could be identical except for an > extra revision statement. It may appear that someone incorrectly bumped a > version when there was no change, until you notice that "oh, this module > includes submodules - one of those must have changed". > > Some tools might be sensitive to changes that could be considered editorial. The YANG to SID mapping algorithm comes to mind as a tool sensitive to moving data definitions between submodules. IMO any change at all (except maybe change in insignificant whitespace) should cause 2 revisions to be different (and require different revision dates and revision labels). Jason > > Andy > > -----Original Message----- > > From: Reshad Rahman (rrahman) <rrahman@cisco.com> > > Sent: Wednesday, May 13, 2020 4:52 PM > > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; Martin > > Björklund <mbj+ietf@4668.se> > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Revision labels for submodules > > > > Hi Jason, > > > > Is your question of option A v/s B just for the case where the schema > > represented by the module does not change? > > > > If the schema changes, even if the module didn't change, the > revision-label > > has to be updated to indicate the change. > > If the schema didn't change, I'd go with editorial revision-label update > as (I > > think) Martin suggested. > > > > Regards, > > Reshad. > > > > On 2020-05-13, 1:30 PM, "Sterne, Jason (Nokia - CA/Ottawa)" > > <jason.sterne@nokia.com> wrote: > > > > So that's the part I'm not sure of. > > > > If a leaf moves between submodules, and the module file doesn't > change > > in any way (as we've said is possible and should be allowed), do we > mandate > > that the module version changes? This is up to us to define IMO > > > > (A) the module version has a scope that includes the module and all > > submodules > > (B) the module version has a scope that is just the module file > contents > > > > I'm on the fence between those two. (A) could make sense but it does > > mean that someone comparing two versions of the just the module file > itself > > may see no difference whatsoever between them except the addition of a > > new version statement. > > > > Jason > > > > > -----Original Message----- > > > From: Reshad Rahman (rrahman) <rrahman@cisco.com> > > > Sent: Wednesday, May 13, 2020 12:46 PM > > > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; > > Martin > > > Björklund <mbj+ietf@4668.se> > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] Revision labels for submodules > > > > > > Hi Jason, > > > > > > > > > On 2020-05-13, 11:50 AM, "Sterne, Jason (Nokia - CA/Ottawa)" > > > <jason.sterne@nokia.com> wrote: > > > > > > Hi guys, > > > > > > As someone who is heavily involved in the development of an > > extensive > > > YANG model comprised of submodules, I'm not a fan of mandating that > > > include by revision is mandatory for submodules. It may indeed be a > > good > > > idea (so perhaps SHOULD is fine) but I can see it causing problems > on the > > > implementation side. > > > > > > The primary development of a data model may be distributed out > to > > > submodules and the main module may only be a top level container > for > > the > > > submodules (and rarely touched). This would suddenly create an > > ordering > > > dependency in the release process that requires the main module > file to > > > systematically be updated after all development of the submodules > is > > halted. > > > Then the results of the submodules has to be used to then go update > > the > > > module. Solvable - yes, but folks who work on large scale projects > will > > know > > > that suddenly requiring that type of development process change > isn't as > > > easy as it may sound on paper. > > > <RR> I can see why you wouldn't want to modify all your include by- > > revision > > > statements. But you would still need to update the module revision- > > label > > > based on changes done in the included submodules. > > > > > > Regards, > > > Reshad. > > > > > > It is possible to manage the "packaging" of submodules and > modules > > out > > > of band or other mechanisms. > > > > > > OpenConfig, for example, uses submodules but does not currently > > include > > > by version. I'm not proposing this is ideal. But I think we should > leave it > > as > > > acceptable. > > > > > > Rgds, > > > Jason > > > > > > > -----Original Message----- > > > > From: Reshad Rahman (rrahman) <rrahman@cisco.com> > > > > Sent: Tuesday, May 12, 2020 9:46 AM > > > > To: Sterne, Jason (Nokia - CA/Ottawa) < > jason.sterne@nokia.com>; > > > Martin > > > > Björklund <mbj+ietf@4668.se> > > > > Cc: netmod@ietf.org > > > > Subject: Re: [netmod] Revision labels for submodules > > > > > > > > Hi Jason, > > > > > > > > On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)" > > > > <jason.sterne@nokia.com> wrote: > > > > > > > > Hi Martin, > > > > > > > > Your approach sounds good to me. I was forgetting about > the > > > "editorial" > > > > level of change (e.g. the 3rd part of SemVer). So I agree > that moving > > a > > > leaf > > > > would be an editorial change in both submodules. > > > > > > > > But what if a module is not doing include by revision? > It may > > indeed > > > make > > > > sense to include by revision but it isn't mandated. For sake > of > > argument > > > here > > > > what if the module itself didn't change at all in this case? > > > > It is now mandated in section 3 of > draft-ietf-netmod-yang-module- > > > > versioning-00. > > > > > > > > > > > > It *feels* like the right thing to do here is to > consider the module > > > overall > > > > to have an editorial change. > > > > > > > > The revision statement of sub-modules has a scope of the > file (the > > > sub- > > > > module). It isn't clear to me whether the revision of a > *module* has > > a > > > scope > > > > that includes all sub-modules or if it is just a scope of > the module > > file. > > > But we > > > > could clarify that as part of this work. > > > > Because of include by revision, the module would have to > change to > > > include > > > > a different revision of a sub-module. > > > > > > > > Regards, > > > > Reshad. > > > > > > > > Jason > > > > > > > > > -----Original Message----- > > > > > From: Martin Björklund <mbj+ietf@4668.se> > > > > > Sent: Saturday, May 9, 2020 11:54 AM > > > > > To: rrahman@cisco.com > > > > > Cc: netmod@ietf.org; Sterne, Jason (Nokia - CA/Ottawa) > > > > > <jason.sterne@nokia.com> > > > > > Subject: Re: [netmod] Revision labels for submodules > > > > > > > > > > "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote: > > > > > > Hi, > > > > > > > > > > > > On 2020-05-08, 5:12 PM, "Martin Björklund" > > <mbj+ietf@4668.se> > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > "Reshad Rahman (rrahman)" <rrahman@cisco.com> > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > This came up during this week's meeting. We > briefly > > discussed > > > > whether > > > > > > > there's a need to version sub-modules or can > we restrict > > > versioning > > > > to > > > > > > > modules only. We would like to hear from the > WG on this, > > > > especially > > > > > > > those with experience managing sub-modules. > > > > > > > > > > > > Yes I think this is needed. At tail-f, there > are several > > modules > > > with > > > > > > many submodules. These modules always use > include by > > > revision, > > > > and > > > > > > always the main module is always uddated when any > > submodule > > > is > > > > > > updated. It doens't make much sense IMO to not > use > > include by > > > > > > revision. > > > > > > > > > > > > > For completeness, below is an update from > Jason in > > github: > > > > > > > My initial reaction is that we should not > preclude the use > > of > > > > revision > > > > > > > label with a submodule. Submodules have their > own > > version > > > > today. The > > > > > > > trick is to define (or explicitly say it is > out of scope) > > whether a > > > > > > > module version must change if any underlying > submodule > > > versions > > > > > > > change. That gets difficult if you consider > simply moving a > > leaf > > > > from > > > > > > > one sub-module to another (without changing > anything > > else > > > about > > > > it - > > > > > > > its context, etc). > > > > > > > > > > > > Why would this be difficult? The revision date > is updated on > > any > > > > > > editorial change (see 7.1.9 of RFC 7950). So if > a leaf gets > > moved > > > > > > from submodule A to submodule B, then their > revisions are > > > udpated, > > > > and > > > > > > hence the module's include-by revision is > udpated, and > > hence > > > the > > > > > > module's revision ois updated. > > > > > > > > > > > > I think what Jason meant is that by moving a leaf > between > > > > submodules, > > > > > > it's possible the module's schema didn't change. > > > > > > So yes revision date is updated, but you can't > blindly update > > the > > > > > > revision-label. > > > > > > > > > > Why not? > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > Reshad. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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/49 > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > Good point. What was meant by that the > label space for > > > > modules and > > > > > > > sub-modules are orthogonal. e.g. the > sub-module and > > > module > > > > both > > > > > have > > > > > > > the same label, it shouldn't be inferred > that the 2 are > > > related. > > > > > > > We'll change/clarify the text. > > > > > > > > > > > > > > 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 labels for submodules Reshad Rahman (rrahman)
- Re: [netmod] Revision labels for submodules Martin Björklund
- Re: [netmod] Revision labels for submodules Reshad Rahman (rrahman)
- Re: [netmod] Revision labels for submodules Martin Björklund
- Re: [netmod] Revision labels for submodules Martin Björklund
- Re: [netmod] Revision labels for submodules Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] Revision labels for submodules Reshad Rahman (rrahman)
- Re: [netmod] Revision labels for submodules Reshad Rahman (rrahman)
- Re: [netmod] Revision labels for submodules Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] Revision labels for submodules Andy Bierman
- Re: [netmod] Revision labels for submodules Reshad Rahman (rrahman)
- Re: [netmod] Revision labels for submodules Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] Revision labels for submodules Jan Lindblad
- Re: [netmod] Revision labels for submodules Reshad Rahman (rrahman)
- Re: [netmod] Revision labels for submodules Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] Revision labels for submodules Andy Bierman
- Re: [netmod] Revision labels for submodules Reshad Rahman (rrahman)
- Re: [netmod] Revision labels for submodules Reshad Rahman (rrahman)