[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 13.7: copy-config
Hi,
There are several problems with the copy-config command,
as it is currently defined:
13.7.2: too many options; no option discovery
Most of the copy modes are optional:
- <running> as target
- <startup> as target
- remote to remote copy
There is no way to tell what the agent actually supports
for source and destination parameters.
13.7.3: limited usefulness without user named databases and files
Apparently, the only mandatory behavior an application can
count on is:
if (#candidate)
(1) copy <running> to <candidate>
if (#candidate && #url)
(2) copy remote-file to <candidate>
(3) copy <candidate> to remote-file
if (#candidate && #startup)
(4) copy <startup> to <candidate>
if (#url)
(5) copy <running> to remote-file
if (#startup && #url)
(6) copy <startup> to remote-file
Mode (1) and (2) are redundant because they are available
via edit-config. It's not clear why anyone would want
to use mode (3). Mode (4) isn't that interesting since
not many products have #candidate and #startup capability.
Mode (5) and (6) are widely used by operators.
13.7.4: implicit format conversion not interoperable
The format conversion "feature" of copy-config is not
well defined and application developers don't have any
way of knowing how XML <--> text translation will be
done on the agent. The mapping may be incomplete and
there is no way to tell which text or XML bits do not have
an appropriate mapping.
13.7.5: <url> mode not documented
The text does not mention that <url> may be used in place
of one of the config targets. This just shows up in the
example.
13.7: Proposal
Since this operation has several problems, and is not
very useful without user named configurations, it should
be removed and deferred until that feature is added in the
future.
--
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/>