Subject: RE: [Sipping] Comments on draft-ietf-sipping-config-framework-09

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 17 Nov 2006 08:17:03 -0700

David,

As per the ad-hoc discussions that happened at the last IETF, we have
quite a few organizations interested in this approach.

Speaking personally, the CableLabs PacketCable PACM framework utilizes
this. The public specifications are available at:
http://www.packetcable.com 
, for your reference. This effort was the collective result of various
organizations.

The efforts in PACM looked at various approaches and found that a SIP
based configuration framework in conjunction with XCAP made the most
sense (details in the specifications or I can take it offline).

As indicated by a few others, it would be nice to complete this effort
in the best possible manner (sooner than later).

Thanks!
- S

-----Original Message-----
From: David Robbins [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 8:09 PM
To: sipping
Subject: Re: [Sipping] Comments on
draft-ietf-sipping-config-framework-09

This framework has been around for a while, and I'm curious as to how
much acceptance it is receiving in the industry. Can anybody on this
list comment on the extent to which SIP device vendors have adopted it
or are planning on adopting it?

Some of you may be aware that in the subset of the industry that pays
attention to the DSL Forum, TR-104 in conjunction with TR-69 is getting
some traction for SIP device management, including configuration. Is the
IETF SIP configuration framework getting comparable traction?

My company has adopted the IETF framework, for one project, roughly as
it was defined in mid-2005 (but without the merging behavior, whose
issues many of you have noted). Will we see wider adoption of this
framework? Is there a broad constituency for this framework, whether
simplified or complexified?

On Nov 6, 2006, at 9:57 AM, Henning Schulzrinne wrote:

> I think this is a good example of a draft that gets less useful by 
> having been around for many, many years. As years and IETF meetings 
> accumulate, more and more stuff gets added, without any real 
> indication that there is a constituency for them. Nobody seems to be 
> paying much attention to the draft, so there's little pushback on 
> feature creep.
>
> Just as for consent and in SIMPLE, I think it's time to step back and 
> see if we can't get 90% of the benefit with 10% of the effort, and 
> maybe scoping the problem so that other features can be added later, 
> if there is demonstrated demand for them. Unfortunately, this draft 
> has become a posterchild on why people consider SIP to be far too 
> complex.
>
> I had said this before, but I'll repeat that I still find the merging 
> stuff far too messy and unpredictable to be useful. (It is difficult 
> for any of the parties to know what exactly happened in the end, 
> making debugging and troubleshooting difficult.) A simple alternative 
> is to designate parameters for each role and only allow certain 
> entities to set them.
>
> The old saying went that a draft isn't finished until there's nothing 
> left to take out. I don't think we've even tried to have this 
> discussion.
>
> Henning
>
> On Nov 6, 2006, at 12:19 AM, EKR wrote:
>
>> $Id: draft-ietf-sipping-config-framework-09-rev.txt,v 1.2 2006/10/25
>> 18:52:13 ekr Exp $
>>
>> I'm fairly naive about SIP UAs and configuration, but this document 
>> strikes me as an extremely complex approach to what's really a fairly

>> simple problem. As I understand the problem space from reading the 
>> draft, there are four main use cases:
>>
>> (1) Plug a naive (out of the box) SIP UA into a network and have
>>     it "just work" like a POTS UA does with no additional 
>> configuration
>>     provided.
>> (2) Have a user be able to provide some identifying information
>>     about a SIP UA (E.g., the MAC address) to some management
>>     console and then have the UA be able to configure itself.
>>     Arguably this is a subcase of (1).
>> (3) Have a user be able to register with some SIP service provider
>>     via some undefined out-of-band mechanism and have that service
>>     provider give them a URL and some authentication credentials
>>     which they can feed to their UA and their UA can use to get
>>     configured.
>> (4) Have a user be able to take a preconfigured SIP UA to a new
>>     network environment and get the new network access information
>>     (e.g., a hotel proxy) while retaining the original configuration
>>     information (the AOR, keying material, etc.)
>>
>> Arguably, something based on this document could do this job--though 
>> note that this document alone cannot because it doesn't actually 
>> specify any of the relevant parameters--but it's not clear that all 
>> near the complexity in this protocol is required. In
>> particular:
>>
>> - I don't see why it's necessary to have three tiers of configuration
>>   data (local network, device, and user) which must somehow be
merged.
>>   In the first three cases, ISTM that you really only have one tier
>>   and in the fourth there is only some very limited set of 
>> well-defined
>>   information, namely the local proxy. It's not like you want a
>>   hotel proxy to even be able to specify what you should be using
>>   as your SIP AOR!
>>
>> - Multiple mechanisms for profile retrieval. As I understand 8.4, a
UA
>>   can get its profile either via SIP or via an external reference
>>   in a NOTIFY. Let's keep life simple.
>>
>> - The mechanisms for discovering the URI seem extremely complicated.
>>   Currently, there are different mechanisms for each of the three
>>   URI types. If we collapse this down to a single type then is
>>   there some reason we can't use the SIP DHCP option?
>>
>> -Ekr
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use 
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments of core SIP
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
>
>
Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Nov 2006 09:56:07 -0600

> in the best possible manner (sooner than later).

For those not familiar with it the PacketCable specifications provide  
the basis for the delivery of conventional-looking telephone services  
over cable television networks. This approach has broad deployment in  
North America and is picking up (although occasionally with minor  
specification variance) in other geographies. Current deployments are  
in the millions, and some industry forecasts predict tens of millions  
over the next few years. Residential phone adapters for PacketCable  
are made  in quantity by large consumer electronics providers  
including Motorola, Linksys (and Siemens, I think) as well as a  
number of possibly less-well-known providers.

So yeah, the config framework has an adequate constituency.

--
Dean

---

From: "Gardell, Steven" <[email-masked]>
Date: Wed, 22 Nov 2006 09:27:36 -0500

Has there been any discussion of using this framework for configuring
Gateway behavior? (In other words for configuring the moral equivalent
of Cisco Dial peer's) In a large network managing these on a per-device
basis can become quite burdensome, so some centralized mechanism is
desirable. On one hand, the specification seems flexible enough to allow

this, on the other hand it seems to be beyond the intent.

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Friday, November 17, 2006 10:17 AM
To: David Robbins; sipping
Subject: RE: [Sipping] Comments on

David,

Thanks!
- S

-----Original Message-----
From: David Robbins [mailto:[email-masked]]
Sent: Thursday, November 16, 2006 8:09 PM
To: sipping
Subject: Re: [Sipping] Comments on

merged.
UA
Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128