Re: [netmod] YANG versioning requirements

Vladimir Vassilev <vladimir@transpacket.com> Wed, 03 October 2018 14:43 UTC

Return-Path: <vladimir@transpacket.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010AF131280; Wed, 3 Oct 2018 07:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84nPoWZAb4Ai; Wed, 3 Oct 2018 07:43:02 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFA413118E; Wed, 3 Oct 2018 07:43:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 2DA132A41045; Wed, 3 Oct 2018 16:43:00 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HdbTy0Y1nWx7; Wed, 3 Oct 2018 16:43:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id F0DC82A41049; Wed, 3 Oct 2018 16:42:59 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eI1icLiJ5g3h; Wed, 3 Oct 2018 16:42:59 +0200 (CEST)
Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id BD23E2A41045; Wed, 3 Oct 2018 16:42:59 +0200 (CEST)
To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Cc: "netmod-ver-dt@ietf.org" <netmod-ver-dt@ietf.org>
References: <c28c40e0-1ee3-7bb1-4d59-5bee88ac21c3@cisco.com>
From: Vladimir Vassilev <vladimir@transpacket.com>
Message-ID: <b34790c9-a53c-0db1-567b-0aa4dd4ce8d6@transpacket.com>
Date: Wed, 03 Oct 2018 16:42:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <c28c40e0-1ee3-7bb1-4d59-5bee88ac21c3@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/DqSIXPYNPjFMrXlnXMndJHEojFs>
Subject: Re: [netmod] YANG versioning requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2018 14:43:05 -0000

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.


Regards,

Vladimir

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