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.