search

netconf-wg / netconf-next

A repository to collection feature requests for NETCONF
0 stars 0 forks source link

Add capability *negotiation* between client and server #26

Open jgcumming opened 10 months ago

jgcumming commented 10 months ago

Currently the client and the server independently advertise their capabilities, but there is no method to negotiate, agree and report on the capabilities in use for the session

avtobiff commented 9 months ago

Duplicate of #10 ?

avtobiff commented 9 months ago

Please add a use case.

abierman commented 9 months ago

the specification for the capability URI should define any algorithms for behavior if the client also sends the URI.

the protocol defines a protocol version exchange algorithm and does not preclude other capability exchanges

This is already supported in base:1.1

jgcumming commented 6 months ago

In the current implementation there is no discussion and agreement of the capabilities supported between client and server. They both transmit their own capabilities and there is (explicitly) no requirement to wait for the other side. The suggestion here is that the client and server negotiate the capabilities so that once the session is established an agreed list of supported capabilities for that session are available.

kwatsen commented 6 months ago

This sounds like an NBC change. If so, then I'd rather a different NBC change, which is to be like RESTCONF and only have server-sent capabilities.

jgcumming commented 6 months ago

Definitely NBC (but as this is a NETCONF-next discussion that's OK). The RESTCONF approach doesn't quite solve the use-case though assuming I'm reading it correctly. Let's consider a solution where a client wants to operate in a certain mode, and the server may or may not support that. Perhaps there is a backup mode that the client would be happy with. The capability negotiation would allow for the client and server to agree on which mode they ended up with. You could then subsequently query this on a client/server ("hey - what mode is session x in?").

abierman commented 6 months ago

The capabilities exchange is clearly defined. Both peers MUST send a hello right away and not wait to receive one first. Negotiation is done by comparing the hello sent to the hello received. I am strongly opposed to changing the hello exchange.

kwatsen commented 6 months ago

@jgcumming What is the exact capability you wish to be negotiated?
I think that this is what @avtobiff was/is asking for above also... Agree with @abierman, negotiation is well-specified...at a high-level.

Also, note that the "NETCONF-next" effort is partitioning the Github issues on BC/NBC lines, with the potential of pushing a BC-update that won't take years to publish.