Subject: subelements

From: Johan Rydberg <[email-masked]>
Date: Fri, 08 Jun 2007 16:50:12 +0200

While working on my data model I encountered a small design problem, and
decided to look what NETCONF normally do in these situations.  This made
me think about a thing that I've always thought was odd:

Why are configurations named with an subelements of <source> or <target>
and not text payload of the element?  This should make it impossible to
have a configuration named "config", for example.

What is the standard way of refering to units in NETCONF? via named
subelements, via reference elements (<store-ref name="running"/>) or via
text?  What was the idea and reason behind using named subelements for
the wire protocol?

Or is the idea that if you want more configurations than those the RFC
mention (running, startup, candidate) you must implement the URL
capability?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Jun 2007 17:32:30 -0400

>have a configuration named "config", for example.

I think you have it backwards, or I'm misunderstanding you.

By using named subelements, we allow extensibility such as:

  <source>
    <divine-inspiration xmlns="http://di.example.net"/>
  </source>

and:

  <source>
    <mythology xmlns="http://myth.example.net">greek</mythology>
  </source>

or even:

  <source>
    <file>config</file>
  </source>

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 09 Jun 2007 21:17:31 +0200 (CEST)

>     <divine-inspiration xmlns="http://di.example.net"/>

... except that this isn't allowed by the XSD in rfc4741.  Should this
be viewed as a bug in the schema?

(In general I think it's unfortunate that the schema is not more
extensible.)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 09 Jun 2007 16:53:13 -0700

> be viewed as a bug in the schema?

no -- there is no mention in the RFC of this extensibility feature
that does not officially exist.  I remember (way back when ;-)
that Phil convinced us that

  <source><running/></source>

was better than

  <source>running</source>

It had something to do with making it easier to define an XSD
that was a subset of the standard configurations.  I don't see
how it makes this possible without editing the schema, same
as if the 'source' was an enumerated string.

However, I don't mind the parameter the way it is,
even if it is harder to implement than a string.
A choice of N elements is more extensible than
a union of N strings.

> (In general I think it's unfortunate that the schema is not more

We are going to make sure the Notification XSD is properly extensible.
Several people (4?) have requested this and nobody has objected.

I am declaring that WG consensus exists to define NETCONF XSDs
such that they can be properly extended and restricted.

If RFC 4741 is ever republished (highly likely), then I see no
reason why the XSD cannot be altered, if it still describes
the same set of valid instance documents.

(But if the RFC cycles at Proposed Standard, this is not even
a requirement.)

> /martin

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Jun 2007 00:41:41 -0400

Andy Bierman writes:
>that was a subset of the standard configurations.

IIRC, my argument was exactly as above, that using elements
gives us extensibility.  It's unfortunate that the xsd doesn't
reflect this, but my view is that capabilities can extend the
base protocol so this isn't really a problem.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Jun 2007 09:40:17 +0200 (CEST)

> base protocol so this isn't really a problem.

But can you really write a capability which modifies the schema in
rfc4741?

/martin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 12 Jun 2007 16:41:34 -0400

>But can you really write a capability which modifies the schema in

If you can't, the protocol isn't extensible.  If I came up with a
new value for the "operation" attribute, I should be able to define
a capability that defines my new operation.  I can then advertise
that capability and clients that understand it can use it.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Jun 2007 22:43:11 +0200 (CEST)

> that capability and clients that understand it can use it.

Agreed.  I meant from a IETF / process point of view.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jun 2007 14:05:54 -0700

> Agreed.  I meant from a IETF / process point of view.

The issue is extension vs. restriction.
There is no problem advertising a "clean extension".

But let's say (hypothetical) you advertised a capability
that said "I do not support the <lock> operation" and you
also advertise the netconf-base capability that implies you
do support the <lock> operation.   That is not allowed
in the protocol.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 12 Jun 2007 23:54:53 -0400

>do support the <lock> operation.   That is not allowed

Right, because by advertising the base netconf capability, you've
agreed to abide by a set of behavior specified on the capability
definition.  This serves as a contract between the client and server.
If your server don't implement parts of a contract that you advertise,
you've lied and misled the client into performing operations that
may fail in ways the client is not prepared to handle.

Thanks,
 Phil