Subject: RE: [sip-config] Re: [SIP] draft-petrie-sip-config-framework-00.t xt

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

> Some questions for those on the list who know SNMP better than I do:
> 
> - how easy is it to configure the destination of traps? Is this done
> through management also?
Let's assume we use SNMPv3.  We want to make that assumption because
of security issues.  There is a "Management Target MIB" that sets
the address you send traps to.

> 
> - are there any small SNMP "engines" out there? Support of 
> ASN.1 implies
> a certain minimum size. The MIB agent on Sun is 154320, which doesn't
> seem too bad.
I've seen 64K implementations of SNMPv1.  For V3, they are a bit bigger.
100K seems about right.  Depends a whole lot on which MIBs.

Brian 

_______________________________________________
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.

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 05 Mar 2001 14:15:15 -0800

Brian,

When I login to a SIP phone in my lobby, and I need new user configuration 
information, how does the SNMP manager configure my box?  I'm assuming you 
will say something like "just send a trap to the network manager, and it 
will reprovision the phone".

The problem is that the network manager is the wrong point of control for 
future config (it might be belong to a different organization than the 
user), etc..

Also I challenge your initial premise.  Do you use SNMP to *configure* your 
laptop?  Do you use SNMP to configure your softphone on your laptop?  Why 
then should you use SNMP to configure a smart phone with browser, etc?

thanks,
-rohan

At 12:17 PM 3/5/01 , Rosen, Brian wrote:
>Actually, I don't agree.
>
>SNMP is the way we configure devices.  Period.
>You design a MIB, and you configure by writing to the MIB.
>
>There is a valid point about new box startup - when you take
>a phone out of the box and plug it in, the network management system
>doesn't know about it, and thus has no way to configure it.
>You have to solve that problem.  Once you are past that problem,
>you configure the device (and configure on reboot, and change
>the configuration, etc).  The network manager has to be able
>to associate the IP address with the box every time you get a new
>IP address.  That problem has known solutions in SNMP.
>
>We don't have to invent an entirely new mechanism because SNMP
>doesn't have a self-discovery mechanism for the network manager.
>
>Brian
>
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[email-masked]]
> > Sent: Monday, March 05, 2001 3:08 PM
> > To: [email-masked]
> > Cc: Daniel G. Petrie; Rosen, Brian; IETF SIP (E-mail);
> > [email-masked]
> > Subject: Re: [sip-config] Re: [SIP]
> > draft-petrie-sip-config-framework-00.txt
> >
> >
> > Hi,
> >
> > I think we have started off on the wrong foot with this thread.
> > As Kevin is beginning to say, there is no "one-size-fits-all"
> > solution.
> > The size of SNMP (almost) becomes irrelevant to this discussion.
> >
> > Sure, dumb UA bricks are likely to need/want SNMP management; SIP
> > application and proxy servers will need SNMP management, but
> > writing a lot
> > of configuration information, much of which is per user data, to (for
> > example) a web-like phone using SNMP is applying the wrong
> > tool to the
> > problem.  The sweet spot for SNMP on endpoint UAs seem to be
> > those whose IP
> > addresses are centrally "provisioned" somewhere.
> >
> > In many SIP phone deployments however, the phone will use a
> > semi-random IP
> > address only known by it and the SIP registration server.
> > Either the phone
> > has to fetch new config as appropriate, or something has to
> > take advantage
> > of the registration datastore to find the right Contact for the
> > phone.  SNMP is clearly not a good fit here. (wrong point of
> > control, etc.).
> >
> > So let's all rest assured that nobody is trying to reinvent
> > SNMP over SIP,
> > and that the problems are complimentary.  Now, can we review
> > the CONTENT of
> > Daniel's draft please?
> >
> > thanks,
> > -rohan
> >
> >
> > At 09:34 AM 3/5/01 , Kevin Lingle wrote:
> > >"Daniel G. Petrie" wrote:
> > > >
> > >e> 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 )
> > >
> > >daniel,
> > >
> > >in the sip-mib work
> > >(http://search.ietf.org/internet-drafts/draft-ietf-sip-mib-02.txt)
> > >we have a SIP-UA-MIB module that is specifically for implementing
> > >by sip user agents.  in the -02 rev of the draft that module has
> > >been reduced in terms of the objects defined there. many objects
> > >were moved to the SIP-COMMON-MIB (also applicable to UAs though).
> > >
> > >above you seem to question whether sip user agents can/should
> > >be managed by snmp.  i don't think that's the right question.
> > >to me the question is whether _all_ sip user agents should
> > >be managed via snmp?   i think the answer to that question
> > >is "maybe" w/ a tendency toward "not likely".
> > >
> > >i personally think that in terms of sheer numbers,  vast majority
> > >of user agents will eventually be things like sip phones and that
> > >they are likely to go the way of PCs and not be considered for
> > >management by SNMP.  i think some form of web-based managment
> > >is more likely to be developed for phones.   it doesn't
> > >have to be that way though.
> > >
> > > >
> > > > 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.
> > >
> > >"may" is the key word here.  i think the reference to "many SIP UA"
> > >is also more of a reference to devices like sip phones than
> > anything else
> > >and i tend to agree that such devices may not be ideal candidates for
> > >SNMP management.
> > >
> > >sip user agents that reside on platforms acting as sip gateways
> > >between pstn and ip networks (eg, routers) are more likely to
> > >already be managed by snmp and be perfect candidates for snmp
> > >management.
> > >
> > >likewise, other sip infrastructure type devices like proxy servers
> > >are also good candiates for snmp management.
> > >
> > >when sip services are another aspect of what service providers are
> > >offering their customers and those services are being offered as
> > >software upgrades to devices that are already part of their
> > >infrastructure, there is going to be an expectation for snmp
> > >network management because they are already using snmp.  having
> > >a complete "picture" of the network from one management application
> > >implies that potentially all sip devices should be considered
> > >for snmp managability... at least all sip devices that are
> > >critical to that service provider maintaining control of the
> > >sip service.
> > >
> > > >
> > > > 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.
> > >
> > >is snmp routinely blocked by firewalls because of it's
> > >ability to interigate snmp-managable devices on the
> > >enterprise networks??   it is up to enterprises to
> > >do minimal things like change the community strings
> > >snmp agents answer to form the obvious "public".
> > >and now there is more security options with SNMPv3
> > >(not i don't think they are widely used at this point).
> > >
> > >
> > > >
> > > > 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.
> > >
> > >not sure why snmp is considered a limiting factor here.
> > >what's wrong with a ua to coming up, send a trap to
> > >say "i'm alive and need some config".  then the snmp manager
> > >who catches that trap would come down with snmp set operations
> > >to configure the device.  depending on how the manager is setup
> > >to behave, generic coldStart or warmStart traps from a known
> > >set of devices would be sufficient to get this started.
> > >
> > >if the unreliablility of a trap/notif is a problem, then
> > >informs could be used as they expect a response from the
> > >manager back to the agent.
> > >
> > >admittedly, we have not addressed any such ideas on the sip mib
> > >work done thus far.   that is not to say that it could not be
> > >done in the future as an additional sip mib module.
> > >
> > >my view is there needs to be some "meeting of the minds" between
> > >the sip-config and the sip-mib teams at some point to see what
> > >commonalities exist and where the true differences are.  we are
> > >both very much in the business of "sip configuration".  the sip-mib
> > >team just has a predisposition to the protocol that is used.
> > >
> > >btw, myself and the other authors of the sip mib draft will
> > >be attending ietf 50.  perhaps we could discuss this more then?
> > >
> > >kevin
> > > >
> > > > 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.
> > > > > >
> > > > > >
> > > > > >
> > >--
> > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > -=-=-=-=-=
> > >  Kevin R. Lingle       919.392.2029
> > >  checkout:
>http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police.html
> >  Sometimes I think I understand everything, then I regain consciousness.
> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >
> >------------------------ Yahoo! Groups Sponsor ---------------------~-~>
> >Find software faster. Search more than 20,000
> >software solutions on KnowledgeStorm. Register
> >now and get started.
> >http://us.click.yahoo.com/._XvHB/uMSCAA/zf4EAA/WNqXlB/TM
> >---------------------------------------------------------------------_->
> >
> >To unsubscribe from this group, send an email to:
> >[email-masked]
> >
> >
> >
> >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Mar 2001 17:19:59 -0500

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Monday, March 05, 2001 3:17 PM
> To: 'Rohan Mahy'
> Cc: Daniel G. Petrie; IETF SIP (E-mail); [email-masked]
> Subject: RE: [sip-config] Re: [SIP]
> draft-petrie-sip-config-framework-00.t xt
> 
> 
> Actually, I don't agree.
> 

Let me also point out a relevant passage of draft-ietf-sip-guidelines:

There are many network layer services needed to make SIP function.
   These include quality of service, mobility, and security, among
   others. Rather than building these capabilities into SIP itself, they
   should be developed outside of SIP, and then used by it.
   Specifically, any protocol mechanisms that are needed by SIP, but are
   also needed by many other application layer protocols, should not be
   addressed within SIP.

and

 While the first criteria might seem obvious, we have observed that
   numerous extensions to SIP have been proposed because some function
   is needed in a device which also speaks SIP. The argument is
   generally given that "I'd rather implement one protocol than many".
   As an example, user agents, like all other IP hosts, need some way to
   obtain their IP address. This is generally done through DHCP [2].
   SIPs multicast registration mechanisms might supply an alternate way
   to obtain an IP address. This would eliminate the need for DHCP in
   clients. However, we do not believe such extensions are appropriate.
   We believe that protocols should be defined to provide specific,
   narrow functions, rather than being defined based on all
   communications requirements between a pair of devices. The latter
   approach to protocol design yields modular protocols with broad
   application. It also facilitates extensibility and growth; single
   protocols can be removed and changed without affecting the entire
   system. We observe that this approach to protocol engineering mirrors
   object oriented software engineering.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 05 Mar 2001 15:23:07 -0800

Jonathan,

Daniel's draft proposes sending a NOTIFY with a list of URIs which 
represent the location of config data.  SIP is not used to fetch the actual 
config data.

In the past, you supported uploading an entire CPL script using 
REGISTER.  Would you object to getting a list of config URLs in the 200 OK 
of a REGISTER instead?

thanks,
-rohan

At 02:19 PM 3/5/01 , Jonathan Rosenberg wrote:
>[snip]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Mar 2001 22:53:12 -0500

> Sent: Monday, March 05, 2001 6:23 PM
> To: Jonathan Rosenberg
> Cc: 'Rosen, Brian'; Daniel G. Petrie; IETF SIP (E-mail);

REGISTER is an odd beast, since its purpose in life is configuration in the
first place. The guidelines draft talks about that also.

-Jonathan R.

---