Subject: Re: analysis of YANG vs. RELAX NG

From: Julian Reschke <[email-masked]>
Date: Sat, 01 Dec 2007 10:19:36 +0100

Lisa Dusseault wrote:
> This is another aspect I'd like to understand better:
> 
> On Nov 28, 2007, at 2:02 PM, Martin Bjorklund wrote:
> 
>> Note that in order to validate the different NETCONF messages, you
>>
>> would either need more than one schema, or a very lax schema which
>>
>> will validate messages/documents which are not actually valid NETCONF.
>>
> 
> Validating XML really limits the customizability, the very extensibility 
> of the XML.  You can't add so much as a <custom-text-description> or 
> <debug-info-only> element without it failing at the other end.  Is the 
> goal here to strictly limit netconf data to only standardized and 
> implemented schemas?  

Well, that depends on the schema language. RelaxNG allows to define 
languages that use the must-ignore rule for new elements.

BR, Julian

---

From: "Tim Bray" <[email-masked]>
Date: Sun, 2 Dec 2007 12:42:07 -0800

> languages that use the must-ignore rule for new elements.

I've been staying off this thread because I don't understand what a
NETCONF is or what you'd do with one.  But Julian's point is massively
important.  If you're going to design your own modeling language, you
need to spend a *lot* of time thinking about the extensibility model.
It's really easy to get wrong.  -Tim

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 03 Dec 2007 14:56:02 +0100

> It's really easy to get wrong.  -Tim

Indeed. An extensibility problem in YANG is IMO the leaf statement. It
is encoded as an XML element but the fact that it is declared as leaf
effectively makes it into an XML attribute: It is impossible to extend
it (e.g., add a qualifying subelement) without changing the leaf into
container. In a RELAX NG schema, if properly designed, such an extension
wouldn't have to touch the parent schema.

Another problem might be the default statement in leaves (or it is
proper to say leafs here?:-) or typedefs. What if a standard data model
defines an item, say a hello timer, with such a default, but an
implementation wants to use another value for the default? Should it
come up with another schema?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Dec 2007 15:08:46 +0100

On Mon, Dec 03, 2007 at 02:56:02PM +0100, Ladislav Lhotka wrote:
> Tim Bray p????e v Ne 02. 12. 2007 v 12:42 -0800:

Leafs carry data and we strongly dislike mixed contents in NETCONF. So
this is actually a YANG feature and not a bug.
 
> come up with another schema?

No. There can only be one standard default. If you are thinking about
reusable groupings, then defaults can actually be changed wherever you
apply a grouping as far as I know.

/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: Mon, 03 Dec 2007 15:33:24 +0100

> this is actually a YANG feature and not a bug.

It doesn't necessarily mean mixed content, just changing

<anel>XYZ</anel>

into

<anel>
  <anel-qual>ABC</anel-qual>
  <anel-value>XYZ</anel-value>
</anel>

Or, alternatively, the qualification info can be encoded in an
attribute, which doesn't seem to be possible in YANG at all. I know,
attributes are also frowned upon, but sometimes such a flexibility comes
handy - and, after all, in some situations the extra attribute can be
understood as metadata.

> apply a grouping as far as I know.

Protocols specifications in RFCS usually say that a particular default
value SHOULD be something. So an impementation might have a reason for
using something else. In such cases, the standard data model thus cannot
use the default statement, right? 

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Dec 2007 16:34:10 +0100

> handy - and, after all, in some situations the extra attribute can be

Historically, network management protocols did not allow such a change
of semantics of a defined construct. 

Once you have standardized <anel>XYZ</anel>, then it is supposed to be
exactly that. If you allow changes as suggested above, the life of
management applications that have to support multiple versions becomes
fun. Note also that it is common to have references between different
parts of a larger data model and if you are allowed to make changes as
above, you might break references you are not aware of. The versioning
rules therefore have always been "once published, don't change" and
"if broken, create something new which is better".

> use the default statement, right? 

Yes, YANG says:

   If the leaf has a default value, the server MUST use this value
   internally if no value is provided by the NETCONF client when the
   instance is created.

So yes, a YANG default is a contract between the device and the
manager I can rely on. You may argue this is bad and sure such a
discussion can be held. But we did this knowingly and not as an
accident.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 Dec 2007 09:21:52 -0800

> this is actually a YANG feature and not a bug.

I strongly agree with Juergen.
YANG is based (in part) on 18+ years experience
with SNMP and SMI.

It s absolutely forbidden in NM to redefine the syntax and semantics
of a managed object in this way.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 03 Dec 2007 19:02:03 +0100

> YANG is based (in part) on 18+ years experience

And ignoring the additional flexibility XML can provide.

> of a managed object in this way.

Why? Even if I explicitly specify I am using another data model? The
difference is that if the data model is easily extensible, I can just
write

import parent-model;

and then 5 lines or so describing the differences, so that it is
immediately clear what I am doing (and hopefully why). If the
extensibility is weak, I have to take the parent model, change few lines
and declare it as a new data model - but the differences are not that
clear.

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 Dec 2007 10:09:00 -0800

> And ignoring the additional flexibility XML can provide.

flexibility is the enemy of inter-operability.
We are trying to create multi-vendor network management systems.
It is well understood in the NM world that refining existing data
definitions breaks existing manager code.

> and declare it as a new data model - but the differences are not that

This does not help the running code that expects the old definition of
the data object.

Deployment of NM code is part of our problem space.
It may be irrelevant to APPs work, but not NM.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 3 Dec 2007 12:01:34 -0800

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, December 03, 2007 10:02 AM
> Subject: Re: analysis of YANG vs. RELAX NG
>

> And ignoring the additional flexibility XML can provide.

I strongly agree with Andy and Juergen.  "Mushy" definitions
are disastrous for interoperability.

> > of a managed object in this way.

Agreed.

> and declare it as a new data model - but the differences are not that

Re-use of definitions in the process of creating *new* definitions is
another matter.  The important point is that those new definitions in
no way affect the models on which they were based, and therefore must
not be understood as a redefinition of either the semantics or the
syntax of a managed object.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Mon, 3 Dec 2007 13:55:10 -0800

I agree with Juergen, Andy, and Randy.

Our goal is interoperability between multiple managed devices and
multiple management applications - we need system-wide
interoperability for M:N relationships. 

Netconf has different requirements than SNMP, and a Netconf DML will
have different requirements than SMI, but NM requirements seem
relatively stable on this point.

A MIB module is a type of contract between the involved parties, and
it is unacceptable to modify the syntax or semantics in ways that
would break contract-compliance/interoperability between the parties.
The SMI does not allow changes to existing datatypes, with very few
exceptions. SMI does permit some extensibility, such as extending
enumerations or BITs, but the change controls for the exceptions are
clearly defined in the SMI. Those restrictions exist to ensure
interoperability among NM entities within the system. 

David Harrington
[email-masked]
[email-masked]

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Monday, December 03, 2007 12:02 PM
> To: [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 3 Dec 2007 23:12:50 +0100

> From: Ladislav Lhotka [mailto:[email-masked]] 
> Sent: Monday, December 03, 2007 8:02 PM
> To: Andy Bierman
> Cc: [email-masked]
> > YANG is based (in part) on 18+ years experience with SNMP and SMI.
> 
> Why? Even if I explicitly specify I am using another data 
> model? The difference is that if the data model is easily 
> extensible, I can just write
> 
> import parent-model;
> 
> and then 5 lines or so describing the differences, so that it 
> is immediately clear what I am doing (and hopefully why). If 
> the extensibility is weak, I have to take the parent model, 
> change few lines and declare it as a new data model - but the 
> differences are not that clear.
> 
> Lada
>  
> --
> Ladislav Lhotka, CESNET
> PGP Key ID: E74E8C0C
> 
>

Lada,

How can two different management entities interoperate if the same object has two different semantics because they have loaded two different versions of the data model? Only the entity that has loaded the newer version will be aware about the ' 5 lines or so describing the differences', what about the older one? 

Dan
(asking as contributor)

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 03 Dec 2007 23:59:46 +0100

Hi,

> are disastrous for interoperability.

I think it's a misunderstanding. I am not pleading for fuzzy (is it
approximately what "mushy" means?;-) data models, the models can and
should be simple and unambiguous, I am talking about additional
flexibility for model *designers*, i.e., straightforward means for
reusing and extending existing models into new models (also by adding
structure to former leaves, why not?), and here I think YANG is rather
rigid when compared to RELAX NG.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Dec 2007 08:25:31 +0100

> rigid when compared to RELAX NG.

The question whether it is a good idea to be able to turn a data
containing XML element into a container element in a future revision
of a data model is pretty much independent of the schema language.

Several network management people believe that having XML elements
that sometimes are containers and sometimes leafs does not help
interoperability. In fact, we would likely require that any solution
(e.g. XSD-+ or RELAX NG-+ extended subset languages) does have
versioning rules attached that guarantee the same behaviour.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 13 Dec 2007 18:11:20 +0100

Hello,
A late reply.
I agree with Juergen, Andy et al. but I also have anther reason.

Imagine when you have one big model that is modified by a 5 liner a bit. Then you get the next 
five liner, the next one. Then you get a five liner that modifies a previous modification.
To understand what really goes on in the node you have to know all the little 5 liners.

In Yang you can at least understand the basic model and consider the rest as extensions, 
because the basic model is not redefined only extended.

Balazs

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