[martini] Fw: Apps Area Review team review: draft-ietf-martini-gin-10.txt

"Spencer Dawkins" <spencer@wonderhamster.org> Tue, 30 November 2010 22:33 UTC

Return-Path: <spencer@wonderhamster.org>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475D03A6C41 for <martini@core3.amsl.com>; Tue, 30 Nov 2010 14:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.531
X-Spam-Level:
X-Spam-Status: No, score=-101.531 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100]
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 sMUy5DuKqUC0 for <martini@core3.amsl.com>; Tue, 30 Nov 2010 14:33:47 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A597D3A6C3C for <martini@ietf.org>; Tue, 30 Nov 2010 14:33:46 -0800 (PST)
Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MGAm7-1P9U2A15br-00FHPV; Tue, 30 Nov 2010 17:34:58 -0500
Message-ID: <B2531FFA0FB3485A9F8854BF4AAF816F@china.huawei.com>
From: "Spencer Dawkins" <spencer@wonderhamster.org>
To: <martini@ietf.org>
Date: Tue, 30 Nov 2010 16:34:54 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
X-Provags-ID: V02:K0:TjOrpByIW6PXAgiVuyQvLa1ZEOUPNEoRUJ1xszbD9eX 1bFugGo4Zqda8ldg2s6xAasqL04Vjs1NR53BoPGjixiSaYf+sU A28COJ4DW3H7TTFdrCVBDJGO0t0GhXhyheEWEP5tloI7Y6AkEn T1bzJi8Ge/1IusHxYxR3/demZsxcbwUEuwZOD0C2ucolxPzNeg w9NwOTKuIP8JiUzkonXPtKT5lukV+9aod5YHzND13U=
Subject: [martini] Fw: Apps Area Review team review: draft-ietf-martini-gin-10.txt
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 30 Nov 2010 22:33:48 -0000

Just to keep the working group in the loop ...

Spencer

----- Original Message ----- 
From: "Ted Hardie" <ted.ietf@gmail.com>
To: "Apps Discuss" <discuss@ietf.org>rg>; <adam@nostrum.com>om>; "Bernard Aboba" 
<bernard_aboba@hotmail.com>om>; "Spencer Dawkins" <spencer@wonderhamster.org>rg>; 
"IESG" <iesg@ietf.org>
Sent: Tuesday, November 30, 2010 4:11 PM
Subject: Apps Area Review team review: draft-ietf-martini-gin-10.txt


>I have been selected as the Applications Area Review Team reviewer for
> this draft
> (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
> Please resolve these comments along with any other Last Call comments
> you may receive.
> Please wait for direction from your document shepherd or AD before
> posting a new version of the draft.
>
> Document: draft-ietf-martini-gin-10.txt
> Title: Registration for Multiple Phone Numbers in the Session
> Initiation Protocol (SIP)
> Reviewer:Ted Hardie
> Review Date: November 30, 2010
>
> Summary: This draft is ready for publication as a proposed standard,
> with a few editorial issues
> which the author or working group may wish to consider.
>
> Major Issues: None identified.
>
> Minor Issues:
>
> In the "Constraints" section, the document notes:
>
>  The following paragraph is perhaps the most important in
>   understanding the reasons for the design decisions made in this
>   document.
>
>   Within the problem space that has been established for this work,
>   several constraints shape our solution.  These are defined in the
>   MARTINI requirements document [18].  In terms of impact to the
>   solution at hand, the following two constraints have the most
>   profound effect: (1) The SIP-PBX cannot be assumed to be assigned a
>   static IP address; and (2) No DNS entry can be relied upon to
>   consistently resolve to the IP address of the SIP-PBX.
>
> I suggest augmenting the pointer to the requirements document
> here with a pointer to Appendix A, which helpfully lists how
> the document meets the requirements (note however that the
> Appendix apparently elides requirements 18, 19, and 20 without
> comment).  Given the existence of appendix A, I am not personally
> certain I see the need for the first of the two paragraphs.
>
> In section 5.1, the document says:
>
>  The "bnc" URI parameter indicates that special interpretation of the
>   Contact URI is necessary: instead of representing a single, concrete
>   Contact URI to be inserted into the location service, it represents
>   multiple URIs (one for each associated AOR), semantically resulting
>   in multiple AOR-to-Contact rows in the location service.
>
> Saying that the URI parameter represents multiple URIs will bend
> the brain of URI folks a bit, and the later text in 5.2 avoids this
> same issue:
>
>   After the SIP-PBX is authenticated, the registrar
>   updates its location service with a unique AOR-to-Contact mapping for
>   each of the AORs associated with the SIP-PBX.  Semantically, each of
>   these mappings will be treated as a unique row in the location
>   service.  The actual implementation may, of course, perform internal
>   optimizations to reduce the amount of memory used to store such
>   information.
>
> I suggest using similar language for the 5.1 text, for example:
>
>  The "bnc" URI parameter indicates that special interpretation of the
>   Contact URI is necessary: instead of indicating the insertion of a 
> single
>   Contact URI into the location service, it indicates that
>   multiple URIs (one for each associated AOR) should be inserted.
>
> Section 7.4 contains two elements which it may be appropriate to consider
> for inclusion in the Security Considerations.  The first of these is that
> proxies will not be able to apply policy decisions on as granular a basis 
> as
> before:
>
>   Proxies will be unable to make policy decisions on a
>   contact-by-contact basis regarding whether to include themselves in
>   the path.  Second, and similarly, all AORs on the SIP-PBX that are
>   registered with a common REGISTER request will be forced to share a
>   common Service-Route.
>
> Would this extend to proxies including themselves for the purposes of
> CALEA?  If so, this might be a privacy issue.  Similarly,  this text:
>
>   This token or cookie may convey information
>   to proxies about the identity, capabilities, and/or policies
>   associated with the user.  Since this information will be shared
>   among several AORs and several Contacts when multiple AOR
>   registration is employed, care should be taken to ensure that doing
>   so is acceptable for all AORs and all Contacts registered in a single
>   REGISTER request.
>
> might properly be considered in the privacy portion of a Security
> Considerations section.  Back pointers to one or both sections may
> be appropriate if the author or WG concur.
>
> In the IANA registrations, IANA lists RFC 5727 as a governing
> document along with the ones listed by this draft; including it
> and a reference may be appropriate.