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

Re: WG Review: Evolution of SNMP (eos)



"Wijnen, Bert (Bert)" wrote:
> 
> Andy, thanks for your input
> 
> I think that SMIng is too ealy a stage to be considered yet.
> We hope to finish the initial set of work items pretty fast
> like Oct 2001. If by that tiem SMIng is making good progress
> and has additional requirements for the SNMP protocol, then
> we can decide at that time to add it to the charter.

The notion of a SetPDU which can return varbinds in the
Response PDU has been around for at least 8 years. It 
will be much easier to realize than the other charter items,
such as bulk transfer. But it can wait another year I guess.
It's better to wait until SMIng is far enough along to
understand all potential protocol enhancements, not that
SMIng is the only WG which could benefit from this transaction
oriented PDU type.

> 
> Hope you can agree
> 
> Bert

Andy

> 
> > ----------
> > From:         Andy Bierman[SMTP:abierman@cisco.com]
> > Sent:         Monday, January 15, 2001 9:05 PM
> > To:   The IESG
> > Cc:   new-work@ietf.org; SMIng WG
> > Subject:      Re: WG Review: Evolution of SNMP (eos)
> >
> > The IESG wrote:
> > >
> > > A new IETF working group has been proposed in the Operations and
> > Management
> > > Area. The IESG has not made any determination as yet.
> > >
> > > The following Description was submitted, and is provided for
> > > informational purposes only:
> > >
> > > Evolution of SNMP (eos)
> > > -------------------------
> > >
> > >  Current Status: Proposed Working Group
> > >
> > > Description of Working Group:
> > >
> > > A small number of changes added to the SNMP protocol would provide a
> > > substantial improvement to the protocol in terms of utility and
> > > efficiency. The changes must fall within the existing SNMP architecture
> > > as defined in RFC 2571. The intent of the working group is to focus on
> > > changes that may be easily defined and implemented which should then
> > > promote rapid acceptance and deployment. New protocol operations are
> > > within the realm of acceptable changes that may be defined.
> > >
> > > The initial work items include:
> > >
> > > - A standards-track document defining the mechanism by which the
> > >   capabilities of a SNMP entity may be determined. This document should
> > >   also define the interoperability requirements of the SNMP protocol
> > >   when extensions are present and when they are absent;
> > >
> > > - A standards-track document defining a mechanism for efficient
> > >   retrieval, creation, and deletion of rows in tables;
> > >
> > > - A standards-track document defining a mechanism used to delete an
> > >   entire subtree of managed object instances. This could, for example,
> > >   be used to remove all information related to a particular username in
> > >   the SNMP administrative framework;
> > >
> > > - A standards-track document defining a mechanism to provide for
> > >   compression of object identifiers to remove as much redundant
> > >   information as possible in the payload of the SNMP message; and,
> > >
> > > - A standards-track document defining a mechanism for bulk transfer of
> > >   SNMP data.
> > >
> > > Some of the documents may be combined if the working group so decides.
> > >
> > > No additional work items may be taken on by the working group until this
> > > initial set of work is close to completion. Additional work will have to
> > > be approved by the IESG and the IAB.
> >
> > I propose that the initial charter also include the following item to
> > support
> > current work in the SMIng WG:
> >
> >  - A standards-track document defining mechanisms for supporting
> >    object-oriented transactions (i.e. OO methods), such as a variant of
> > the
> >    SetPDU in which additional varbinds may be be returned in the
> > ResponsePDU.
> >    Other protocol extensions for support of OO mechanisms defined in
> >    the SMIng WG may also be needed.
> >
> > Andy
> >