[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: relationship of snmpconf to midcom?
> From: Randy Presuhn[SMTP:email@example.com]
> Reply To: firstname.lastname@example.org
> Sent: Saturday, January 06, 2001 1:15 AM
> To: email@example.com
> Subject: relationship of snmpconf to midcom?
> Hi -
> Does anyone know how this relates to the snmpconf work?
> > Message-Id: <200101052054.PAA22275@ietf.org>
> > From: The IESG <firstname.lastname@example.org>
> > To: IETF-Announce: ;
> > Subject: WG Review: Middlebox Communication (midcom)
> > Date: Fri, 05 Jan 2001 15:54:08 -0500
> > Sender: email@example.com
> > Status: RO
> > A new IETF working group has been proposed in the Transport Area.
> > The IESG has not made any determination as yet.
> > The following Description was submitted, and is provided for
> > informational purposes only:
> > Middlebox Communication (midcom)
> > --------------------------------
<.... snip ...>
> > The focus of the working group will be the architectural framework and
> > the requirements for the protocol between the requesting device and the
> > middle box and the architectural framework for the interface between the
> > middle box and the policy entity. In both cases we intend to reuse
> > existing or in process IETF protocols if possible.
at this point it did list examples of IETF protocols.... SNMP was not there
and I suggested that SNMP could be used as well, in addition to probably
quite a few others. So... as to not "direct" the architectural and
work into a specific direction, we (IESG) changed it to not list any
protocol for this phase of the charter.
<... snip ...>
> > Discovery of middle boxes is out of scope.
> > The deliverables will be
> > o a document specifying the architecture and interfaces on
> > . a requesting entity
> > . a middle box
> > o a document the requirements for both the
> > architecture and the control language
> > o a document describing the requirements for a policy enity
> > Once these deliverables are complete, the Area Directors will decide if
> > the working group should be rechartered. If rechartered the working
> > group could undertake protocol development or development of profiles
> > of existing protocols.
And at this point, it might be good for SNMP and/or SNMPCONF folks
to see how we could fit in the architecture and how could meet the
Bert (AD hat on)