Re: [martini] [Technical Errata Reported] RFC6140 (3144)

Adam Roach <adam@nostrum.com> Thu, 01 March 2012 22:09 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: martini@ietfa.amsl.com
Delivered-To: martini@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A5121E82FD for <martini@ietfa.amsl.com>; Thu, 1 Mar 2012 14:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.338
X-Spam-Level:
X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHV5UlRiQ5Nc for <martini@ietfa.amsl.com>; Thu, 1 Mar 2012 14:09:01 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D721E8018 for <martini@ietf.org>; Thu, 1 Mar 2012 14:09:01 -0800 (PST)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q21M8s8d043911 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 16:08:55 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4F4FF375.60607@nostrum.com>
Date: Thu, 01 Mar 2012 16:08:53 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20120301213913.CC43BB1E004@rfc-editor.org>
In-Reply-To: <20120301213913.CC43BB1E004@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: gonzalo.camarillo@ericsson.com, martini@ietf.org, rjsparks@nostrum.com
Subject: Re: [martini] [Technical Errata Reported] RFC6140 (3144)
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 22:09:02 -0000

This issue has already caused substantial confusion. The behavior that 
David proposes was clearly the intention of the working group, based on 
the discussions that went into development of the document. I believe 
the proper classification (based on the criteria published at 
http://www.ietf.org/iesg/statement/errata-processing.html) is "Approved."

/a

On 3/1/12 3:39 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC6140,
> "Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6140&eid=3144
>
> --------------------------------------
> Type: Technical
> Reported by: David Hancock<d.hancock@cablelabs.com>
>
> Section: 5.2
>
> Original Text
> -------------
> <none -- new text being added>
>
> Corrected Text
> --------------
> <Insert following new paragraph between existing 2nd and 3rd paragraph>
>
> The registrar MUST populate the Contact header field of the 200 (OK) response
> to REGISTER only with the explicitly registered Contact URIs identified in the
> REGISTER request (i.e., for bulk number registration, the Contact URIs
> containing the “bnc” parameter). The Contact header field of the 200 (OK)
> response MUST NOT contain the multiple contact addresses that are implicitly
> created by the bulk number registration procedure.
>
> Notes
> -----
> The proposed text clarifies how the MUST statement in RFC 3261 section 10.3 item-8 applies in the case of bulk number registration.
>
> RFC 3261 section 10.3 item-8 says ...
> 8. The registrar returns a 200 (OK) response.  The response MUST
>     contain Contact header field values enumerating all current
>     bindings.<... text deleted...>
>
> For bulk number registration, this means that the Contact header field in the 200 (OK) response to REGISTER contains the Contact URI with the "bnc" parameter, and not the multiple derived contact URIs that are bound to the multiple E.164 numbers associated with the registering PBX.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6140 (draft-ietf-martini-gin-13)
> --------------------------------------
> Title               : Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)
> Publication Date    : March 2011
> Author(s)           : A.B. Roach
> Category            : PROPOSED STANDARD
> Source              : Multiple AoR reachabiliTy InformatioN Indication
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG