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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Sun, 18 March 2012 07:48 UTC

Return-Path: <gonzalo.camarillo@ericsson.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 1F09121F85C7 for <martini@ietfa.amsl.com>; Sun, 18 Mar 2012 00:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.346
X-Spam-Level:
X-Spam-Status: No, score=-110.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 sAkPFntAotVN for <martini@ietfa.amsl.com>; Sun, 18 Mar 2012 00:48:18 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 263EA21F85C5 for <martini@ietf.org>; Sun, 18 Mar 2012 00:48:17 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-bb-4f65933fb19a
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id ED.E7.27041.F33956F4; Sun, 18 Mar 2012 08:48:15 +0100 (CET)
Received: from [131.160.126.134] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Sun, 18 Mar 2012 08:48:15 +0100
Message-ID: <4F65933E.9040506@ericsson.com>
Date: Sun, 18 Mar 2012 09:48:14 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Spencer Dawkins <spencer@wonderhamster.org>
References: <20120301213913.CC43BB1E004@rfc-editor.org> <4F4FF375.60607@nostrum.com> <4F565466.5070600@wonderhamster.org>
In-Reply-To: <4F565466.5070600@wonderhamster.org>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Tue, 20 Mar 2012 13:45:37 -0700
Cc: "martini@ietf.org" <martini@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "rjsparks@nostrum.com" <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: Sun, 18 Mar 2012 07:48:19 -0000

Hi Spencer,

no, you do not have anything else (beyond saying you agree with Adam).
We will "verify" the erratum so that everybody can see it is correct.

Thanks,

Gonzalo

On 06/03/2012 8:16 PM, Spencer Dawkins wrote:
> 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
>>
>>
>