Re: [netmod] All IETF YANG modules MUST include revision-label statements

Andy Bierman <andy@yumaworks.com> Mon, 30 March 2020 18:51 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 BEEA23A0E3D for <netmod@ietfa.amsl.com>; Mon, 30 Mar 2020 11:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Level:
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[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 jjQ_GVRLX3MX for <netmod@ietfa.amsl.com>; Mon, 30 Mar 2020 11:51:30 -0700 (PDT)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 431C73A0E38 for <netmod@ietf.org>; Mon, 30 Mar 2020 11:51:29 -0700 (PDT)
Received: by mail-yb1-xb33.google.com with SMTP id c13so6433094ybp.9 for <netmod@ietf.org>; Mon, 30 Mar 2020 11:51:29 -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=JNWwL+Xhq1VxwjvlTtLw+inGDm+EC+f89zRULEXGM6c=; b=zIUhv24WUfazVOJEF2jdiHEMzU3K3Z011APBqxLzX+6dGIGo4NY2Xz9uCkF3fBD4P9 1J2RrG/AWXizrA/50+QALZ0UIEPHCd+I7dHMGv23OfHfjytK7KUqM/0CBrigWhnwKgCe PiwRGB09S6B0bVPeAz+0K3GbVJnN6ZVjkShPbfjdpemSNiDM/GomP0RFYCPRJYed3YUs u/c5+CiWKBFuJl+k9+IB6sxHoBBqhbNBkvyvC1DsV/Z87+Z/UkVLuDo/fTo/bffkbgJY Y1zZ3NvoTCCmf57d+CSHp5lNfTM//1SONArNIWhEdpvb9cgGAk8cAvK+c/LtUaK5ahVB HaRg==
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=JNWwL+Xhq1VxwjvlTtLw+inGDm+EC+f89zRULEXGM6c=; b=Hm7MNF9UrfHwyn05GuC0usdFeChDBQFZA6AW9lTmJk1pB/NDj7HqXjngWetgntrd8F 52Z1+3WdqjHYBTJDXeMq3xHnH1/VeOLtGPnc6FH6MQfKyYLe/iGPj2+2/7hv9ZF28/2P zISlLaSlJDr0eSziqEFAS/cdO9E7V/NJzvHkK0A7g4Bj0D6Dwo0ClS9xZ/MT+ozMF1Zo ddrAA3dRh+jSBrquZ+vjimLWnJAPE6V6CtzGlHYEOMXU87DqNRqt+2ow4zJeAvXmoNEp QhyRGiO6dsmpTP7szOVe8GuxWxx23DVPC4eAzxwl0iaowacmzsrHIjX4dZ422qNa2qz7 X99g==
X-Gm-Message-State: ANhLgQ1DCwiIgk6DjSt0mEuMS+wMIUmmZ14yqbRMqGzPKy/uUnpfyGGs NxAOmhYchsSCxZYIgqoQ/1UZhPnRh5gxd/t6UASmqw==
X-Google-Smtp-Source: ADFU+vt1M7x9gZXULe/Cj5lExl/5COvy6vep+vrTVSZXPbZirmLXAUI/iMKu4IcVUmuysZql9HE0vktyqiVuW2N34pI=
X-Received: by 2002:a25:d495:: with SMTP id m143mr23419832ybf.274.1585594288029; Mon, 30 Mar 2020 11:51:28 -0700 (PDT)
MIME-Version: 1.0
References: <75CFDBD9-143C-407A-B7C3-26CEC51E229C@cisco.com> <20200328.094121.1160081114435152145.id@4668.se> <76623C79-BB91-4B5F-8FEA-406ADEAD1647@cisco.com> <20200330.202016.930329343788112268.id@4668.se>
In-Reply-To: <20200330.202016.930329343788112268.id@4668.se>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 30 Mar 2020 11:51:17 -0700
Message-ID: <CABCOCHS=y8d00xHLzV+LNpvN_=jScw5VizGYWXGopsQAi8qZUw@mail.gmail.com>
To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004bd91a05a216f01d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1JudmfdAZLbYJjwbX7NjIMDyiV8>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements
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, 30 Mar 2020 18:51:35 -0000

On Mon, Mar 30, 2020 at 11:20 AM Martin Björklund <mbj+ietf@4668.se> wrote:

> "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
> > On 2020-03-28, 4:41 AM, "Martin Björklund" <mbj+ietf@4668.se> wrote:
> >
> >     "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
> >     > Hi,
> >     >
> >     > https://github.com/netmod-wg/yang-ver-dt/issues/45
> >     >
> >     >         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.
> >     >
> >     > We believe some IETF models may not follow linear history, this was
> >     > brought up (I think) for IDR. Modified semver allows for non-linear
> >     > history and also doesn't preclude linear history. So even if we
> end up
> >     > having no IETF modules using branching, modified semver still
> works.
> >
> >     With the clarifiactions and updates in
> >     draft-verdt-netmod-yang-module-versioning, non-linear versioning
> >     works without modified semver.  So there is no technical reason to
> use
> >     modified semver in IETF modules.
> >
> > So are you proposing we use some other revision-label scheme (e.g.
> semver 2.0.0) for IETF modules?
> >
> > Or that IETF modules shouldn't use revision-labels?
>
> That IETF shouldn't use revision labels.
>
>
I do not like modified semver because it will cause confusion with the real
semver
introduced by OpenConfig.

Sometimes multiple release trains are needed, and the revision label (in
addition to revision-date)
can help distinguish revisions from each release train, so plain semver
that is introduced over time
would be OK.

It is possible to introduce only BC changes on each release train.
The BC vs. NBC issue has nothing to do with multiple release trains.



I am all for using rev:nbc-changes or rev:editorial-changes (which I
> think should be added) in IETF modules.
>
>
I agree that this is sufficient and modified semver provides no added
value, only confusion.


>
> /martin
>
>

Andy


>
> >
> > Or do you have something else in mind?
> >
> > Regards,
> > Reshad.
> >
> >     I can reluctantly accept that modified smever is published as
> >     Experimental.  But that doesn't mean that IETF modules should use it.
> >
> >
> >     /martin
> >
> >
> >     >
> >     > 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
>