Subject: [NGO] NETCONF Data Modeling "Rules"

From: Andy Bierman <[email-masked]>
Date: Fri, 25 May 2007 09:03:23 -0700

Hi,

I thought I would kick up some dust by asking if
there is any consensus that NETCONF Configuration Databases
should be restricted by some data modeling rules.
Currently, any valid XML (w/ restrictions specified in RFC 4741)
is allowed in the <config> contents.

Some implementers (myself included) have found that certain
practices are "more complicated than worth doing", and since
the DM choice is up to the vendor, there may not be any need
for restrictions.

Here are the Top 5 restrictions I would make if I wanted
to simplify NETCONF Data Modeling:

  - use of writable XML attributes inside config data elements not allowed

  - use of unnamed data (no key defined and "maxOccurs > 1" is true)
    not allowed

  - use of keyed data without a container not allowed
    (e.g., /interface[ifIndex=1] instead of 
/interfaces/interface[ifIndex=1])

  - 1 top-level element (child of <config>) per namespace allowed

  - each top-level element must be a container node
    - a container must have complex content, not simple content
    - zero or one instance of a container is allowed

I am not going to go into the implementation details.
(You saw some of if wrt/ edit-config on the 'any' data type).
I actually support most of these things in my code, but IMO
the complexity isn't worth it.

So are these restrictions a good idea or just more CLRs?
I think we are already following these restrictions in
the Notifications draft data models.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 27 May 2007 21:12:37 +0200 (CEST)

Hi,

> Currently, any valid XML (w/ restrictions specified in RFC 4741)

What are those restrictions (where are they specified)?

>   - use of writable XML attributes inside config data elements not allowed

This one doesn't necessarily make implementations simpler.  I think
this rule follows from the recommendation that attributes should
contain meta-data (like owner, last-updated etc).

>   - use of unnamed data (no key defined and "maxOccurs > 1" is true)

As you say we have discussed this one before.  IMO this rule is
necessary in order for <edit-config> to work.  You could argue that
it's useful w/o keys if the object is "small", but how do you define
"small"?  This special rule probably just makes things more
complicated.

> /interfaces/interface[ifIndex=1])

I don't see how that makes things simpler.

>   - 1 top-level element (child of <config>) per namespace allowed

We (in our agent) started out with that restriction, but it feels like
a CLR and it's difficult to motivate.  So we now support multiple
top-level elements.  XSD and RelaxNG support it.  Why should we make
this restriction?

>     - zero or one instance of a container is allowed

This probably makes sense.  So you wouldn't be allowed to define a
single leaf as top-level node?

> the Notifications draft data models.

I think that the most important rule is _not_ followed in the
Notifications draft - the NamedProfile does not have a key.  (See my
earlier comments for details).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 May 2007 07:16:34 -0700

> What are those restrictions (where are they specified)?

no mixed XML, no DTDs; I forget the section #

> contain meta-data (like owner, last-updated etc).

Merge and rollback of only attribute merges in interior nodes
is special-case code.  IMO, not worth the trouble, but not impossible.

> "small"?  This special rule probably just makes things more

Unnamed data is technically data named by its relative position
among the set of instances of the element.  As you pointed out,
it is impossible to use edit-config to identify a specific
instance for deletion or editing (e.g., /foo[3] has no analog
in subtree filtering)

If multiple unnamed instances are allowed, then 'merge' never works as intended.
It always adds a new instance instead of changing the old one.

So unnamed data is okay to use if you don't want to use edit-config
on that data.

> I don't see how that makes things simpler.

Just a data organization thing.
Perhaps a SHOULD instead of a MUST.

> top-level elements.  XSD and RelaxNG support it.  Why should we make

You are probably right.
It is better not to make any rules about namespace usage.
An ad-hoc, organizational train-wreck has worked so far ;-)

> single leaf as top-level node?

Just a data organization thing and avoiding a subtree-filtering corner case.
Data organization never looks like a problem when the data pool size is '3'.

> earlier comments for details).

This is just one of the bugs that needs to get fixed in that draft.

Andy