Re: distinct startup capability

[Phil Shafer <phil@juniper.net>]

Rose-Marie.LIEVROUW@fr.thalesgroup.com writes:
>Actually this mades that A thinks the equipement will start with a configuration (runnin
>g) although it will be with an other one (startup different from running). 

Yes, if A doesn't understand the distinct startup capability, it
will fail to copy-config to startup, leaving the original config
in place on the next reboot.  This leads to the conclusion that all
clients must understand/implement the distinct startup capability.

The candidate capability makes a more interesting case, since the
server faces a decision when a client attempts to write to running.
They can fail the write, with an error message saying that only the
candidate is writable, or they could assume the client doesn't grok
the candidate capability and attempt to locally handle the logic
to perform the change (lock, change, commit, unlock).

Originally netconf had a base model and the client and server agreed
on a set of capabilities that modified that base model.  This makes
the answer to your question more definitive, but was judged to
painful to implement.

Thanks,
 Phil

--
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/>