[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Difference between get and get-config

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:

Johan Rydberg wrote:

Martin Bjorklund skrev:


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

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.


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


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





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.


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>


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


    <system xmlns="http://example.com/ns/system";>
       ...
    </system>
    <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:notification">
       ...
    </eventStreams>


The latest draft has a <netconf> container defined.



  </config xmlns="andys-namespace">

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.




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? 


no



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>


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.



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.



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...




/martin


Andy

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