Open jgcumming opened 10 months ago
Duplicate of #10 ?
Please add a use case.
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
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.
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.
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?").
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.
@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.
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