[Netconf] capability exchange (was Re: draft-cole-netconf-robust-config-01)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Netconf] capability exchange (was Re: draft-cole-netconf-robust-config-01)



Andy Bierman wrote:
> Martin Bjorklund wrote:
....
> 
> I don't want to introduce an incompatible version of
> the protocol.  The charter already assumes in advance
> that there are no problems worthy of a new protocol version.
> 
> But you will tell me that we could just introduce :confirmed-commit.1.1,
> so I guess it doesn't matter.  But I am not so sure the complexity on
> the NMS is less in the long run if we do this.  A lot of capabilities
> interact.  So now we have to document how every version of every
> capability interacts with every other, for all time.  Sounds hard.
> This is probably why most protocol WGs just version the entire protocol,
> and not arbitrarily small subsets of it. (hint)
> 

At this point, the NETCONF WG cannot introduce any new version
of a single capability, because the current capability exchange
is not documented to support it.

RFC 4741 says very clearly what capabilities the manager
MUST sent (netconf-base) and what an agent MUST send
(everything it has).  So manager implementations do
not send all the capabilities (like confirmed-commit)
that they support.  They know a 4741 agent will just
ignore them, so why bother.


Except:
   1) if the agent advertises just :foo.1.1, then
      old managers break, since they only know about :foo.1.0

   2) if the agent advertises :foo.1.0 and :foo.1.1,
      and they are not backward-compatible, then
      the agent may not know which one the manager expects

If I were thinking about a solution to the problem
that is optimal, instead of worrying about the charter,
I would suggest that capability exchange needs to
be rewritten in 4741-bis so both side always send
everything they know, and they automatically pick
the highest capability version in common.

But a charter-compatible solution would be to put
CLRs in place that a new capability version MUST follow
all the same revision rules as YANG modules.

For example, adding 'test-only' follows the rules.
An agent could advertise both :validate1.0 and :validate.1.1,
and both old and new managers will work.

I don't think the same is true (so far) wrt/ :confirmed-commit.1.1.



> .....
>> /martin
>>
> 
> Andy
>

Andy


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.