[netmod] YANG versioning requirements
Robert Wilton <rwilton@cisco.com> Wed, 03 October 2018 09:44 UTC
Return-Path: <rwilton@cisco.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 E772513122C; Wed, 3 Oct 2018 02:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 cp0rRKYNVk6w; Wed, 3 Oct 2018 02:44:47 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E08131211; Wed, 3 Oct 2018 02:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5620; q=dns/txt; s=iport; t=1538559886; x=1539769486; h=to:from:subject:cc:message-id:date:mime-version; bh=3b6id0Y0LqmCQOa1an+vFhRw2PWpXvM9wEOLfETStQY=; b=ZM+f9sZ3daTILwsjJEdYYEaypLqVU6YQa0XbRDfCg3eg4rOiK6ttx/F4 TGattv93mTeVlbCPQBwCQ65Ngp0egE7EWm4CPWHiK7HUwuYFojAEX6192 5/Mfu83Myoqnhj+7FJjyiqnhjtankgKB7vLdmRSpwufL5xUaqheo7H6mC A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AcAACWjrRb/xbLJq0XAUIZAQEBAQEBAQEBAQEBBwEBAQEBAYFUgRSCShKEHIh0jSGRSYc6C4RshD03FQEDAQECAQECbSiFYlZdAl8BDAgBAReDBoICiAGcZYEuH4RYhReLNoFBP4ESJ4pqglcCnUkJkDcGF4kRhlGPKoYjgVgigVUzGggbFYMokFQ+jw0BAQ
X-IronPort-AV: E=Sophos;i="5.54,335,1534809600"; d="scan'208,217";a="6965620"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 09:44:44 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w939iisQ013492; Wed, 3 Oct 2018 09:44:44 GMT
To: Vladimir Vassilev <vladimir@transpacket.com>, "netmod@ietf.org" <netmod@ietf.org>
From: Robert Wilton <rwilton@cisco.com>
Cc: "netmod-ver-dt@ietf.org" <netmod-ver-dt@ietf.org>
Message-ID: <c28c40e0-1ee3-7bb1-4d59-5bee88ac21c3@cisco.com>
Date: Wed, 03 Oct 2018 10:44:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------18CD32F5A77F83DA44B42D38"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YypGOMMcGo4YEb06P5r2pYZwmYk>
Subject: [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 09:44:49 -0000
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
- [netmod] YANG versioning requirements Robert Wilton
- Re: [netmod] YANG versioning requirements Vladimir Vassilev
- Re: [netmod] YANG versioning requirements Robert Wilton