Re: [Netconf] capability exchange

[Andy Bierman <andy at netconfcentral.com>]

Martin Bjorklund wrote:
> 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/>.
> 

Yes -- but a verify-commit.1.0 would also require all the
behind-the-scenes integration with the verification tests,
in order to send the mandatory notifications.  I don't see
the log-term benefits of creating lots of tiny little
protocol capabilities, even down to adding enums to
parameters.  It seems expedient now, when they are
still on the order of O(10).  Add one zero
to that and you end up with spaghetti YANG.

There is nothing in RFC 4741 that says the same session has
to issue the 2 <commit> operations.  I really don't like this
at all.  It clearly indicates the <commit> is overloaded,
since (even with all its CLRs) it still requires global locks
to work correctly.

I know we don't really have a proper database transaction model in
NETCONF, but the pseudo-transaction model can be
much cleaner that whatever it is we have now.  Just bolting
more parameters and modes onto this supposedly documented transaction
model is just asking for trouble later.  IMO, the NETCONF database
transaction model (including partial locking) is somewhat amateurish.
It's got more holes in it than Swiss cheese.

I don't really care what the capability is called,
as long as there are no restrictions to the design.
Whatever works best -- not whatever band-aid fits the quickest.


> 
> /martin
> 

Andy