Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-01-12

I'm good with your proposed changes.

Joe

On 2/17/21 11:15, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Thx Joe.  About this paragraph:

                3.3.2.  Removing revisions from the revision history

                   Module authors may wish to truncate revision histories to either
                  remove a revision that should no longer be used or reduce the size of
                  a module.  However, removing any revision from a module's history can
                  cause issues and SHOULD NOT be done.  Doing so can lead to import
                  breakages when import by revision-or-derived is used.  Moreover,
                  truncating history may cause loss of visibility to when non-
                  backwards-compatible changes were introduced.

We may want to explicitly state that it is allowed, even though it is risky.  And we allow revisions to be removed in the middle (not just truncating at the end).  There may also be other reasons authors want to do it so we may not want to preclude those.  How about this:

Module authors may wish to remove revision statements from a module or submodule. Removal of revision information may be desired for a number of reasons including reducing the size of a large revision history, or removing a revision that should no longer be used or imported. Removing revision statements is allowed, but can cause issues and SHOULD NOT be done without careful analysis of the impacts to users of the module or submodule. Doing so can lead to import breakages when import by revision-or-derived is used.  Moreover, truncating history may cause loss of visibility of when non-backwards-compatible changes were introduced.

Jason

From: Joe Clarke (jclarke) <jclarke@cisco.com><mailto:jclarke@cisco.com>
Sent: Saturday, February 13, 2021 5:43 PM
To: Reshad Rahman <reshad=40yahoo.com@dmarc.ietf.org><mailto:reshad=40yahoo.com@dmarc.ietf.org>; Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com><mailto:jason.sterne@nokia.com>; netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-01-12

Well, if we want to re-publish the draft with those additional spaces, Datatracker will insist it has a new revision :-).

Thanks for the feedback.  I'll make the change in git.  Note: I haven't committed/pushed yet.  I especially wanted you, as editor of module-versioning, to weigh in.

Joe
On 2/13/21 12:53, Reshad Rahman wrote:
Hi Joe,

The extra spaces are due to xml2rfc? Should we bump up the version because of extra white-space 😊
Section 3.3.2, good with me. Last sentence may need a small tweak, e.g s/may cause loss of visibility to when/may cause loss of visibility as to when/?

Yang-semver changes also good with me.

Regards,
Reshad.

From: netmod <netmod-bounces@ietf.org><mailto:netmod-bounces@ietf.org> on behalf of "Joe Clarke (jclarke)" <jclarke=40cisco.com@dmarc.ietf.org><mailto:jclarke=40cisco.com@dmarc.ietf.org>
Date: Wednesday, February 10, 2021 at 4:02 PM
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com><mailto:jason.sterne@nokia.com>, "netmod@ietf.org"<mailto:netmod@ietf.org> <netmod@ietf.org><mailto:netmod@ietf.org>
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-01-12

On T4 (gaps in revision numbers and revision history), I have some proposed text for both draft-ietf-netmod-yang-module-versioning and draft-ietf-netmod-yang-semver.  See these diffs (some changes are due to xml2rfc changes, but you'll note the more substantive text additions).  Thoughts:

module-versioning : https://tools.ietf.org/rfcdiff?url1=draft-ietf-netmod-yang-module-versioning&url2=https://namale.marcuscom.com/~jclarke/draft-ietf-netmod-yang-module-versioning.txt

yang-semver : https://tools.ietf.org/rfcdiff?url1=draft-ietf-netmod-yang-semver&url2=https://namale.marcuscom.com/~jclarke/draft-ietf-netmod-yang-semver.txt

Joe
On 1/12/21 13:43, Sterne, Jason (Nokia - CA/Ottawa) wrote:
YANG Versioning Weekly Call Minutes - 2021-01-12

Topics and owners for Feb virtual interim:

Reshad - editor for YANG versioning draft
Jason - coordinate virtual interim, agenda. Do introduction at VI.

T1) Definition/meaning of BC vs NBC for config false nodes
https://github.com/netmod-wg/yang-ver-dt/issues/15
- Balazs

T2) IANA considerations: how are final RFC revision labels assigned ?
https://github.com/netmod-wg/yang-ver-dt/issues/59
- Rob

T3) YANG file naming when revision labels are being used (symbolic links? @<revision-label>) ?
- Reshad to prepare material, TBD to present/lead at VI

T4) SemVer: gaps in history, removing revision statements
https://github.com/netmod-wg/yang-ver-dt/issues/61
- Joe

We spent most of the time discussing Balazs' rules for backwards compatibility of config false nodes (T1 above):
- clients SHOULD be able to deal with (not crash) unexpected output
- some changes to config false nodes should be BC (increasing value space within the same type), some will be NBC (e.g. removing mandatory, changing type)
- the YANG author can mark a change that increases value space as NBC if they feel it is significant & breaks compatibility

We also talked briefly about Rob's proposal for IANA considerations (T2 above).
- we may also want some guidance for RFC editors (coordinate with authors on final SemVer for example)

Next week we'll continue focus on the four Virtual Interim topics.

Other topics we need to get back to at some point:
- whitespace
- github issues (left off at #15)

Jason

_______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod