Subject: distinct startup capability

From: [email-masked]
Date: Wed, 14 Dec 2005 19:16:48 +0100

Hi,

Client A does not implement the distinct startup capability and client B does. 
A and B display the model.
If A does a modification in the running, the modification is done in the startup.B knows it.
If B does a  modification in the startup, only the startup is updated. How can A know it ?

Actually this mades that A thinks the equipement will start with a configuration (running) although it will be with an other one (startup different from running). 

Does someone have the same problem ?

thanks for your answer.

Rose-Marie LIEVROUW 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 14 Dec 2005 15:28:17 -0500

[email-masked] 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Dec 2005 12:53:18 -0800

>the answer to your question more definitive, but was judged to

It was more than that.
If other access modes such as CLI or SNMP use
the native model (whatever it is) than things will
break if NETCONF doesn't use the same model.

We decided the best we could do is expose the
different models in use and make the client deal with it.
If you bother to write a NETCONF client then
the various standard capabilities should all be understood.
The extra commands (or parameter changes) dues to
the startup config (1 copy-config command) are minor.

> Phil

Andy