[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: url clarification
Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:
Did we ever resolve all the issues here? (A: no)
Here are the operations that use rpcOperationTargetType:
operation text-allows-url notes
------------------------------------------------
edit-config N 1
copy-config Y 2
delete-config Y 3
lock N 4
unlock N 4
[...]
Summary Issues:
A) Which is right: The text or the XSD?
Should the edit-config, lock, and unlock XSD definitions change from
rpcOperationTargetType to configNameType? This will explicitly
disallow URL as <target> in these operations.
I think the text makes more sense than the XSD.
I can see it both ways.
One one hand, I sure don't want to make it mandatory
for the :url capability to include <url> as a target of edit-config.
On the other, I don't want to prohibit it without reason either.
Section 8.8.5 is the critical text here.
Taken literally, this section says that <url> as
a target for <edit-config> must be supported,
but the target should be a local file. Lock and unlock
are not allowed (they are not listed in this section).
This part seems kind of broken to me.
It is data model specific what it means to edit a file
instead of configuration datastore.
I don't think the WG ever really thought through the
details of this section, especially 8.8.5.1.
The one thing that is clear is that the text in several sections
is out of sync with the XSD wrt/ the <url> element.
B) If an agent advertises the :url capability, what operations
MUST, SHOULD, or MAY it apply to? What if an agent only
supports URLs as the <source> parameter and not the <target> parameter
on some or all operations?
One example is the http/https schemes as target to copy-config. Which
HTTP operation should the agent use? PUT? POST?
good question
Another thing which is not clear is what the file pointed to by an url
looks like. Suppose you send the agent the following command:
<copy-config>
<target>
<url>ftp://ftp.server.com/my.conf</url>
</target>
<source>
<config>
<foo xmlns="http://my-foo-ns";>
...
</foo>
<bar xmlns="http"//my-bar-ns">
...
</bar>
</config>
</source>
</copy-config>
What will the 'my.conf' file look like? Like this:
<config>
<foo xmlns="http://my-foo-ns";>
...
</foo>
<bar xmlns="http"//my-bar-ns">
...
</bar>
</config>
The WG decided awhile back to remove the text vs. XML "format"
parameter from these operations. There is only XML. (Even if a
text config file is only conceptually wrapped in a top-level element.)
What my.conf looks like is data model dependent.
This would be a valid XML document, where 'config' does not belong to
any namespace. Another alternative is the same contents but w/o the
<config> element, but that wouldn't be valid XML. There are some
other reasonable alterantives as well. Maybe this also is
implementation-specific? (with the usual inter-op drawbacks)
Data-model specific, not implementation-specific.
There is a big difference.
Here is what I mean by top-level wrapper:
(Top-level element name doesn't really matter)
<config>
<my.conf xmlns="http://example.com/config/1.3";>
ascii config file command
ascii config file command
ascii config file command
</my.conf>
</config>
/martin
Andy
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>