[netmod] schema mount and YANG library

Ladislav Lhotka <lhotka@nic.cz> Fri, 08 December 2017 15:32 UTC

Return-Path: <lhotka@nic.cz>
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 9FDC0126E64 for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 07:32:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 NZUtyfad19VO for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 07:32:20 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D996A120721 for <netmod@ietf.org>; Fri, 8 Dec 2017 07:32:19 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 3F2E363E4D for <netmod@ietf.org>; Fri, 8 Dec 2017 16:32:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512747138; bh=t+N+VNTwotIfiJyINTjR/j3+AzjT1npbRE9imHr7CO0=; h=From:To:Date; b=lgjnpk2TNO0zFxEXU8jNEXVeRo9qQaIZijHjuNZQSUmR+N6vsr7QLklykTgywNujW qsehkitWHaboXHApEDaZXeh3ZpGRZ3Nv53QY0WoHIW4mFkjjFOubH17Y/g73mVr6rX QVA2Yl2wnSo5Pq51CxQ1/R44O8zeB5LIVm1XMm4Q=
Message-ID: <1512747137.3467.71.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: NETMOD WG <netmod@ietf.org>
Date: Fri, 08 Dec 2017 16:32:17 +0100
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/X3YvbVvM4EuNNSxMwTZTowvrXzw>
Subject: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 08 Dec 2017 15:32:22 -0000

Hi,

the following text in sec. 3.2 of schema-mount-08 is wrong for traditional
datastores, and even more so for NDMA:

   In case 1 ["inline"], the mounted schema is determined at run time: every
   instance of the mount point that exists in the parent tree MUST
   contain a copy of YANG library data [RFC7895] that defines the
   mounted schema exactly as for a top-level data model.  A client is
   expected to retrieve this data from the instance tree, possibly after
   creating the mount point.  Instances of the same mount point MAY use
   different mounted schemas.

An instance of the mount point in any *configuration* datastores cannot contain
YANG library (being state data), and so the MUST cannot hold.

It is not clear to me how to repair this without considerable complications
and/or a lot of handwaving. There is actually one good solution but it has
impact on YANG library: the server could provide it in a reply to an operation,
say "get-yang-library" rather than as state data. Then everything would be fine
- this operation would turn into an action for the mount point, and it can be
used equally well for config true and false mount points.

So my proposal is to move from YANG library as state data to an operation. It
could be done along with changing the YANG library structure, so there will be
little extra impact on implementations. 

Lada 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67