Subject: RE: [SIP] draft-petrie-sip-config-framework-00.txt

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 5 Mar 2001 11:09:41 -0500

I can't imagine a device provided by a service provider that did
not require a management interface.  I can't imagine that such
an interface on a small device would be anything other than SNMP.

If SNMP in was required to manage the device, then SNMP would have
to be allowed in to the site.  I expect that it would have to be
SNMPv3, with security enabled.  That's a pretty doable thing these
days, even in small devices.  You might end up using local SNMP
proxy to keep the implementation in the end device simpler.

I'm also pretty skeptical of the issue of "top down" nature of
SNMP managed systems.  It's true, of course, but for configuration,
that doesn't seem to be any big deal.  You boot, you get some
configuration data.  It might change, in which case this is
known centrally, not at the end point (that is, the configuration
database is changed, and that is pushed to the client).  I can't
see any real issue of client initiated changes that traps don't
cover real well.

It seems to me that
	SNMP is required, not optional
	Extending SIP for configuration is not a real good use of
		our limited resources

Brian

> -----Original Message-----
> From: Daniel G. Petrie [mailto:[email-masked]]
> Sent: Monday, March 05, 2001 10:31 AM
> To: Rosen, Brian
> Cc: IETF SIP (E-mail); [email-masked]
> Subject: Re: [SIP] draft-petrie-sip-config-framework-00.txt
> 
> 
> There is probably little proposed in this spec that
> could not be done with SNMP.  However the question
> is whether the SNMP can perform the functions within
> the constraints in this specific domain (i.e. SIP user
> agents).  SNMP was discussed as a possible solution
> for this problem as were others such as ACAP (see
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-s
> ip-config-00.txt )
> 
> There are few reasons why SNMP is not appropriate:
> 1) many SIP UA have very limited resouces (i.e. instruction
> and memory foot print limitations). Adding another application
> protocol, parser etc. may not be possible.
> 
> 2) It is intended that this framework could be used in an
> environment where voice services are hosted in the Internet
> cloud somewhere and the user agents are on enterprise premises.
> The servers delivering configuration may as well be hosted in
> the Internet cloud with only UAs in the enterprise LAN.
> I suspect that many network administrators would have a
> hard time allowing SNMP into their enterprise LAN from
> outside a firewall.
> 
> 3) SNMP is pretty much a waterfall management approach
> were entities are managed from top down.  It does not support
> endpoint initiated events (aside from traps) or any concept of
> autonomy of the end point.
> 
> There is no question that this draft is re-inventing the wheel.
> Unfortinately I do not see any way to avoid it and still have
> it adopted by a reasonable population of UAs.  The question
> as to whether this is a work group item came up at the interim
> meeting in Dallas.  It was believed this was a neccessary effort.
> However it may be an individual (or group) IETF submission as
> opposed to the SIP WG.  It is currently an Informational draft as
> opposed to Standards track.
> Cheers,
> Dan
> 
> "Rosen, Brian" wrote:
> 
> > What would this facility be used for that SNMP could not 
> reasonably provide?
> >    Might whatever is to be configured be described as a MIB?
> >
> > Assuming that there is a reason, why is such a facility SIP 
> specific,
> > i.e., why wouldn't we want a general purpose configuration system
> > independent of SIP?
> >
> > I wonder if SIP is really the appropriate WG to work on this.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Daniel G. Petrie [mailto:[email-masked]]
> > > Sent: Friday, March 02, 2001 6:13 PM
> > > To: IETF SIP (E-mail); [email-masked]
> > > Subject: [SIP] draft-petrie-sip-config-framework-00.txt
> > >
> > >
> > > This draft proposes a configuration and management framework
> > >
> > > for SIP user agents. It has been submitted and is in the
> > > pipeline.
> > > You can access this in the mean time from:
> > > 
> http://www.pingtel.com/docs/draft-petrie-sip-config-framework-00.txt
> > >
> > > Abstract
> > >
> > >    This document defines the application of a set of
> > > protocols for
> > >    configuring a SIP user agent.  The SIP user agent must
> > > discover how
> > >    and from where to retrieve its initial configuration and
> > > be notified
> > >    of changes and updates which impact its configuration.
> > > The
> > >    objective is to define a means for automatically
> > > configuring a user
> > >    agent such that it can be functional without user or
> > > administrative
> > >    intervention.  The framework for discovery, delivery,
> > > notification
> > >    and updates of user agent configuration is defined here.
> > > This
> > >    framework is also intended to ease ongoing
> > > administration,
> > >    configuration and upgrading of large scale deployments of
> > > SIP user
> > >    agents.  The contents and format of the configuration
> > > data to be
> > >    defined is outside the scope of this document.
> > >
> > >
> > >
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementor's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to
> > > [email-masked] with "subscribe" 
> in the body.
> > >
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.