Subject: Re: analysis of YANG vs. RELAX NG

From: Martin Bjorklund <[email-masked]>
Date: Tue, 27 Nov 2007 13:03:55 +0100 (CET)

Hi,

"Rohan Mahy" <[email-masked]> wrote:
> I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and
> thought immediately that all of the problems the draft is trying to
> address looked very suitable to use RELAX NG as a schema language.
> Looking at section F.2 (Why not RELAX NG) I did not see any specific
> examples motivating the apparently contradictory statements that Relax
> is not expressive enough and Relax is too expressive.

What we mean with this is that generic XML schema languages such as
RelaxNG and XSD are designed to specify the grammar for (almost) any
XML instance document.  For example they both support mixed content
and XML attributes, neither of which we use in YANG.  You could of
course just state that these constructs MUST NOT be used.

None of these languages support important configuration management
concepts like default values (XSD has a default construct, but it is
not the same); you cannot see if a parameter represents configuration
or state data (since it's very domain specific).  In RelaxNG there is
not support (by design) for integrity contraints and keys.  None of
the languages have support for specific augmentation (this is
important e.g. for vendors to add vendor-specific stuff to standard
data models).

We also note in the draft that both languages are extensible, and with
an extensible language you can add whatever you want.

All this means that the existing tools might not be that simple to
use.  These tools are not aware of any restrictions on the usage
imposed by NETCONF, and they do not understand the NETCONF-specific
extensions.

Another question regarding existing tools is what exactly these tools
are supposed to be used for?  Probably not instance document (NETCONF
PDU) validation, unless all elements are defined as optional, since
e.g. in an edit-config request you just include the elements you want
to modify.

> keyref and instance-identifier are probably better served by referencing
> an 'id' attribute and using the 'ID' type

The problem with the ID type is that its value is global to a
document.  If the document is the entire configuration datastore, all
IDs will have to be unique.  Since you can reference any key (or maybe
even any leaf), every key (or leaf) will have to have it's own unique
ID.  This won't scale and would be very difficult to maintain.

> Below, I also show examples of the YANG concepts of leaf node,
> leaf-list, container, and list expressed in YANG, how it would be
> expressed in NETCONF, and expressed in RELAX NG.

Here's another one:

in module foo:
   
   rpc my-rpc {
     input {
       leaf foo { type string; }
     }
     output {
       leaf-list bar { type int32; }
       leaf baz      { type int32; }
     }
   }

in module bar:

  augment /foo:my-rpc/foo:output {
     leaf data { type int32; }
  }

How would this translate to RelaxNG?

/martin

---

From: Leif Johansson <[email-masked]>
Date: Tue, 27 Nov 2007 13:45:30 +0100

> How would this translate to RelaxNG?
I don't know about RelaxNG, but it is pretty close to OWL. Apart from
the C-like syntax (which might be important to some) the example
suggests a modeling language which supports classes, packages,
properties (possibly associations?) and a form of multiple inheritance.

While I am as happy as the next guy that we won't be seeing RFCs
with XMI in them anytime soon I am curious as to why something like
OWL isn't a strong candidate for something like this. Is it just "anti-XML"
or is there something more substantial to it?

I'm looking foward to the BOF.

    Cheers Leif

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Nov 2007 13:47:12 +0100

> course just state that these constructs MUST NOT be used.

It might be important form some people on this list who are not too
heavily involved in the network management activities of the IETF to
know some of the history and experience with the IETF's SMI data
modeling language very widely used to write MIB modules (within the
IETF, by other SDOs, and a large number of device vendors; in 2005, I
counted ~170 IETF modules, ~480 Cisco modules, and ~100 Juniper
modules with a rough total of 32,000 object definitions [1]).

Back in the old times when SNMP came up, the language of the day was
called ASN.1. When the SMI became formalized (after it turned out that
plain textual descriptions are too difficult to be understood by
tools), something now called an adapted subset of ASN.1 was
created. The idea was to take ASN.1, forbit those constructs that are
somehow not useful in the SNMP context, and add some new constructs
via ASN.1 macros that carry the stuff needed for SNMP data
modeling. Since then, the SMI has become pretty much its own language
and almost all SNMP tools I have seen in the last decade actually do
not use generic ASN.1 parsers to parse MIB modules. There are several
reasons for this which I will not go into here. The experience,
however, has been that creating an "adapted subset" of ASN.1 (1987)
turned out to be no money or energy saver and there are still today
questions popping up whether some constructs are legal which you can't
easily answer since you need the 1987 spec of ASN.1 and then find the
"right" interpretation of it. (Note that the whole macro notation
meanwhile got dropped from ASN.1.)

I think it is important to consider the long term implications of
creating adapted subsets of other languages in the IETF. NETCONF needs
a data modeling language and framework that must be long term stable
and easy to use. I personally believe that designing a domain specific
language for NETCONF has large benefits since we can optimize the
language for what is needed for NETCONF, make the language simple to
read, ensure the language works well in the IETF process (max 76 ASCII
character lines, compact for plain text email discussions), and we can
have long term stability and full chance control in the IETF.

/js

[1] J. Schoenwaelder, Characterization of SNMP MIB Modules,
    Proc. 9th IFIP/IEEE International Symposium on Integrated Network
    Management, 2005

[2] K. McCloghrie, D. Perkins, J. Schoenwaelder, Structure of
    Management Information Version 2 (SMIv2), STD0058, April 1999

-- 
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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Nov 2007 17:37:27 +0100

> or is there something more substantial to it?

NETCONF uses XML for data encoding and is this is just fine.

YANG is a domain specific data modeling language designed to support
NETCONF (no more, no less). The YANG language reflects many years of
experience with other network management data modeling languages in
the IETF and proprietary languages created by NETCONF implementors to
support their implementations (after figuring out that creating
adapted subset languages did not work well in their companies or for
their customers).

While YANG clearly lacks features such as multiple inheritance or
support for semantic web reasoning engines, we feel that it helps a
lot in writing understandable and extensible NETCONF data models and
in addition it can enjoy long-term predictability and stability.

/js

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 27 Nov 2007 11:54:23 -0800

Another question to answer, is why is having a data model (an  
ontology) not enough?  The question of needing a standard data model  
must be separated from the need for a custom modeling language.  Some  
of the justifications I've seen so far for a modeling language have  
really been justifying only a standard data model.

Of course using XML as the data format doesn't, by itself, give  
enough of a common data model for 3rd-party NetConf tools to  
understand arbitrary data.  NetConf probably does need a common data  
model, perhaps defining how IDs are expressed and what a container  
is, what is a netconf "object" that can be operated on.

But a common data model does not need to depend on a modeling  
language at all.  Put it differently: a sufficiently strong common  
data model can work with multiple modeling languages without harming  
interoperability.  Thus, having a standard data model that is  
independent of the modeling language can be a real win for clarity  
and robustness and somewhat more proof against changing stylistic  
preferences.

The commonest approach for IETF protocols that deal with an ontology  
is to define the data model in English, limiting the ways the data  
can be expressed to something that becomes essentially self- 
describing (the name of a new thing/object, and its contents or  
value, can be derived from the document without seeing a specific  
schema).  LDAP is one of the clearest examples of this.  An LDAP  
agent can handle custom content because it follows the expected data  
model. There's no need, in LDAP, for a special language to describe  
new attributes.  The iCalendar and vCard formats are the same.  SNMP  
is really different in having a special language to learn, and using  
that in specs.

My experience with description languages or other formalizations is  
that these often take the place of proper specification.  Authors  
think that they are done when they've written the code that describes  
the format.  However, the most important aspect to a new standard  
schema is usually what it *means*.

Lisa

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 27 Nov 2007 15:04:53 -0800

Hi Martin,

More comments inline.

> course just state that these constructs MUST NOT be used.

Yes, these languages are used to define many schema that do not support
mixed content. Defining a set of templates in Relax would make it very clear
how the new data should be organized, and is very easy for readers to parse
and validate with boatloads of existing tools.  Most netconf implementors
will already have an XML parser that will automatically validate against
either XSD or Relax schema.

> important e.g. for vendors to add vendor-specific stuff to standard

I understand that you want semantic data mixed with your syntax data. I
don't think you need to define a new schema language to do this. Relax
allows arbitrary annotations in other namespaces, and these annotations can
have semantic meaning.  Rather than define a whole new syntax as well, I am
much more comfortable defining additional semantics layered on top of an
existing schema which validates the syntax.

> imposed by NETCONF, and they do not understand the NETCONF-specific

This is a tautological statement. The existing tools will automatically
catch large categories of errors automatically (that's as simple as it
gets). If you want additional semantic checking, you will define those rules
whether you write a whole new language or not.

> ID.  This won't scale and would be very difficult to maintain.

In RAI we had some rather painful experience with referencing keys in XCAP
(RFC 4825) which also uses XPath expressions to point at subparts or
subtrees of an XML document. You can certainly maintain a unique key within
a list which is not generated from the data in each record.  Not doing so
"won't scale and would be very difficult to maintain".  However, this
argument is orthogonal to our main topic.

> How would this translate to RelaxNG?

I am assuming that this would generate the following XML in Netconf:
<rpc message-id="45">
  <my-rpc>
    <foo>some string</foo>
  </my-prc>
</rpc>

<rpc-result message-id="45">
  <bar>4134</bar>
  <bar>3882</bar>
  <baz>112334</baz>
  <data>82382</data>
</rpc-result>

I was not clear exactly the significance of "module foo" and "module bar".
If I understood correctly, module foo defines the "my-rpc" RPC call, and
module bar just extends the response.  I will call these "my-rpc.rng" and  "
my-rpc-extension1.rng" respectively.

<!-- my-rpc.rng  -->
<include href="netconf-rpc.rng"/>

<define name="rpc-requests" combine="choice">
  <ref name="my-rpc-request"/>
</define>

<define name="rpc-responses" combine="choice">
  <ref name="my-rpc-response"/>
</define>

<define name="my-rpc-request">
  <element name="foo">
    <data type="string"/>
  </element>
  <netconf:rpc-method type="request">my-rpc</netconf:rpc-method>
</define>

<define name="my-rpc-response">
  <oneOrMore>
    <element name="bar">
      <data type="int"/>
    </element>
  </oneOrMore>
  <element name="baz">
    <data type="int"/>
  </element>
  <netconf:rpc-method type="response">my-rpc</netconf:rpc-method>
</define>

Note that I used a Relax annotation to convey extra semantic data.  This is
ignored during relax syntax validation, but available to the implementation
if it wants to use this additional semantic information.  An example of this
is described in the book in chapter 13.3:
http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-3.html

The "augment" is accomplished using a define with interleave:

<!-- my-rpc-extension1.rng -->

<include href="my-rpc.rng"/>

<define name="my-rpc-response" combine="interleave">
  <element name="data">
    <data type="int"/>
  </element>
</define>

Finally, if you are allergic to angle brackets, you can do all this in
compact form as well:

# my-rpc.rnc
include "netconf-rpc.rnc"
rpc-requests |= element foo { xsd:string }
rpc-responses |= {
  element bar { xsd:int }+,
  element baz { xsd:int }
}

# my-rpc-extension1.rnc
include "my-rpc.rnc"
my-rpc-response &= element data { xsd:int }

For a more full example, I invite you to look at how Jari Urpalainen did
this for the PIDF family of XML schemas to allow full automatic syntax
validation. While his draft is recently expired, I have archived a copy
here:
http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt

Also section 10.2 "Merging Grammars" in the Relax NG book describes this
very nicely: http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html

thanks,
-rohan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2007 09:38:52 +0100

On Tue, Nov 27, 2007 at 11:54:23AM -0800, Lisa Dusseault wrote:

> Another question to answer, is why is having a data model (an ontology) not 
> enough?  The question of needing a standard data model must be separated 
> from the need for a custom modeling language.  Some of the justifications 
> I've seen so far for a modeling language have really been justifying only a 
> standard data model.

Different areas happen to use different terminology. What you call a
data model is what network management people happen to call an
information model, see RFC 3444. I don't care which terminology we use
in this discussion as long as we happen to understand the same thing
when we use the same words.

> Of course using XML as the data format doesn't, by itself, give enough of a 
> common data model for 3rd-party NetConf tools to understand arbitrary data. 
> NetConf probably does need a common data model, perhaps defining how IDs 
> are expressed and what a container is, what is a netconf "object" that can 
> be operated on.
>
> But a common data model does not need to depend on a modeling language at 
> all.  Put it differently: a sufficiently strong common data model can work 
> with multiple modeling languages without harming interoperability.  Thus, 
> having a standard data model that is independent of the modeling language 
> can be a real win for clarity and robustness and somewhat more proof 
> against changing stylistic preferences.

The network management world is used to automated processes and the
number of MIB modules in existences may serve as a proof that people
do find benefits from using machine readable definitions. OK, to be
fair, I must admit that SNMP is almost unusable with generic tools
without at least translating OIDs into something textual. But there is
of course much more you get out of concrete machine readable data
models since they can drive large (and annoying and error prone) parts
of implementation processes.

> The commonest approach for IETF protocols that deal with an ontology is to 
> define the data model in English, limiting the ways the data can be 
> expressed to something that becomes essentially self-describing (the name 
> of a new thing/object, and its contents or value, can be derived from the 
> document without seeing a specific schema).  LDAP is one of the clearest 
> examples of this.  An LDAP agent can handle custom content because it 
> follows the expected data model. There's no need, in LDAP, for a special 
> language to describe new attributes.  The iCalendar and vCard formats are 
> the same.  SNMP is really different in having a special language to learn, 
> and using that in specs.

I would call the "iCalendar apprach" semi-formal and this is likely
true for the others you mention as well. My understanding is that
iCalendar does in fact use some ABNF plus several other "conventions",
i.e., certain naming and structuring rules, value notation rules,
quoting rules and so on. So there is somewhat formalized content but I
also agree that the overall format is not as strict as the SMIv2 or
YANG or RelaxNG or XSD (just to name a few ;-).

I believe the key difference is simply the number of definitions
network management people happen to deal with. The complete
configuration of high-end routers involves significantly more than
just a few 10s of knobs. I am sure people from the network device
vendor business can provide concrete numbers concerning the size of
configuration options you find on today's products in case that is
useful. Once you reach a critical threshold, you really like to have
precise machine readable specifications that can drive a tool chain
and to some extend validate definitions, automate some of the
implementation work, reduce implementation bugs, drive documentation
tools and so on.

> My experience with description languages or other formalizations is that 
> these often take the place of proper specification.  Authors think that 
> they are done when they've written the code that describes the format.  
> However, the most important aspect to a new standard schema is usually what 
> it *means*.

Sure, languages can't turn lazy people into smart people. But the IETF
is actually very good at handling this. You can't publish a protocol
by writing down just a few ABNF definitions. You can't publish a MIB
module by leaving description clauses empty. You can't publish a
protocol by just writing down message formats in ASCII art and nothing
else. The key to good specifications is simply good reviews.

I do not really want to be involved in a high-level discussion whether
formalized notations, semi-formal notations, or plain English
notations are most useful and I hope we can avoid getting into such a
discussion to save us all time and bandwidth. I suggest that the WGs
and people actually involved in a given protocol take this decision.
Personally, I happen to believe that the scale in terms of the number
of definitions you have to handle determines whether machine readable
definitions are worth the extra formalization efforts.

In the case of NETCONF, it is important to allow operators to quickly
and easily understand what configuration knobs exist on their devices,
what they mean and how to turn them. A common notation is needed for
that so that SDOs, vendors, and operators have a common language to
work with. In order to deal with the large number of knobs you find on
today's devices, I believe that a formalized notation is well worth
the effort.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 28 Nov 2007 13:28:55 +0100

Lisa,

As Juergen has pointed, we differentiate in the OPS area between
information model and data model. I believe that much of what you say
about ontology and data model in English actually relates to what we
call information models. There was an effort to start a new information
model (nim) in the IETF, we had a BOF some time ago, but the general
feeling was that the endeavor is too big, the field too dynamic, and
other SDOs may be better places for IM definition. The approach that you
see today which starts with the definition of a data modeling language
and uses it to perform a one step modeling resulting in an interoperable
data structure is the result of accumulating experience and a few basic
requirements derived from the needs of the operators performing network
management operations - scalability, extensibility, machine readable and
yet human comprehensible format, interoperability between different
vendors agents and managers, form factor that allows rather complex and
large configuration data bases to run or relatively resource challenged
devices. 

Dan

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]] 
> Sent: Tuesday, November 27, 2007 9:54 PM
> To: [email-masked]
> Cc: [email-masked]; Leif Johansson
> Subject: Re: analysis of YANG vs. RELAX NG
> 
> ontology) not enough?  The question of needing a standard 
> data model must be separated from the need for a custom 
> modeling language.  Some of the justifications I've seen so 
> far for a modeling language have really been justifying only 
> a standard data model.
> 
> Of course using XML as the data format doesn't, by itself, 
> give enough of a common data model for 3rd-party NetConf 
> tools to understand arbitrary data.  NetConf probably does 
> need a common data model, perhaps defining how IDs are 
> expressed and what a container is, what is a netconf "object" 
> that can be operated on.
> 
> language at all.  Put it differently: a sufficiently strong 
> common data model can work with multiple modeling languages 
> without harming interoperability.  Thus, having a standard 
> data model that is independent of the modeling language can 
> be a real win for clarity and robustness and somewhat more 
> proof against changing stylistic preferences.
> 
> The commonest approach for IETF protocols that deal with an 
> ontology is to define the data model in English, limiting the 
> ways the data can be expressed to something that becomes 
> essentially self- describing (the name of a new thing/object, 
> and its contents or value, can be derived from the document 
> without seeing a specific schema).  LDAP is one of the 
> clearest examples of this.  An LDAP agent can handle custom 
> content because it follows the expected data model. There's 
> no need, in LDAP, for a special language to describe new 
> attributes.  The iCalendar and vCard formats are the same.  
> SNMP is really different in having a special language to 
> learn, and using that in specs.
> 
> My experience with description languages or other 
> formalizations is that these often take the place of proper 
> specification.  Authors think that they are done when they've 
> written the code that describes the format.  However, the 
> most important aspect to a new standard schema is usually 
> what it *means*.
> 
> Lisa
> 
> >> While I am as happy as the next guy that we won't be 
> seeing RFCs with 
> >> XMI in them anytime soon I am curious as to why something like OWL 
> >> isn't a strong candidate for something like this. Is it just 
> >> "anti-XML"

---

From: Leif Johansson <[email-masked]>
Date: Wed, 28 Nov 2007 14:16:01 +0100

> schema is usually what it *means*.
I could not agree more. A formal language *can* make the specification
more precise
and less readable (and useful) at the same time.

Having said that I've found that using formal languages for ontologies
can help, especially
if you actually plan on producing "stuff" from the ontology (code for
instance). I don't
think MIBs would be very useful if they were written in English :-)

    Cheers Leif

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 28 Nov 2007 14:22:21 +0100

> From: Leif Johansson [mailto:[email-masked]] 
> Sent: Wednesday, November 28, 2007 3:16 PM
> To: Lisa Dusseault
> Cc: [email-masked]
> I could not agree more. A formal language *can* make the 
> specification more precise and less readable (and useful) at 
> the same time.
> 
> Having said that I've found that using formal languages for 
> ontologies can help, especially if you actually plan on 
> producing "stuff" from the ontology (code for instance). I 
> don't think MIBs would be very useful if they were written in 
> English :-)
> 
>     Cheers Leif
> 

Well, actually the common practice is that MIBs take a mid-way approach
using a formal data language and plain English DESCRIPTION clauses
associated with the definition of each object. 

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Nov 2007 14:57:01 +0100 (CET)

Hi,

> > > is not expressive enough and Relax is too expressive.

[...]

> don't think you need to define a new schema language to do this.

Right.  I think we say that in the draft as well.  This can absolutely
be done, but for the reasons we have listed in the draft and in this
email thread so far, we think a better solution is to use a domain
specific language.  Note that YANG is not a XML schema language.  A
RelaxNG or XSD schema can be used to validate the NETCONF XML encoding
of the data, operations and notifications described in YANG modules.
(actually, you'd typically need more than one schema, depending on
which NETCONF operation you're validating - these can be generated by
the tools and fed into the XML parsers).

> whether you write a whole new language or not.

Absolutely.  This work has to be done anyway.

> argument is orthogonal to our main topic.

Yes.

/martin

---

From: Jon Saperia <[email-masked]>
Date: Wed, 28 Nov 2007 09:16:01 -0500

On Nov 28, 2007, at 3:38 AM, Juergen Schoenwaelder wrote:

>> ontology) not
>> enough of a
>> language at
>> ontology is to

Juergen, there is one additional point/requirement for a solution  
related to the number of objects you suggest.  That is the rate of  
change, not be the standards body, in this case since we are talking  
about configuration information, but by the vendors.  With each new  
technology, hardware platform, software revision and potentially  
firmware revision, a vendor will need to modify the 'knobs'.  This is  
where the formalized notation in my view has a strong payback.
> /js

Thanks,
/jon
----
Jon Saperia
[email-masked]
(mobil)	617-201-2655
(office)	978-461-0249

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 28 Nov 2007 15:42:02 +0100

Hello,
Ericsson uses it"s own formalized language (which we would like to change to a standard 
solution) to automatically
- generate code
- generate html documentation in a strict Ericsson-format
- do semantic checks
- provide standard interface description e.g. LDAP schema files, Corba IDLs

Doing all this without a precise formal language would be near impossible.

Balazs

Jon Saperia wrote:
>>> is to 
> [email-masked] <mailto:[email-masked]>
> (mobil) 617-201-2655
> (office) 978-461-0249
> 
> 
> 

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

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 28 Nov 2007 17:04:36 +0100

Hello,
I am no expert in RelaxNg but here are some thoughts why I like Yang better.

I have the feeling once you extend RelaxNg with all the necessary bits, half your statements 
will start with <other:xxx>.

There are many aspects that can be somewhat tricky and/or simply time consuming, and are 
missing from RelaxNg:
- what does a default mean for configuration data
- what is considered a compatible or incompatible change
- ordering of items within list, leaf-lists
- netconf edit-config semantics
- differentiating between configuration and operational data
- differentiating between RPCs, notifications and data containers (in YANG you have separate 
statements)
- connecting RPC request definitions with RPC reply definitions
- definition of more complex types (IpAddress, MacAddress, ZeroBasedCounter, etc.). Nothing 
special but work to do even for RelaxNg
- Netconf specific error messages

Certainly all these can be done as extensions to RelaxNg as well, but even after taking RelaxNg 
as your base, you still have a big work to do. And once your specification is complete you need 
to build custom tools to understand the <other:xxx> statements. (For YANG we already have 
tools. see http://www.yang-central.org/twiki/bin/view/Main/YangTools)

--------------------------------------------------------------------------------------------

For NETCONF readability by operators, untrained in modeling languages, is a crucial 
requirement. The question is after how many hours (not days) of training can an operator grok a 
YANG model or a RelaxNg model? I feel YANG is easier.

One important advantage of YANG is that the number of features in YANG is much smaller then in 
RelaxNg. If we would count the number of features excluding stuff that is missing from RelaxNg, 
   the difference would become even more pronounced.

Generally YANG uses the terminology that network management people are familiar with e.g. 
container, augment, configuration data. Learning the RelaxNg terminology takes time.

In the network management world there is a general dislike for so called "little rules". Things 
like
- you can use RelaxNg but don't use attributes
- you can use RelaxNg but don't use mixed pattern
- you can use RelaxNg but don't redefine or remove patterns

With RelaxNg we will need a number of such rules. With a problem specific solution - YANG - 
the number of such rules is minimal.

Balazs

Rohan Mahy wrote:
> Hi Martin,
> 
> More comments inline.
> 
> On Nov 27, 2007 4:03 AM, Martin Bjorklund <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     "Rohan Mahy" <[email-masked] <mailto:[email-masked]>> wrote:
[BALAZS]: Relax can say a number of things we don't need, but can't say a number of other 
things we do. If you have thousands of words for ice cream but no words for colors then your 
language is too big and too small at the same time.
> mixed content. Defining a set of templates in Relax would make it very 
> clear how the new data should be organized, and is very easy for readers 
> to parse and validate with boatloads of existing tools.  Most netconf 
> implementors will already have an XML parser that will automatically 
> validate against either XSD or Relax schema.
>  
> 
> allows arbitrary annotations in other namespaces, and these annotations 
> can have semantic meaning.  Rather than define a whole new syntax as 
> well, I am much more comfortable defining additional semantics layered 
> on top of an existing schema which validates the syntax.
>  
> 
> gets). If you want additional semantic checking, you will define those 
> rules whether you write a whole new language or not.
>  
> 
> In RAI we had some rather painful experience with referencing keys in 
> XCAP (RFC 4825) which also uses XPath expressions to point at subparts 
> or subtrees of an XML document. You can certainly maintain a unique key 
> within a list which is not generated from the data in each record.  Not 
> doing so "won't scale and would be very difficult to maintain".  
> However, this argument is orthogonal to our main topic.
>  
> 
> I was not clear exactly the significance of "module foo" and "module 
> bar".  If I understood correctly, module foo defines the "my-rpc" RPC 
> call, and module bar just extends the response.  I will call these " 
> my-rpc.rng" and  "my-rpc-extension1.rng" respectively.
> 
> 
> <!-- my-rpc.rng  -->
> Note that I used a Relax annotation to convey extra semantic data.  This 
> is ignored during relax syntax validation, but available to the 
> implementation if it wants to use this additional semantic information.  
> An example of this is described in the book in chapter 13.3: 
> <http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt>
> 
> very nicely: 
> http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html 
> <http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html>
> 
> thanks,
> -rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 28 Nov 2007 10:25:50 -0800

Hi,

Comments inline.

> will start with <other:xxx>.

We will never know unless we try the exercise. It seems you are suggesting
that we don't even try. However, I see a pretty small number of additional
semantic items you list below:
- an indicator of a default value (if any)
- a flag that indicates whether a subtree is atomic for edit-config
- an indicator that the schema is an rpc method and what its matching
request or response is
- a flag that indicates whether a subtree is configuration or operational
data (read-write or read-only).

Setting that aside for a moment, even if half the statements in a schema are
annotation, the other half can still do something very, very useful.  They
can validate the syntax and structure of the XML received on the wire
automatically in a piece of code (the XML parser) that the implementation
probably already has.

If we decided we wanted to build something like YANG, we would still need a
tool to generate valid XSD or Relax from the YANG definitions to turn on
validation in the XML parser.

There are many aspects that can be somewhat tricky and/or simply time
> consuming, and are

These aspects are not *missing* from Relax NG.  Some of these things are not
in the scope of the Relax NG schema, but can be defined as an additional
layer on top of a specific Relax schema.  We can even write schema which
describes what syntax is allowed for these annotations in a
netconf-semantics namespace.

> - what does a default mean for configuration data

this is semantic.

> - what is considered a compatible or incompatible change

I believe I already covered this. Adding an additional choice (adding a new
rpc method), adding via interleave (adding additional data within a
container), and copying and redefining via restriction or addition (reusing
parts of one container for a new container) are all pretty easy.

> - ordering of items within list, leaf-lists

The schema I described preserves ordering.

> - netconf edit-config semantics

semantic

semantic

- differentiating between RPCs, notifications and data containers (in YANG
> you have separate

This is easy to do using pure syntax.  As in my example, to add an RPC
method or response, you just "combine with choice" and you insure that the
method isn't used as a notification or a data container.

> - connecting RPC request definitions with RPC reply definitions

This is semantic.  I provided an example of how to link these.

- definition of more complex types (IpAddress, MacAddress, ZeroBasedCounter,
> etc.). Nothing

To me this strongly motivates using Relax for the syntax. A language to
define new data types has already been invented and it works very well.

If you are talking about error messages sent on the wire, this is a
syntactic issue that Relax can handle out of the box.

> tools. see http://www.yang-central.org/twiki/bin/view/Main/YangTools)

Are you implying that the act of writing, review, and maintaining a brand
new 150 page specification on YANG is not a lot of work?  I am quite sure
that a motivated group could define just the additional semantics in
substantially fewer pages or text, and that there would be many more
participants in the IETF who could make credible comments on it.

I am hardly a Relax expert. I glanced at the Relax tutorial and the the
Relax book for just under two hours in order to start *writing* schema.  I
have shown relax schema to implementors with no previous experience,
explained how define and ref work on the whiteboard for 5 minutes and then
seen working accessors in under an hour.  The W3C, OASIS, OpenGIS and others
are all using Relax for all of its specifications that use XML going
forward. Perhaps you should spend an hour or two and see what you are
missing.

> RelaxNg.

This is a preposterous statement. There is no need for an operator to learn
features of Relax (or XSD even) that they will never use in order to read
and write schema. I do not understand the finer points of <mixed> content. I
don't need to currently and I can easily skip over and ignore these parts of
the spec.

> If we would count the number of features excluding stuff that is missing
> from RelaxNg,

Maybe I have different implementors, but the implementor is more likely to
have some XML experience than to be a "network management person".
Following the principle mentioned in Section 3.1 of
draft-schoenw-sming-lessons-01.txt, the implementor is a "reader" and
simplicity for the reader takes precedence:

   As a consequence, preference should be give to solutions that
   simplify the task of readers.  Reduction of the efforts required by
   writers is of secondary importance and the reduction of the efforts
   required by tool developers is of least important preference.  While
   this perhaps seems obvious, it is at times difficult to take
   according design decisions, especially if the group working on a new
   data modeling language is dominated by tool developers or data model
   writers.

> the number of such rules is minimal.

I disagree. It looks like you have lots of implicit little rules in the YANG
draft. A network management person might have become desensitized to these
rules to the point of not noticing them, but they are there and there are
plenty of them.

thanks,
-rohan

> > <

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Nov 2007 23:02:44 +0100 (CET)

Hi,

> automatically in a piece of code (the XML parser) that the implementation

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.
As one very simple example, suppose we have these in the data model:

   leaf ifAdminStatus {
      config true;
      type ...;
   }
   leaf ifOperStatus {
      config false;
      type ...;
   }

In a <get-config> only ifAdminStatus can occur.  In a <get> both can
occur.  In an <edit-config>, there can be an nc:operation attribute on
the ifAdminStatus, but that attribute cannot be present in a <get>.

> validation in the XML parser.

One such tool is available from www.yang-central.org.  It currently
supports a single XSD output, but adding e.g. RelaxNG should be
possible.  YANG is based on three different vendor-specific languages,
which all three have tools that generate XSD.

Three of the people in the YANG gang have existing NETCONF
implementations.  None of these implementations are actually using XSD
or RelaxNG to do validation in the parser, (partly) for the reasons
listed above.

[...]

> layer on top of a specific Relax schema.

In my experience, people who design data models for device
configuration and monitoring do not typically think in terms of
patterns which match an XML instance document.  Instead they might
think in terms of objects with certain attributes, operations and
notifications, or in terms of a hierarchical structure of config
parameters.  From an operator perspective I also believe (although I
don't really know) that it's more common to think about which config
parameters can be set, than which patterns might match some virtual
XML instance document.  Thus, IMO a domain specific language with
a smaller semantic gap between the language and how people think about
and understand the problem will be more appropriate.

/martin

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 28 Nov 2007 14:43:45 -0800

Hi Martin,

> the ifAdminStatus, but that attribute cannot be present in a <get>.

You can express this very easily like this:

<define name="get-config" combine="interleave">
  <ref name="ifAdminStatus"/>
</define>

<define name="get" combine="interleave">
  <ref name="ifAdminStatus"/>
</define>

<define name="get" combine="interleave">
  <ref name="ifOperStatus"/>
</define>

or in short form:

get-config &= ifAdminStatus
get &= ifAdminStatus
get &= ifOperStatus

thanks,
-rohan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2007 23:56:52 +0100

> get-config &= ifAdminStatus

You are suggesting to extend the definition of the NETCONF operations
get, get-config, edit-config etc. for every possible data item they
might carry?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Nov 2007 23:57:50 +0100 (CET)

Hi,

> get-config &= ifAdminStatus

But then you also have edit-config, where the nc:operation attribute
has to be added for ifAdminStatus, and you have copy-config where the
attribute must not be added.  So you would have to explicitly add each
leaf to these four rpcs...?  And I'm not even sure this approach would
work for deep structures, where some leafs are config and some are
not:
  
  container interfaces {
    leaf ifNumber { config false; type int32; }
    list interface {
      key ifIndex;
      leaf ifIndex { type uint32; }
      leaf ifAdminStatus { config true; ... }
      leaf ifOperStatus  { config false; ... }
      ...
    }
  }

/martin

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 28 Nov 2007 15:34:06 -0800

This is another aspect I'd like to understand better:

> 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?

thanks,
lisa

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 28 Nov 2007 17:31:56 -0800

Hi Juergen,

> get, get-config, edit-config etc. for every possible data item they

I am suggesting that an implementation "extend" the definition of each
netconf operation to include each top-level data item they actually
understand and use.  I hope you see the distinction.

thanks,
-rohan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Nov 2007 08:53:09 +0100

> understand and use.  I hope you see the distinction.

The phrase "implementation 'extend' the definition" sounds to me like
there is some little tool taking a data model and turning it into
something you can use for validation. But then it might also be the
case that I do not really understand the distinction you are trying to
make.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Nov 2007 09:16:00 +0100

On Wed, Nov 28, 2007 at 03:34:06PM -0800, Lisa Dusseault wrote:
> 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?

The point Martin and Any were trying to make is that validation
against a schema within a NETCONF implementation does not make too
much sense; you have to validate the data exchanged against the
datastore. And the implementations we are aware of do this without
using generix XML schema validators.

And yes, since we are talking about configuration, we do expect that
easy support for vendor extensions is crucial.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 29 Nov 2007 10:17:24 +0100

Hello Rohan,
Thanks for your response. Here are some replies.
Balazs

Rohan Mahy wrote:
...
> These aspects are not *missing* from Relax NG.  Some of these things are 
> not in the scope of the Relax NG schema, but can be defined as an 
> additional layer on top of a specific Relax schema.  
[BALAZS]: Yes but if you need to extend RelaxNg, you loose much/most of the advantage of using 
a standard language. As we agreed all the extensions will need custom tools. These tools are 
already available for Yang, but not for RelaxNg. The experience with SNMP/SMI tools in the last 
decades also tells us that at the end nearly all SNMP tools were custom built and not based on 
standard ASN.1 tools. So the gain of following the standard is even more limited.
> We can even write 
> schema which describes what syntax is allowed for these annotations in a 
[BALAZS]: Yes, you recognized one of our main points: NETCONF needs semantics and processing 
rules. These have to be defined. Current schema languages don really do this. Thats one of our 
reasons to do YANG.
A quote from the book RelaxNg by Eric van der List you recommended:

"XML reintroduces a clean separation between data and processing. "

However Netconf does need rules about processing, so RelaxNg is not enough for us. We can 
reintroduce processing hints into RelaxNg, but is that still RelaxNg. Processing features 
needed include:
- handling semantics of NETCONF edit-config
- the meaning of default data for operational and configuration data
- ordering of list data
- automatic creation of some data (containers)
- placement of data in normal structures, notifications or RPCs
- others ???

> 
> Maybe I have different implementors, but the implementor is more likely 
> to have some XML experience than to be a "network management person".  
[BALAZS]: Yes as the above quote says it is NOT the implementors but the readers i.e. network 
operators that are important. I think they are much more familiar with the concept of a managed 
object or a list then "Pattern Compositions".

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 29 Nov 2007 10:48:08 +0100

Hello Rohan,

Rohan Mahy wrote:
> On Nov 28, 2007 8:04 AM, Balazs Lengyel <[email-masked] 
> 
> We will never know unless we try the exercise. It seems you are 
> suggesting that we don't even try. 

[BALAZS]: Your question is very valid, but it has some costs. A serious effort to bring the 
RelaxNg based solution to todays level in Yang would cost according to my guess at least 500 
manhours. After this we might still conclude that a domain specific effort (YANG) is better. 
Are you willing to get involved and invest 2 months (possibly more) of dedicated work?

regards Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 29 Nov 2007 10:56:57 +0100

Hello Rohan,
Some questions/answers below.
Balazs

Rohan Mahy wrote:
> <mailto:[email-masked]>> wrote:
> 
>     Hello,
> We will never know unless we try the exercise. It seems you are However, I see a pretty small number
> of additional semantic items you list below:
> - a flag that indicates whether a subtree is configuration or 
> operational data (read-write or read-only).
[BALAZS]: Please add
- what does a default value mean for operation data?
- a flag stating if a part of configuration is current, deprecated, obsolete
- a flag indicating if a bit of writable data is stored in non-volatile storage
- information indicating whether the sort order in a list is set by the user or the managed system
- a number of documentation options. And it is not enough to just say documentation, we need 
separate tags/elements for description, contact, revision info etc.
- enterprise specific extensions, do you need to define them or just use them
- formal descriptions of constraint e.g. if encryption method is non-null then we need a password
- references between different parts of the model e.g. this subscriber should use XXX 
application server. And simple ID based referencing is not enough as I want to state that here 
you can only reference application servers but not DNS servers.
- how do you handle data models with multiple roots, that are not well formed XML. (This is a 
current, existing customer demand not a theoretical question.)
- how do you refer to managed object instances e.g. a the observed speed of interface eth0
- etc.

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 29 Nov 2007 11:11:45 +0100

Hello Rohan,
Further comments below.
regards Balazs

Rohan Mahy wrote:

> I believe I already covered this. Adding an additional choice (adding a 
> new rpc method), adding via interleave (adding additional data within a 
> container), and copying and redefining via restriction or addition 
> (reusing parts of one container for a new container) are all pretty easy.
[BALAZS]: So if I change the default value of a leaf/attribute is that compatible? Do I have to 
rename my model in this case? If I extend/restrict the value range of a variable is that 
compatible?
I see a number of questions here that are not obvious for me. I feel they need work.
> The schema I described preserves ordering.
[BALAZS]: Yes but is that the order in which the user inputs the leafs, or some order defined 
by the system? If it is user defined how do you insert in the middle.  For me your answer is 
not complete. As we say in Hungary: "The devil lurks in the details. And there are many little 
devils still hiding here.
> method or response, you just "combine with choice" and you insure that 
> the method isn't used as a notification or a data container.
[BALAZS]: yes but more work
> syntactic issue that Relax can handle out of the box.
[BALAZS]: I mean questions like what will be the content of the <error-app-tag> NETCONF element 
be on the wire, if the uniqueness constraint on interface names is violated? By the way how do 
you declare it in RelaxNg that interface names must be unique?
> This is a preposterous statement. There is no need for an operator to 
> learn features of Relax (or XSD even) that they will never use in order 
> to read and write schema. 
[BALAZS]: I agree that there is no need to learn RelaxNg fully. But there are some dangerous 
constructs in RelaxNg that they need to understand e.g. like redefining patterns. Or is this 
not a problem?
> I disagree. It looks like you have lots of implicit little rules in the 
> YANG draft. A network management person might have become desensitized 
> to these rules to the point of not noticing them, but they are there and 
> there are plenty of them.
>
[BALAZS]: Could you please list YANG's  implicit little rules. We will try to remove as many as 
possible.

regards Balazs

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 29 Nov 2007 08:24:15 -0800

Hi Juergen,

If you want to do strict validation of things like RPC methods on the
receiving implementation, the implementation can contain a list of all the
RPC methods it supports (an effective schema). If this level of validation
is not desired, we can ignore this concept.

thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 29 Nov 2007 08:30:08 -0800

Hi Balazs,

I don't think anyone is suggesting spending 3 months of full time effort
trying something to see if it works, but I think spending a few days is a
reasonable cost to invest.  By comparison, the YANG team is asking the IETF
community and the full IESG to review and possibly comment on their work to
the tune of dozens or hundreds of man-hours of work.

thanks,
-rohan

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 29 Nov 2007 17:39:48 +0100

Hello Rohan,
See inline.

Rohan Mahy wrote:
> trying something to see if it works, but I think spending a few days is 
> a reasonable cost to invest.  
[BALAZS]: It might look unreasonable, but I think sadly that is the real cost. There ARE so 
many little details to check.
> By comparison, the YANG team is asking the 
> IETF community and the full IESG to review and possibly comment on their 
> work to the tune of dozens or hundreds of man-hours of work.
[BALAZS]: True. Is there any alternative?
> 
> thanks,
> -rohan
> 
> On Nov 29, 2007 1:48 AM, Balazs Lengyel <[email-masked] 
>      > On Nov 28, 2007 8:04 AM, Balazs Lengyel
>     <[email-masked] <mailto:[email-masked]>
>      >
>      >>     I have the feeling once you extend RelaxNg with all the
>     necessary
>      >>     bits, half your statements

---

From: Phil Shafer <[email-masked]>
Date: Thu, 29 Nov 2007 11:48:34 -0500

>is not desired, we can ignore this concept.

The issue isn't validation of the messages, but validation of the
NETCONF datastore.  We want to be modeling the data inside the NETCONF
datastore, thinking more in terms of the object instances than the
xml content being sent over the wire.  XSD and RNG model the syntax of
the xml content, not the semantics of the databases that NETCONF is
building.

If I say that a particular node is mandatory in the datastore, I'm not
saying that it must appear in every XML RPC that's manipulating the
datastore.  If <b> is a mandatory leaf under <a>, I can perform an RPC
that creates <c> under <a> without that RPC containing <b>.  The
validation tests are only meaningful to the complete data contents,
not for individual RPCs.  The constraints imposed by the YANG module
definition must be complied with to have a valid configuration
datastore, but do not apply to each <edit-config> operation.

The semantics YANG provides are also important for defining the
operations that are available over NETCONF.  For example, when the
order of entries in a list are maintained in an order defined by the
user, you use YANG's "ordered-by user" statement to indicate that the
list entries can be modified using the "insert" attribute.  And saying
that a container is operational data (rather than configuration) tells
me that this container will be in the output of a suitable <get> RPC,
within the proper hierarchy and keys defined in the YANG module.

With YANG, I don't need distinct schemas to describe the scenarios
where I traffic my YANG module's data, if I drive my validation from a
YANG-enabled parser.  But I can derive those schemas from my YANG
module as needed.

In many respects, YANG is similar to the approach of WSDL and WADL,
which puts high-level concepts in specific high-level statements, but
allows easy translation to XML schema languages.  You can think of
YANG as an IDL for NETCONF, but it does considerably more, in terms of
modeling the configuration.

Thanks,
 Phil

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 29 Nov 2007 11:00:55 -0800

> "XML reintroduces a clean separation between data and processing. "

yes

However Netconf does need rules about processing,

yes

> so RelaxNg is not enough for us.

This does not logically follow.  You need chocolate and you need peanut
butter, but it does not follow logically that you need a Reese's Peanut
Butter Cup.

I am proposing that you could combine syntax and semantics, or you can layer
one on top of the other. Right now YANG is neither pure semantics, nor pure
syntax. For example the distinction between the leaf-list and list objects
in YANG is pretty syntactic. (One of the YANG team's "little-rules").
Likewise, creating containers automatically is a syntactic construction.
(Another "little-rule", but at least this one is explicit). Defining new
data types in YANG is completely gratuitous syntax.

I think having semantics for configuration information in general would be a
boon for the IETF, as we have several protocol that are used for
configuration.  Providing a way to describe semantics of common
configuration concepts like default values, list keys, constraints among
non-parent-child objects, all looks like great work to me, but I don't want
to this so tied to NETCONF that I cannot use it elsewhere for other
configuration data.

I also don't want this rigidly attached to a specific syntax either.  A lot
of existing XML-based data formats use attributes extensively. Some
XML-based languages (ex: GML) implement the equivalent of leaf-list using a
single attribute with whitespace separated values (there is even a built-in
data type (called "list") to handle this case).

thanks,
-rohan

We can

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 29 Nov 2007 11:28:42 -0800

Hi -

> From: "Rohan Mahy" <[email-masked]>
> To: "Balazs Lengyel" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, November 29, 2007 11:00 AM
...
> to this so tied to NETCONF that I cannot use it elsewhere for other

This is an admirable goal, but those of us who survived the GDMO / SMI
wars have good reason to be wary here.  Even something as simple
as parent-child constraints can play out in protocol-specific ways.  It
might be nice in theory to have one language for everything, but there are
good reasons why C displaced PL/1, and why attempts to use the SMI
with CMIP, or GDMO with SNMP, never achieved much traction in the
marketplace.

Part of the problem is the risk that a language sufficiently expressive to
define any legal model in all the protocol environments will be able
to define models which will be broken in at least one of the protocol
environments.  (Consider the conflict, both syntactic and semantic,
between SMI's "INDEX" and GDMO "NAME-BINDING", even though
their purpose is the same, both from an information model and from
a data model perspective.)

...

If the data modeling language doesn't let us know unambiguously how
things can show up on the wire, there's not much point, in my opinion.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Nov 2007 21:06:04 +0100

> data types in YANG is completely gratuitous syntax.

Perhaps it helps me if you can define what you consider syntactic and
what semantic. Having your definition will help me to understand what
you have in mind and where you draw the line.

I must note that types have been extremely successful in terms of
actual reuse in the SMI world. You may consider data types "gratuitous
syntax" but they are damn useful from our experience in writing data
models.
 
> I think having semantics for configuration information in general
> would be a boon for the IETF, as we have several protocol that are
> used for configuration.  Providing a way to describe semantics of
> common configuration concepts like default values, list keys,
> constraints among non-parent-child objects, all looks like great
> work to me, but I don't want to this so tied to NETCONF that I
> cannot use it elsewhere for other configuration data.
>
> I also don't want this rigidly attached to a specific syntax either.
> A lot of existing XML-based data formats use attributes
> extensively. Some XML-based languages (ex: GML) implement the
> equivalent of leaf-list using a single attribute with whitespace
> separated values (there is even a built-in data type (called "list")
> to handle this case).

There are specific reasons why YANG does not support white space
separated lists. I am sure Phil is happy to tell you how much fun
these white space separated values can be and why we prefer to have
every value within its own element in an instance document. (Well,
actually even RFC 4741 states that subtree filtering on list content
and mixed content is not supported.)

I have been involved in a project where we tried to develop a data
modelling language (called SMIng) that is protocol independent. From
this experience, I have serious doubts that semantics decoupled from
syntax will work anytime soon. There are relative obvious issues where
for example the underlying naming system impacts the way you can
formulate expressions.  And then there are issues that only pop up
once you really do it in practice, e.g. dealing with exceptions or
errors. (In YANG, you can say that a violation of a given constraint
leads to a specific NETCONF error report. Once you all do this in a
decoupled semantics layer, you end up having to abstract the
error/exception reporting mechanisms, which in my experience does not
make the result necessarily easier to use). My personal eye opener in
the SMIng project happened when started to move from toy examples to
model something of moderate complexity (we picked DiffServ at that
time because it actually has a nice informal information model plus a
MIB module which does supports configuration).

But don't get me wrong, I do not want to discourage anyone from trying
it - perhaps there are people who can solve this challenge. My only
concern is that it will take years to get it done with no clear signs
upfront that it will actually work. The YANG mission is much less
ambitious and down to earth, simply driven by the goal to create a
vendor independent domain specific data modeling languages that can
replace proprietary solutions that have already been created.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Nov 2007 20:38:49 +0100 (CET)

Hi,

I really appreciate your comments on the YANG draft.  If there are
other little rules you have found, please let us know.

"Rohan Mahy" <[email-masked]> wrote:
> For example the distinction between the leaf-list and list objects

I can understand if you argue that leaf-list is not necessary, since
we have list.  But why is having leaf-list a little-rule?

We think leaf-list is useful of course, but that's not the point (I
think).

> (Another "little-rule", but at least this one is explicit).

I think that this is something we can fix.  I think the problem lies
more in the current description of the concept (of containers used for
structuring purpose), than in the concept itself.  The underlying idea
is that if a container is used for structural purposes only, then it
doesn't have to be present in the XML encoding unless necessary.
I.e. if it currently doesn't have any children, then it doesn't have
to be encoded.

> Defining new data types in YANG is completely gratuitous syntax.

I'm sorry, I don't understand what this means. Could you explain what
you mean?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Nov 2007 11:56:03 -0800

> I'm sorry, I don't understand what this means. Could you explain what

I am confused by this as well.
I think this means the extra types in YANG that are
not in RNG.  They are mostly NETCONF-specific, or
at least NM-specific.

The choice of builtin types is somewhat subjective.
Some of the 'extra' types could be derived types instead.

Almost all types could just be 'string', and we don't
need to bother with any data-typing at all.  Indeed,
that is a choice the data model writer could make, although
IMO it is bad SW design.

> /martin

Andy