Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 3 Oct 2006 15:28:17 +0200

Not sure if WG chairs agree to discuss this draft on this list.

I did a very evry quick browse.
Looks to me that we need to see example scenarios on how this
woprks with chaninging (i.e. configuring) a device/system.
How are the locking mechanims handled in that case?

The subagent approach for gets is relatively easy I think, but the
problems may arise when we want to modify data... 

Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Romascanu, Dan (Dan)
> Sent: Tuesday, October 03, 2006 05:40
> To: [email-masked]
> Subject: FW: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt 
> 
> 
>  
> In case some of you are not subscribed to i-d-announce. 
> 
> Dan
> 
> 
>  
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, October 02, 2006 4:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: NETCONF Master-agent Sub-agent Communication
> Protocol
> 	Author(s)	: J. Kulkarni
> 	Filename	: draft-kulkarni-netconf-subagent-prot-00.txt
> 	Pages		: 16
> 	Date		: 2006-10-2
> 	
> This memo contains a mechanism by which NETCONF server and client can
> extended to operate in a master-agent sub-agent scheme.  It extends
> the base NETCONF protocol with additional NETCONF operations,
> describes the protocol for this interaction and provides error
> messages exchanged during this interaction.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kulkarni-netconf-sub
agent-prot
-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-kulkarni-netconf-subagent-prot-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-kulkarni-netconf-subagent-prot-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--
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: Andy Bierman <[email-masked]>
Date: Tue, 03 Oct 2006 09:05:55 -0700

> problems may arise when we want to modify data... 

The WG is not going to standardize a sub-agent protocol,
not only because there are more important issues already
in the queue, but because this is a very agent implementation
specific problem.

The complexity required for robust <edit-config> support
is just huge.  And what about special RPCs like <reset-interfaces>
which might be implemented across multiple sub-agents?

The notion of a "standard" agent callback implementation design
is not something we are ready to think about (or even should
think about in this WG).

> Bert

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Oct 2006 10:37:05 +0200 (CEST)

> The WG is not going to standardize a sub-agent protocol,

If the WG does not want to work on a subagent protocol, that's fine.

I just want to say that I do think the subagent idea (in general) is
appealing, and I know for a fact that subagents will be used in some
netconf deployments.

> is just huge.

I don't think it is.  XPath filtering across subagents is more
tricky...

> And what about special RPCs like <reset-interfaces>

This might be another reason for using a standard <exec> method (where
the operation itself is defined in the data model) as been discussed
earlier.

/martin

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 4 Oct 2006 13:37:04 -0400

Hi,

The SNMPv3 WG and the agentX WGs worked independently, because the
implementation interfaces being defined by agentX were largely outside
the scope of the SNMP operations, and the operations were clearly
defined. In the RFC3411 diagram, the agentX interfaces would be
positioned between the "SNMP application" and the underlying
instrumentation.

A master-subagent proposal might also be viable for netconf, but it
would be really helpful if netconf had an architecture that showed
where the interface is between netconf and the instrumentation, and
what functionality is included in the netconf environment. 

It will be somewhat more difficult, I expect, to design an interface
between the internal "applications" and the instrumentation, when the
nature of "applications" is not yet defined, and special verbs might
be related to specific sets of data. Presumably, special verbs will
only work with specially-addressed data.

The lack of any addressing model of data in netconf is going to make
it difficukt to divide the data into addressable subsets in a
master-subagent design.

As Bert points out, it may be more difficult to design a subagent
interface for SETs. For monitoring functionality, a standard can be
defined based on a common vendor-neutral subset, but SET commands
typically need to deal with extra parameters that may be vendor or
equipment-model specific.

dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Tuesday, October 03, 2006 12:06 PM
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt
> 
> >> Subject: FW: I-D 
> ACTION:draft-kulkarni-netconf-subagent-prot-00.txt 
> >>
> >>
> >>  
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Oct 2006 19:49:07 -0700

> I don't think it is.  XPath filtering across subagents is more

I think it would be almost as much work to write this document
as it was to write the netconf-prot document.  In practice,
the capabilities and operations will not be the same across
all sub-agents.  All the bells and whistles (error-option,
confirmed-commit, etc.), for all the operations seems like
a lot of complexity to me.

> the operation itself is defined in the data model) as been discussed

My point was that if every RPC is to be supported,
then a generalized algorithm would be needed to
define how it is properly invoked in the presence
of multiple sub-agents.  IMO, this is difficult.
It is hard enough to define the algorithm for
RPC methods we know about (like <edit-config>),
but what about any arbitrary RPC?  I don't
think <exec> really helps here, unless the contents
of the exec command are tightly constrained.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Oct 2006 13:11:11 +0200 (CEST)

> a lot of complexity to me.

I agree.

> of multiple sub-agents.  IMO, this is difficult.

I agree.

> of the exec command are tightly constrained.

The idea with exec is that the operation is defined for an instance in
the data model.  Something like
  <exec>
    <operation>restart</operation>
    <instance>/interface[ifIndex='1']</instance>
  </exec>

If the master knows which subagent handles /interface, he can dispatch
to that subagent.

Anyway, I agree that this isn't high on the priority list, and we
should probably collect real-world experience before doing this.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Oct 2006 08:59:49 -0700

>...

> should probably collect real-world experience before doing this.

Agree 110%
The AgentX work was done after many years of experience with
the SNMP protocol, and after multiple high-quality implementations
of a master-agent/sub-agent system.

Andy