Re: [netmod] schema-mount pre09 branch

Robert Wilton <> Tue, 06 February 2018 13:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F1BB12D7E4 for <>; Tue, 6 Feb 2018 05:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.52
X-Spam-Status: No, score=-12.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 4ACVdsm3Ds8L for <>; Tue, 6 Feb 2018 05:45:45 -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 A4AAB12AF84 for <>; Tue, 6 Feb 2018 05:45:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7472; q=dns/txt; s=iport; t=1517924744; x=1519134344; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=t3SAlmd14M4w54aseNbj47xsxfy0CW04tYkVRoZ0KFQ=; b=KSFRFyaS2a71OglhimOAt4gg2wqYHcpxcUao7Ewl2+PjRqwExnmPUCyC OhJuvyD7bZhjKfLAkdz0i2f3PkAr3vBtD5lRek4sUPCOxtzjie9fjGmxK wdv1bsigYmzpvvzi4HEkIJCIOWpCDoET4suEh/mVmRrANCFU7Zuj5o5BE 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQAWsXla/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMkgRNwKINlixiPP5Fzh20KGAEFhE5PAoMxFAEBAQEBAQEBAms?= =?us-ascii?q?ohSQBAQQBASFLGwsOCioCAicwBgEMBgIBAReKGhC2WoInJoRag3uBeAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFhGqDbIIRgwWDLwEBAhmBQIMtgmUFpC2IGo1agh6?= =?us-ascii?q?GJoNziASLDIJlgXaIF4E8NiIlgSszGggbFT2CRoN7AQhzQTcBAQGPIwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,468,1511827200"; d="scan'208,217";a="1841783"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 13:45:37 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w16DjaVf003136; Tue, 6 Feb 2018 13:45:37 GMT
To: Kent Watsen <>, "" <>, Martin Bjorklund <>, Ladislav Lhotka <>
References: <>
From: Robert Wilton <>
Message-ID: <>
Date: Tue, 6 Feb 2018 13:45:36 +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: <>
Content-Type: multipart/alternative; boundary="------------7B3DF82DB9F908C0559419C5"
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 13:45:47 -0000


Some comments on the pre-09 version, particularly the data model.

1) I still don't get why this draft is called "YANG Schema Mount" rather 
than "YANG Mount", since to me this implies that it *only* the schema 
that is being made available, and by implication not the instance data.  
I.e. I can see what schema a VM is using, but I cannot access the 
instance data of that VM.

I understand the scope of the draft (and I'm not trying to change that 
at all), and agree that it doesn't specify any protocol for how to 
remotely mount data (e.g. peer mount).  But my understanding of the 
solution here is that it doesn't just mount the schema.  I think that it 
also always makes the mounted instance data available using the regular 
NETCONF/RESTCONF operations right?  Which sounds like it is doing more 
than just mounting the schema!

2) Regarding the YANG Data Model:

(i) Should "schema-mounts" just be "mounts", since it is already under 
the "schema" container.

(ii) Should "parent-references" be part of the "use-schema" container, 
or should then be part of a schema directly.  E.g. should schema-mount 
augment yanglib:schema with both a "mounts" container and a 
"parent-reference" leaflist.

(iii) Do we definitely need the namespace list?  Shouldn't the 
prefixes/namespaces be resolved against the implemented modules in the 
referenced schema, or is this not sufficient?  If this is not 
sufficient, I wonder if it would be helpful for the draft to describe this.

(iv) I agree with Juergen that "inline" is a confusing term because it 
is meaning that the mounted schema is available inline in the instance 
data tree, not that it is inline in the schema tree.


On 31/01/2018 21:36, Kent Watsen wrote:
> All,
> 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?
> The "txt" version of the draft:
> rfcdiff against the current -08 draft:
> Since rfc7895bis obsoletes RFC 7895, the server-must-implement-rfc7895bis requirement is no surprise, right?
> Thanks,
> Kent // shepherd
> _______________________________________________
> netmod mailing list
> .