Subject: [netmod] versioning procedures (RFC vs. I-D)

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Apr 2020 10:28:34 -0700

Hi,

I just want to confirm that all the proposed documentation procedures
using new extensions are limited in scope to published modules only,
and not applied to unpublished modules (terms defined in RFC 8407).

IMO it would be harmful to module usability to assign revision-labels or
include revision-related extensions in unpublished modules (e.g., Internet
Drafts).
Consider how cluttered and confusing the client-server modules would be
if the 50+ NBC changes and versions were tracked through all the I-Ds.

For IETF modules, the first usage of the revision-label
should be in the initial RFC, and be set to 1.0.0.

If the RFC is ever republished then one can expect to find an updated
revision-label and possibly extensions tracking NBC changes.

Andy

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 1 Apr 2020 17:38:18 +0000

> On Apr 1, 2020, at 13:28, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> include revision-related extensions in unpublished modules (e.g., Internet Drafts).

The semver scheme allocates a major version of 0 for pre-releases where the BC/NBC rules do not apply.  I agree that a first official RFC release should be 1.0.0 (from a semver revision-label standpoint).  From a design team standpoint, I know we mentioned the 0 versioning early on, but I don’t think we spent much time talking about modules under development overall.

My take would align to yours that we wouldn’t clutter a module with development NBC tracking.

Joe

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Apr 2020 11:07:09 -0700

On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) <[email-masked]>
wrote:

> The semver scheme allocates a major version of 0 for pre-releases where
> the BC/NBC rules do not apply.  I agree that a first official RFC release
> should be 1.0.0 (from a semver revision-label standpoint).  From a design
> team standpoint, I know we mentioned the 0 versioning early on, but I don’t
> think we spent much time talking about modules under development overall.
>
>

IMO it is confusing to ignore the semver rules for the special 0.x.y
releases.
There are many NBC changes made at this point which are treated as minor or
patch changes.
The procedure is really broken once you consider a WG developing any
RFC-bis module.
Now the major version is not 0 and all updates look like real releases.

Andy

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 1 Apr 2020 18:13:26 +0000

From: netmod <[email-masked]> on behalf of 'Andy Bierman' <[email-masked]>
Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>> wrote:

> On Apr 1, 2020, at 13:28, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>

IMO it is confusing to ignore the semver rules for the special 0.x.y releases.
There are many NBC changes made at this point which are treated as minor or patch changes.
The procedure is really broken once you consider a WG developing any RFC-bis module.
Now the major version is not 0 and all updates look like real releases.
<RR> I don’t think that’s needed. Initial module in RFC has 1.0.0, module in (released) RFC-bis can go to 1.0.1, 1.1.0 or 2.0.0 depending on the change.

Regards,
Reshad.

Joe

Andy

---

From: Italo Busi <[email-masked]>
Date: Thu, 2 Apr 2020 09:06:09 +0000

Reshad,

My doubt and, if I understand well also Andy’s question, is about the fact that before publishing an RFC-bis with e.g., 1.1.0, we will have a set of Internet-Drafts updating the RFC with 1.0.0

What versions should be used in the YANG modules published in these Internet-Drafts?

Think about the following scenario: -00 version provide BC changes to the RFC module but the -01 version provide NBC changes to what has been added in the -00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with the -00 version module)

Thanks, Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Reshad Rahman (rrahman) [mailto:[email-masked]]
Sent: mercoledì 1 aprile 2020 20:13
To: Andy Bierman <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of 'Andy Bierman' <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" <[email-masked]<mailto:[email-masked]>>
Cc: NetMod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

Regards,
Reshad.

Joe

Andy

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 2 Apr 2020 11:11:40 +0000

Hi,

From: Italo Busi <[email-masked]>
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" <[email-masked]>, 'Andy Bierman' <[email-masked]>, "Joe Clarke (jclarke)" <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: RE: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

Think about the following scenario: -00 version provide BC changes to the RFC module but the -01 version provide NBC changes to what has been added in the -00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with the -00 version module)
<RR> So bis 00 would be 1.1.0 (BC with RFC module).
Bis 01 should be updated according to its relationship to the RFC module (bis 00 doesn’t matter anymore), when RFC bis is published it won’t have the full history.

Hope I correctly understood your question.

Regards,
Reshad.

Thanks, Italo

Italo Busi

Regards,
Reshad.

Joe

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Apr 2020 07:26:02 -0700

On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Hi,
>
>
>
> *From: *Italo Busi <[email-masked]>
> *Date: *Thursday, April 2, 2020 at 5:06 AM
> *To: *"Reshad Rahman (rrahman)" <[email-masked]>, 'Andy Bierman' <
> [email-masked]>, "Joe Clarke (jclarke)" <[email-masked]>
> *Cc: *NetMod WG <[email-masked]>
> *Subject: *RE: [netmod] versioning procedures (RFC vs. I-D)
>
>
>
> Reshad,
>
>
>
> My doubt and, if I understand well also Andy’s question, is about the fact
> that before publishing an RFC-bis with e.g., 1.1.0, we will have a set of
> Internet-Drafts updating the RFC with 1.0.0
>
>
>
> Think about the following scenario: -00 version provide BC changes to the
> RFC module but the -01 version provide NBC changes to what has been added
> in the -00 module (thus the -01 version is BC with the RFC 1.0.0 module but
> NBC with the -00 version module)
>
> Bis 01 should be updated according to its relationship to the RFC module
> (bis 00 doesn’t matter anymore), when RFC bis is published it won’t have
> the full history.
>
>
>

This semver plan is not very intuitive and not sure it works.

draft-00

   container the-container;             version 0.1.0      OK

draft-01:
   container my-container;             version 0.2.0;   rules violated; NBC
should force 1.0.0

draft-02:

    container my-container {           version 0.3.0; should be 1.1.0
        leaf my-leaf { type int32; }
    }

RFC-1:

    container my-container {           version 1.0.0;  should be 2.0.0
according to NBC rules
        leaf my-leaf { type uint32; }
    }

bis-draft-00:

   container my-container {           version 1.1.0; OK
        leaf my-leaf { type uint32; }
        leaf another-leaf { type int32; }
    }

bis-draft-01:

  container my-container {                  diff against RFC-1:  version
1.1.0 but already used; use 1.2.0?
        leaf my-leaf { type uint32; }
        leaf another-leaf { type uint32; }
    }

bis-draft-02:

  container example-my-container {                  diff against RFC-1:
version 2.0.0 but use 1.3.0 instead?
        leaf my-leaf { type uint32; }
        leaf another-leaf { type uint32; }
    }

[repeat NBC step bis-draft-02 10 times.... now up to version 12.0.0 or is
it 1.13.0? something else?

RFC-2:   publish draft-12 as RFC-2: now change the label from 1.13.0 to
2.0.0? or leave it 12.0.0?

IMO it is very confusing that the stated rules are so inconsistent and
are violated so many ways.
There should be no revision-label at all in Internet Drafts because these
documents are unpublished.
They should only be added to the RFC version.

The semver procedures are not intended to work for unpublished modules that
are only
meant for review, not for implementation. The revision-label provides only
noise in Internet Drafts.

Regards,

Andy

> *Italo Busi*
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
>
>
>
> *From:* Reshad Rahman (rrahman) [mailto:[email-masked]]
> *Sent:* mercoledì 1 aprile 2020 20:13
> *To:* Andy Bierman <[email-masked]>; Joe Clarke (jclarke) <
> [email-masked]>
> *Cc:* NetMod WG <[email-masked]>
> *Subject:* Re: [netmod] versioning procedures (RFC vs. I-D)
>
>
>
>
>
> *From: *netmod <[email-masked]> on behalf of 'Andy Bierman' <
> [email-masked]>
> *Date: *Wednesday, April 1, 2020 at 2:07 PM
> *To: *"Joe Clarke (jclarke)" <[email-masked]>
> *Cc: *NetMod WG <[email-masked]>
> *Subject: *Re: [netmod] versioning procedures (RFC vs. I-D)
>
>
>
>
>
>
>
> <RR> I don’t think that’s needed. Initial module in RFC has 1.0.0, module
> in (released) RFC-bis can go to 1.0.1, 1.1.0 or 2.0.0 depending on the
> change.
>
>
>
> Regards,
>
> Reshad.
>
>
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 2 Apr 2020 14:46:24 +0000

From: 'Andy Bierman' <[email-masked]>
Date: Thursday, April 2, 2020 at 10:26 AM
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: Italo Busi <[email-masked]>, "Joe Clarke (jclarke)" <[email-masked]>, NetMod WG <[email-masked]>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

From: Italo Busi <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, 'Andy Bierman' <[email-masked]<mailto:[email-masked]>>, "Joe Clarke (jclarke)" <[email-masked]<mailto:[email-masked]>>
Cc: NetMod WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

draft-00

draft-01:
   container my-container;             version 0.2.0;   rules violated; NBC should force 1.0.0

draft-02:

RFC-1:

    container my-container {           version 1.0.0;  should be 2.0.0 according to NBC rules
        leaf my-leaf { type uint32; }
    }

bis-draft-00:

bis-draft-01:

  container my-container {                  diff against RFC-1:  version 1.1.0 but already used; use 1.2.0?
        leaf my-leaf { type uint32; }
        leaf another-leaf { type uint32; }
    }

bis-draft-02:

  container example-my-container {                  diff against RFC-1:  version 2.0.0 but use 1.3.0 instead?
        leaf my-leaf { type uint32; }
        leaf another-leaf { type uint32; }
    }

[repeat NBC step bis-draft-02 10 times.... now up to version 12.0.0 or is it 1.13.0? something else?

RFC-2:   publish draft-12 as RFC-2: now change the label from 1.13.0 to 2.0.0? or leave it 12.0.0?

IMO it is very confusing that the stated rules are so inconsistent and are violated so many ways.
There should be no revision-label at all in Internet Drafts because these documents are unpublished.
They should only be added to the RFC version.

The semver procedures are not intended to work for unpublished modules that are only
meant for review, not for implementation. The revision-label provides only noise in Internet Drafts.
<RR2> I think it’s useful to have a revision label in a draft because it indicates nature of changes (BC v/s NBC) compared to the previous published revision (RFC).
But you are absolutely right that setting the version based on changes with the previous draft revision is useless and confusing.

Regards,
Reshad.

Regards,
Reshad.

Thanks, Italo

Andy

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : [email-masked]<mailto:[email-masked]>

From: Reshad Rahman (rrahman) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: mercoledì 1 aprile 2020 20:13
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>
Cc: NetMod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

Regards,
Reshad.

Joe

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Apr 2020 08:27:59 -0700

On Thu, Apr 2, 2020 at 7:46 AM Reshad Rahman (rrahman) <[email-masked]>
wrote:

>
>
>
>
> *From: *'Andy Bierman' <[email-masked]>
> *Date: *Thursday, April 2, 2020 at 10:26 AM
> *To: *"Reshad Rahman (rrahman)" <[email-masked]>
> *Cc: *Italo Busi <[email-masked]>, "Joe Clarke (jclarke)" <
> [email-masked]>, NetMod WG <[email-masked]>
> <RR2> I think it’s useful to have a revision label in a draft because it
> indicates nature of changes (BC v/s NBC) compared to the previous published
> revision (RFC).
>
> But you are absolutely right that setting the version based on changes
> with the previous draft revision is useless and confusing.
>
>

IMO the part that is confusing is that the rules for picking the next
revision-label
are violated for the draft versions (including the special case 0.x.y
versions).
NBC changes appear to be minor changes.  The SEM in SEMVER is not useful
if the identifier does actually reflect the semantics of the label.

Comparing against the last published version also seems to violate the
rules.
Either the same label (e.g. 2.0.0 is used over and over, or new numbers are
used
based on the last draft version (2.0.0, then 2.1.0or maybe 3.0.0 - not
sure).
Using the same label for different versions of a module would be really
confusing.
It is confusing to use incremental numbers to sometimes mean "compare
against last label"
and other times mean "compare against some unspecified label in the past".
There is no way to distinguish a label for a published module and an
unpublished module.

Andy

---

From: Italo Busi <[email-masked]>
Date: Thu, 2 Apr 2020 15:48:35 +0000

If I understand correctly, the Reshad’s solution could lead to an history as:

-          bis-00 being 1.1.0 (BC with the RFC module)

-          bis-01 being 1.1.0 (BC with the RFC module even if NBC with bis-00)

-          bis-02 being 2.0.0 (NBC with RFC module even if BC with bis-01)

-          bis-03 being 1.1.0 (BC with RFC module but not NBC with bis-02 because e.g., the changes in bis-02 that were NBC with RFC module have been removed and/or made BC with RFC module)

The rule looks like that an I-D version represents the version that would be used by that module if the I-D were published as an RFC and all the old I-Ds have never existed.

If this rule works, I do not understand why we need the 0.x.y releases. I think that the I-Ds with the initial draft versions of the module can be 1.0.0.

Am I missing something?

Tools could work if they are able to use the revision date to get the latest version of a given module/version.

Thanks, Italo

Italo Busi

From: Andy Bierman [mailto:[email-masked]]
Sent: giovedì 2 aprile 2020 17:28
To: Reshad Rahman (rrahman) <[email-masked]>
Cc: Italo Busi <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; NetMod WG <[email-masked]>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

On Thu, Apr 2, 2020 at 7:46 AM Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

From: 'Andy Bierman' <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 2, 2020 at 10:26 AM
To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Cc: Italo Busi <[email-masked]<mailto:[email-masked]>>, "Joe Clarke (jclarke)" <[email-masked]<mailto:[email-masked]>>, NetMod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

draft-00

draft-01:

draft-02:

RFC-1:

bis-draft-00:

bis-draft-01:

bis-draft-02:

IMO the part that is confusing is that the rules for picking the next revision-label
are violated for the draft versions (including the special case 0.x.y versions).
NBC changes appear to be minor changes.  The SEM in SEMVER is not useful
if the identifier does actually reflect the semantics of the label.

Comparing against the last published version also seems to violate the rules.
Either the same label (e.g. 2.0.0 is used over and over, or new numbers are used
based on the last draft version (2.0.0, then 2.1.0or maybe 3.0.0 - not sure).
Using the same label for different versions of a module would be really confusing.
It is confusing to use incremental numbers to sometimes mean "compare against last label"
and other times mean "compare against some unspecified label in the past".
There is no way to distinguish a label for a published module and an unpublished module.

Regards,
Reshad.

Andy

Regards,
Reshad.

Thanks, Italo

Andy

Italo Busi

Regards,
Reshad.

Joe

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Apr 2020 09:01:31 -0700

Hi,

I agree that a revision-label could be useful in an I-D but not to indicate
NBC changes (because it doesn't).
The rules need to be clear and simple with no exceptions.

 1) Special version 0.x.y contains NO NBC information
     Major version = 0 means the module has no published version

 2) First published version is 1.0.0

 3) The revision-label in an unpublished module has a special form which
simply identifies
      the source of the development and the iteration of the
work-in-progress.
      You can't really pick the next published label until the module is
ready.

>From my example:

draft-00:   0.1.0

draft-01:   0.2.0

draft-02:   0.3.0

RFC-1:    1.0.0

bis-draft-00:   1.0.0+1

bis-draft-01:   1.0.0+2

bis-draft-02:   1.0.0+3

[repeat NBC step bis-draft-02 10 times]  1.0.0+4 .. 1.0.0+13

RFC-2:  2.0.0   (in general: 1.0.1 or 1.1.0 or 2.0.0)

The BC vs. NBC distinction is not relevant for a work-in-progress.
We have seen many times in this WG where a NBC change was made
and then later undone.  There is no value in tracking the module during
development.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Apr 2020 09:22:41 -0700

On Thu, Apr 2, 2020 at 8:48 AM Italo Busi <[email-masked]> wrote:

> -          bis-03 being 1.1.0 (BC with RFC module but not NBC with bis-02
> because e.g., the changes in bis-02 that were NBC with RFC module have been
> removed and/or made BC with RFC module)
>
>
>

I do not see how it is useful to assign the same revision-label to
different versions,
or to use a real label for a work-in-progress.  The semantics "This might
be v1.1.0 someday"
is not useful, and easily confused with "this is v1.1.0".

Andy

The rule looks like that an I-D version represents the version that would
> be used by that module if the I-D were published as an RFC and all the old
> I-Ds have never existed.
>
>
>
> If this rule works, I do not understand why we need the 0.x.y releases. I
> think that the I-Ds with the initial draft versions of the module can be
> 1.0.0.
>
>
>
> Am I missing something?
>
>
>
> Tools could work if they are able to use the revision date to get the
> latest version of a given module/version.
>
>
>
> Thanks, Italo
>
>
>
>
>
> *Italo Busi*
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* giovedì 2 aprile 2020 17:28
> *To:* Reshad Rahman (rrahman) <[email-masked]>
> *Cc:* Italo Busi <[email-masked]>; Joe Clarke (jclarke) <
> [email-masked]>; NetMod WG <[email-masked]>

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 2 Apr 2020 16:41:56 +0000

On Apr 2, 2020, at 12:01, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I agree that a revision-label could be useful in an I-D but not to indicate NBC changes (because it doesn't).
The rules need to be clear and simple with no exceptions.

 3) The revision-label in an unpublished module has a special form which simply identifies
      the source of the development and the iteration of the work-in-progress.
      You can't really pick the next published label until the module is ready.

draft-00:   0.1.0
draft-01:   0.2.0
draft-02:   0.3.0
RFC-1:    1.0.0
bis-draft-00:   1.0.0+1
bis-draft-01:   1.0.0+2
bis-draft-02:   1.0.0+3

The BC vs. NBC distinction is not relevant for a work-in-progress.
We have seen many times in this WG where a NBC change was made
and then later undone.  There is no value in tracking the module during development.

I support this scheme.  Rob raised it on the call today as well.  Since YANG semver is a superset of semver 2.0.0, these pre-release and build appendixes will work and could be a way to handle bis drafts well.

Joe

---

From: Martin Björklund <[email-masked]>
Date: Thu, 02 Apr 2020 18:51:41 +0200 (CEST)

>       You can't really pick the next published label until the module is

If this was normal semver, it would be:

bis-draft-00:   2.0.0-1
bis-draft-01:   2.0.0-2

etc.  ("+" and "-" have special meaning in semver).

One problem though is that when the -bis work starts, it might not be
clear if the end result (published RFC) will be NBC or BC.  And this
might change back and forth during development of the I-D.

I think it quite clear that such a label should not be used in I-Ds.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Apr 2020 20:15:12 +0200

> I think it quite clear that such a label should not be used in I-Ds.

I agree.

Yesterday, com.example-1.2.3m+1 would have made sense to me. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 2 Apr 2020 18:21:07 +0000

This is being tracked via https://github.com/netmod-wg/yang-ver-dt/issues/56

Regarding this:

It might not be relevant/important during the multiple initial revisions. But when we reach (WG)LC, I think it’s an important piece of information.

Regards,
Reshad.

Date: Thursday, April 2, 2020 at 12:02 PM

Hi,

From my example:

draft-00:   0.1.0
draft-01:   0.2.0
draft-02:   0.3.0
RFC-1:    1.0.0
bis-draft-00:   1.0.0+1
bis-draft-01:   1.0.0+2
bis-draft-02:   1.0.0+3

Andy

Reshad,

draft-00

draft-01:

draft-02:

RFC-1:

bis-draft-00:

bis-draft-01:

bis-draft-02:

Regards,
Reshad.

Regards,
Reshad.

Thanks, Italo

Andy

Italo Busi

Regards,
Reshad.

Joe

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Apr 2020 11:22:24 -0700

> might change back and forth during development of the I-D.
What happens if there are multiple release trains in progress?
Seems more useful to base the label on the known starting point
instead of the possible ending point.

Agreed

Andy

> > > There are many NBC changes made at this point which are treated as
> minor
> > > or patch changes.
> > >

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 3 Apr 2020 11:33:22 +0000

[As a contributor]

Although, I can see how increasing the number from the starting version makes more logical sense, I think that it is better to conform to the semver rules.

Hence, I would suggest that the process to update the version string could look something like this:

Starting with RFC 6991 version 1.0.0.

Bis version with backwards compatible change: “1.1.0-6991bis-01”

If the next bis version has NBC changes, then it would be : “2.0.0-6991bis-02”

Then the WG decide that an NBC change isn’t required, so the next draft version is: : “1.1.0-6991bis-03”

Once it gets to new RFC, then the version becomes “1.1.0”.

I think that this conforms to the Semver 2.0.0 rules, specifically paragraph 9 at https://semver.org/

Regards,
Rob

From: netmod <[email-masked]> On Behalf Of Andy Bierman
Sent: 02 April 2020 19:22
To: Martin Björklund <[email-masked]>
Cc: NetMod WG <[email-masked]>; Italo Busi <[email-masked]>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

On Thu, Apr 2, 2020 at 9:51 AM Martin Björklund <[email-masked]<mailto:[email-masked]>> wrote:

bis-draft-00:   2.0.0-1
bis-draft-01:   2.0.0-2

etc.  ("+" and "-" have special meaning in semver)..

Agreed

/martin

Andy

> > *From: *'Andy Bierman' <[email-masked]<mailto:[email-masked]>>
> > *To: *"Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
> > *Cc: *Italo Busi <[email-masked]<mailto:[email-masked]>>, "Joe Clarke (jclarke)" <
> > [email-masked]<mailto:[email-masked]>>, NetMod WG <[email-masked]<mailto:[email-masked]>>
> > *From: *Italo Busi <[email-masked]<mailto:[email-masked]>>
> > *To: *"Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, 'Andy Bierman' <
> > [email-masked]<mailto:[email-masked]>>, "Joe Clarke (jclarke)" <[email-masked]<mailto:[email-masked]>>
> > *Cc: *NetMod WG <[email-masked]<mailto:[email-masked]>>
> > [repeat NBC step bis-draft-02 10 times.... now up to version 12.0..0 or is
> > *From:* Reshad Rahman (rrahman) [mailto:[email-masked]<mailto:[email-masked]>]
> > *To:* Andy Bierman <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <
> > [email-masked]<mailto:[email-masked]>>
> > *Cc:* NetMod WG <[email-masked]<mailto:[email-masked]>>
> > *From: *netmod <[email-masked]<mailto:[email-masked]>> on behalf of 'Andy Bierman' <
> > [email-masked]<mailto:[email-masked]>>
> > *To: *"Joe Clarke (jclarke)" <[email-masked]<mailto:[email-masked]>>
> > *Cc: *NetMod WG <[email-masked]<mailto:[email-masked]>>
> > should be 1.0.0 (from a semver revision-label standpoint).  >From a design

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 3 Apr 2020 11:38:39 +0000

[As an individual contributor]

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Martin Björklund
> Sent: 02 April 2020 17:52
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
<snipped>
> I think it quite clear that such a label should not be used in I-Ds.
[RW] 

Currently, it takes IETF a long time to publish YANG modules.  If IETF decides to use Semver labels for YANG modules then I think that giving a pre-release version label to work in progress is helpful for folks who choose to implement pre-release versions of those modules while they wait for the formal versions to be standardized.

Regards,
Rob

> > We have seen many times in this WG where a NBC change was made and
> > then later undone.  There is no value in tracking the module during
> > development.
> >
> >
> > Andy
> >
> >
> > > *To: *"Reshad Rahman (rrahman)" <[email-masked]>, 'Andy Bierman'
> > > < [email-masked]>, "Joe Clarke (jclarke)" <[email-masked]>
> > > My doubt and, if I understand well also Andy’s question, is about
> > > the fact that before publishing an RFC-bis with e.g., 1.1.0, we will
> > > have a set of Internet-Drafts updating the RFC with 1.0.0
> > >
> > >
> > >
> > > Think about the following scenario: -00 version provide BC changes
> > > to the RFC module but the -01 version provide NBC changes to what
> > > has been added in the -00 module (thus the -01 version is BC with
> > > the RFC 1.0.0 module but NBC with the -00 version module)
> > >
> > > Bis 01 should be updated according to its relationship to the RFC
> > > module (bis 00 doesn’t matter anymore), when RFC bis is published it
> > > won’t have the full history.
> > >
> > >
> > >
> > >    container my-container;             version 0.2.0;   rules
> violated;
> > > NBC should force 1.0.0
> > >
> > >
> > >
> > > draft-02:
> > >
> > >
> > >
> > > <RR2> I think it’s useful to have a revision label in a draft
> > > because it indicates nature of changes (BC v/s NBC) compared to the
> > > previous published revision (RFC).
> > >
> > > But you are absolutely right that setting the version based on
> > > changes with the previous draft revision is useless and confusing.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Reshad.
> > >
> > >
> > >
> > >
> > >
> > > Regards,
> > >
> > > Reshad.
> > >
> > >
> > >
> > > Thanks, Italo
> > >
> > >
> > >
> > >
> > >
> > > Andy
> > >
> > >
> > >
> > >
> > >
> > > *Italo Busi*
> > >
> > > This e-mail and its attachments contain confidential information
> > > from HUAWEI, which is intended only for the person or entity whose
> > > address is listed above. Any use of the information contained herein
> > > in any way (including, but not limited to, total or partial
> > > disclosure, reproduction, or dissemination) by persons other than
> > > the intended recipient(s) is prohibited. If you receive this e-mail
> > > in error, please notify the sender by phone or email immediately and
> delete it!
> > >
> > >
> > >
> > > *From: *netmod <[email-masked]> on behalf of 'Andy Bierman'
> > > < [email-masked]>
> > > > I just want to confirm that all the proposed documentation
> > > > procedures using new extensions are limited in scope to published
> > > > modules only, and not applied to unpublished modules (terms defined
> in RFC 8407).
> > > >
> > > > IMO it would be harmful to module usability to assign
> > > > revision-labels or include revision-related extensions in
> > > > unpublished modules (e.g.,
> > > Internet Drafts).
> > > > Consider how cluttered and confusing the client-server modules
> > > > would be if the 50+ NBC changes and versions were tracked through
> all the I-Ds.
> > > >
> > > > For IETF modules, the first usage of the revision-label should be
> > > > in the initial RFC, and be set to 1.0.0.
> > > >
> > > > If the RFC is ever republished then one can expect to find an
> > > > updated revision-label and possibly extensions tracking NBC changes.
> > >
> > > The semver scheme allocates a major version of 0 for pre-releases
> > > where the BC/NBC rules do not apply.  I agree that a first official
> > > RFC release should be 1.0.0 (from a semver revision-label
> > > standpoint).  From a design team standpoint, I know we mentioned the
> > > 0 versioning early on, but I don’t think we spent much time talking
> about modules under development overall.
> > >
> > >
> > >
> > >
> > >
> > > minor or patch changes.
> > > <RR> I don’t think that’s needed. Initial module in RFC has 1.0.0,
> > > module in (released) RFC-bis can go to 1.0.1, 1.1.0 or 2.0.0
> > > depending on the change.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Reshad.
> > >
> > >
> > >
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod