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

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

> 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".
Yes, I will.

> 
> 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..
There are very few scenarios where the entity that manages the phone
is not the entity that deals with configuration.  In almost every system
I know, they are one and the same.

There is very often a lot of systems between the thing that initiates
a change in configuration (which might be, for example, the user interacting
with a web page), and the thing that actually changes the configuration
itself.
All of that is often, these days, automated.  There are few systems where
there is not at least a policy server between the user request and the
configuration change agent.  The kinds of systems we were actually
discussing
seemed to be an outsourced service where the management system and the
configuration agent were outside an enterprise firewall.  Those kinds of
systems clearly are like what I describe.  A more prosaic internal system
may not have too much, but it's not exactly completely open (any user
can configure his phone any way he wants).  In the latter, it's the network
guys (who use SNMP) that manage the phone system.  Giving them a different
tool will not be appreciated.

> 
> 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?
Actually, my laptop is configured by SMS, which doesn't use SNMP, but
should.
If the IETF did it, it probably would :)

But to answer your question, yes, I actually do expect that SNMP will be
used
to configure the phone.  It's not static (the configuration is not
completely
stored in the phone), and it's a big deal when it breaks, requiring a pretty
good, very reliable mechanism to diagnose and repair whatever ails it.
That's a job for SNMP (v3, please).

Brian
> 
> 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.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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.
> > > >
> > > >--
> > > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > -=-=-=-=-=
> > > >  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/

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 6 Mar 2001 08:24:49 -0800 (PST)

I think it's important to separate out:

1) SNMP, the transport vehicle
2) SNMP MIBS, the configuration schema
3) Device Configuration
4) User Configuration

In particular, device configuration does not
necessarily equate to user configuration, any more
than /etc/.login equates to ~thomasm/.login. The
device may, in fact, allow transient user
preferences to be loaded into the UA while that
user is "logged in". The source of those
preferences is a matter of local policy:
some deployments may want them to come from
a centrally maintained data store, others --
and in particular the "public phone" may
need to pull them in from whereever the
user has its data store. 

I believe that the latter is, in fact, a superset
of the former and in all cases, there is going to
have to be a binding between the user and the
device (logging in) and the device and the
ultimate data store (logging into the file
server).

As far as SNMP goes, I don't think that SNMP is
the final word on configuration qua configuration.
In fact, SNMP is somewhat schizophrenic about
whether it's a monitoring tool or a monitoring and
configuration tool; the former being far more
pervasive than the latter. There are many, many
other ways to accomplish configuration, and I
really don't think that we should be hide-bound
about SNMP in all cases, in all situations. Also:
we need to be careful about SNMP's overhead. SNMP
is a peek-poke protocol and it's not very good at
bulk transfers (which is why the
DOCSIS/Packetcable specs always use
SNMP-in-TFTP-config-files).

In fact, the user preferences case may not be an
especially good fit for SNMP; An HTTP scheme with
XML may be better. Perhaps using SIP REGISTER's
with a MIME attachment makes sense too (I believe
that Henning suggested this once upon a time). It
seems to me that the choice of transport and
schema is far more likely to be bound up in the
means that the user is cryptographically
identified and authorized which is going to limit
the candidate transport protocols pretty severely
since there is very spotty coverage of standard
authentication mechanisms to standard transport
candidates.

		Mike