Subject: [Netconf] capability-change

From: Andy Bierman <[email-masked]>
Date: Sun, 13 Jun 2010 10:30:22 -0700

Hi,

This is 1 of the few remaining open 4741bis issues.

The proposal (although distributed in many emails)
is let the client ask for the server to treat a
capability-change as a error, with new error-tag
'capabilities-changed'.  Then the client can call
a new operation to clear the error and re-get the <hello>
message.

This sounds sort of reasonable in theory.
However, IMO, this is not an operational error.
It is simply a system event.

Before discussion solutions, the WG needs to agree
that this is a problem that 4741bis needs to solve.

Are there any real NETCONF implementations that are having this
problem now?  If so, please describe the use-case.

Are there even any implementations that can alter or remove
NETCONF capabilities on-the-fly, without dropping sessions
or rebooting?

Are there any vendor capability URIs defined, which are legitimate
NETCONF protocol-related extensions?  (E.g., a hardware 'identifier'
as a NETCONF capability URI is a gross misuse of the protocol).

SNMP and CLI have no concept of freezing out the operator because
the system changed in some way.  This is quite fragile, and maybe naive,
to think operators want to be interrupted when the system changes.

I completely agree that a session MUST be dropped if the
server needs to remove or alter any of the NETCONF (4741,partial-lock,
with-defaults) capabilities from the session. Beyond that,
there is nothing for the standard to define.

A common use-case is going to be the dynamic loading/reloading/upgrading
of YANG modules, on-the-fly.  This is a feature, not an error.

IMO, there is no consensus to change anything in 4741bis wrt/ capability
errors.
If so, we are done, and the next draft can be the last one.  The lack of
progress on this issue means nobody cares, are we can just drop it and
move on.

Andy