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

Ted Hardie <ted.ietf@gmail.com> Tue, 30 November 2010 22:10 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id B67253A6C8E; Tue, 30 Nov 2010 14:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.142
X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_83=0.6]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5fT29UaB27wv; Tue, 30 Nov 2010 14:10:13 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id 64A843A6C43; Tue, 30 Nov 2010 14:10:13 -0800 (PST)
Received: by qwg5 with SMTP id 5so5187279qwg.31 for <multiple recipients>; Tue, 30 Nov 2010 14:11:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=7lzQ5XeeMoRAALJBRwoaLX3DYpQHzParIhus88oZHxY=; b=MzjTNh2nhqZACMB/eSdiHqS7XcVDACxPPR37ZB4lrvt+P1jYLYblSu9x6Glcbk5ytc of7S6J1BTe8XpIxroZOkgz44u8oYZO+pFCfTxTDxNR4JMvgMr0PN8WCinwIeEqBKweym eONp4KR9nUNeRXh8rgFYHhPLkNeqj/VK07FLk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=n0XtXGapeiJbABMdRa2oH5z+ONjPwuy3pksZUUFtjEaoM7lrS8s98tOk15CA+tafoy g7F4W1uyBLhhMaJ0e6dsXmcUXaavpVjoKDJa3DMgexup7vJnPuJwhv0PkRsG0Bxwqe9Q NB2PjiK3Unp0XSQ7Kw7AxIpee6YpCyhhbGVQI=
MIME-Version: 1.0
Received: by with SMTP id gz9mr6585592qcb.226.1291155085168; Tue, 30 Nov 2010 14:11:25 -0800 (PST)
Received: by with HTTP; Tue, 30 Nov 2010 14:11:25 -0800 (PST)
Date: Tue, 30 Nov 2010 14:11:25 -0800
Message-ID: <AANLkTi=pF9d0z3vQYAq+mPrpSiDK9OZzVPkE84W+-qGp@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Apps Discuss <discuss@ietf.org>, adam@nostrum.com, Bernard Aboba <bernard_aboba@hotmail.com>, Spencer Dawkins <spencer@wonderhamster.org>, IESG <iesg@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2010 22:10:14 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft
(for background on apps-review, please see
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

   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

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

   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.