Subject: RE: capabilities exchange and pipelining issues

From: "Rob Enns" <[email-masked]>
Date: Thu, 8 Jul 2004 14:27:02 -0700

Comments below... (look for rpe>)

_______________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Tuesday, July 06, 2004 11:02 PM
	To: [email-masked]
	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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 08 Jul 2004 14:47:18 -0700

>>>>> On Thu, 8 Jul 2004 14:27:02 -0700, "Rob Enns" <[email-masked]> said:

rpe> So we can dispense with manager capabilities. Any comments on
rpe> this?

I predict some coming up in the future.  If the ability to have agents
send channel-specific event reports comes back, it would need a
capability flag.  Just because there is not need now doesn't mean you
shouldn't create a placeholder for stuff that will likely be around in
the future.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Jul 2004 08:34:05 +0200

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

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Fri, 09 Jul 2004 11:41:20 -0700

>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