Re: [Netconf] capability exchange
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Netconf] capability exchange
Andy Bierman <andy at netconfcentral.com> wrote:
> 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.
Yes! See below.
> > 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
Right.
> 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
There is nothing that prevents us from requiring the client to
advertise foo:1.1, if it is necessary. So if foo:1.1 changes some
semantics of foo:1.0, then we can say that the client MUST advertise
foo:1.1, otherwise the agent will use the semantics of foo:1.0.
> 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.
I think it can be made to work this way, without requiring the client
to advertise :confirmed-commit:1.1.
For example, :confirmed-commit:1.1 could add one rpc method
<cancel-confirmed-commit/>.
/martin
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.