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

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

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.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 05 Mar 2001 10:31:15 -0500

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-sip-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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 5 Mar 2001 07:58:15 -0800 (PST)

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

 > hard time allowing SNMP into their enterprise LAN from

   Well, they don't allow SIP either so something
   is going to have to give. 

 > 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"

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 05 Mar 2001 11:15:03 -0500

"Daniel G. Petrie" wrote:

> autonomy of the end point.

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?

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

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Kevin Lingle <[email-masked]>
Date: Mon, 05 Mar 2001 11:37:47 -0500

caveat:  i have not yet read this draft.  i have only briefly looked
at previous drafts from this sip-config initiative.

> - how easy is it to configure the destination of traps? Is this done

yes.  in the past vendors generally developed their own mib variables
for trap destination configuration.  now we have SNMP-TARGET-MIB
(RFC 2573) that formalizes/standardized this.

> a certain minimum size. The MIB agent on Sun is 154320, which doesn't

i'm sure there are.  the size of an agent has so much to do with what
the mib support is that it's difficult to arrive at any rule of thumb.
it can also vary based on other factors like whether you have a monolithic
agent entity or a minimal master agent w/ subagents handling the various
mibs you support.

kevin
> ------------------------ 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/

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

---

From: Kevin Lingle <[email-masked]>
Date: Mon, 05 Mar 2001 12:34:58 -0500

> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sip-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.

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

> hard time allowing SNMP into their enterprise LAN from

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

> 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

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 05 Mar 2001 13:16:38 -0500

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

---

From: Roy Smith <[email-masked]>
Date: Mon, 05 Mar 2001 14:31:12 -0500

Before it gets configed, how does it know where to send the trap?

--On Monday, March 5, 2001 12:34 PM -0500 Kevin Lingle <[email-masked]> wrote:
> say "i'm alive and need some config".

--
Roy Smith
Staff Engineer
Visionary Model Development
[email-masked]
+1 914 747 7612

---

From: Roy Smith <[email-masked]>
Date: Mon, 05 Mar 2001 14:35:31 -0500

"Daniel G. Petrie" <[email-masked]> wrote:
> hurdle of ability.

On the other hand, the more ability SIP has to alter device configurations, the less likely, I suspect, network admins will be willing to 
let it in.  It's a lot easier to persue the "please punch a hole for me" argument if the size of the hole you need is small.

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 05 Mar 2001 12:08:09 -0800

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:
>e> There is probably little proposed in this spec that