[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Romascanu, Dan (Dan) wrote:

To me this means two things:

1. Maybe it's not that much about netconf lacking an architecture, but
about not having documented the architecture that draws the relation
between protocol and implementation
2. Defining a way to organize data in netconf may need to happen before
we can talk about standardizing something like a master-subagent
protocol


I seem to remember a massive amount of effort
going into the SNMPv3 architecture, and its ASI definitions,
yet implementors found it less than relevant.  It turned
out that not 1 implementation followed the ASIs.

IMO, we are in a discovery stage, in which developers are
trying to go beyond the SNMP "peek/poke" architecture, to a service
oriented architecture, focusing on high-level operations, not data models.
If we create a NETCONF architecture now, based on what we learned
from SNMP (and a tiny bit of NETCONF) we will probably not end
up with a viable long-term solution.




Dan
(speaking as a low-bandwidth contributor)


Andy


-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington 
Sent: Wednesday, October 04, 2006 7:37 PM
To: 'Andy Bierman'; 'Wijnen, Bert (Bert)'
Cc: netconf@ops.ietf.org
Subject: RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt

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


-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, October 03, 2006 12:06 PM
To: Wijnen, Bert (Bert)
Cc: netconf@ops.ietf.org
Subject: Re: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt

Wijnen, Bert (Bert) wrote:

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


-----Original Message-----
From: owner-netconf@ops.ietf.org

[mailto:owner-netconf@ops.ietf.org]On

Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, October 03, 2006 05:40
To: netconf@ops.ietf.org
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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Monday, October 02, 2006 4:50 PM
To: i-d-announce@ietf.org
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

i-d-announce-request@ietf.org 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:
	mailserv@ietf.org.
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
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/>




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




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



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





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