RE: capabilities exchange and pipelining issues

["Rob Enns" <rpe@juniper.net>]

Comments below... (look for rpe>)

_______________________________

	From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of vedula.sarma@wipro.com
	Sent: Tuesday, July 06, 2004 11:02 PM
	To: netconf@ops.ietf.org
	Subject: capabilities exchange and pipelining issues
	
	
	Hi All,
	      I have few queries regarding the capabilities exchange and
pipeling. 
	 
	1. pipelining:
	 
	 In the case of an Error will the following statement still hold
good?
	 
	"NETCONF <rpc> requests are processed serially by the managed
device. Additional <rpc> requests MAY be sent before previous  
	 
	ones have been completed. The managed device MUST send responses
only in the order the requests were received."
	 
	To explain the above question please consider the following
scenario-
	a. Request1 from Session1 is accepted and the processing is in
progress.
	b. Request2 from Session1 is accepted and during validation (of
say, protocol operation schema), an error occurs.
	The question is, will the error be notified/propagated to the
Manager as soon as it occurs, or, should it be sent  
	 
	sequentially after response to Request1 is sent to Manager. 

rpe>
rpe> The intent of the spec is that the response would be sent
sequentially.
rpe>

	2.Capabilities Exchange:
	 
	   section 6.1 of ID:draft-ietf-netconf-prot-03 states:
	 
	   "Capabilities are advertised in messages sent on the NETCONF
channel
	   when each peer starts operation.  When the NETCONF channel is
opened,
	   each peer sends a <hello> element containing a list of that
peer's
	   capabilities".
	   
	   It makes sense to me in advertising the capabilities of the
Agent.But, what is the purpose of advertising manager  
	 
	capabilities. what the agent is going to do with the
capabilities of the netconf manager.

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?


	3. Should a message containing the Authentication
status(success/failure) be sent to the Manager?
	 
	To explain the above question please consider the following
scenario-
	a. Manager1 connects to Agent passing the username and password.
	b. The Agent accepts the connection and authenticates the
Manager w.r.t the Device(say using  RADIUS) .
	 
	     should the "Hello" message be sent to the other peer as
soon as the connection request is successful or should it wait 
	 
	for the "Device" authentication(say Radius) and if successful
then only send the "Hello" message. 

rpe> The agent should wait for successful authentication before
rpe> starting the NETCONF protocol. Authentication success/failure
indication
rpe> is part of the substrate and is addressed in those drafts.	 
	        
	Thanks & Regards,
	V.Sarma
	 


--
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/>