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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 6 Mar 2001 11:38:49 -0500

I also don't want to beat SNMP as a does-everything-right protocol.
I just don't want to process a big extension to SIP that
duplicates what SNMP does well, and I don't to standardize a
new infrastructure if we don't need one.  Putting out
a standardized XML DTD for user preferences, if that is really
useful, might make some sense.  I wonder if we a really ready
for that (could we agree on what is in it, and is that more
important than other work we are doing?)

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 11:25 AM
> To: Rosen, Brian
> Cc: 'Rohan Mahy'; Daniel G. Petrie; IETF SIP (E-mail);
> [email-masked]
> Subject: RE: [SIP] RE: [sip-config] Re: [SIP]
> draft-petrie-sip-config-fram ework-00.t xt
> 
> 
> 
> 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
> 
> Rosen, Brian writes:
>  > 
>  > > 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.
> 

_______________________________________________
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 09:24:41 -0800 (PST)

I'm not sure who "we" is here, but mime
attachments make just about everything into a
potential transport protocol with much less
effort, including SIP :-)

I do know that Packetcable is working on an XML
schema for configuring call agents which is,
essentially, a SIP UA. Heck, it may even be
advantageous to have a mechanical XML->MIB
translator for this schema and support both so we
don't have to have a religious MIB/XML
angels-on-a-pinhead argument.

[and no, I don't mean this kind of shortcut:

sipConfigMibXMLstring OBJECT-TYPE
    SYNTAX	OCTET STRING
    MAX-ACCESS	read-write
    STATUS	current
    DESCRIPTION 
	"This variable contains the XML string
         which configures SIP devices"
    ::= { sipConfigMibXMLstring 2 }
]