Subject: [Netconf] <edit-config> and remote URLs

From: Mark Ellison <[email-masked]>
Date: Thu, 1 Oct 2009 11:46:33 -0400

Regarding use of URL in the <edit-config> protocol operation:

sxn 7.2., "<edit-config>" - states "...such as using a local file, a
remote file, or inline."

Within section 8.8. "URL capability", section 8.8.5.1 "<edit-config>"
states, "If the <url> element is specified, then it should identify a
local configuration file."

My best guess at interpreting the intent would be that 8.8.5.1
suggests that a URL *target* in an  <edit-config> operation should be
a file that is local to the NETCONF server.  And, I assume that a URL
*source* in an <edit-config> operation may be a file that is local or
remote to the NETCONF server.

I would appreciate clarification on this issue and apologize if this
issue was previously discussed on the NETCONF email listserv.

Regards,

Mark

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Oct 2009 22:53:51 +0200 (CEST)

> remote to the NETCONF server.

I think 8.8.5.1 is pretty clear.  It says:

   The :url capability modifies the <edit-config> operation to accept
   the <url> element as an alternative to the <config> parameter.  If
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the <url> element is specified, then it should identify a local
   configuration file.

I.e. the *source* url should be a local file.  According to 8.8.5.1,
using url as a *target* is not supported at all.

7.2. also does not allow a url as target, but it does say:

      This operation allows the new configuration to be expressed in
                                ^^^^^^^^^^^^^^^^^
      several ways, such as using a local file, a remote file, or
      inline.

So the word "remote file" in 7.2 contradicts the text in 8.8.5.1, and
it also contradicts the next paragraph in 7.2.

However, it is not clear to me why the edit-config source url should
be a local file.  The copy-config operation does not have such a
restriction.

I don't think edit-config of a *target* url was ever intended to be
supported.

/martin

---

From: Mark Ellison <[email-masked]>
Date: Thu, 1 Oct 2009 17:30:50 -0400

>   the <url> element as an alternative to the <config> parameter.  If

Got it- the :url capability offers an alternate only to the <config>
element in the <edit-config> operation.  The :url capability does not
make the url element within the <target> element usable.
>      This operation allows the new configuration to be expressed in

Yes- the "remote file" bits serve as the 'catalyst of confusion' for
my hunting for intent.
> I don't think edit-config of a *target* url was ever intended to be
So the "target" of <edit-config> can only be one of running, candidate
or startup configuration datastore as allowed by the NETCONF server
capabilities?

And, it looks like there is a multi-step process involving
<copy-config> and <edit-config>.  I can use a remote url as source and
a local url as target in the <copy-config> operation to move
configuration data onto the local server, then (lock and) use a local
source url with the <edit-config> to update the candidate target, then
validate, etc.  Finally, I can use <copy-config> to move the 'new
configuration' contained in the candidate datastore to either a local
or a remote url/file.

> /martin

I appreciate your time and thank you for your help in getting my
thoughts sorted out.  I may have additional confusions to sort out as
implementation proceeds.

Regards,

Mark

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Oct 2009 23:45:54 +0200 (CEST)

> or startup configuration datastore as allowed by the NETCONF server

In fact, it can not be <startup>.  See 8.7.5.1.  I recommend that you
look at the YANG model in draft-ietf-netconf-4741bis-01 - it is a bit
more precise than the old XSD.

> configuration' contained in the candidate datastore to either a local

This is a use case described in Appendix D.  But I am not sure if
copy-config was intended to be a "ftp" operation, i.e. copy any file?

I think copy-config makes sense only when at least one of target and
source is a data store.  (Then it is like a load / save backup
operation).

/martin

---

From: Mark Ellison <[email-masked]>
Date: Thu, 1 Oct 2009 18:29:46 -0400

> more precise than the old XSD.

In fact I am working with the XSD from 4741bis-01 since it works with
tools that draw nice UML diagrams for me ;-)  I just took a look at
the YANG and see some useful information but guess it will take some
time to understand YANG better than XSD.  In the "rpc edit-config
{...}" YANG block I see a reference to section 8.8.5.1., but do not
see a reference to section 7.2. (which would seem useful)
> copy-config was intended to be a "ftp" operation, i.e. copy any file?

I have been looking through this Appendix ("E") and see where the
<copy-config> operation moves inline config to a local url/file.
Section 7.3 has an example of <copy-config> using a remote http
source.
> source is a data store.  (Then it is like a load / save backup

Okay- duly noted.  However, it would seem that a <copy-config> from a
remote http/file to a local file would serve a use case where there is
one of many of the same model devices where a configuration is
validated and this configuration is then moved out to the many
devices- which will then load the config from the local url/file at
some future (possibly coordinated) time.

I don't think the protocol precludes this.

Also, I noticed that the :url capability applied to the :validate
capability does not constrain the source to local.  I guess this
allows a NETCONF server to validate a remote configuration before
sending it to the device?  Or is this possibly an oversight?

Also (sorry!) why does the YANG in 4741bis refer to "agent" rather
than "NETCONF server"? (e.g. in feature validate-1.1)

Again, it'll take me a while to start 'getting' the YANG as I am still
much more comfortable with the UML generated from the XSD.  Guess I'll
have to try a YANG --> XSD conversion tool here.
> /martin

Thanks Martin.

Regards,

Mark

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 02 Oct 2009 13:08:11 +0200 (CEST)

Mark Ellison <[email-masked]> wrote:
> tools that draw nice UML diagrams for me ;-)

That's fine; I just wanted to point out that the XSD in 4741 allows
more than is actually legal according to the text.

> I just took a look at

Thanks, that was a bug in the script that adds xrefs to the YANG
module; fixed.

> I don't think the protocol precludes this.

If not, what checks, if any, should be done by copy-config when both
target and source are urls?  Is this legal:

    <copy-config>
      <target>
        <url>file://incoming.conf</url>
      </target>
      <source>
        <url>http://www.ietf.org/index.html</url>
      </source>
    </copy-config>

> sending it to the device?  Or is this possibly an oversight?

I think this should be ok.  The only operation that is restricted to
local files is <delete-config>.

Hmm.. the reason for restricting <delete-config> to local files was
for security.  We don't want the NETCONF server to delete files on
remote computers; it is pointless.  But <copy-config> to a remote file
is allowed, so you can get the NETCONF server to overwrite remote
files.

> than "NETCONF server"? (e.g. in feature validate-1.1)

Bug, now fixed.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Oct 2009 13:22:40 +0200

> is allowed, so you can get the NETCONF server to overwrite remote

I fail to follow the logic - why is overwriting OK but deleting not?
At the end, it is a matter of the remote ftp/http/... server to
enforce access control rules.

/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: Martin Bjorklund <[email-masked]>
Date: Fri, 02 Oct 2009 13:25:27 +0200 (CEST)

> I fail to follow the logic - why is overwriting OK but deleting not?

That's what I meant - the reasoning is flawed.

> enforce access control rules.

So we should simply remove the text about local config files then.

/martin

---

From: Mark Ellison <[email-masked]>
Date: Fri, 2 Oct 2009 09:34:26 -0400

>> > Mark Ellison <[email-masked]> wrote:

[deletions]

>        <url>http://www.ietf.org/index.html</url>

I see your point that <copy-config> could be misused by placing
garbage into a local file.  However, the same could be attempted when
the target is a configuration data store which is then saved to a
local file.

When a client is using <copy-config> properly, it seems an extra step
to load a remote source into a configuration date store in order to
copy to a local file and an extra step to load a local file into a
configuration data store in order to save to a remote file.

[deletions]

Regards,

Mark