Re: [netmod] YANG versioning requirements

[Robert Wilton <[e-mail]>]

On 03/10/2018 15:42, Vladimir Vassilev wrote:
> Hi Robert,
>
> On 10/3/18 11:44 AM, Robert Wilton wrote:
>>
>> 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.
>
> I agree with your point in (1). As long as 2.2 is optional there is no 
> problem.
>
>>
>>
>> (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.
>
> 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.
Thanks for confirming.

Rob

>
>
> Regards,
>
> Vladimir

>
>>
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>>
>>
> .
>