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

Spencer Dawkins <spencer@wonderhamster.org> Tue, 06 March 2012 18:16 UTC

Return-Path: <spencer@wonderhamster.org>
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 D42F021F88B8 for <martini@ietfa.amsl.com>; Tue, 6 Mar 2012 10:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AlRLwKHK6GUt for <martini@ietfa.amsl.com>; Tue, 6 Mar 2012 10:16:21 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D46B021F8842 for <martini@ietf.org>; Tue, 6 Mar 2012 10:16:20 -0800 (PST)
Received: from [10.252.1.44] (host225-111.cablelabs.com [192.160.73.225]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MHoSj-1S6MVW3zTh-003LtW; Tue, 06 Mar 2012 13:16:18 -0500
Message-ID: <4F565466.5070600@wonderhamster.org>
Date: Tue, 06 Mar 2012 12:16:06 -0600
From: Spencer Dawkins <spencer@wonderhamster.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
References: <20120301213913.CC43BB1E004@rfc-editor.org> <4F4FF375.60607@nostrum.com>
In-Reply-To: <4F4FF375.60607@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V02:K0:LCdrqgp2tHmF9iwULuuUwfOOWb3pLRawvmRQUJAhZG5 ZcpMmDwpLY1qZlG3w5u0PxVRJcQU1oraX2keyMeq3i5TgaZ9Pt sY0haFNlbt/lFV51CfF4/N6fFbH7siioqw/O0aTlJN/FKCM+tE 7k2jiKOvppobD0V2J4mFcPHvQuR1ydukovGD0bhhPGX1XYeZqf AzqLaaKp8FHFuzCrOXDCQ6f8rZ6fmvbhZhCL4gJKJIKX7FpQiq S98IFdwocKs5J8bvR+uhd48WyqTjigoULWSubUR2nSLxbUnF7D AcQ0hyLa6B9jCW7CP8rcDcF/UqATD62bP1cAamomr+reupCsKi HOD/bkXzS933SKMVXtQ7tyQMd/cJC6lqQTu5bgUuP
Cc: gonzalo.camarillo@ericsson.com, martini@ietf.org, RFC Errata System <rfc-editor@rfc-editor.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: Tue, 06 Mar 2012 18:16:22 -0000

On 3/1/2012 4:08 PM, Adam Roach wrote:
> 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

Adam, I agree ...

Gonzalo, I'm looking at 
http://www.ietf.org/iesg/statement/errata-processing.html, and it looks 
like the IESG would be evaluating this, since the MARTINI working group 
has closed.

Do the (former) chairs need to do anything, except possibly say, "we 
agree with Adam"?

It would be helpful for the SIPconnectIT discussions at SIP Forum to 
know whether this errata is approved (they're looking at SIPconnect 
interop test cases, and CableLabs has already identified this issue in 
interop testing).

Thanks,

Spencer

> 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
>
>