Subject: [netmod] All IETF YANG modules MUST include revision-label statements (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 27 Mar 2020 21:41:35 +0000

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.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" <[email-masked] on behalf of rrahman=[email-masked]> 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" <[email-masked] on behalf of [email-masked]> 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
        [email-masked]
        https://www.ietf.org/mailman/listinfo/netmod

    _______________________________________________
    netmod mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Björklund <[email-masked]>
Date: Sat, 28 Mar 2020 09:41:21 +0100 (CET)

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> 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.

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)"
> <[email-masked] on behalf of
> rrahman=[email-masked]> wrote:
> 
>     Hi Martin,
>     
>     We've opened issues to track your review comments (see below). Will
>     kick off separate therads for each issue.
>     
>     On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
>     <[email-masked] on behalf of [email-masked]> wrote:
>     
>         Hi,
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 30 Mar 2020 17:55:50 +0000

On 2020-03-28, 4:41 AM, "Martin Björklund" <[email-masked]> wrote:

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?

Or do you have something else in mind?

Regards,
Reshad.

    /martin

---

From: Martin Björklund <[email-masked]>
Date: Mon, 30 Mar 2020 20:20:16 +0200 (CEST)

> Or that IETF modules shouldn't use revision-labels?

That IETF shouldn't use revision labels.

I am all for using rev:nbc-changes or rev:editorial-changes (which I
think should be added) in IETF modules.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Mar 2020 11:51:17 -0700

On Mon, Mar 30, 2020 at 11:20 AM Martin Björklund <[email-masked]> wrote:

> >     >             All IETF YANG modules MUST include revision-label
> statements for
> >     >             all
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.

> think should be added) in IETF modules.
I agree that this is sufficient and modified semver provides no added
value, only confusion.

> /martin

Andy

> >     >                reordered, as long as they do not change the
> ordering or any
> >     >                "rpc"
> >     >                "input" substatements.
> >     >
> >     >             Submodules MUST NOT use revision label schemes that
> could be
> >     >             confused
> >     >               In the filename of a YANG module, where it takes the
> form:
> >     >               module-
> >     >           filenames, but need to parse all available modules
> (wijust to find
> >     >           the
> >     >
> >     >
> >     >
> >     >         o  3.4
> >     >
> >     >             Alternatively, the first example could have used the
> revision
> >     >             label
> >     >             All IETF YANG modules MUST include revision-label
> statements for
> >     >             all

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 30 Mar 2020 20:18:33 +0000

On 2020-03-30, 2:20 PM, "Martin Björklund" <[email-masked]> wrote:

The revision label allows a user to easily figure out whether 2 revisions are (N)BC. Without the label, you always have to use tooling.

Regards,
Reshad.

    /martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 30 Mar 2020 20:26:25 +0000

From: 'Andy Bierman' <[email-masked]>
Date: Monday, March 30, 2020 at 2:51 PM
To: Martin Björklund <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, NetMod WG <[email-masked]>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

On Mon, Mar 30, 2020 at 11:20 AM Martin Björklund <[email-masked]<mailto:[email-masked]>> wrote:
"Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>> wrote:
> On 2020-03-28, 4:41 AM, "Martin Björklund" <[email-masked]<mailto:[email-masked]>> wrote:
>
>     "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>> wrote:
>     > Hi,
>     >

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.

I agree that this is sufficient and modified semver provides no added value, only confusion.
<RR> There are 2 questions here:

  1.  Is revision-label useful? We believe it is useful since it allows a user to easily figure out whether 2 revisions are (N)BC
  2.  If it is useful, what’s the best scheme to use? Semver, modified semver, …?

You’re not keen on modified semver just because of the name, or are there other reasons?

Regards,
Reshad.

Regards,
Reshad.

/martin

Andy

>     > <[email-masked]<mailto:[email-masked]> on behalf of
>     > rrahman=[email-masked]<mailto:[email-masked]>> wrote:
>     >
>     >     Hi Martin,
>     >
>     >     <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>     >
>     >         Hi,
>     >
>     >         [email-masked]<mailto:[email-masked]>
>     >     [email-masked]<mailto:[email-masked]>
_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Björklund <[email-masked]>
Date: Mon, 30 Mar 2020 22:39:57 +0200 (CEST)

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> The revision label allows a user to easily figure out whether 2
> revisions are (N)BC.

I think you meant "modified semver as revision label allows ..."

But it is not true.  What happened between 1.0.2M and 1.0.3M?

/martin

> Without the label, you always have to use tooling.
> 
> Regards,
> Reshad.
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Mar 2020 13:45:55 -0700

On Mon, Mar 30, 2020 at 1:26 PM Reshad Rahman (rrahman) <[email-masked]>
wrote:

>
>
> *From: *'Andy Bierman' <[email-masked]>
> *Date: *Monday, March 30, 2020 at 2:51 PM
> *To: *Martin Björklund <[email-masked]>
> *Cc: *"Reshad Rahman (rrahman)" <[email-masked]>, NetMod WG <
> [email-masked]>
> *Subject: *Re: [netmod] All IETF YANG modules MUST include revision-label
> statements
>
>
>
>
>
>
>
>    1. Is revision-label useful? We believe it is useful since it allows a
>    user to easily figure out whether 2 revisions are (N)BC

IMO it is a bad idea to overload a well-understood pattern like
major.minor.patch with
extra semantics like backward-compatibility.  A tool or a person can read
the revision history
for details about revision changes.  Adding letters to the end just
confuses people who
thought they were looking at openconfig-version or a familiar linux library
version string.

I don't agree that the IETF should be working to normalize NBC changes in
the first place.

Regards,

Andy

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 30 Mar 2020 21:35:07 +0000

> But it is not true.  What happened between 1.0.2M and 1.0.3M?

It tells you there is an NBC change between 1.0.2M and 1.0.3M.

The M gives an indication that a branch has been "poisoned" by an NBC change and that all bets are off from that point onwards in that branch.

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Martin Björklund
> Sent: Monday, March 30, 2020 4:40 PM
> To: [email-masked]
> Cc: [email-masked]
> >     >     >             All IETF YANG modules MUST include revision-label statements
> for
> >     >     >             all
> >     >     >     https://github.com/netmod-wg/yang-ver-
> dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> >     >     >
> >     >     >     Regards,
> >     >     >     Reshad.
> >     >     >
> >     >     >             Submodules MUST NOT use revision label schemes that could
> be
> >     >     >             confused
> >     >     >           filenames, but need to parse all available modules (wijust to
> find
> >     >     >           the
> >     >     >
> >     >     >
> >     >     >
> >     >     >         o  3.4
> >     >     >
> >     >     >             All IETF YANG modules MUST include revision-label statements
> for
> >     >     >             all

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 30 Mar 2020 21:38:01 +0000

>IMO it is a bad idea to overload a well-understood pattern like major.minor.patch with
extra semantics like backward-compatibility.

Semver already encodes BC information as a fundamental part of the numbering scheme. The major gets bumped for a NBC change.

>A tool or a person can read the revision history for details about revision changes.

That's only if the revision history is 100% complete. Those could get long and there may be a desire to eventually truncate.  And having to scan up a list is a lot more painful than looking at a nice 3.2.1 vs 2.0.1.

>Adding letters to the end just confuses people who thought they were looking at openconfig-version or a familiar linux library version string.

If there are no letters, then they can interpret it as a normal semver. If they see the letters it prompts them to say "oh - what's that. I'd better go look up what that means".

Jason

From: netmod <[email-masked]> On Behalf Of Andy Bierman
Sent: Monday, March 30, 2020 4:46 PM
To: Reshad Rahman (rrahman) <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

On Mon, Mar 30, 2020 at 1:26 PM Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

From: 'Andy Bierman' <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 30, 2020 at 2:51 PM
To: Martin Björklund <[email-masked]<mailto:[email-masked]>>
Cc: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, NetMod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

IMO it is a bad idea to overload a well-understood pattern like major.minor.patch with
extra semantics like backward-compatibility.  A tool or a person can read the revision history
for details about revision changes.  Adding letters to the end just confuses people who
thought they were looking at openconfig-version or a familiar linux library version string.

I don't agree that the IETF should be working to normalize NBC changes in the first place.

Regards,
Reshad.

Regards,
Reshad.

Andy

/martin

Andy

>     >     https://www.ietf.org/mailman/listinfo/netmod<https://www.ietf..org/mailman/listinfo/netmod>
>     >
>     >
>
>

---

From: Martin Björklund <[email-masked]>
Date: Mon, 30 Mar 2020 23:50:46 +0200 (CEST)

> It tells you there is an NBC change between 1.0.2M and 1.0.3M.

No.  As you note below it says that all bets are off.  The change
between these two could be a spelling error fix.  Hence, Reshad's
statement that "The revision label allows a user to easily figure out
whether 2 revisions are (N)BC." is not correct.

> The M gives an indication that a branch has been "poisoned" by an
> NBC change and that all bets are off from that point onwards in that
> branch.

/martin

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 30 Mar 2020 21:56:50 +0000

Please see inline

> From: Martin Björklund <[email-masked]>
> Sent: Monday, March 30, 2020 5:51 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> Cc: [email-masked]; [email-masked]

[>>JTS: ] You are correct and I made a mistake in my reply (looked too quickly). The M gives you one chance to indicate a NBC change in a branch. After that you no longer know (i.e. no worse than no revision label at all).
it is a compromise that allows:
- knowledge about the nature of changes on a branch that hasn't been poisoned yet
- one chance to alert users that an NBC change was made on a branch
That is useful enough to have it IMO. 

> > > >     >     >             existing YANG modules.  The revision-label MUST take the
> form
> > > of a
> > > >     >     >     We've opened issues to track your review comments (see
> below).
> > > Will
> > > >     >     >                reordered, as long as they do not change the ordering or
> any
> > > >     >     >                "rpc"
> > > >     >     >                "input" substatements.
> > > >     >     >
> > > >     >     >           What if my project use another dialect of semver, that
> wouldn't
> > > be
> could
> > > >     >     >           Hmm, how do I ensure that this MUST NOT is handled
> correctly?
> > > What
> > > >     >     >           says "SHOULD".  But existing tools implement this SHOULD,
> and
> > > they
> > > >     >     >           for a module with a certain revision date cannot simply
> check
> > > the
> > > >     >     >           I think the module name "ietf-yl-revisions" should be
> changed
> > > to
> > > >     >     >             existing YANG modules.  The revision-label MUST take the
> form
> > > of a

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 30 Mar 2020 22:11:15 +0000

On 2020-03-30, 5:51 PM, "Martin Björklund" <[email-masked]> wrote:

    No.  As you note below it says that all bets are off.  The change
    between these two could be a spelling error fix.  Hence, Reshad's
    statement that "The revision label allows a user to easily figure out
    whether 2 revisions are (N)BC." is not correct.
You are correct that once a branch is poisoned with an 'M', the information provided is not as rich.
Even though you don't know whether 1.0.3M is BC/NBC with 1.0.2M, you still know that
- 1.0.2M is NBC with 1.0.1 and 1.0.0
- 1.0.3M is NBC with 1.0.1 and 1.0.0
- 1.0.1 is BC with 1.0.0

Still useful IMO.

Regards,
Reshad.

    /martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Mar 2020 15:15:28 -0700

On Mon, Mar 30, 2020 at 2:57 PM Sterne, Jason (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> [>>JTS: ] You are correct and I made a mistake in my reply (looked too
> quickly). The M gives you one chance to indicate a NBC change in a branch.
> After that you no longer know (i.e. no worse than no revision label at all).
Don't agree.
Also find the argument that the revision history will be incomplete not
convincing.
If a developer knows enough to add the M then they can know enough to
fill in the revision-stmt correctly.

 Andy

> > > > Subject: Re: [netmod] All IETF YANG modules MUST include
> revision-label
> > > > statements
> > > >
> > > > >     > On 2020-03-28, 4:41 AM, "Martin Björklund" <[email-masked]
> >
> > wrote:
> > > > >     >
> > > > >     >     >             newly published YANG modules, and all
> newly published
> > > > revisions of
> > > > >     >     >             YANG semantic version number
> [I-D.verdt-netmod-yang-
> > > > semver].
> > > > >     >     >
> > > > >     >     >           I strongly disagree with this new rule.
> IETF modules use a
> > linear
> > > > >     >     > 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.
> > > > >     >
> > > > >     >     works without modified semver.  So there is no technical
> reason to
> > use
> > > > >     > So are you proposing we use some other revision-label scheme
> (e.g.
> > > > semver 2.0.0) for IETF modules?
> > > > >     >
> > > > >     >     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)"
> mbj+ietf@4668..se>
> > > > >     >     >             o  In statements that have any data
> definition statements
> > as
> > > > >     >     >                substatements, those data definition
> substatements MAY
> > be
> > > > >     >     >           I think this needs to capture that no
> descendant statements
> > to
> > > > >     >     >           "input" can be reordered.  Same for "output"
> (note, "input"
> > and
> > > > >     >     >             typedef in the ietf-yang-semver YANG
> module MUST be
> > > > interpreted as
> > > > >     >     >               In the filename of a YANG module, where
> it takes the form:
> > > > >     >     >               module-
> > > > >     >     >           Should this section update 5.2 of RFC 7950?
> I know that 5.2
> > just
> > > > >     >     >           But I wonder if this a good idea.  It means
> that a tool that
> > looks
> > > > >     >     >           I don't think rev:status-description is
> necessary / worth it.
> > This
> > > > >     >     >           can easily be written with the normal
> description statement
> > > > instead:
> > > > >     >     >
> > > > >     >     >           The example modules should be legal YANG
> modules.  Use
> > e.g.
> > > > >     >     >           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 {
> > > > >     >     >           "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:
> > > > >     >     >
> > > > >     >     >             newly published YANG modules, and all
> newly published
> > > > revisions of
> > > > >     >     >             YANG semantic version number
> [I-D.verdt-netmod-yang-
> > > > semver].
> > > > >     >     >
> > > > >     >     >           I strongly disagree with this new rule.
> IETF modules use a
> > linear
> > > > >     >     >            4.  For status "obsolete", it is
> RECOMMENDED to keep the
> > > > "status-
> > > > >     >     >           All extensions should specify the grammar;
> i.e., in which
> > > > statements

---

From: Kent Watsen <[email-masked]>
Date: Mon, 30 Mar 2020 22:48:52 +0000

[I’ve scanned the entire thread before circling back to respond to this message]

> Martin writes:

> Experimental.  But that doesn't mean that IETF modules should use it.

I assume Martin’s reference to Experimental follows my adoption-call comment here: https://mailarchive.ietf.org/arch/msg/netmod/uZZqBs1yK0EpbXgRJRFQihHWo5s/ <https://mailarchive.ietf.org/arch/msg/netmod/uZZqBs1yK0EpbXgRJRFQihHWo5s/>

Changing the "Intended Status” for an adopted document is easily done at any time before publication.

PS: Andy didn’t participate in the call, though he appears to be coming in strong now...

Kent

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 30 Mar 2020 23:07:14 +0000

Hi Kent,

Even though we are debating/discussing whether iETF moduels should use YANG semver (aka modified semver), please note that there is interest from other publishers of YANG modules to use semver or YANG semver.

Regarding your comment below, is it specific to IETF modules or more general?
I don’t think the “semver" label has been fully justified relative to the disruption I perceive it may cause.

Regards,
Reshad.

From: Kent Watsen <[email-masked]>
Date: Monday, March 30, 2020 at 6:49 PM
To: Martin Björklund <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

Martin writes:

I assume Martin’s reference to Experimental follows my adoption-call comment here: https://mailarchive.ietf.org/arch/msg/netmod/uZZqBs1yK0EpbXgRJRFQihHWo5s/

Kent

---

From: Kent Watsen <[email-masked]>
Date: Mon, 30 Mar 2020 23:22:01 +0000

> Even though we are debating/discussing whether iETF moduels should use YANG semver (aka modified semver), please note that there is interest from other publishers of YANG modules to use semver or Y…

Details?

> "I don’t think the “semver" label has been fully justified relative to the disruption I perceive it may cause.”

I was thinking in general.  YMMV.

Kent // contributor

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 31 Mar 2020 02:41:26 +0000

Details?
    
I was referring to vendors, not SDOs.

Regards,
Reshad.

    Kent // contributor

---

From: "Ivory, William" <[email-masked]>
Date: Tue, 31 Mar 2020 07:40:16 +0000

Apologies if this has already been suggested and deemed unworkable, but if you have access to all previous version labels for a branch then you can add 'M' only to the versions that are NBC with the previous version, and subsequent versions could drop the M until the next NBC change, ie:

1.0.0 -> 1.0.1 -> 1.0.2 > 1.0.3M -> 1.0.4 -> 1.0.5M ...

Here 1.04 is BC with 1.03 but not 1.0.0 - 1.0.2; 1.0.5 is NBC with 1.0.4 and previous versions etc.

The revision statements contain the revision-labels so you should have all the previous revision-labels present in the file, and you have all the data you need. Now you don't have the problem of the branch being poisoned as soon as the first M is added.

William

On Mon, 2020-03-30 at 22:11 +0000, Reshad Rahman (rrahman) wrote:

On 2020-03-30, 5:51 PM, "Martin Björklund" <[email-masked]<mailto:[email-masked]>> wrote:

- 1.0.1 is BC with 1.0.0

Still useful IMO.

Regards,

Reshad.

    /martin

    > > From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Björklund

    > > To: [email-masked]<mailto:[email-masked]>

    > > Cc: [email-masked]<mailto:[email-masked]>

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

    > > > On 2020-03-30, 2:20 PM, "Martin Björklund" <[email-masked]<mailto:[email-masked]>> wrote:

    > > >     > On 2020-03-28, 4:41 AM, "Martin Björklund" <[email-masked]<mailto:[email-masked]>> wrote:

    > > >     >     > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dver-2Ddt_issues_45&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=nyxzbv7ZWMgcXuMEW8MqjeT3oVxla6qFiF96M8SaMUY&e=

    > > >     >     >             newly published YANG modules, and all newly published

    > > >     >     >             existing YANG modules.  The revision-label MUST take the form

    > > >     >     >             YANG semantic version number [I-D.verdt-netmod-yang-

    > > >     > So are you proposing we use some other revision-label scheme (e.g.

    > > >     >     > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman

    > > >     >     > rrahman=[email-masked]<mailto:rrahman=[email-masked]>> wrote:

    > > >     >     >     We've opened issues to track your review comments (see below).

    > > >     >     >     https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dver-2D&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=HjVuj69fVsCLulvyNUajxCbtSKPAVkUZVJNK8s-f-Ho&e=

    > > >     >     >     <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    > > >     >     >                reordered, as long as they do not change the ordering or any

    > > >     >     >             typedef in the ietf-yang-semver YANG module MUST be

    > > >     >     >           What if my project use another dialect of semver, that wouldn't

    > > >     >     >           Hmm, how do I ensure that this MUST NOT is handled correctly?

    > > >     >     >               In the filename of a YANG module, where it takes the form:

    > > >     >     >           says "SHOULD".  But existing tools implement this SHOULD, and

    > > >     >     >           for a module with a certain revision date cannot simply check

    > > >     >     >           can easily be written with the normal description statement

    > > >     >     >             Alternatively, the first example could have used the revision

    > > >     >     >             "1.0.0" instead, which selects the same set of

    > > >     >     >           I think the module name "ietf-yl-revisions" should be changed

    > > >     >     >           Wouldn't it be better if the leaf "deprecated-nodes-

    > > >     >     >           "obsolete-nodes-absent" were of type "boolean" rather than

    > > >     >     >             newly published YANG modules, and all newly published

    > > >     >     >             existing YANG modules.  The revision-label MUST take the form

    > > >     >     >             YANG semantic version number [I-D.verdt-netmod-yang-

    > > >     >     >            4.  For status "obsolete", it is RECOMMENDED to keep the

    > > >     >     >           All extensions should specify the grammar; i.e., in which

    > > >     >     >         https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=z5LiDOlko48vuqlIgA0Gm7dcsxmHOtwfod6wC46lRU0&e=

    > > >     >     >     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=z5LiDOlko48vuqlIgA0Gm7dcsxmHOtwfod6wC46lRU0&e=

    > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=z5LiDOlko48vuqlIgA0Gm7dcsxmHOtwfod6wC46lRU0&e=

netmod mailing list

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=z5LiDOlko48vuqlIgA0Gm7dcsxmHOtwfod6wC46lRU0&e=

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 31 Mar 2020 12:09:14 +0000

[As an individual contributor]

My impression is that Semver 2.0.0 works fine if you can always force clients to move to the latest version of the API whenever any bugfixes are made to the API (whether they are BC or NBC).  This is a natural fit for open source projects, but not so great for long life paid support contracts.

The goal of YANG semver is not to facilitate release branching.  It is to allow vendors to fix YANG modules without forcing clients to update to the latest version of that YANG module (which may contain other unrelated NBC changes and have lots of dependencies on other modules).

Note that OpenConfig also hit this problem, but they proposed a different solution.  I.e. ship the base module with another module that contains deviations to fix any bugs in the base module.  Alas this completely decouples the real module history from any revision-date/version number contained in the module, since to really understand the version of the module you also need to know the set of associated patch modules containing any deviations to the base module.

Regards,
Rob

Sent: 30 March 2020 19:51

/martin

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 31 Mar 2020 15:37:12 +0000

[replying to Reshad as well]

Hi Rob,

> My impression is that Semver 2.0.0 works fine if you can always force clients to move to the latest version of the API whenever any bugfixes are made to the API (whether they are BC or NBC).  This…

Agreed.

> The goal of YANG semver is not to facilitate release branching.  It is to allow vendors to fix YANG modules without forcing clients to update to the latest version of that YANG module (which may co…

This is what Reshad was pointing to as well.  I’m very familiar with the issue, from my Juniper days, where there were all sorts of patch and (gasp) customer special releases, either of which could introduce any number of NBCs.  

The background, of course, is that [very important] customers have working/validated infrastructure running a specific release and simply cannot tolerate any change beyond the very specific one they need *NOW*

I get it, truly,  but I feel that the ‘m’ / ‘M’ suffixes are both inconsistent with general understanding and insufficiently to express what is needed.  

A possible fix might be to allow for <major>.<minor>.<patch>[-<anystring>], thereby enabling vendors to encode any format off a base release…and rely on inspection of the “revision” history indicate if/when NBC changes occurred.  

But then I question (again) the need for the simplified format at all, as opposed to just using revision dates.  For instance, if <anysting> represents a long history of NBCs, that they were based on some source M.m.p starts to lose relevance.

Is the expectation that the vendor's module versions will use <major>.<minor>.<patch> values mimicking their release numbers?  For instance, would FooBar OS version 20.1.2 implement YANG module "[email-masked]”?    I can see product mangers pushing for this, but then are companies (like Juniper) that use alternate release name-formatting strategies disadvantaged?  How is that fair?   To thwart this, would the WG be willing to assert that the history MUST start at 0.0.0 and MUST only monotonically increment values?

> Note that OpenConfig also hit this problem, but they proposed a different solution.  I.e. ship the base module with another module that contains deviations to fix any bugs in the base module.  Alas…

I’d need to see an illustration of this to be sure I understand, but my first impression is that it is yet another attempt to fit a square into a circle.  

In the end, I see no substitute to relying on “revision” history which 1) perfectly tracks branching history and can flag if/when NBC changes occurred.  

Kent // contributor

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 31 Mar 2020 16:04:25 +0000

Hi,

Thanks for the suggestion.

This was discussed, I think the reason we didn’t go with that solution is that (as you mentioned) you need the module contents with all the previous version labels. Does anyone from the design team recall any other details?

Regards,
Reshad.

From: "Ivory, William" <[email-masked]>
Date: Tuesday, March 31, 2020 at 3:40 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

William

- 1.0.1 is BC with 1.0.0

Still useful IMO.

Regards,

Reshad.

    /martin

netmod mailing list

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Mar 2020 09:19:32 -0700

On Tue, Mar 31, 2020 at 8:37 AM Kent Watsen <[email-masked]> wrote:

> My impression is that Semver 2.0.0 works fine if you can always force
> clients to move to the latest version of the API whenever any bugfixes are
> made to the API (whether they are BC or NBC).  This is a natural fit for
> open source projects, but not so great for long life paid support contracts.
>
>
> Agreed.
>
>
> The goal of YANG semver is not to facilitate release branching.  It is to
> allow vendors to fix YANG modules without forcing clients to update to the
> latest version of that YANG module (which may contain other unrelated NBC
> changes and have lots of dependencies on other modules).
>
>
> This is what Reshad was pointing to as well.  I’m very familiar with the
> issue, from my Juniper days, where there were all sorts of patch and (gasp)
> customer special releases, either of which could introduce any number of
> NBCs.
>
> The background, of course, is that [very important] customers have
> working/validated infrastructure running a specific release and simply
> cannot tolerate any change beyond the very specific one they need *NOW*
>
> I get it, truly,  but I feel that the ‘m’ / ‘M’ suffixes are both
> inconsistent with general understanding and insufficiently to express what
> is needed.
>
>

+1

I also find the granularity of NBC info to be mostly worthless at the
module level.
There is no difference between a 1 leaf bugfix and a complete rewrite of
the module.
Let's say 1 leaf "type string" needs to be changed to add "length 1..max".
This reduces the value set for 1 leaf by 1 value.

This flags the entire module as NBC and you would bump the major revision
number.
The entire premise that one can decide if it is safe to upgrade based on
the version string is flawed.

A possible fix might be to allow for <major>.<minor>.<patch>[-<anystring>],
> thereby enabling vendors to encode any format off a base release…and rely
> on inspection of the “revision” history indicate if/when NBC changes
> occurred.
>
> But then I question (again) the need for the simplified format at all, as
> opposed to just using revision dates.  For instance, if <anysting>
> represents a long history of NBCs, that they were based on some source
> M.m.p starts to lose relevance.
>
> Is the expectation that the vendor's module versions will use
> <major>.<minor>.<patch> values mimicking their release numbers?  For
> instance, would FooBar OS version 20.1.2 implement YANG module
> "[email-masked]”?    I can see product mangers pushing for this, but then
> are companies (like Juniper) that use alternate release name-formatting
> strategies disadvantaged?  How is that fair?   To thwart this, would the WG
> be willing to assert that the history MUST start at 0.0.0 and MUST only
> monotonically increment values?
>
>
> Note that OpenConfig also hit this problem, but they proposed a different
> solution.  I.e. ship the base module with another module that contains
> deviations to fix any bugs in the base module.  Alas this completely
> decouples the real module history from any revision-date/version number
> contained in the module, since to really understand the version of the
> module you also need to know the set of associated patch modules containing
> any deviations to the base module.
>
>
> I’d need to see an illustration of this to be sure I understand, but my
> first impression is that it is yet another attempt to fit a square into a
> circle.
>
>

I don't have a solution proposal, but it would be great if a vendor could
issue a patch
to a standard module which says "this is the standard module plus these
known Errata ".
OK if this is in the form of deviations

In the end, I see no substitute to relying on “revision” history which 1)
> perfectly tracks branching history and can flag if/when NBC changes
> occurred.
>
>
Agreed

Andy

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 31 Mar 2020 16:42:08 +0000

The idea is that following down a chain of YANG versions of a module results in a semver that is "cumulative".  Just like you can't do this:

1.0.0 -> 1.1.0 -> 2.0.0 -> 3.0.0 -> 1.1.0

That would be confusing when comparing 1.0.0 and 1.1.0. The numbers would imply they are BC.

Once you mark an "M" you can't take it away.

In William's example, someone looking at 1.0.4 vs 1.0.2 would think they are BC with each other (by just looking at the yang semver.

We'd rather err on the side of "false positives" for an NBC change so that someone looks into it.  (e.g. 1.0.3M -> 1.0.4M may not be an NBC change but users should look just in case).

Jason

From: Reshad Rahman (rrahman) <[email-masked]>
Sent: Tuesday, March 31, 2020 12:04 PM
To: Ivory, William <[email-masked]>; [email-masked]; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

Hi,

Regards,
Reshad.

From: "Ivory, William" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 31, 2020 at 3:40 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

William

- 1.0.1 is BC with 1.0.0

Still useful IMO.

Regards,

Reshad.

    /martin

netmod mailing list

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 31 Mar 2020 16:48:09 +0000

Darn - poor choice of my first example.  I meant this:

1.0.0 -> 1.1.0 -> 2.0.0 -> 3.0.0 -> 1.2.0

would be confusing comparing 1.0.0 and 1.2.0.

(I wasn't trying to illustrate a "loop", or coming back to a file that was the same content as previously)

From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Tuesday, March 31, 2020 12:42 PM
To: Reshad Rahman (rrahman) <[email-masked]>; Ivory, William <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [netmod] All IETF YANG modules MUST include revision-label statements

Jason

From: Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 31, 2020 12:04 PM
To: Ivory, William <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

Hi,

Regards,
Reshad.

William

- 1.0.1 is BC with 1.0.0

Still useful IMO.

Regards,

Reshad.

    /martin

netmod mailing list

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 31 Mar 2020 17:18:59 +0000

Hi Andy,

I wasn't so much worried about people filling in the revision statements as they go along. But after a while (especially for vendor models) the list of revision statements could get very large and there may be a desire to remove some of them, or somehow "compress" the information for the 2nd half of the statements, etc.

One primary value of the yang semver is a quick easy way to see if two arbitrary versions are BC, NBC (or in the case of M, "possibly NBC, you'd better check"). It doesn't require keeping a long history to have a "cumulative" indication.

Jason

From: Andy Bierman <[email-masked]>
Sent: Monday, March 30, 2020 6:15 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Cc: Martin Björklund <[email-masked]>; [email-masked]
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements

On Mon, Mar 30, 2020 at 2:57 PM Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Please see inline

> From: Martin Björklund <[email-masked]<mailto:[email-masked]>>
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Don't agree.
Also find the argument that the revision history will be incomplete not convincing.
If a developer knows enough to add the M then they can know enough to
fill in the revision-stmt correctly.

 Andy

> > > > On 2020-03-30, 2:20 PM, "Martin Björklund" <[email-masked]<mailto:[email-masked]>> wrote:
> > > >
> > > >     >     >     <[email-masked]<mailto:[email-masked]> on behalf of mbj+ietf@4668..se>
> wrote:
> > > >     >     >
> > > >     >     >         Hi,
> > > >     >     >

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Mar 2020 12:26:27 -0700

> Darn - poor choice of my first example.  I meant this:

This is the use-case I want to support.
Using revision-date alone, a tool and administrator would think 1.2.0 is an
update to 3.0.0
If a revision-label is added, then it is clear that 1.2.0 is based on
1.1.0, not 3.0.0.

Whether ANY update has BC vs. NBC changes in it is another issue.
There might be lots of info that one might encode into the revision-label.
This is often the case, and a good argument to create additional metadata
fields
and leave the revision-label "clean". (e.g. vendor-revision-label)

Andy

> *From:* Sterne, Jason (Nokia - CA/Ottawa)
> *Sent:* Tuesday, March 31, 2020 12:42 PM
> *To:* Reshad Rahman (rrahman) <[email-masked]>; Ivory, William <
> [email-masked]>; [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: [netmod] All IETF YANG modules MUST include revision-label
> statements
>
>
>
> The idea is that following down a chain of YANG versions of a module
> results in a semver that is "cumulative".  Just like you can't do this:
>
>
>
> In William's example, someone looking at 1.0.4 vs 1.0.2 would think they
> are BC with each other (by just looking at the yang semver.
>
>
>
> We'd rather err on the side of "false positives" for an NBC change so that
> someone looks into it.  (e.g. 1.0.3M -> 1.0.4M may not be an NBC change but
> users should look just in case).
>
>
>
> Jason
>
>
>
> *From:* Reshad Rahman (rrahman) <[email-masked]>
> *Sent:* Tuesday, March 31, 2020 12:04 PM
> *To:* Ivory, William <[email-masked]>; [email-masked];
> Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [netmod] All IETF YANG modules MUST include revision-label
> statements
>
>
>
> Hi,
>
>
>
> This was discussed, I think the reason we didn’t go with that solution is
> that (as you mentioned) you need the module contents with all the previous
> version labels. Does anyone from the design team recall any other details?
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *"Ivory, William" <[email-masked]>
> *Date: *Tuesday, March 31, 2020 at 3:40 AM
> *To: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> Apologies if this has already been suggested and deemed unworkable, but if
> you have access to all previous version labels for a branch then you can
> add 'M' only to the versions that are NBC with the previous version, and
> subsequent versions could drop the M until the next NBC change, ie:
>
>
>
> The revision statements contain the revision-labels so you should have all
> the previous revision-labels present in the file, and you have all the data
> you need. Now you don't have the problem of the branch being poisoned as
> soon as the first M is added.
>
>
>
> William
>
>
>