Subject: [netmod] YANG versioning requirements

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 10:44:44 +0100

Hi Vladimir,

At IETF 102, when I was presenting on the YANG versioning requirements 
(draft-verdt-netmod-yang-versioning-reqs-00), I think you raised a 
concern about requirement 2.2:

        2.2  A mechanism SHOULD be defined to determine whether data
             nodes between two arbitrary YANG module revisions have (i)
             not changed, (ii) changed in a backward compatible way,
             (iii) changed in a non-backward compatible way.

IIRC, I think that your specific concern is that this leads to a complex 
solution, which I understand, but I still think that this requirement 
should remain for several reasons:

(1) It is only marked as a SHOULD rather than a MUST.  I.e. it is 
desirable that a solution is able to achieve this but is not strictly 
required.

(2) Some tooling for this already exists.  RFC 7950 section 11 already 
defines what constitutes a backwards compatible change, and pyang is 
already capable of comparing two module revisions to partially determine 
what non backwards compatible changes exist between two module revisions

(3) Having considered all the various potential solutions to the 
versioning problem, my opinion is that there is only one solution that 
is generically capable of accurately telling a client of what the impact 
is when updating between two releases.  That solution is to compare the 
complete schema for both releases (considering module versions, 
deviations, and features), potentially filtering the comparison output 
by the subset of the schema actually used by the client.

So, whilst I still think a simpler solution may be helpful to 
communicate what sort of changes are contained in a module, I still 
think that the full complex solution will eventually be required to 
truly solve this problem in a robust way.

Hence, are you OK with this requirement text remaining as is, or do you 
still want to see it changed?

Thanks,
Rob

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 3 Oct 2018 16:42:59 +0200

Hi Robert,

On 10/3/18 11:44 AM, Robert Wilton wrote:
> 2.2 A mechanism SHOULD be defined to determine whether data nodes 
> between two arbitrary YANG module revisions have (i) not changed, (ii) 
> changed in a backward compatible way, (iii) changed in a non-backward 
> compatible way.
>
> IIRC, I think that your specific concern is that this leads to a 
> complex solution, which I understand, but I still think that this 
> requirement should remain for several reasons:
>

I agree with your point in (1). As long as 2.2 is optional there is no 
problem.

> already capable of comparing two module revisions to partially 
> determine what non backwards compatible changes exist between two 
> module revisions
>
>
> is generically capable of accurately telling a client of what the 
> impact is when updating between two releases.  That solution is to 
> compare the complete schema for both releases (considering module 
> versions, deviations, and features), potentially filtering the 
> comparison output by the subset of the schema actually used by the client.
>

My point was that the need of complete schema comparison as described in 
(3) is needed for 2.2 but not for 2.1 and thus it will probably make 
sense to decouple the solutions. I am looking forward to see what your 
solution ideas are.

>
>  Hence, are you OK with this requirement text remaining as is, or do 
> you still want to see it changed?
Yes I am OK with the text.

Regards,

Vladimir

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 15:47:55 +0100

On 03/10/2018 15:42, Vladimir Vassilev wrote:
>> At IETF 102, when I was presenting on the YANG versioning 
>> requirements (draft-verdt-netmod-yang-versioning-reqs-00), I think 
>> you raised a concern about requirement 2.2:
>>
>> between two arbitrary YANG module revisions have (i) not changed, 
>> (ii) changed in a backward compatible way, (iii) changed in a 
>> non-backward compatible way.
>>
>> (2) Some tooling for this already exists.  RFC 7950 section 11 
>> already defines what constitutes a backwards compatible change, and 
>> pyang is already capable of comparing two module revisions to 
>> partially determine what non backwards compatible changes exist 
>> between two module revisions
>>
>>
>> versioning problem, my opinion is that there is only one solution 
>> that is generically capable of accurately telling a client of what 
>> the impact is when updating between two releases.  That solution is 
>> to compare the complete schema for both releases (considering module 
> My point was that the need of complete schema comparison as described 
> in (3) is needed for 2.2 but not for 2.1 and thus it will probably 
> make sense to decouple the solutions. I am looking forward to see what 
> your solution ideas are.
>
>>
Thanks for confirming.

Rob

> .