Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

Scott Lawrence <xmlscott@gmail.com> Wed, 07 April 2010 18:04 UTC

Return-Path: <xmlscott@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4343A68F8 for <ietf@core3.amsl.com>; Wed, 7 Apr 2010 11:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.15
X-Spam-Level:
X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk5OLRYE2i4S for <ietf@core3.amsl.com>; Wed, 7 Apr 2010 11:04:34 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 1544128C0E4 for <ietf@ietf.org>; Wed, 7 Apr 2010 11:04:30 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id 2bDd1e0061c6gX85Ai4VEF; Wed, 07 Apr 2010 18:04:29 +0000
Received: from [192.168.10.10] ([98.229.134.198]) by omta23.westchester.pa.mail.comcast.net with comcast id 2i8P1e0084H02bE3ji8PYW; Wed, 07 Apr 2010 18:08:24 +0000
Subject: Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
From: Scott Lawrence <xmlscott@gmail.com>
To: dcrocker@bbiw.net
In-Reply-To: <4BBCABE8.5000506@dcrocker.net>
References: <430FC6BDED356B4C8498F634416644A91A79E92FC7@mail> <2AA0BE29-340C-4C8E-8541-087C9A9EE2D2@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CBFD@mail> <1270492215.30814.227.camel@localhost> <430FC6BDED356B4C8498F634416644A91A79F3CC6D@mail> <1270497302.30814.265.camel@localhost> <430FC6BDED356B4C8498F634416644A91A79F3CCE0@mail> <04CD732B-2D7D-45E5-8ED8-A0B27E5BAB8B@cisco.com> <4BBB602C.3050400@dcrocker.net> <1270571685.30814.404.camel@localhost> <4BBCABE8.5000506@dcrocker.net>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 07 Apr 2010 14:04:26 -0400
Message-ID: <1270663466.2210.136.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12)
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 18:04:35 -0000

On Wed, 2010-04-07 at 08:59 -0700, Dave CROCKER wrote:
> 
> On 4/6/2010 9:34 AM, Scott Lawrence wrote:
> >> What is the justification that mandates a more complex model than
> >> these use?  It's not usually considered sufficient to simply cite the fact that
> >> some operators somewhere want something different.  There needs to be a
> >> compelling case made.
> >>
> >> It is always possible to invent edge cases that appear to justify a different
> >> paradigm.  The real question is about real need.
> >
> > The configuration data we're discussing here is substantially more
> > complex and more important to the operation of the device than the
> > information provided by either DHCP or DNS.
> 
> The data are more "important" than the device's IP Address?
> 
> As for "complexity", I don't see how the choice of update mechanism is affected 
> by data complexity.

Spenser was correct in complexity analogy, but there's more to it than
that.  In SIP (at least in the phone/communication systems I'm most
familiar with) the functionality of the system as a whole is distributed
- some things are done in a proxy, some are done in various 'feature
servers', and many things are done in the UAs themselves.  For many
changes in 'phone system' behavior to be done correctly, one must change
the behavior of the UAs at the edge.  Pushing intelligence out to the
edge has many nice scaling and evolution qualities, but it has downsides
too; specifically the need to be able to modify configuration data in
many devices at the edge of the network.

Typical SIP phones have hundreds of configuration parameters - the few
that are listed here are not the ones that would need changing
frequently.  Since there is no standard for what those parameters are or
how they are expressed, they are not in scope for this spec (personally,
I'd have left all of section 3 out).