Subject: Re: [Netmod-ver-dt] Comments on clacla draft

From: Benoit Claise <[email-masked]>
Date: Thu, 6 Dec 2018 16:55:04 +0100

Rob, all
>
> Hi,
>
> I've read the clacla draft, and these are some comments for 
> discussion, on the presumption that the DT is going to use this draft 
> as a basis for some of the solution.
>
>
> 1) As Juergen suggests after the introduction I think that we should 
> explicitly list the sections that may end up modify YANG's behaviour, 
> e.g. by updating RFC 7950.
>
> 1 ii) I think that the draft should explicitly state which 
> requirements it addresses, and which is does not address.  I'm 
> presuming that this draft, at least at this stage, should try and 
> address everything except 2.2, 3.1? and 3.2.
>
>
> 2) Section 2.1: Semantic Versioning
> - Use modified semver (probably we need a better name for this), 
> perhaps "YANG semver".
> - Document the rules for modified semver.
>
> 2 ii) I think that we should think about removing sections 2.1.2 and 
> 2.1.3 on "Derived Semantic Version".  I think that this text should 
> eventually end up as part of a tooling based schema comparison draft.
>
What is this draft?
What about putting 2.1.2 and 2.1.3 in the appendix
It's important to explain that the Derived Semantic Version/tooling 
might help but it's not THE solution.
>
> Perhaps we could create a separate clone of the draft on github to 
> hold the text that we are saving for later.
>
> 2 iii) I think that we should provide a section on guidelines on how 
> Semver should be used (perhaps updating RFC 8407 and 7950 section 11).
>
Yes. Guidelines for Authors and Reviewers
>
> This would (at least partially) address requirement 5.1, "The solution 
> MUST provide guidance to model authors and clients on how to use the 
> new YANG versioning scheme."
>
Regards, Benoit

---

From: Robert Wilton <[email-masked]>
Date: Thu, 6 Dec 2018 16:03:50 +0000

Hi Benoit,

>> eventually end up as part of a tooling based schema comparison draft.

Currently this is a hypothetical draft because no one has started 
writing it yet.  I know that both Juergen and I are interested in this, 
but we are both busy and I think that this is probably lower priority 
relative to the other YANG versioning related work. Juergen pointed out, 
which I agree with, is that the draft probably needs to be done hand in 
hand with developing the associated tooling to work out the issues.

> might help but it's not THE solution.

Yes, that is what I have currently done in the edits that I'm working on 
- so that we don't lose this text.

Thanks,
Rob

>> This would (at least partially) address requirement 5.1, "The 
>> solution MUST provide guidance to model authors and clients on how to 
>> use the new YANG versioning scheme."
>>
> Regards, Benoit
> .
>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 6 Dec 2018 17:37:26 +0100

> writing it yet.  I know that both Juergen and I are interested in 
> this, but we are both busy and I think that this is probably lower 
> priority relative to the other YANG versioning related work. Juergen 
> pointed out, which I agree with, is that the draft probably needs to 
> be done hand in hand with developing the associated tooling to work 
> out the issues.
As a side note, we recently paid a contractor to make sure that pyang is 
fully compliant with all RFC7950 Section 11 rules
   --check-update-from=OLDMODULE
                         Verify that upgrade from OLDMODULE follows RFC 6020
                         and 7950 rules.

Basically, extracting as much as we can from the syntax differences in 
order to help tagging the semantic difference.

Regards, Benoit.