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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Balazs,

Thanks for the review comments.

I think that I have applied most of these comments.  Updated version of the draft is attached.

> -----Original Message-----
> From: Netmod-ver-dt <[e-mail]> On Behalf Of Balázs
> Lengyel
> Sent: 09 May 2019 17:08
> To: [e-mail]
> Subject: Re: [Netmod-ver-dt] Update & today's DT meeting
> 
> 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.
[RW] 
I've reworked the paragraph to include this.


> 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.
[RW]
As agreed, I've not added this.


> 
> 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 .
[RW]
I've removed this text and simplified the sub-section of the document about updates to existing standards.

> 
> 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."
[RW] 
Changed "this document updates" to "this document updates and clarifies 7950"

> 
> 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/
[RW] 
Yes, fix this.

> 
> Move the first para into 2.1.2 as it speaks about an NBC change
[RW] 
Yes, but also move text updating chap 11 to section 2.1.

.
> 
> 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)
[RW] 
I've taken your text, tweaked it very slightly, and deleted the last paragraph.
> 
> 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.
[RW] 
I will defer this comment for the moment.  I think that we need to look at what is already in the YANG author guidelines and avoid repeating it here.

> 
> 
> 7)
> 
> Why exclude space from label-string?
> Should not start with @ as that's the separator to the filename?
[RW] 
Label must not start (or include?) '@'.

> 
> 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
> 
[RW] 
I've reworked all of the constraints (using MAY rather than MUST).


> 
> status description
> use all 3 point as in the text or none (replacing node, reason for status-
> change, potential date of removal)
[RW] 
I've turned it into an example and included the first two reasons as examples.

Thanks,
Rob

> 
> regards Balazs
>