Subject: [YANG] relation to XML PDUs

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Jan 2008 14:22:26 +0100

Hi,

I understand that YANG data models describe entire configuration
datasets, but do they also pose any restrictions to the NETCONF XML
PDUs? For example: the order of children in a YANG model is fixed - does
it mean that the corresponding XML elements in PDUs must appear in the
same order?

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

_______________________________________________
YANG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/yang

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Jan 2008 14:50:54 +0100 (CET)

> it mean that the corresponding XML elements in PDUs must appear in the

Currently we do this, mainly b/c of the requirement to be XSD
compatible, i.e. we want to be able to generate an XSD which can be
used to validate the PDUs.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Jan 2008 08:21:19 -0800

> used to validate the PDUs.

Really?  Where is that documented?

Let's review the NETCONF PDUs so we can stop talking about
schema validation in high altitude abstractions.  I don't care about
abstract requirements, I care about running code.

There are 3 types of parameters for RPC operations:

  1) XML represents RPC parameter abstractions (e.g., error-option)
     XSD can validate these RPCs fine.

  2) XML represents subtree filter parameters
     XSD cannot do anything with this.  There are no requirements
     except well formed XML.  Unknown namespaces and elements
     are just 'no-match' conditions, not errors.

  3) XML represents config database fragment
     XSD cannot do much with this unless minOccurs=0 is set for
     every element and the NETCONF operation attribute is added
     everywhere it is allowed.  I have never seen an XSD that
     actually does this.  Instead they all model the config-database
     representation, not any particular PDU.

The <edit-config> and <copy-config> operations allow arbitrary subsets of
config data to be sent in a given PDU, with an almost infinite
number of permutations. A subset of those permutations will
actually be valid for a given data model.   Since YANG models
the data, not the XML, the number of 'extra' permutations in
a YANG schema can be reduced to almost zero.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Jan 2008 18:46:01 +0100 (CET)

> Really?  Where is that documented?

In the XML Encoding Rules section of the container statetement (and
same for list statement).

> schema validation in high altitude abstractions.

[...]

>      representation, not any particular PDU.

I'm not protesting here.  So if they do model the config-database
representation, is the order important in this config-database?  Is
the NETCONF server supposed to keep an XML instance document
representation of the config database, with all elements in order?
This sounds like vendor-specific internals...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Jan 2008 10:11:52 -0800

> This sounds like vendor-specific internals...

OK -- IMO it is bad to force data model order in NETCONF PDUs.
SNMP does not do this for varbinds.  It is hard enough on applications
just to get every node right, let alone the order of every node.

This also goes for RPC methods.
Since every RPC method parameter is clearly identified, and an <rpc>
is self-contained, there is no need to force any particular
element order in an <rpc> PDU.

But there is still a canonical order (for diff purposes) that
is defined as document order.

For 'bits' elements, the canonical order of bit names in PDUs
is also defined as document order, with all duplicates removed.

Andy