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

[Martin Bjorklund <mbj at tail-f.com>]

Mark Ellison <ellison at ieee.org> wrote:
> On Thu, Oct 1, 2009 at 5:45 PM, Martin Bjorklund <mbj at tail-f.com> wrote:
> > Mark Ellison <ellison at ieee.org> wrote:
> >> So the "target" of <edit-config> can only be one of running, candidate
> >> or startup configuration datastore as allowed by the NETCONF server
> >> capabilities?
> >
> > 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.
> 
> In fact I am working with the XSD from 4741bis-01 since it works with
> 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
> 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)

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

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

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>


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

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.

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

Bug, now fixed.


/martin