Re: [netmod] schema mount and YANG library
Martin Bjorklund <mbj@tail-f.com> Tue, 16 January 2018 13:26 UTC
Return-Path: <mbj@tail-f.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 6F313131509 for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 05:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1pup7e7bsAGy for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 05:26:20 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BA6E713151E for <netmod@ietf.org>; Tue, 16 Jan 2018 05:24:10 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DE971AE0399; Tue, 16 Jan 2018 14:24:08 +0100 (CET)
Date: Tue, 16 Jan 2018 14:24:07 +0100
Message-Id: <20180116.142407.1498790690296330642.mbj@tail-f.com>
To: lberger@labn.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <160feef5550.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <160febbc230.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1516104404.11372.15.camel@nic.cz> <160feef5550.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/f1GQGoRo6scDkdeLo7O9npJfAec>
Subject: Re: [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: Tue, 16 Jan 2018 13:26:27 -0000
Lou Berger <lberger@labn.net> wrote: > Lada, > > > On January 16, 2018 7:07:15 AM Ladislav Lhotka <lhotka@nic.cz> wrote: > > > On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote: > >> Lada, > >> > >> It sounds like you are proposing in (1) a fairly significant change in > >> the > >> direction of the draft and in (2) a basic approach that has been > > > > It is no change in direction, just a simplification of the > > schema-describing > > state data. Given the recent developments in 7895bis it makes no sense > > to me to > > have two "schema" lists if we can have just one. > > > > Managing transition is hard. It's also highlights why Yang Library > this needs to be at least equally discussed in this group. > > I will talk with my co-chairs and perhaps the ADs to get their opinion > on making such a change this point in the process. > > > >> > >> rejectected by the WG multiple times. FWIW there are drafts already > >> with > > > > No at all. The first and last time I proposed this was on 15 December > > 2017: > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html > > > > Oh, I certainly would call you proposing that the schema for inline be > part of the rest of the schema Mount module well before that. I'm sure > I can dig up mail / slides it really necessary... I don't think this has been proposed before. All previous proposals were basically variants on what is now "use-schema", which works fine when all instances have the same schema. This new proposal solves the issue with different schemas in different instances. > > The only reply was from you. To me, it is the cleanest solution of the > > inline > > case. Of course, I am open to technical objections. > > > > I'm sure I can find material on this as well.... Ok. /martin > > Lou > > > If it's not clear what I mean, I can make up some examples. > > > > Lada > > > > > >> the iesg that will need to be returned to their WGs if either change > >> is made. > >> > >> Martin, > >> > >> Do share Lada's view? > >> > >> Lou > >> > >> > >> On January 16, 2018 2:14:42 AM Ladislav Lhotka <lhotka@nic.cz> wrote: > >> > >> > Hi Lou, > >> > > >> > in my view, we should do the following two (significant) changes: > >> > > >> > 1. Instead of borrowing a grouping from ietf-yang-library and having a > >> > parallel > >> > list of mounted schemas, we should keep *all* mounted schemas directly > >> > in > >> > the > >> > YANG library and refer to them from schema-mounts structures. Juergen > >> > suggested > >> > this change and it is IMO the right thing to do. > >> > > >> > 2. Define a metadata annotation (e.g. @schema-ref) that would be > >> > required > >> > for > >> > inline mount point instances and specify the inline-mounted schema > >> > also by > >> > referring to a schema specified in YANG library. > >> > > >> > The advantage of #2 is that an annotation can be attached equally well > >> > to > >> > both > >> > state an configuration data. So, instead of papering over the issue > >> > that > >> > YANG > >> > library (state data) cannot appear in configuration datastores, we can > >> > use > >> > this > >> > general and straightforward approach. This also allows for defining > >> > different > >> > mounted schemas for instances of the same mount point in different > >> > datastores. > >> > > >> > I strongly believe that these changes (along with the new YANG library > >> > schema > >> > and NMDA) make for a simple and elegant datastore architecture in > >> > which > >> > schema > >> > mount would be an optional feature. > >> > > >> > Lada > >> > > >> > > >> > > >> > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote: > >> > > Lada/Martin, > >> > > > >> > > I don't believe we reached closure on this discussion. The open > >> > > issues > >> > > relate to proposed new text (slightly modified): > >> > > > >> > > at the end of the section [3.2] adding a new paragraph along the > >> > > lines of: > >> > > > >> > > The use of mount points does not impact the nature of the > >> > > mounted data or in which data store information is made > >> > > available. For example, mounted YANG Library modules define > >> > > only operational state data and, as such, the information in > >> > > these modules is available from operational data stores using > >> > > the appropriate protocol operations. It is also worth > >> > > noting that the Schema Mount module itself parallels the > >> > > YANG Library module and only defines operational state data. > >> > > > >> > > Is this change acceptable? > >> > > > >> > > What other issues related to SM are outstanding? > >> > > > >> > > Thank you, > >> > > > >> > > Lou > >> > > > >> > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote: > >> > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote: > >> > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote: > >> > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote: > >> > > > > > > Hi Lada, > >> > > > > > > > >> > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote: > >> > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote: > >> > > > > > > > > Lada, > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka > >> > > > > > > > > <lhotka@nic.cz > >> > > > > > > > > > > >> > > > > > > > > wrote: > >> > > > > > > > > > >> > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote: > >> > > > > > > > > > > lada, > >> > > > > > > > > > > > >> > > > > > > > > > > See below. > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote: > >> > > > > > > > > > > > Hi, > >> > > > > > > > > > > > > >> > > > > > > > > > > > unfortunately, using an action for querying embedded > >> > > > > > > > > > > > YANG > >> > > > > > > > > > > > library > >> > > > > > > > > > > > data > >> > > > > > > > > > > > (needed for the "inline" case of schema mount) > >> > > > > > > > > > > > doesn't > >> > > > > > > > > > > > work > >> > > > > > > > > > > > either > >> > > > > > > > > > > > because now under NMDA actions can be used only on > >> > > > > > > > > > > > instances > >> > > > > > > > > > > > in > >> > > > > > > > > > > > the > >> > > > > > > > > > > > <operational> datastore. > >> > > > > > > > > > > > >> > > > > > > > > > > but the inline/embedded library would (only) be present > >> > > > > > > > > > > in > >> > > > > > > > > > > the > >> > > > > > > > > > > in > >> > > > > > > > > > > the > >> > > > > > > > > > > operational datastore, so what's the issue? > >> > > > > > > > > > > >> > > > > > > > > > Well, the issue is described in my initial mail of this > >> > > > > > > > > > thread: > >> > > > > > > > > > the > >> > > > > > > > > > current > >> > > > > > > > > > text > >> > > > > > > > > > requires that every instance of an inline mount point > >> > > > > > > > > > contains > >> > > > > > > > > > the > >> > > > > > > > > > embedded > >> > > > > > > > > > YANG library. Tha latter is state data, so the above > >> > > > > > > > > > requirement > >> > > > > > > > > > cannot > >> > > > > > > > > > be > >> > > > > > > > > > satisfied if the mount point instance is in a > >> > > > > > > > > > configuration > >> > > > > > > > > > datastore. > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > That's not how I read the intent of the current text. I > >> > > > > > > > > don't > >> > > > > > > > > see > >> > > > > > > > > SM > >> > > > > > > > > impacting which data stores information is presented. Just > >> > > > > > > > > like > >> > > > > > > > > use > >> > > > > > > > > of > >> > > > > > > > > scheme mount doesn't transform RO configuration information > >> > > > > > > > > into > >> > > > > > > > > operational information. I sent you a couple of sentences > >> > > > > > > > > clarifying > >> > > > > > > > > this > >> > > > > > > > > at one point, I'll dig up the proposed text and resend. > >> > > > > > > > > >> > > > > > > > Please do, this has to be discussed in the WG mailing list. > >> > > > > > > > >> > > > > > > Agreed - that's why I asked to start this thread! > >> > > > > > > > >> > > > > > > Here's the original proposal: > >> > > > > > > > >> > > > > > > How about at the end of the section [3.2] adding a new > >> > > > > > > paragraph along the lines of: > >> > > > > > > > >> > > > > > > It is important to note that both YANG Library and Schema > >> > > > > > > Mount Modules contain only operational state data. As such, > >> > > > > > > >> > > > > > s/contain/define/ > >> > > > > > > >> > > > > > > the information in these modules should be retrieved by > >> > > > > > > clients from operational data stores using the appropriate > >> > > > > > > >> > > > > > This is based on two assumptions: > >> > > > > > > >> > > > > > 1. For every configuration datastore there is a corresponding > >> > > > > > operational > >> > > > > > datastore. > >> > > > > > >> > > > > well the text is revised below. In any case, "these modules" > >> > > > > refers > >> > > > > to > >> > > > > yang library, and yes, I'm assuming YL is always and only in > >> > > > > operational. If the revised text below isn't clear s/these/YANG > >> > > > > Library/ > >> > > > > - > >> > > > > >> > > > The thing is that we have the top-level YANG library in > >> > > > <operational>, > >> > > > and > >> > > > then > >> > > > embedded YANG libraries scattered inside inline mount point > >> > > > instances. > >> > > > > >> > > > > > 2. For every mount point instance in any configuration datastore > >> > > > > > there > >> > > > > > is a > >> > > > > > corresponding mount point instance (with the same path) in an > >> > > > > > operational > >> > > > > > datastore. > >> > > > > > > >> > > > > > I think that neither of these has to be true in general. > >> > > > > > >> > > > > agreed in general, but for inline, where YL is required, it must be > >> > > > > true. > >> > > > > >> > > > How do you know? I provided an example in Singapore where a mount > >> > > > point > >> > > > instance > >> > > > in <intended> is a part of pre-provisioned data (for non-existent > >> > > > hardware). > >> > > > Then, according to the NMDA rules there is no corresponding instance > >> > > > in > >> > > > <operational>, hence no place where the embedded YANG library can be > >> > > > placed. > >> > > > (I can easily provide a concrete example if needed). > >> > > > > >> > > > > >> > > > Dean replied that this cannot happen, so it seems there are some > >> > > > assumptions > >> > > > how > >> > > > the inline method of schema mount may be applied. If so, these > >> > > > assumptions > >> > > > have > >> > > > to be explicitly stated. > >> > > > > >> > > > > > > protocol operations. > >> > > > > > > >> > > > > > In contrast, the substance of my proposal with metadata > >> > > > > > annotations > >> > > > > > is > >> > > > > > to be > >> > > > > > able to retrieve all schemas from a well-known location in *the* > >> > > > > > <operational> > >> > > > > > datastore, namely from the top-level YANG library. > >> > > > > > >> > > > > What about a schema that is based on dll that contains modules that > >> > > > > isn't loaded until a mount point is instantiated -- this is > >> > > > > certainly > >> > > > > a > >> > > > > valid approach for supporting LNEs, but would be precluded in this > >> > > > > approach. I really don't think a top level approach works for all > >> > > > > inline (managed) types of mounts. > >> > > > > >> > > > It isn't precluded: when the mount point is instantiated (no matter > >> > > > which > >> > > > datastore it is in), the server adds the schema as a new entry to the > >> > > > "schema" > >> > > > list in the top level YANG library (with a unique key), and annotates > >> > > > the > >> > > > mount > >> > > > point instance with a leafref pointing to that key. So different > >> > > > instances > >> > > > of > >> > > > the same mount point can have different schemas. > >> > > > > >> > > > > > > Given this discussion, we can generalize it further to: > >> > > > > > > > >> > > > > > > The use of mount points does not impact the nature of the > >> > > > > > > mounted data or in which data store information is made > >> > > > > > > available. For example, mounted YANG Library modules contain > >> > > > > > > only operational state data and, as such, the information in > >> > > > > > > these modules is available from operational data stores > >> > > > > > > using > >> > > > > > > the appropriate protocol operations. > >> > > > > > > >> > > > > > The whole question here is whether and how we can locate the > >> > > > > > schema > >> > > > > > for > >> > > > > > an > >> > > > > > inline mount point in any configuration datastore. > >> > > > > > >> > > > > Why is a mounted YL different than a top level YL? What works for > >> > > > > and > >> > > > > >> > > > It is not different, but it can be only in an operational datastores, > >> > > > and so > >> > > > for > >> > > > mount point instances inside configuration datastores we need a way > >> > > > how > >> > > > to > >> > > > locate the schema for that mount point, because it cannot be found > >> > > > directly > >> > > > under the mount point instance (as the current text assumes). > >> > > > > >> > > > > is sufficient for the normal case of YL shouldn't be impacted or > >> > > > > modified by SM -- at least that's how I thought we've been talking > >> > > > > about > >> > > > > since SM was started. Again, we never made any special provisions > >> > > > > for > >> > > > > any other rw/ro/state data, assuming top level YL is not handled as > >> > > > > metadata, why start now? > >> > > > > > >> > > > > I'm getting the impression that your argument may be more about if > >> > > > > YL > >> > > > > should be treated as something other than operational data, is this > >> > > > > wrong? > >> > > > > >> > > > This is wrong. My argument is that there should be only one top-level > >> > > > YANG > >> > > > library (state data) and each inline mount point instance just points > >> > > > to > >> > > > a > >> > > > schema inside it by means of a metadata annotation attached to the > >> > > > mount > >> > > > point > >> > > > (in any datastore). > >> > > > > >> > > > Lada > >> > > > > >> > > > > Thanks, > >> > > > > Lou > >> > > > > > >> > > > > > Lada > >> > > > > > > >> > > > > > > Lou > >> > > > > > > > >> > > > > > > > Lada > >> > > > > > > > > >> > > > > > > > > Lou > >> > > > > > > > > > > > However, a good alternative seems to be a metadata > >> > > > > > > > > > > > annotation > >> > > > > > > > > > > > along > >> > > > > > > > > > > > the > >> > > > > > > > > > > > lines of RFC 7952, for example with the alternative B > >> > > > > > > > > > > > of > >> > > > > > > > > > > > the > >> > > > > > > > > > > > newly > >> > > > > > > > > > > > proposed YANG library schema: > >> > > > > > > > > > > > > >> > > > > > > > > > > > md:annotation schema-ref { > >> > > > > > > > > > > > type leafref { > >> > > > > > > > > > > > path "/yanglib:yang- > >> > > > > > > > > > > > library/yanglib:schema/yanglib:name"; > >> > > > > > > > > > > > } > >> > > > > > > > > > > > } > >> > > > > > > > > > > > > >> > > > > > > > > > > > In other words, all inline mounted schemas would be > >> > > > > > > > > > > > included > >> > > > > > > > > > > > in > >> > > > > > > > > > > > the > >> > > > > > > > > > > > top-level YANG library, and mount point instances in > >> > > > > > > > > > > > all > >> > > > > > > > > > > > datastores > >> > > > > > > > > > > > would be annotated with leafref pointing to the > >> > > > > > > > > > > > actual > >> > > > > > > > > > > > schema. > >> > > > > > > > > > > > > >> > > > > > > > > > > > Unlike regular state data, it is IMO no problem to > >> > > > > > > > > > > > permit > >> > > > > > > > > > > > such > >> > > > > > > > > > > > annotations in configuration datastores. > >> > > > > > > > > > > > > >> > > > > > > > > > > > Opinions? > >> > > > > > > > > > > > >> > > > > > > > > > > I'm not sure this will work for all architectures of > >> > > > > > > > > > > LNEs > >> > > > > > > > > > > as > >> > > > > > > > > > > well > >> > > > > > > > > > > as > >> > > > > > > > > > > other possible future use cases. In short, this seems > >> > > > > > > > > > > *very* > >> > > > > > > > > > > restrictive. > >> > > > > > > > > > > >> > > > > > > > > > I don't understand, IMO it is not restrictive at > >> > > > > > > > > > all. What > >> > > > > > > > > > kind > >> > > > > > > > > > of > >> > > > > > > > > > restrictions > >> > > > > > > > > > do you see? > >> > > > > > > > > > > >> > > > > > > > > > Lada > >> > > > > > > > > > > >> > > > > > > > > > > Lou > >> > > > > > > > > > > > >> > > > > > > > > > > > Thanks, Lada > >> > > > > > > > > > > > > >> > > > > > > > > > > > Ladislav Lhotka <lhotka@nic.cz> writes: > >> > > > > > > > > > > > > >> > > > > > > > > > > > > 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 > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > _______________________________________________ > >> > > > > > > > > > > > > netmod mailing list > >> > > > > > > > > > > > > netmod@ietf.org > >> > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > >> > > > > > > > > > > > >> > > > > > > > > > > _______________________________________________ > >> > > > > > > > > > > netmod mailing list > >> > > > > > > > > > > netmod@ietf.org > >> > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > >> > > > > > > > > > > >> > > > > > > > > > -- > >> > > > > > > > > > Ladislav Lhotka > >> > > > > > > > > > Head, CZ.NIC Labs > >> > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > >> > > > > > > > > > > >> > > > >> > > > >> > > >> > -- > >> > Ladislav Lhotka > >> > Head, CZ.NIC Labs > >> > PGP Key ID: 0xB8F92B08A9F76C67 > >> > > >> > >> > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > >
- [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Juergen Schoenwaelder
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Robert Wilton
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Robert Wilton
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Robert Wilton
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Juergen Schoenwaelder
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Juergen Schoenwaelder
- Re: [netmod] schema mount and YANG library joel jaeggli
- Re: [netmod] schema mount and YANG library Juergen Schoenwaelder
- Re: [netmod] schema mount and YANG library Kent Watsen
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library joel jaeggli
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Martin Bjorklund
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Robert Wilton
- Re: [netmod] schema mount and YANG library Lou Berger
- Re: [netmod] schema mount and YANG library Dean Bogdanovic
- Re: [netmod] schema mount and YANG library Kent Watsen
- Re: [netmod] schema mount and YANG library Kent Watsen
- Re: [netmod] schema mount and YANG library Juergen Schoenwaelder
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Ladislav Lhotka
- Re: [netmod] schema mount and YANG library Acee Lindem (acee)
- Re: [netmod] schema mount and YANG library Jeff Tantsura
- Re: [netmod] schema mount and YANG library Juergen Schoenwaelder
- Re: [netmod] schema mount and YANG library Acee Lindem (acee)
- Re: [netmod] schema mount and YANG library Juergen Schoenwaelder
- Re: [netmod] schema mount and YANG library Andy Bierman
- Re: [netmod] schema mount and YANG library Martin Bjorklund