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

[Mark Ellison <ellison at ieee.org>]

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

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