Re: capabilities exchange and pipelining issues

[Andy Bierman <abierman@cisco.com>]

At 11:34 PM 7/8/2004, Juergen Schoenwaelder wrote:
>On Thu, Jul 08, 2004 at 02:27:02PM -0700, Rob Enns wrote:
> 
>> rpe> The original plan was to exchange
>> rpe> capabilities simultaneously and have both the manager and
>> rpe> agent honor the resulting contract--including possibly modifying
>> rpe> their behavior to match the capabilities advertised by their peer.
>> rpe> However I believe we've dropped this concept because none of the
>> rpe> capabilties in the spec today would need to be sent by the
>> rpe> manager (the substrate has to indicate which peer acts in
>> rpe> the manager or agent role). So we can dispense with manager
>> rpe> capabilities. Any comments on this?
>
>Announcing manager capabilities does not hurt so I prefer to keep
>this feature even if it is not used in netconf 1.0.

I agree.  However, we need to make sure capability definitions
are unambiguous wrt/ manager or agent roles.  Since our v1.0
capabilities describe specific operational behavior, rather than 
general feature capabilities, we are okay in this regard.
(E.g., #validate describes an operation accepted in a <rpc>
request.  Only a NETCONF peer acting in the agent role accepts
<rpc> requests, so this capability doesn't apply to managers.)

It is also important to note in the spec that the <hello> message 
sent by the manager MUST NOT be used by the agent to infer the 
intended usage or non-usage of certain operations.

(We were going to using the (now defunct) #notification capability 
to allow the agents that dynamically load modular SW images to
omit notification support if the manager didn't indicate a desire
to use notifications in its <hello> message.)


>/js

Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>