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.