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

From: EKR <[email-masked]>
Date: Mon, 06 Nov 2006 00:19:08 -0800

$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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Nov 2006 06:57:33 -0800

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Nov 2006 13:31:11 -0500

Let me chime in here and agree with Henning and Ekr on this. I too have 
complained, at several past meetings, that I think the merging stuff is 
way too complicated and not worth the incremental benefit. For this 
reason most implementations remain proprietary and have not adopted this 
specification.

-Jonathan R.

Henning Schulzrinne wrote:

> 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.
> 
> 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.
> 
> 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.
> 
> left to take out. I don't think we've even tried to have this  discussion.
> 
> Henning
> 
>>   and in the fourth there is only some very limited set of well- defined

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: David Robbins <[email-masked]>
Date: Thu, 16 Nov 2006 22:09:04 -0500

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?

>>   there some reason we can't use the SIP DHCP option?
Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128