Andy Bierman <[email protected]> writes: > On Tue, Aug 4, 2015 at 2:34 AM, t.petch <[email protected]> wrote: > >> ----- Original Message ----- >> From: "Andy Bierman" <[email protected]> >> To: "t.petch" <[email protected]> >> Sent: Monday, August 03, 2015 5:17 PM >> >> > ----- Original Message ----- >> > From: "Andy Bierman" <[email protected]> >> > To: "t.petch" <[email protected]> >> > Sent: Monday, August 03, 2015 4:10 PM >> > >> > > ----- Original Message ----- >> > > From: "Andy Bierman" [email protected] >> > > Sent: Saturday, August 01, 2015 7:05 PM >> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <[email protected]> >> > > >> >>> On 8/1/15, 2:51 AM, [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
