Re: [netmod] schema-mount pre09 branch

Robert Wilton <> Tue, 06 February 2018 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFF1512D84E for <>; Tue, 6 Feb 2018 07:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wo2ogKBPCk49 for <>; Tue, 6 Feb 2018 07:25:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7973B126FDC for <>; Tue, 6 Feb 2018 07:25:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4392; q=dns/txt; s=iport; t=1517930755; x=1519140355; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TC+OfsXlezBUofNdOHKT1gH4qKiqsRkh2nfalsiNz2Q=; b=EB9PE+UYix57QmdvZ48R2SCrlxUvWSK8q1U4SdhRav1TV8vU6iHR89qu +wylFFpDN01QDhf0e/q4wZbZAyQWmb+FbDLMvWUo0pClpvEIMADPNpS3J 7aUVYwFIC0CLrnCQe8Zp4w/f8nDxZtXQKkdMzMDTYQIHd/VLNodEMGTUc Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDVx3la/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMkggMog2WLGI8YJ5lgCoU7AoM0FAEBAQEBAQEBAmsohSQBBSM?= =?us-ascii?q?VUQsOAggCAiYCAlcGAQwGAgEBijG2LYInhQCDfIF4AQEBAQEBAQECAQEBAQEBA?= =?us-ascii?q?SGBD4Nbg2yCEQyCeYMvBIFZgy2CZQEEpC6VdIIehieDc4gEiwyEXYgXgTw2IoF?= =?us-ascii?q?QMxoIGxWDA4N7AQhzQTePGgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,469,1511827200"; d="scan'208";a="1895834"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 15:25:53 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w16FPrJA002593; Tue, 6 Feb 2018 15:25:53 GMT
To: Martin Bjorklund <>,,
References: <> <20180206083344.o5vqjwwtkq7awrxy@elstar.local> <> <20180206141655.6iast3lbhubk6rk5@elstar.local>
From: Robert Wilton <>
Message-ID: <>
Date: Tue, 6 Feb 2018 15:25:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180206141655.6iast3lbhubk6rk5@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] schema-mount pre09 branch
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Feb 2018 15:25:58 -0000

On 06/02/2018 14:16, Juergen Schoenwaelder wrote:
> On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote:
>> Hi Juergen,
>> Thanks for your review, comments inline.
>> Juergen Schoenwaelder <> wrote:
>>> On Wed, Jan 31, 2018 at 09:36:07PM +0000, Kent Watsen wrote:
>>>> The authors created a "pre09" branch on GitHub a few weeks back.  On this branch, they completed a full update of the draft.  While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts can be discussed.  With this in mind, can folks please have a quick look and post any technical comments they have?
>>> I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched
>>> today from GitHub. Here are my comments:
>>> * Perhaps the abstract can be improved. The single sentence that we
>>>    have is not even quite correct.
>>>     This document defines a mechanism to combine YANG modules into the
>>>     schema defined in other YANG modules.
>>>    According to YL bis, a datastore has a schema, which consists of a
>>>    set of YANG modules. The terminology used in RFC 7950 is 'schema
>>>    node' and 'schema tree'. Perhaps this sentence can be rewritten to
>>>    better explain the purpose of this document.
>> Maybe something along the lines of:
>>    This document defines a mechanism to extend a datastore schema with
>>    other schemas.
>> It is still a bit terse...
> One question here is: Does the datastore schema include the mounted
> schema tree or not? We can side step this question by writing:
>    This document defines a mechanism to extend a YANG schema tree with
>    other schema trees.
> This is still terse but I think in terms of terminology this is
> clear and correct.
>>> * Definition of inline schema:
>>>     o  inline schema: a mounted schema whose definition is provided as
>>>        part of the mounted data, using YANG library
>>>        [I-D.ietf-netconf-rfc7895bis].
>>>     I am not sure 'as part of the mounted data, using YANG library' is
>>>     a good definition. Which YANG library? I think what this term means
>>>     is a mount point specific YANG library, not the master server's
>>>     YANG library.
>>>     This is also why I was largely confused about the inline case; the
>>>     schema used by the mountpoint is not defined inline from the master
>>>     server's point of view, from which the document is written. From
>>>     the master server's point of view, the 'inline schema' is actually
>>>     the opposite, it is an 'external schema' since I have to pull the
>>>     schema information from an external source;
>> No this is not quite correct.  It is "inline" from the master's point
>> of view, in the sense of "inline in the data tree", as opposed to
>> "part of the (augmented) yang-library schema definition".
> This means its inline from the viewpoint of the mounted data, it is
> external from the viewpoint of the master. You are swapping the
> viewpoint here.
>> And it is *not* external.  The client still fetches this data from the
>> "master" server; and how the master server handles this is an
>> implementation detail (or possibly standardized in the future - *one*
>> use case is peer mount in which case the data is fetched from another
>> system, but again, this is just one example).
> It is external from the viewpoint of the master servers YANG library. The
> schema sits in a different YANG library instantiation. I have to fetch
> this separately. This makes it kind of external for me.
I think that the term "external" could also be confusing, since I think 
that sort of implies peer mount like semantics.

I would suggest the term "dynamic" instead of "inline " but that could 
easily be confused with dynamic datastores.

Perhaps rather than "inline" another choice could be "discoverable", 
i.e. the schema is not known, and is dynamically discoverable inline at 
the mount point.
Equally, rather than "use-schema", perhaps a better choice would be 
"known", i.e. the schema is already known, and made available as part of 
YANG library.

Whether it would be right to change these at this time, I've no idea ...