Re: [netmod] Y34 - root node
Ladislav Lhotka <lhotka@nic.cz> Mon, 10 August 2015 07:21 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA8A1ACC88 for <netmod@ietfa.amsl.com>; Mon, 10 Aug 2015 00:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.199
X-Spam-Level: *
X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6] autolearn=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 CX-Ufqmn-XoT for <netmod@ietfa.amsl.com>; Mon, 10 Aug 2015 00:21:03 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7E42C1AC43C for <netmod@ietf.org>; Mon, 10 Aug 2015 00:21:02 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0DDBC1CC0329; Mon, 10 Aug 2015 09:21:05 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, "t.petch" <ietfc@btconnect.com>
In-Reply-To: <CABCOCHS0vJF61B-TLqUH=QEzBN0LN6n+_fBsh054Tg13XCr0Ng@mail.gmail.com>
References: <CABCOCHRS-JF8UK+9fQ=yvZy9ttcj3j6oJn0n3Co6f7kB0tpFgA@mail.gmail.com> <F990644A-4CBE-43D5-AB2B-A20E54A91A65@nic.cz> <20150720210041.GA17614@elstar.local> <D1D917F8.29821%acee@cisco.com> <CABCOCHSm=VCMqoMJRAstV-FwZqkitKVoAjkVMGHxKcKB_RdpGQ@mail.gmail.com> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <CABCOCHQ-XOJMXfZfijd1OJcgvx4wkRuY0P7UhF5zej_Q36GHYg@mail.gmail.com> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <CABCOCHQAc310ZwScEN=BFEzHUj3uY3HBQjo131J6yigGEW9Yrw@mail.gmail.com> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> <D1E270C7.29F82%acee@cisco.com> <CABCOCHSPmCdd2eeb6S9sPzjD+G7vrCs+HNac5KDj3QHUuGMofQ@mail.gmail.com> <002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> <CABCOCHQOosSE3B973WG1uqBjF2aoexViR3OfD9Rfo6qoHg0W6Q@mail.gmail.com> <03d301d0ce05$c320a800$4001a8c0@gateway.2wire.net> <CABCOCHRUk9hkpVh6tT6sV-YzLYjDmFeu9FOtY9sH6PAcjFyVTw@mail.gmail.com> <01e601d0ce98$df05e240$4001a8c0@gateway.2wire.net> <CABCOCHS0vJF6 1B-TLqUH=QEzBN0LN6n+_fBsh054Tg13XCr0Ng@mail.gmail.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 10 Aug 2015 09:21:10 +0200
Message-ID: <m2zj1zzk0p.fsf@birdie.labs.nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/rf62loOa8N_oGJq6IJf58fDLo70>
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] Y34 - root node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 10 Aug 2015 07:21:06 -0000
Andy Bierman <andy@yumaworks.com> writes: > On Tue, Aug 4, 2015 at 2:34 AM, t.petch <ietfc@btconnect.com> wrote: > >> ----- Original Message ----- >> From: "Andy Bierman" <andy@yumaworks.com> >> To: "t.petch" <ietfc@btconnect.com> >> Sent: Monday, August 03, 2015 5:17 PM >> >> > ----- Original Message ----- >> > From: "Andy Bierman" <andy@yumaworks.com> >> > To: "t.petch" <ietfc@btconnect.com> >> > Sent: Monday, August 03, 2015 4:10 PM >> > >> > > ----- Original Message ----- >> > > From: "Andy Bierman" andy@yumaworks.com >> > > Sent: Saturday, August 01, 2015 7:05 PM >> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com> >> > > >> >>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: >> >>> >> >>> Section 1.1 in >> >>> >> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> >>> lists the goals of a generic model structure that will accommodate >> >> most >> >>> modern network devices. I guess you don’t agree that these are >> >> desirable? >> > > >> > > The only objection I have to this draft is the insertion of a >> top-level >> > > root >> > > called "device". (Might as well be called "self"). >> > > There are no sibling nodes planned or intended for >> > > this node, so it serves as an extra document root. >> > > >> > > <tp> >> > > One aspect of YANG I have never grasped is what a root means, if >> > > anything. >> > > >> > > I understand that it is needed for NETCONF (filters) and for YANG >> > > (augments, constraints) and so must be somewhere and must be >> > relatively >> > > stable, but has it any other significance in the data model? >> > > >> > > As you may recall, I was involved with SMI first, where the root is >> > > somewhere up in the sky and life only becomes interesting some six >> > > levels down the hierarchy and that may colour my thinking. >> > > >> > >> > YANG does a poor job of defining the root for YANG data nodes. >> > It is sometimes called a datastore (in the abstract). >> > Technically, YANG borrows the definition from XPath. >> > YANG just defines top-level data nodes and the parent of >> > these nodes is the document root. >> > >> > There is no protocol or encoding neutral definition, >> > only an XML-specific definition. >> > >> > <tp> >> > >> > Thanks for that. >> > >> > It seems to me that much of the extensive discussion on Y34 (all of >> > which I have read) is as much political as technical, that is SMI is >> > hierarchical, top down, perhaps befitting its origins in ISO, whereas >> > YANG is bottom up. IETF-like. YANG could have had a single tree, but >> > doesn't. So when I read >> > >> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> > >> > I see a plea for a more hierarchical organisation, and when I read >> > >> > draft-bjorklund-netmod-openconfig-reply-00 >> > >> > I see a response that says we are not like that. >> > >> > If so, I doubt that there ever will be a technical solution. >> > >> > And I am mindful that when I configure routing in a (Cisco) router, I >> > have to do some of it under the interface definitions and some of it >> > under the definition of the routing protocol. Which is life, never >> > wholy interface-centric and never wholy routing protocol-centric! >> >> Are you saying the job would be easier if the >> path was /device/interfaces/interface instead >> of just /interfaces/interface? Are you saying >> that /protocols/routing could not also be defined? >> Clearly edit-config and copy-config allow both >> subtrees to be accessed in the same operation, >> so I don't understand your concern. >> >> I have been trying to get the root node to be better defined >> in the protocols that use YANG (i.e., ncx:root, Y34-04). >> IMO this is a better approach than defining a YANG module >> with a special container that all other modules are expected >> to augment. YANG is designed such that each vendor or SDO >> is not dependent on other vendors or SDOs in order to >> define data nodes. >> >> <tp> >> >> Andy >> >> I am agreeing with you that adding 'device' brings no technical benefit, >> rather that the motivation is the opposite of technical (which I >> referred to as political). I am also agreeing with the current declared >> consensus on Y34. >> >> And yes, YANG is going to give us a large number of modules, some >> tightly coupled (augments) some loosely so (how many do you need to >> configure OSPF?) and work in this area will be of benefit now and >> probably essential in a few years time. That said, I am unsure what >> such work would be like; I am looking (in despair) at 50 routing area >> YANG models and wondering how a user will ever get a coherent picture of >> how to do what they want to do. >> >> > > The "YANG Land Grab" gives a false sense of progress. > Reaching WG consensus on every single leaf is hard work. > > I don't think a collection of 100s of YANG modules is ever > going to to be easy to understand. Operators will not examine > a NETCONF <hello> message, look at 150 module URIs, > and say "I know exactly what this device supports". > I guess it is up to client tools to do that. > > I wrote a draft that defines YANG Packages, which can provide > a higher level of organization for YANG modules. > > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ > > You and I are apparently in the minority, since the official status > is that there is no problem with the current approach, and no need > to organize individual YANG modules into any larger abstractions. > I believe most people agree something like this is needed, and the attempt to clarify import semantics in YANG 1.1 isn't meant as a replacement for packages. Lada > > > Tom Petch >> >> > > Andy > > >> Andy >> >> > Andy >> > >> > > The well-specified XPath and YANG root (/) can be >> > > accessed by all protocol operations, exactly the same >> > > as a node called 'device'. The actual node name will >> > > depend on the RPC function (e.g. 'data' or 'config'). >> > > >> > > This is more than redundant however. It introduces a "super-module" >> > > into YANG that every other module is expected to augment. >> > > YANG is intended to be more loosely coupled than that. >> > > This introduces an extra node and namespace declaration >> > > in all protocol messages, increasing message sizes. >> > > >> > > It also assumes all existing YANG models will get rewritten to >> > > account for "/device" in all path and XPath expressions. >> > > This is highly disruptive to existing deployments. >> > > Also, multiple data models to edit the same thing causes lots >> > > of extra complexity in the server (supporting both old >> > > location and new location). >> > > >> > > IMO a resource directory approach is much more realistic. >> > > The /device tree can contain all the organized NP containers. >> > > Instead of all the actual data nodes, this tree just has pointers >> > > to the real location of the resource. (like 301 Moved Permanently) >> > > >> > > > Acee >> > > > >> > > Andy >> >> >> ** Solution Y34-02 >> >> Keep 'anyxml'. Introduce 'anydata' as above but without the >> 'format' substatement. >> >> 'anyxml' would still be used to represent unrestricted XML, as is >> done in NETCONF. >> >> 'anydata' would be an unknown chunk of data that can be modelled >> with YANG. Can be encoded as xml or json. >> >> For example: >> >> #+BEGIN_EXAMPLE >> anydata data; >> #+END_EXAMPLE >> >> ** Solution Y34-05 >> >> Same as Y34-02 plus two guidelines adopted from Y34-04: >> >> - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This >> ensures backward compatibility. >> - Introduce a new 'anydata' statement that represents an unknown >> chunk of data that can be modeled with YANG >> - Document that implementations MAY have restrictions for anyxml and >> that anyxml is not necessarily interoperable; data model writers >> should use anydata whenever possible. >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules when YANG 1.1 is adopted to >> avoid its use whenever possible. >> >> >> > >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Acee Lindem (acee)
- Re: [netmod] Y34 Lou Berger
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Lou Berger
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Lou Berger
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Lou Berger
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Acee Lindem (acee)
- Re: [netmod] Y34 Juergen Schoenwaelder
- Re: [netmod] Y34 Andy Bierman
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node Jonathan Hansford
- Re: [netmod] Y34 - root node Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Acee Lindem (acee)
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Acee Lindem (acee)
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Robert Wilton
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Robert Wilton
- Re: [netmod] Y34 - root node Martin Bjorklund
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node Robert Wilton
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Martin Bjorklund
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node Robert Wilton
- Re: [netmod] Y34 - root node Martin Bjorklund
- Re: [netmod] Y34 - root node Ladislav Lhotka
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Juergen Schoenwaelder
- Re: [netmod] Y34 - root node Kent Watsen
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Eric Voit (evoit)
- Re: [netmod] Y34 - root node Nadeau Thomas
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Alexander Clemm (alex)
- Re: [netmod] Y34 - root node Martin Bjorklund
- Re: [netmod] Y34 - root node Juergen Schoenwaelder
- Re: [netmod] Y34 - root node Lou Berger
- Re: [netmod] Y34 - root node Andy Bierman
- Re: [netmod] Y34 - root node Lou Berger
- Re: [netmod] Y34 - root node Ambika Prasad Tripathy (ambtripa)
- Re: [netmod] Y34 - root node t.petch
- Re: [netmod] Y34 - root node Alexander Clemm (alex)
- Re: [netmod] Y34 Robert Varga
- Re: [netmod] Y34 Robert Varga
- Re: [netmod] Y34 Ladislav Lhotka
- Re: [netmod] Y34 Robert Varga