Last Call results for draft-lawrence-sipforum-user-agent-config

Scott Lawrence <xmlscott@gmail.com> Wed, 21 April 2010 16:52 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 8CA9F3A6968 for <ietf@core3.amsl.com>; Wed, 21 Apr 2010 09:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level:
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_05=-1.11]
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 l7MHcdHp-me0 for <ietf@core3.amsl.com>; Wed, 21 Apr 2010 09:52:42 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id 87D9128C433 for <ietf@ietf.org>; Wed, 21 Apr 2010 09:30:42 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id 8DMb1e00A0ldTLk5EGWZeD; Wed, 21 Apr 2010 16:30:33 +0000
Received: from [192.168.10.11] ([98.229.134.198]) by omta04.westchester.pa.mail.comcast.net with comcast id 8GWZ1e00D4H02bE3QGWZZy; Wed, 21 Apr 2010 16:30:33 +0000
Subject: Last Call results for draft-lawrence-sipforum-user-agent-config
From: Scott Lawrence <xmlscott@gmail.com>
To: IETF-Discussion list <ietf@ietf.org>
In-Reply-To: <1271340180.27093.81.camel@localhost>
References: <20100415135522.DC3FB3A6896@core3.amsl.com> <1271340180.27093.81.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 21 Apr 2010 12:30:32 -0400
Message-ID: <1271867432.12457.608.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12)
Content-Transfer-Encoding: 7bit
Cc: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
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, 21 Apr 2010 16:52:43 -0000

The IETF Last Call draft-lawrence-sipforum-user-agent-config ended
yesterday (it began 2010-03-23).

> > Abstract:
> > This document defines procedures for how a SIP User Agent should
> > locate, retrieve, and maintain current configuration information from
> > a Configuration Service.
> > 
> > This document is the product of the SIP Forum Technical Working Group
> > User Agent Configuration Task Group.

There were a number of reviews on this list, including a substantial
thread on whether or not there should be an alternative mechanism for
updating configurations, because the SIP subscription required by draft
00 was seen to be more than was needed in some deployment environments.

On 04-15, an 01 draft was published that addressed that issue and a
couple of editorial issues:

> Change Summary:
> 
>       * The major change is to provide the Configuration Service a
>         choice of whether to require the User Agent to create a change
>         notice subscription or to require the User Agent to poll for
>         changes using HTTP.  The User Agent is required to support both
>         and use whichever mechanism the CS chooses.
> 
>       * There is small correction to the expression of the U-NAPTR
>         regular expression to make it exactly match the one in RFC 4848.
> 
>       * The wording in the Scope section was changed from 'is free to'
>         to 'MAY'.
> 
> The specifics of the changes can be generated at:
> https://datatracker.ietf.org/doc/draft-lawrence-sipforum-user-agent-config/

The remaining issues that were raised in the discussion were questions
regarding whether or not the level of detail in the draft on various
protocol usages (such as which parameters must be used from DHCP) were
appropriate (could have been replaced by pointers to other RFCs).  Since
this document is intended to serve as a guide to implementing and
deploying a comprehensive configuration service, the authors feel that
carefully specifying the minimum usages is useful.

The authors believe that the 01 draft appropriately responds to all the
issues raised during Last Call.