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

[Balázs Lengyel <[e-mail]>]

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