Subject: Difference between get and get-config

From: Johan Rydberg <[email-masked]>
Date: Wed, 23 May 2007 17:12:14 +0200

What is the difference between get and get-config(running) with the
exception of <get/> returning device state information as well?

--
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: Martin Bjorklund <[email-masked]>
Date: Wed, 23 May 2007 17:24:21 +0200 (CEST)

> exception of <get/> returning device state information as well?

That is the difference.

/martin

---

From: Johan Rydberg <[email-masked]>
Date: Wed, 23 May 2007 17:30:27 +0200

>> exception of <get/> returning device state information as well?

Is this device state information read-only per defintion?  Or is it
possible edit it (via <edit-config/>) if the agent supports the writable
running capability?

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 May 2007 17:35:47 +0200 (CEST)

> possible edit it (via <edit-config/>) if the agent supports the writable

<edit-config> modifies the configuration data only, not the state
data.  So from a <edit-config> perspective, the state data is
read-only.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 May 2007 09:37:36 -0700

> data.  So from a <edit-config> perspective, the state data is

Also, if the non-volatile <startup> config is supported,
then an explicit <copy-config> (from <running> to <startup>) is
needed to update the NV storage contents.  The agent will copy
only the config data (like <get-config>) with this operation.

It may not be clear in the RFC that <copy-config> works the
same way as <get-config>.

If there are read-only 'state' data objects mixed in with
configuration data (in the agent), they are simply skipped
when generating the XML output.  The agent must know somehow
(outside the standard) what to filter out.

> /martin

Andy

---

From: Johan Rydberg <[email-masked]>
Date: Thu, 24 May 2007 13:38:56 +0200

> data.  So from a <edit-config> perspective, the state data is

Is the state data said to be part of the data model?

I'm trying to figure out what happen if the user pipes the data
unmodifed from <get/> to <edit-config(replace)> and stores it in
a configuration store.  As I see it there are three possible
outcomes;

  1. the state data is filtered out.
  2. the config and non-config data is stored in the store.
  3. yields an error.

Also, should it be possible to <validate/> a document with state data?

~j

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 24 May 2007 14:18:47 +0200 (CEST)

> Is the state data said to be part of the data model?

Yes.

>   2. the config and non-config data is stored in the store.

It is an error.  You will probably get an 'unknown-element' or
'unknown-attribute' error if you try to pass state data in an
<edit-config>.

> Also, should it be possible to <validate/> a document with state data?

No.  (Follows from the above).  Also note that the <validate> command
isn't very useful for validating documents, since you can't specify
the target db in <validate>.  So <validate> of a document can not do
much more than simple syntax checks.  There's an non-standard
extension that has been discussed on the list, which adds a
'test-only' <test-option> to <edit-config> that is useful for this
kind of validation.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 May 2007 10:50:39 -0700

>  1. the state data is filtered out.

This is what <get-config> and <copy-config> does

>  2. the config and non-config data is stored in the store.

Yes -- an access-failed error because you are attempting
to write to read-only data

Andy

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 24 May 2007 18:20:57 -0700

Hi,

I find it disturbing (but not surprising) that Andy
and Martin suggested two different errors (and two
different underlying reasons).  

The underspecified behavior of Netconf for various 
error conditions will probably be a source of very
widely divergent behavior on the part of Netconf
clients - who apparently should expect just about
anything in responses and somehow always gracefully 
cope with it.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Andy Bierman
Sent: Thursday, May 24, 2007 12:51 PM
To: Johan Rydberg
Cc: Martin Bjorklund; [email-masked]
Subject: Re: Difference between get and get-config

Andy

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.467 / Virus Database: 269.8.0/817 - Release Date: 5/24/2007 4:01 PM

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 May 2007 08:34:09 +0200 (CEST)

> anything in responses and somehow always gracefully 

I agree with this.  In my generic NETCONF test suites I have comments
like this:

            # no std error message exists; accept any error

In this particular case, internally I use an error-code
'not-writable', which is then translated into the 'unknown-element',
with an <error-app-tag> of "not-writable".

'access-denied' is described as:
           Access to the requested RPC, protocol operation,
           or data model is denied because authorization failed.

  IMO, authorization didn't fail in this case.

'unknown-element' is described as:
           An unexpected element is present.

  The read-only element is unexpected (but not unknown...)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 May 2007 08:36:01 +0200

> different underlying reasons).  

Ira,

it usually takes implementation experience to work out all the corner
cases attached to a protocol design. NETCONF is a Proposed Standard
and if we take our standards process as it was conceived, then finding
these sorts of inconsistencies is exactly what is expected to happen
at this stage of the protocol lifecycle. So I do not at all find this
disturbing - for me, these are encouraging signs that people are
building up decent implementation experience.

/js

-- 
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: Johan Rydberg <[email-masked]>
Date: Fri, 25 May 2007 14:13:34 +0200

>> exception of <get/> returning device state information as well?

Related question;

Reading the RFC I got the impression that the stores can only store a
single configuration (ie, a XML tree with data).  But extensions such
as notification and monitor introduces data parallel to the
configuration data (the 'top' node).

Also, on the NGO list Andy states the following:

   I don't use a real node called 'top'.  The <config> or <data>
   node is the conceptual 'top'.

Does this mean that the configuration data can be split in several
XML documents?  Or should the <config> and <data> nodes be treated
as part of the document [1] ?

~j

[1] http://en.wikipedia.org/wiki/Root_element

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 May 2007 14:48:29 +0200 (CEST)

Johan Rydberg <[email-masked]> wrote:
> XML documents? 

Yes, in the sense that you can get e.g.

  <data>
    <interface xmlns="http://example.com/ns/interface">
       ...
    </interface>
    <system xmlns="http://example.com/ns/system">
       ...
    </system>
    <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
       ...
    </eventStreams>
  </data>
    
Each of these can be viewed as a separate XML document if you wish.

/martin

---

From: Johan Rydberg <[email-masked]>
Date: Fri, 25 May 2007 14:51:56 +0200

> configuration data (the 'top' node).

For reference, was scanning through the NETCONF RFC and found the
following statements:

   In 7.3, in regards to the source parameter to copy-config;

      Name of the configuration datastore to use as the source
      of the copy operation or the <config> element containing
      the configuration subtree to copy.

   My interpretation is that subtree means a single XML node.

   In 7.2, in regards to the config parameters to edit-config;

      A hierarchy of configuration data as defined by one of the
      device's data models. [...]

   My interpretation is that hierarchy mandates a single XML node.

In the netconf-model I-D [2], section 5.7 there is an example of a
<get/> that returns both configuration and non-configuration data.
In the example, the configuration data is contained in a <xc:config>
node.  My feeling is that is probably an error in the I-D.

~j

[2] http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-06.txt

---

From: Johan Rydberg <[email-masked]>
Date: Fri, 25 May 2007 14:58:48 +0200

> Each of these can be viewed as a separate XML document if you wish.

In other words, a configuration datastore can store several documents?

~j

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 May 2007 06:48:35 -0700

> In other words, a configuration datastore can store several documents?

A NETCONF configuration database is not an XML instance document.
Only the NETCONF PDUs on the wire are XML instance documents.

The data root is the <config> element or the <filter> element,
which does not actually exist as part of the agent data model(s).
That is why I called it a conceptual root.

It is quite possible that different child nodes of <config> or <filter>
could be defined in different XSDs.  (The <netconf> node will be
defined in NETCONF Notifications, and proprietary nodes will be
defined elsewhere.)

When the agent does a 'copy-config', a top-level element has to
be created to hold the arbitrary number of data nodes (I call
this element <config> in my code.)  Otherwise the file written
will not be well-formed XML.  Otherwise you could not take
the output of a <get-config> or <copy-config> and use it directly
as the input to an <edit-config> operation.

Network configuration is not a document editing problem.
Use WEBDAV for that problem, not NETCONF.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 25 May 2007 16:15:51 +0200

Hello,
Until now I interpreted this as:
The configuration will have many top nodes, one for every namespace. Or do we allow it that 
even for one namespace there will be multiple top level nodes?

Balazs

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 May 2007 08:02:16 -0700

Balazs Lengyel wrote:
> The configuration will have many top nodes, one for every namespace. Or 
> do we allow it that even for one namespace there will be multiple top 
> level nodes?

XSD does not support this.
There can only be one top-level element in a given namespace.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 May 2007 08:05:21 -0700

Andy Bierman wrote:
>> The configuration will have many top nodes, one for every namespace. 
>> Or do we allow it that even for one namespace there will be multiple 
>> top level nodes?
> 

oops -- XSD does support this, but I still think each top-level
data node should have a different namespace, as you suggest.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 May 2007 18:46:12 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> will not be well-formed XML.

I do that as well, but does the rfc mandate that the file has to be
valid XML?

> Otherwise you could not take

So when you do a <copy-config> to a file you get something like:

  <config xmlns="andys-namespace">
    <interface xmlns="http://example.com/ns/interface">
       ...
    </interface>
    <system xmlns="http://example.com/ns/system">
       ...
    </system>
    <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
       ...
    </eventStreams>
  </config xmlns="andys-namespace">

Correct?  We do the same.  But with out own namespace uri :(

And then you can pipe this into a <edit-config>:

  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
      <target>
        <running/>
      </target>
      <source>
        <config>
          <config xmlns="andys-namespace">
            <interface xmlns="http://example.com/ns/interface">
              ...
            </interface>
            <system xmlns="http://example.com/ns/system">
              ...
            </system>
            <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
              ...
            </eventStreams>
          </config>
        </config>
      </source>
    </edit-config>
  
Is this correct?

We don't do that.  You'd have to remove the top-level <config> tag
from the file and do:

  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
      <target>
        <running/>
      </target>
      <source>
        <config>
          <interface xmlns="http://example.com/ns/interface">
            ...
          </interface>
          <system xmlns="http://example.com/ns/system">
            ...
          </system>
          <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
            ...
          </eventStreams>
        </config>
      </source>
    </edit-config>

IMO, it would have been nice if this top-level <config> element was in
the netconf namespace, and documented in the rfc, so that the file
content of a <copy-config> was well defined.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 May 2007 10:24:08 -0700

> I do that as well, but does the rfc mandate that the file has to be

no -- some vendors wanted text, some wanted XML, so it is
left unspecified.

>     <interface xmlns="http://example.com/ns/interface">

I would put <interface> in a container <interfaces> (or maybe <IF-MIB>)

>     <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">

The latest draft has a <netconf> container defined.

> Correct?  We do the same.  But with out own namespace uri :(

Actually, I put the <config> element in the netconf namespace,
and each top-level container (e.g., <system>)
is an 'application node' in its own namespace.
Thus, 'netconf', 'interfaces', and 'system' can all be defined
in separate XSDs.

>             <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">

no

>           <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">

yes -- this is what I do.
That is why I call the <config> node a conceptual root.
You have to be able to copy/translate from the conceptual internal root
to the real root (e.g., <config>) in a PDU.

> content of a <copy-config> was well defined.

Yes, well, thankfully, the IETF lets us change and correct documents.
As Juergen pointed out, the standards process does not actually
expect documents to be perfect at the time of Proposed Standard.

We are allowed to do any of 4 things (I think) wrt/ IETF Process,
subject to IETF Approval:

  1) Advance RFC 4741 to Draft Standard as-is
  2) Create a clarification-only update to RFC 4741 and advance to DS
  3) Create any update to RFC 4741 and cycle at Proposed Standard
  4) Reclassify RFC 4741 as Historic (yeah, right ;-)

Gather all the clarifications for later...

Andy

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 25 May 2007 15:05:20 -0700

Hi,

> Gather all the clarifications for later...

About your options (1) or (2):

Well, not quite.  Once an IETF Draft Standard is approved,
that Draft Standard MUST NEVER be revised in a way that 
breaks backward compatibility.  Also, two independent 
implementations of a client as well as two independent 
implementations of a server that implement EVERY operation 
and element are necessary to advance to Draft Standard. 
These flaky Netconf error conditions would effectively 
preclude such advancement, even if the rest of the Netconf
protocol were bullet-proof (which it isn't).

Your option (3) would be appropriate, but cleaning up the
error conditions and all the other ambiguities should be
done before forwarding it to the IESG for last call.

Your option (4) isn't really such a joke - a clean page
might be the better approach.

IMHO - a management protocol without a data model and
complete object/attribute/element semantics is of very 
dubious value.

Cheers,
- Ira

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.0/818 - Release Date: 5/25/2007 12:32 PM

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 May 2007 15:27:45 -0700

> About your options (1) or (2):

NETCONF is at Proposed Standard status now, not Draft Standard.
I was not stating any opinion on which choice (1 - 3) is most
appropriate.  Option (3) is the easiest and most likely.
If and when the protocol reaches DS status, different options
would be available.

> done before forwarding it to the IESG for last call.

The error ambiguities are due to the separation of protocol
and content layers.

> might be the better approach.

NETCONF isn't starting over because some corner-case error codes
are not spelled out for every conceivable data model that could
ever be used with the protocol.

> complete object/attribute/element semantics is of very 

And yet some people are still bothering to implement the
protocol anyway, believing good proprietary solutions
will lead to good standards someday.

Data models (like those in the Notifications draft) will
get defined one or two at a time, and get fully documented
as well as possible by the WG volunteers doing the work (as usual).

There are plenty of NETCONF data modeling proposals out there already,
and all it takes to make them standards is lots of hard work.

Andy