Subject: [Netmod-ver-dt] Update & today's DT meeting

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 2 May 2019 13:39:47 +0000

I think that I'm making reasonable progress on refactoring (the base draft at least).

There is still work to do, but I have included where I am at, so folks can at least read and see if they think that this is heading in the right direction.

I'm still in the progress of moving the semantic versioning number scheme into a separate draft.

The whole draft is a bit rough, but areas that particularly still need work are:

  *   Fixing the import examples
  *   Guidelines.

I will set up the bridge for today for folks who would like to discuss, but I appreciate that nobody will have time to read it.  I can at least give a quick walk through explaining what I have done and why.

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 9 May 2019 13:53:38 +0000

I suggest that we continue the discussions today.

I've not had the opportunity to significantly update the documents over the last week, but I have pushed what I have so far to github.

Here are the brief notes that I took from last week:

2.1.1
- Perhaps describe these as updates to RFC 7950 rules.
2.1.2
- Do the examples provide any help here.  Or should they move to the guidelines, or do we need them at all?  Only clarifications of RFC 7950.

2.2
- Document needs to clearly indicate that it adds a new revision to the revision history.  Check what 7950 says on this.
- Text on how one determines the lineage.

2.3:
- Extension that hadn't been updated might break.
- Do we want a separate import statement, separate revision-label?

Examples:
  - Do we want to show a branch have an nbc change.
  - Add column, or marker, for nbc-changes.

3. Import by revisions:
- Do we allow a revision to import an older file that is not listed in the history?

Thanks,
Rob

From: Netmod-ver-dt <[email-masked]> On Behalf Of Rob Wilton (rwilton)
Sent: 02 May 2019 14:40
To: [email-masked]
Subject: [Netmod-ver-dt] Update & today's DT meeting

Thanks,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 9 May 2019 16:07:34 +0000

Hello,

First of all thanks for your  work on the text. Some comments:

1)

I propose to add after para 2:

The need for NBC changes is present both in standard and vendor modules. 
However the as vendor modules often serve in a more controlled and 
constrained environment the risks of harming client is often lower and 
as a consequence the benefits of accepting NBC changes may be greater.

1.1.1)

I do not understand what this means:
"ensure that does not adversely impact when (parts of) a revised
    standards based YANG module update solution is available."

I would remove the last paragraphs describing what the next chapters 
will contain. I also dislike that the topic is now partly in 1.1.1 but 
also continued in 1.1.2 and 1.1.3 .

2)

I don't remember in 7950 where this is stated. Some people may have 
assumed this, but it is not written and at least we never believed it:
"it is prohibited to have two
    independent revisions of a YANG module that are both derived from the
    same parent revision."

2.1)  All this is already stated in section 2). Remove or merge.

2.1.1)

s/ to 'obsolete' is not  classified as a backwards-compatible/is 
classified as a non-backwards-compatible/

Move the first para into 2.1.2 as it speaks about an NBC change.

2.1.2)

Para 2,3  are somewhat complicated. Why not make it more simple e.g.

Non-backwards-compatible changes are allowed.

If a new module revision contains non-backwards-compatible changes, the 
revision statement MUST include ...

5) Reword to:
------------------------------------------------------------------
Instance data sets [I-D.ietf-netmod-yang-instance-file-format] do not
  use the nbc-changes extension or anything similar, as compatibility 
for instance data
  is undefined.

Instance data specifies the content-schema of the data-set. This schema
should make use of versioning using revision dates and/or revision labels
for the individual YANG modules or potentially for the entire schema itself
(e.g.,   [I-D.rwilton-netmod-yang-packages]).

    In this way, the versioning of the content-schema of the instance
    data set, may help a client to determine whether the instance data
    could also be used in conjunction with other revisions of the YANG
    schema, or other revisions of the modules that define the schema.
---------------------------------------------------------------------

IMHO the last paragraph about up/downgrade is out of scope for instance 
data,
fully implementation specific, it is better to not mention it. (although 
the problem is real and interesting)

6.1)

Add : It benefits clients if they are notified ahead of time about NBC 
changes. Before removing or obsoleting a schema node it SHOULD be in 
deprecated status for a period of time unless the schema node is 
directly replaced with another new alternative schema node.

7)

Why exclude space from label-string?
Should not start with @ as that's the separator to the filename?

nbc-changes
             The statement MUST only be a substatement to the revision 
statement.
             Parent MUST have zero or one nbc-changes statement.
             NO substatements are allowed.

label
same as above

status description
use all 3 point as in the text or none (replacing node, reason for 
status-change, potential date of removal)

regards Balazs