Re: [netmod] Y34 - root node

"Jonathan Hansford" <jonathan@hansfords.net> Mon, 10 August 2015 08:46 UTC

Return-Path: <jonathan@hansfords.net>
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 0C7781B3358 for <netmod@ietfa.amsl.com>; Mon, 10 Aug 2015 01:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level:
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 3D9-f_fffvsd for <netmod@ietfa.amsl.com>; Mon, 10 Aug 2015 01:46:46 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan28.extendcp.co.uk [176.32.228.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A33C1B3341 for <netmod@ietf.org>; Mon, 10 Aug 2015 01:46:46 -0700 (PDT)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan3.hi.local) by mailscan-g68.hi.local with esmtp (Exim 4.80.1) (envelope-from <jonathan@hansfords.net>) id 1ZOijE-0002w7-3K; Mon, 10 Aug 2015 09:46:44 +0100
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=webmail5.hi.local) by mailscan3.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <jonathan@hansfords.net>) id 1ZOijA-0000K9-6w; Mon, 10 Aug 2015 09:46:41 +0100
Received: from localhost ([127.0.0.1]) by webmail5.hi.local with esmtp (Exim 4.80.1) (envelope-from <jonathan@hansfords.net>) id 1ZOij9-00029T-GT; Mon, 10 Aug 2015 09:46:39 +0100
Message-Id: <e30a7cae98788842423d1a1ad5760d81077a8ed1@webmail.hansfords.net>
From: Jonathan Hansford <jonathan@hansfords.net>
To: "Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>, Andy Bierman <andy@yumaworks.com>
X-Mailer: Atmail 6.6.0.11156
X-Originating-IP: 79.77.2.126
in-reply-to: <1FF17F20-66A0-4E68-8E07-08FD3CA76F04@cisco.com>
Date: Mon, 10 Aug 2015 09:46:39 +0100
Content-Type: multipart/alternative; boundary="=_723a6bbc62437eaf520205db1b51efd0"
MIME-Version: 1.0
X-Authenticated-As: jonathan@hansfords.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/2cdbqXullSr7C2vPqGSZDYQvSgo>
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 08:46:51 -0000

 And it is not just end users who need help to better understand YANG
models and how to use them. For those still on the edge, looking to
finally take the plunge and use NETCONF/YANG to configure their
devices, help is also required to determine how best to structure
their YANG models, make use of the existing ones, etc. For those who
have "grown up" with the developments in NETCONF and YANG, much of
this is probably second nature. But coming to it cold (in the sense of
compiling/writing a first set of YANG models for a device; I've been
following the netconf/netmod WGs for 3+ years), it still feels very
much like a dark art! It is not just the individual modules, it is how
to put them together to best manage a device (let alone a system).
Jonathan

----- Original Message -----
From: "Einar Nilsen-Nygaard (einarnn)" 
To:"Andy Bierman" 
Cc:"NETMOD Working Group" 
Sent:Sat, 8 Aug 2015 11:10:15 +0000
Subject:Re: [netmod] Y34 - root node

 Andy, 
 I agree that there is a need for organization of models, but I
don’t have a firm position
on draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model
or draft-bierman-netmod-yang-package. But we absolutely need
*something* to help end-users of the models comprehend the overall
structure of models, their relationship and how to use them. 
 Cheers, 
 Einar 
  On Aug 4, 2015, at 5:16 PM, Andy Bierman  wrote: 

On Tue, Aug 4, 2015 at 2:34 AM, t.petch   wrote:
 ----- Original Message -----
 From: "Andy Bierman" 
 To: "t.petch" 
 Sent: Monday, August 03, 2015 5:17 PM

 > ----- Original Message -----
 > From: "Andy Bierman" 
 > To: "t.petch" 
 > Sent: Monday, August 03, 2015 4:10 PM
 >
 > > ----- Original Message -----
 > > From: "Andy Bierman" andy@yumaworks.com [7]
 > > Sent: Saturday, August 01, 2015 7:05 PM
 > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
 > >
 >>> On 8/1/15, 2:51 AM,  j.schoenwaelder@jacobs-university.de [9]>
wrote:
 >>>
 >>> Section 1.1 in
 >>>
 >
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
[10]
 >>> 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.
 > >
 > > 
 > > 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.
 >
 > 
 >
 > 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
[11]
 >
 > 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.

 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  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/
[12]

 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. 

   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 [13]
 https://www.ietf.org/mailman/listinfo/netmod

 

Links:
------
[1] mailto:andy@yumaworks.com
[2] mailto:ietfc@btconnect.com
[3] mailto:andy@yumaworks.com
[4] mailto:ietfc@btconnect.com
[5] mailto:andy@yumaworks.com
[6] mailto:ietfc@btconnect.com
[7] mailto:andy@yumaworks.com
[8] mailto:acee@cisco.com
[9] mailto:j.schoenwaelder@jacobs-university.de
[10]
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
[11]
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
[12]
http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
[13] mailto:netmod@ietf.org