[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.