Subject: [netmod] FW: I-D Action:draft-linowski-netmod-yang-abstract-00.txt

From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" <[email-masked]>
Date: Mon, 13 Jul 2009 14:37:34 +0300

Hi All,

please find below the -00 draft we submitted on "Extending YANG with
Language Abstractions".
This is an early draft and needs some discussion for further
development.
Please give us your comments.

Regards,
Bernd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext
[email-masked]
Sent: Monday, July 06, 2009 9:00 PM
To: [email-masked]
Subject: I-D Action:draft-linowski-netmod-yang-abstract-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Extending YANG with Language Abstractions
	Author(s)       : B. Linowski, M. Ersue
	Filename        : draft-linowski-netmod-yang-abstract-00.txt
	Pages           : 42
	Date            : 2009-07-06

YANG - the NETCONF Data Modeling Language - supports modeling of a
tree of data elements that represent the configuration and runtime
status of a particular network element managed via NETCONF.  This
memo suggests to enhance YANG with supplementary modeling features
and language abstractions with the aim to improve the model
extensibility and reuse.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract-
00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Jul 2009 08:41:44 -0700

> Please give us your comments.

The new constructs that are proposed seem to overlap the
YANG grouping and uses statements a great deal.

Before YANG, I implemented something called NCX
which had complex types, and every node
had a type.  Every node also formed a containment
layer, even choices, because the type was a complete
abstraction, and what if it changed from a list to a choice?

I found that the complexity level in the agent callback
structure went up a lot because of this abstraction.

At first I did not like YANG groupings, because they are so
much more fragile and 'hands-on' than complex types.
You must control the containment layering and refinements.
It is not handled automatically like with complex types.

But now I think that groupings are more appropriate for
embedded systems, and align better with traditional
agent callback design.

> Bernd

Andy

> ------------------------------------------------------------------------
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 22 Jul 2009 13:04:57 +0200

Hello Andy,
So you are saying, using complex types is more complicated. You wanted to use complex types, 
but later abandoned it due to implementation complexity.

A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard organizations (IETF-IPFIX, 
3GPP, SAForum, DMTF CIM) find, that for the human user it is easier to think in terms of 
Managed objects with complex types then in terms of groupings.

Also we stated somewhere that readers are the most important community. I think we should not 
block this effort.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jul 2009 07:23:23 -0700

Balazs Lengyel wrote:
> Hello Andy,
> So you are saying, using complex types is more complicated. You wanted
> to use complex types, but later abandoned it due to implementation
> complexity.
> 
> A lot of people (Ericsson, NSN, S3 a Netconf vendor) and standard
> organizations (IETF-IPFIX, 3GPP, SAForum, DMTF CIM) find, that for the
> human user it is easier to think in terms of Managed objects with
> complex types then in terms of groupings.
> 
> Also we stated somewhere that readers are the most important community.
> I think we should not block this effort.

I am not in favor or turning YANG into XSD,
with elements and element lists mixed in
with the containers and lists.  I think YANG mechanisms
are sufficient, and the proposed mechanisms do
not add any important new functionality.   Instead, they add more
ways to do the same things already supported by YANG.

I think we should finish YANG 1.0 and start using it.
I don't see a need to delay YANG further, or
to start working on a replacement for it.

I did not find that the 'complex-type' and 'element' constructs
made the IPFIX data model even slightly easier to understand.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 22 Jul 2009 11:22:51 -0400

>> complex types then in terms of groupings.

I've not finished the draft yet, but there were concerns (when OO
constructs were earlier proposed as part of YANG) about how reuse
and revision would work with these OO constructs.  Are these solved
in the draft?

Thanks,
 Phil

---

From: David Partain <[email-masked]>
Date: Wed, 22 Jul 2009 18:52:30 +0200

Hi,

My co-chair is currently on vacation, but I think I'm speaking for both of 
us...

This draft is NOT a working group item.  It is on the agenda because we (1) 
have time and (2) there are people in the NETMOD working group who want to 
gauge interest and perhaps work more together after Stockholm.  

However, the fact that this is on the agenda should not be interpreted to 
mean "We're considering re-chartering to include this right now."  While I 
don't get to decide such things alone, I will strenuously oppose any such 
action right now.

We will finish our currently-chartered items before we consider re-chartering 
to include ANY new work.  That includes this draft and the SMI draft by 
Juergen and any other NETMOD-related draft.  We have a set of deadlines that 
I intend to do my utmost to see that we meet.  Adding new work now would not 
be helpful in doing so.

Cheers,

David

---

From: David French <[email-masked]>
Date: Wed, 22 Jul 2009 17:59:32 +0200

Hi,

Just to add to Balazs mention, our (S3 / embeddedMIND)
experience has also been that an emphasis on managed object
hierarchy concepts when modelling rather than
Yang-style groupings leads to a more straightforward mapping
and lower integration costs with the applications on the device.

Regards,

David French
www.embeddedmind.com

Balazs Lengyel wrote:
> Also we stated somewhere that readers are the most important
> community. I think we should not block this effort.
> Balazs
>
> Andy Bierman wrote:

-- 

-----------------------------------
David French, VP Product Management
Management Infrastructure for Networked Devices
www.embeddedmind.com
+48 71 3348174 (use email not voicemail)

http://www.s3group.com/legal/

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 23 Jul 2009 08:44:56 +0200

> and lower integration costs with the applications on the device.

Why is YANG insufficient for modelling such object hierarchies? In fact,
YANG allows for "multiple inheritance", which might be very useful - and
safe, since we don't have to care about method lookup strategies.

Perhaps the difference is just that YANG doesn't *enforce* object
orientation.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 23 Jul 2009 09:56:30 +0200

Hello,
The two main points I am missing are
- actions/rpcs in groupings/lists
- type information on groupings/lists. Unless you do a deep analysis of the YAMs there is no 
way to find out that e.g. a leafref points at something derived from a grouping.

I don't believe anyone wants to enforce object orientation in YANG.
Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 23 Jul 2009 12:30:37 +0200

> - actions/rpcs in groupings/lists

Hmm, do you mean something like methods? Bernd & Mehmet's draft does not
propose anything like this (yet) but IMO without support for late
binding it is just unnecessary syntactic sugar.

> way to find out that e.g. a leafref points at something derived from a grouping.

Validation including type checking is performed on instance XML
documents where this information is not available anyway. An
instance-identifier points to a concrete data node whose presence can be
directly checked for. Everything else is quite complicated - how would
you specify an XPath expression pointing to a complex type that has no
corresponding node in the data tree?

YANG is much closer to an XML schema language than to a programming
language and I think it should stay this way.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Jul 2009 05:52:24 -0700

> language and I think it should stay this way.

Yes -- I know the IETF does not work on APIs,
but this seems like a problem for the code generators to solve.

It there was some sort of class hierarchy (from NETCONF session to content)

   myitf = session.interfaces.interface.get_config(name='eth0');

   status = session.interfaces.interface.reset(name='eth0');

Extensions could be used to declare a method.
Access control and normal <rpc> processing
give the illusion the rpc is coupled to the data.

module interfaces {

  rpc reset {
     x:method /interfaces/interface;
     input {
        leaf name { ... }
     }
  }

  container interfaces {
     list interface { ... }
  }

}

then would this be good enough?
Could something like this be standardized at all?

(I know the callingPoint mechanism is similar,
but not quite the same as this 'method' extension.)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 23 Jul 2009 10:01:14 -0400

>then would this be good enough?

If you wanted this, you could do it by just tagging the
input item:

module interfaces {

  rpc reset {
     x:method-of name;
     input {
        leaf name {
            type leafref {
                path /interfaces/interface;
            }
        }
     }
  }

  container interfaces {
     list interface { ... }
  }
}

Your code generator sees "method-of name", looks up "name" in the input
parameter list, finds the leafref to /interfaces/interface and adds it
as a method of that class.  And you'd still be able to invoke it as a
normal netconf operation, with no changes to the netconf content.  Only
your local coders need to know that interfaces.interface has a method
called reset.  You could even:

    rpc reset-interface {
        x:method-of name {
            x:method-name reset;
        }
    }

to distinquish the method name from the real RPC name.

Anyhow the point is that you can add features for oo tool support
without impacting other YANG users.

Thanks,
 Phil

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 23 Jul 2009 20:28:08 +0200

Hi,

I like groupings and they are appropriate for many of our modeling 
work. 

But I also believe strongly that complex types are a useful option 
for straightforward modeling when people have managed objects 
with complex types in mind. 

Well, I agree that some of us don't use them and think they are 
not necessary.
But I also know clearly that many of us use complex types and 
type-safe modeling extensively.

I would like to enable complex types also for YANG-based modeling 
and NETCONF-based configuration.

> made the IPFIX data model even slightly easier to understand.

I think this a subjective impression which accept fully. 
OTOH based on the feedback we got some of us seem to think that 
the IPFIX model prepared with complex types is at least easier to 
read and more straightforward to model.
We summarized the benefits for the use of complex types in the draft.

Cheers,
Mehmet

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Andy Bierman
> Sent: Wednesday, July 22, 2009 4:23 PM
> To: Balazs Lengyel
> Cc: [email-masked]
> Subject: Re: [netmod] FW:I-D 
> Action:draft-linowski-netmod-yang-abstract-00.txt
> 
> Balazs Lengyel wrote:
> > Hello Andy,

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 23 Jul 2009 20:28:37 +0200

Hi Balazs,

thank you for pointing this out.

We indeed have a lot to do and the -00 draft is for sure 
not complete. 

Actions/rpcs in groupings/lists and type information on 
groupings are features we definitely need.
We would be happy to have your suggestions and input. 

Cheers,
Mehmet

> [mailto:[email-masked]] On Behalf Of ext Balazs Lengyel
> Sent: Thursday, July 23, 2009 9:57 AM
> To: Ladislav Lhotka
> Cc: [email-masked]
> Subject: Re: [netmod] FW: 
> I-DAction:draft-linowski-netmod-yang-abstract-00.txt
> 
> Hello,

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 23 Jul 2009 20:25:50 +0200

Hi All,

sorry for not stating it more clearly on the NETMOD maillist 
earlier. 

As discussed with the chairs we don't want to disturb the 
development of YANG 1.0. This is the reason why we waited 
until WGLC of the chartered YANG specification work.

It might be still a bit early but after having finalized the 
YANG development mostly I think it is the right time to start
the discussion on new YANG features, which are useful and 
interesting to develop soon.

Cheers,
Mehmet

> [mailto:[email-masked]] On Behalf Of ext David Partain
> Sent: Wednesday, July 22, 2009 6:53 PM
> To: [email-masked]
> Subject: [netmod] Regarding draft-linowski-netmod-yang-abstract-00.txt
> 
> Hi,
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Jul 2009 12:00:41 -0700

Hi,

Didn't we do a requirements gathering phase of some sort,
in order to get to the point where charter decisions
were made, so that the NETMOD WG could proceed and
finish in finite time?

I believe the consensus at the time was that we did
not want an OO data modeling language and we choose YANG over several
other proposals, including the OO proposal from your co-author.

It is rather subjective to start comparing comfort-levels
with 1 variant of the IPFIX model or another.  I doubt we
could reach agreement in the IETF on a data modeling language
that had enough OO programming language features to make a
real difference.  I prefer to get a stable YANG 1.0 deployed,
and start defining some standard content.   IMO, the DML used
would not make much difference at all if I were deciding whether to
implement the IPFIX model or not.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Jul 2009 23:31:44 +0200 (CEST)

Hi,

> Well, I agree that some of us don't use them and think they are 

It seems you are saying that using complex types is just a different
way of doing what can already be done.  Some people find models with
complex types easier to read, and some people find them harder to
read.  

I don't like the idea of introducing new alternative ways of doing
what we already do.  This just adds complexity to the language.  Even
if you think models with complex types are easier to read, the result
will be that some models use complex types and others don't, so the
net result will not be easier to understand.

/martin

---

From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" <[email-masked]>
Date: Fri, 24 Jul 2009 11:13:47 +0300

Hi,

Ladislav Lhotka wrote:
> Sent: Thursday, July 23, 2009 12:31 PM
> To: Balazs Lengyel
> Cc: [email-masked]
> Subject: Re: [netmod] FW: I-D 

We haven't covered actions/rpcs in complex-types simply because
of lack time.
Having an action defined in the scope of the target
of that action would improves clarity in some cases imho
(e.g. having a "witch-group" action as part of a "protection-group" complex type
 would tell that this action may be applied only to protection groups)

> > way to find out that e.g. a leafref points at something 

I agree with Balazs here. 

The typed instance identifier addresses this by explicitly including the type
of the target in the model.

> corresponding node in the data tree?

By including the type information in the model explicitly, what is
done in the proposed typed instance identifier.

> language and I think it should stay this way.

Well, as soon as you describe behavior in a language - which YANG does
already in form of rpc's and notifications - it is also an interface description language.
In that respect it goes already far beyond what XML schema does.

- Bernd

> > >>>>>     Filename        : 
> draft-linowski-netmod-yang-abstract-00.txt
> > >>>>>     Pages           : 42
> > >>>>>     Date            : 2009-07-06
> > >>>>>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 24 Jul 2009 14:48:52 +0200

Hi Martin,

I think it is the feature richness which makes a modeling
language successful. Different people will prepare their 
YAM on different abstraction levels and will use different 
language constructs based on their preferences.

There might be models, where groupings are the most 
appropriate construct to use, e.g. for the modeling 
of structured data tables. Others will use complex 
types _and_ groupings because they have a bigger amount 
of modeling work to do. Their system and the huge amount 
of data models makes it necessary to design in a top-down 
manner and to do hierarchical modeling.

I also can imagine that some of us will be interested to 
use and derive their data models from industry standard
information models. A language mapping at the interface 
between the two models becomes important.
I believe it will be useful to have YANG easier mappable 
to other modeling languages. This will also enable easy
adoption of IETF data models by other SDOs. I think it 
is a good thing if TMF or 3GPP would be able to map YAMs 
to their model easily or adopt and use YAMs as they are.

Cheers,
Mehmet

> From: ext Martin Bjorklund [mailto:[email-masked]] 
> Sent: Thursday, July 23, 2009 11:32 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jul 2009 16:08:45 +0200

On Fri, Jul 24, 2009 at 02:48:52PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:

Disclaimer: I have not read the document yet in detail but I have some
questions to understand the stated motivation. 
 
> manner and to do hierarchical modeling.

Can you provide the necessary text for the guidelines document that
tells people which construct to use when and why?
 
> between the two models becomes important.

Are you saying a mapping of those industry standard models (which
ones?) to YANG 1.0 is not possible? Why is it not possible?

> to their model easily or adopt and use YAMs as they are.

Now you are talking of mapping YANG to other languages (which
ones?). Why is that not possible with YANG 1.0?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 24 Jul 2009 16:54:00 +0200

> complex types easier to read, and some people find them harder to

I suspect the main problem of groupings is that they may be perceived as
something like macros - which they aren't in reality.

> net result will not be easier to understand.

+1

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 24 Jul 2009 17:04:04 +0200

Linowski, Bernd (EXT-Other - DE/Dusseldorf) píše v Pá 24. 07. 2009 v

> We haven't covered actions/rpcs in complex-types simply because

Yes, I understand, but without a reasonably detailed proposal it is
difficult to discuss such features.

>  would tell that this action may be applied only to protection groups)

This is again subjective, some implementors might prefer to have all the
RPCs and notifications in one place.
 
> done in the proposed typed instance identifier.

Yes, but it doesn't answer my question. If no trace of the complex type
remains in the instance document, what does the "instance identifier of
a complex type" point to in the instance document (or datastore)?

> In that respect it goes already far beyond what XML schema does.

No, YANG specifies just the signatures of RPC methods, no behaviour at
all.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" <[email-masked]>
Date: Fri, 24 Jul 2009 19:39:52 +0300

Hi 

> ones?) to YANG 1.0 is not possible? Why is it not possible?

For example, mapping of recursive structures is an area where
things get difficult.

In 3GPP a 3GSubNetwork might contain other 3GSubNetworks, in the SID
a Hardware instance might contain other Hardware instances.
Currently, you have to use a leafref-typed leafs to point the
the parent (and/or the children) to emulate recursive containment.
This also has the disadvantage that the hierarchy is not visible
in the NETCONF payload. It also makes filtering based on
a location in the (conceptual) containment tree formed by recursice
structures difficult.

BR,
Bernd

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 27 Jul 2009 16:25:57 +0200

Hi Andy,

I think this wouldn't be sufficient as the example does not 
address derived types and using a type in different places 
in the node tree.

We need to discuss this in detail in the session on Wednesday.

BTW: We noted RPCs and invocations as open issue in the
draft.

Cheers,
Mehmet

> Sent: Thursday, July 23, 2009 2:52 PM
> To: Ladislav Lhotka
> Cc: [email-masked]