Subject: [netmod] container netconf

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Dec 2008 16:20:14 -0800

Hi,

I was just looking at netconf-state.yang
and then I looked at notifications.yang.

They both define a top-level <netconf> container.
One of them defines it 'config true' and the other one
defines it 'config false'.

I know it is early for real data models and all,
but notifications is a standards track RFC,
so it must be right ;-)

Every NETCONF model (rooted under /netconf) is going
to have to augment the notifications data model.
That doesn't seem very clean, but multiple /netconf containers
in different XML namespaces is even worse.

Suggestions to clean this mess up before it starts?

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Dec 2008 09:57:15 +0100 (CET)

> Suggestions to clean this mess up before it starts?

That would be nice, and I believe that Sharon's intention has always
been to have a single 'netconf' container.

However, we're sort of stuck with the limitations of XSD.  YANG is
designed to handle this situation, but the YANG models are
non-normative.

Assuming we cannot change the structure of the data model in the
notification RFC, and that we want one single 'netconf' container, it
would have to be called:

   {urn:ietf:params:xml:ns:netmod:notification}netconf

which is not optimal...

Anyway, here are a few alternatives:

  1)  Add a substitionGroup to the 'netconf' element, as an errata to
      rfc 5277.   The monitoring schema would then use this
      substitionGroup.

  2)  As an errata to 5277, add text that explains that the XSD is
      supposed to be completely open (<openContent> in XSD 1.1)  The
      monitoring schema would then have text that explains that the
      contents would go under the
      {urn:ietf:params:xml:ns:netmod:notification}netconf element.

  3)  Live with it, and do better next time.  Maybe as soon as in the
      monitoring spec - it could define a simple schema / YANG module
      with a single 'netconf' container in a generic namespace, and
      then augment this container with the monitoring stuff.   When we
      do the third data model for netconf, we will then have this
      'netconf' container element in place.

But there are still a couple of unanswered questions - should we have
one 'netconf' container for config and one for operational data?  If
we have one single container for both kinds, should we have two
distinct subtrees underneath that one?

/martin