Re: [netmod] schema mount and YANG library
Robert Wilton <rwilton@cisco.com> Tue, 16 January 2018 12:41 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 E8DED12DB6D for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 04:41:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, 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 XpiHo2n90933 for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 04:41:23 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9B912711B for <netmod@ietf.org>; Tue, 16 Jan 2018 04:41:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14431; q=dns/txt; s=iport; t=1516106482; x=1517316082; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KCbVMsgnQTPnkRQGbs7lGXDmF9L5DLbW2rw6p7Duz2M=; b=DV5Pf2QTwNLC8l2C5680E08kLJv497BA72zfjx0HX2OLc/o9j5TjnA0w Px2SVqwnEJrdHncvDUTDEDXthIs44uwt+IztbHQ8niH3Pph3hEDiBhU8/ WVUYNxD3ZQ/JczgyAE/GaN+Wh0r9AHoLLClRyE2Weyx0Fug0RYe9BhN5l 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B0AQBs8l1a/xbLJq1cGQEBAQEBAQEBAQEBAQcBAQEBAYQndCeEE4sYj26ZQgoYC4RJTwKFHhQBAQEBAQEBAQFrKIUjAQEBAQIBAQEhDwEFNgsQCxIGAgImAgInIg4GAQwGAgEBF4oQCBClb4IniUkBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhxmBaSmDBYMvAQECgU8BAQhCgmuCZQWSJ5E9iziKE4IZhh2DbyaHRY8ciAmBPDYigVAyGggbFT2CKoRXQTeLA4I8AQEB
X-IronPort-AV: E=Sophos;i="5.46,368,1511827200"; d="scan'208";a="1478661"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 12:41:18 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0GCfHPr029061; Tue, 16 Jan 2018 12:41:18 GMT
To: Ladislav Lhotka <lhotka@nic.cz>, Lou Berger <lberger@labn.net>, Martin Bjorklund <mbj@tail-f.com>
Cc: NETMOD WG <netmod@ietf.org>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz> <e8830510-e9ef-2179-8c83-763ce379777d@labn.net> <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <a8777c7c-a5bb-a0ea-ff6a-e57acd5fdc8e@cisco.com>
Date: Tue, 16 Jan 2018 12:41:17 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <1516086847.3188.24.camel@nic.cz>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kxjTGTDVeWJNAC5raUUvzqSYomU>
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 12:41:26 -0000
On 16/01/2018 07:14, Ladislav Lhotka 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. I also support this approach. I think that it easier for everyone if schema are defined in one place. This was also the suggested approach that I presented at IETF 100 for the YANG library bis draft, which seemed to have reasonable support in the room, and I don't recall anyone objecting to this approach. I also provided the same comment in November during the WG LC on schema mount ... Thanks, Rob > > 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 >>>>>>>>> >>
- [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