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

Re: relationship of snmpconf to midcom?



I should be rather surprised if there was any relationship at all.  From 
reading Elliot's notes, Midcom is about defining architecture (and maybe 
even protocols) which get in the middle of the users data streams.  The 
most obvious example is web caches and proxies.  I believe that they also 
include NATs and Applications gateways in the problem space.  None of this 
has anything to do with SNMP or SNMP for Configuration.
Yours,
Joel M. Halpern

At 04:15 PM 1/5/01 -0800, Randy Presuhn wrote:
>Hi -
>
>Does anyone know how this relates to the snmpconf work?
>
>  -------------------------------------------------------
>  Randy Presuhn           randy_presuhn@bmc.com
>  Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
>  Fax:   +1 408 965-0359  2141 North First Street
>  http://www.bmc.com/     San Josť, California 95131  USA
>  -------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  -------------------------------------------------------
>
> > Message-Id: <200101052054.PAA22275@ietf.org>
> > From: The IESG <iesg-secretary@ietf.org>
> > To: IETF-Announce: ;
> > Subject: WG Review: Middlebox Communication (midcom)
> > Date: Fri, 05 Jan 2001 15:54:08 -0500
> > Sender: scoya@cnri.reston.va.us
> > 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)
> > --------------------------------
> >
> >  Current Status: Proposed Working Group
> >
> > Description of Working Group:
> >
> > As trusted third parties are increasingly being asked to make policy
> > decisions on behalf of the various entities participating in an
> > application's operation, a need has developed for applications to be
> > able to communicate their needs to the devices in the network that
> > provide transport policy enforcement. Examples of these devices include
> > firewalls, network address translators (both within and between address
> > families), signature management for intrusion detection systems, and
> > multimedia buffer management. These devices are a subset of what can be
> > referred to as 'middle boxes.'
> >
> > Decomposing applications requiring policy decisions by removing
> > application logic from the middle box and instead providing a
> > generalized communications interface provides a number of benefits,
> > including improved performance, lower software development and
> > maintenance costs, improved ability to support traversal of packet
> > filters by complex protocols, easier deployment of new applications, and
> > the ability to consolidate management functions.  For example, by moving
> > stateful inspection of protocols such as H.323 and SIP out of firewalls,
> > it is possible to improve performance and scalability and reduce
> > development and costs.
> >
> > The elements of this architecture include
> >
> >     . one or more middle boxes in the data path
> >
> >     . an external requesting entity
> >
> >     . a policy entity for consultation purposes when the
> >       requesting entity is untrusted.
> >
> > The requesting entity may be trusted or untrusted. In the case where it
> > is trusted, the middle box will treat the request from the entity as
> > authoritative.  In the case where it is not trusted, the intermediate
> > device will have to verify that it is authorized to complete the
> > request. That authorization could come from a separate or a built in
> > policy server.
> >
> > The primary focus of the working group will be the application of this
> > architecture to communicating requests between applications and
> > firewalls or NATs.  This will not preclude other uses, and care will be
> > taken to ensure that the framework is extensible.
> >
> > 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.
> >
> > The security of the interfaces will be one of the primary focuses of the
> > work, and potential vulnerabilities on the interfaces and in the
> > architecture along with defenses against those threats will be
> > identified.
> >
> > 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.
>...