[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-kulkarni-netconf-subagent-prot-00.txt
HI,
Some people love AgentX. I don't, since I believe that it
represents a failure of the managed system to provide
"usable" control paths that can be used for SNMP. And
I believe that a netconf-subagent would proprogate
forward such failures.
Lets assume we buy the argument of "let's be practical -
it's easier to add another control path in a system than
to fix the existing control path(s) to add support for
another management interface", and look at the costs
of AgentX. First, it limits changes in the management
protocol. When Wes and I (and others) wanted to add
an improved retrieval operation to SNMP, it couldn't
really be done with AgentX, since it didn't support
it. (And also, if you want to add caching in the
"master", the AgentX protocol is not very efficient
for doing this.) There are other protocol limitations
due to AgentX. In addition, there are access control
issues with agentx, primarily with not making the
security identity from the request available to subagents.
So, I haven't read the details of the netconf-subagent
proposal, but I do have concerns based on both issues
voiced by andy, but also from the SNMP agentX experience.
Regards,
/david t. perkins
On Wed, 4 Oct 2006, 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
>
> Dan
> (speaking as a low-bandwidth contributor)
>
>
>
>
>
> > -----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/>