Re: [Netconf] <edit-config> and remote URLs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Netconf] <edit-config> and remote URLs
On Thu, Oct 1, 2009 at 4:53 PM, Martin Bjorklund <mbj at tail-f.com> wrote:
> Mark Ellison <ellison at ieee.org> wrote:
>> 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 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.
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.
>
> 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.
Yes- the "remote file" bits serve as the 'catalyst of confusion' for
my hunting for intent.
>
> 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.
>
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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.