Re: [Netconf] draft-cole-netconf-robust-config-01

[Balazs Lengyel <balazs.lengyel at ericsson.com>]

Hello,
Very interesting draft. Some comments, questions:

General:
If we introduce some new testing/verification mechanisms, I would like to see how it can be 
used for to make sure it will be available for writable-running based nodes as well.


About this version of the draft:
1) I think your examples are not the best. Today confirmed commit only checks whether OAM 
connectivity is still available. For any config-change, that is not related to this 
connectivity, you need extra checks. Examples could be:
- configuring an License server. OAM is OK, but the License server does not serve half of the 
License-client nodes. It is possible to confirm, but obviously extra tests between the License 
server and its License clients are needed.
- Configuring a SIP server. While the config looks nice and it can be committed, will it still 
serve all the SIP user agents
- In telecoms often the OAM connection and the "traffic" connections are on completely 
different networks for security reasons. So even though OAM is up and running, the configured 
node might have lost some or all of the traffic links

2) The easiest way to start checks would be to define in the specific YAMs rpcs or relevant 
state data that the manager can check. We already have these possibilities. Why not let the 
manager invoke these test. (Could be one big generic-health-check rpc or many small specific 
tests) Maybe this should go into the YANG usage guide.

3) I asked earlier,but again: What does test-then-set mean for the running config? According to 
YANG the running is always valid. Which set of checks are run for test-then-set against a 
candidate?

Balazs



About the existing commit:
I) As Andy pointed out today the commit operation is overloaded (original commit, confirming 
commit). This can lead to the mistake when two operators both want to send just an 
original-commit but and up confirming the commit. Broken-> fix it! At least provide a separate 
confirm-commit operation (compatible change), or maybe also remove the possibility to use a 
second commit operation for confirming the commit (incompatible change).

II) The cancel-commit operation is missing. Add it!

III) Netconf should allow the Netconf server itself to rollback a commit, when it detects 
problems (and issue a corresponding notification). Add the possibility!

Balazs