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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 5 Mar 2001 14:25:04 -0500

I don't think there are any service providers who would agree
to manage a service that they could not reasonably manage.  
Although we might have an impasse, I would say that SNMPv3,
with security enabled, would be acceptable inbound to an
enterprise.  Among other things, it could be source filtered.
This is a much bigger problem than just configuration. 
It has to do with managing the service, and giving service
level agreements.

I think a reasonable discussion of the pros and cons of 
how real systems are managed would be sufficient for the
network administrators I know to permit, and even welcome
the service.  

Let's put it this way - if the net admin will accept configuration
of his telephones and gateways by an outside agent by this mechanism, 
he will accept management of them via SNMP.

I don't understand the push/pull argument.  The data flow is the
same.  The issue is, who initiates, who responds.  I don't see
an issue with the network management system doing the initiation.
I also think that the sequence is most often triggered by action
that results in the management system knowing that an update is
required, and never the phone. 

The trap on boot works the way you want it.

The real issue is how changes to configurations are propagated.
Think about it - the way these things will work is that the customer
will use a web form that asks for a configuration change.  This will
trigger a set of actions in the OSS of the service provider to
create the appropriate database entries, cause billing changes, and,
will notify the service providers management system to accomplish the
change.  The phone is blissfully unaware of this.

Brian

> -----Original Message-----
> From: Daniel G. Petrie [mailto:[email-masked]]
> Sent: Monday, March 05, 2001 1:17 PM
> To: Michael Thomas
> Cc: Rosen, Brian; IETF SIP (E-mail); [email-masked]
> Subject: Re: [SIP] draft-petrie-sip-config-framework-00.txt
> 
> 
> 
> 
> Michael Thomas wrote:
> 
> > Daniel G. Petrie writes:
> >  > 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.
> >
> >    I find this somewhat uncompelling. First of all,
> >    a dumb SNMP implementation isn't all that big --
> >    it's mainly the number of MIB's that you support
> >    that chews memory. However, that's true no matter
> >    how you slice or dice it: the more things you want
> >    to configure or monitor, the more instrumentation
> >    you have to code and that takes resources
> >    whether it's SNMP or stone tablets.
> >
> >    Also: I'd say that headless widgets are
> >    poster children for the need for SNMP
> >    management. Like it or not, that's how a large
> >    part of the net is managed, and I expect that
> >    a huge slice of SIP widgets are going to expect
> >    to be managed that way. If you had to pick a
> >    second protocol, SNMP is probably the right
> >    one.
> >
> >  > 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.
> >
> >    Well, they don't allow SIP either so something
> >    is going to have to give.
> >
> 
> Just a point of clarification: I do not believe that network
> administrators will be willing (regardless of ability or ease)
> to let SNMP in from outside their firewall.  I do believe
> that they are willing to let SIP in and that this is largely a
> hurdle of ability.  SIP firewall solutions are trickling in,
> some are commercially available now (one can argue
> whether they are viable or acceptable).  I think we
> have to assume that getting SIP through a firewall
> will be solved or we have a much larger problem.
> 
> I think that administrator willingness the let in SNMP is
> the larger problem here.  How does a service provider
> manage a set of UAs in an enterprise?  The way this
> framework is defined, it minimizes the amount of data
> that is pushed to the UA.  Most of the configuration data
> is pulled by the UA.  Except for the bootstrapping
> (i.e. SIP messages) this framework will work through
> a standard firewall today (i.e. it is pulling http from inside
> the firewall).
> 
> I am not against SNMP.  We already have a SNMP agent
> on our phone.  I just do not think that it is generally palatable
> to the SIP phone vendor community or as a solution to the
> customers of hosted voice service providers.  Perhaps it
> make sense to make a SNMP MIB(s) as well.  However
> I think there is a  need for a SIP based solution.
> 
> >
> >  > 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.
> >
> >    Is there something wrong with traps/informs?
> >
> >    I don't understand what you mean by autonomy
> >    either.
> >
> >                 Mike, who is only a reluctant
> >                  SNMP "advocate"
> >
> > _______________________________________________
> > 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.