From john.elwell@siemens-enterprise.com Thu Jul 1 00:42:46 2010 Return-Path: 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 AF22028C0D8 for ; Thu, 1 Jul 2010 00:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599] 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 hEj-sw96Omad for ; Thu, 1 Jul 2010 00:42:45 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2CC5028C0CF for ; Thu, 1 Jul 2010 00:42:45 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-705186; Thu, 1 Jul 2010 09:42:55 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id D56011EB82AE; Thu, 1 Jul 2010 09:42:55 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 1 Jul 2010 09:42:55 +0200 From: "Elwell, John" To: Martien Huysmans , "martini@ietf.org" Date: Thu, 1 Jul 2010 09:42:54 +0200 Thread-Topic: Impact of friends on martini-gin Thread-Index: AcsY6vOMm/z+btRzR6WuRPxdo2vtoAABc54Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Impact of friends on martini-gin X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 07:42:46 -0000 We could equally well use a different URI parameter for the federated case,= e.g., "bncf". John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > Sent: 01 July 2010 07:59 > To: martini@ietf.org > Subject: [martini] Impact of friends on martini-gin >=20 > In MARTINI Interim V martini-friends was discussed. > I think there is impact of friends on martini-gin. > =20 > Friends makes a distinction between two modes of operation,=20 > which are called basic and federated. > The basic mode is described in the current MARTINI-GIN. > The PBX would announce the used mode by setting the bulk=20 > contact parameter to either "basic" or "federated". > This bulk contact parameter could be the bnc parameter. > =20 > Regards Martien > = From pkyzivat@cisco.com Thu Jul 1 07:45:30 2010 Return-Path: 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 A91483A68DE for ; Thu, 1 Jul 2010 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 CCbNQRAVQmjP for ; Thu, 1 Jul 2010 07:45:29 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9C7FD3A6907 for ; Thu, 1 Jul 2010 07:45:29 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208";a="127750383" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2010 14:45:41 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o61EjetD001407; Thu, 1 Jul 2010 14:45:41 GMT Message-ID: <4C2CAA1F.7020809@cisco.com> Date: Thu, 01 Jul 2010 10:45:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Martien Huysmans References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> <4C2BE02D.4080703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN temp GRUU X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 14:45:30 -0000 Martien Huysmans wrote: > The mail was called: GIN and anonymous GRUUS > > I was not considering "out of dialog requests". > Is that a requirement for anonymous calls? Its required for certain features to work, such as: - transfers using REFER - use of KPML > With a B2BUA in place, perhaps gruu would not be needed at all. Well, a contact is required that is globally routable, and that uniquely identifies the UA. In my book that is a GRUU, regardless of how it is constructed. Thanks, Paul > /Regards Martien > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, July 01, 2010 2:24 AM > To: Martien Huysmans > Cc: Cullen Jennings; martini@ietf.org > Subject: Re: [martini] GIN temp GRUU > > > > Martien Huysmans wrote: >> Hi >> >> In the mailing list also the option of a privacy service provided by >> the SSP was suggested, which when acting as B2BUA, would ensure that a party remains anonymous. >> No comments were posted on this suggestion. >> Can this be a viable alternative? > > I didn't see that mail - can you provide a reference? > > What privacy service spec/features does this imply? > > To provide full functionality, for every dialog it would have to insert a B2BUA, create a temp gruu to replace the supplied contact, and then route out-of-dialog requests for that temp-gruu to the calling UA. And it would have to inactivate that temp-gruu at some suitable time. > > The real gruu mechanism seems less trouble. > > Thanks, > Paul > >> Regards Martien >> >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: Wednesday, June 16, 2010 7:01 PM >> To: martini@ietf.org >> Subject: [martini] GIN temp GRUU >> >> >> I'm not OK with requiring out of band provisioning for K_e2. This would be a nightmare in practice. Could it be passed in the register response? >> >> Having this as optional does not really work for me because most the US based customers doing PSTN replacement believe they are required to provide anonymous call. >> >> Overall, looks workable yet complicated - I wish there was a simpler way but I could live with this. >> >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > From adam@nostrum.com Thu Jul 1 11:29:18 2010 Return-Path: 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 0D9F33A67A3 for ; Thu, 1 Jul 2010 11:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, SPF_PASS=-0.001] 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 vKgzX8dP8cXD for ; Thu, 1 Jul 2010 11:29:17 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E01BC3A6A25 for ; Thu, 1 Jul 2010 11:29:16 -0700 (PDT) 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 o61ITGdr021055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jul 2010 13:29:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C2CDE7C.5070003@nostrum.com> Date: Thu, 01 Jul 2010 13:29:16 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Martien Huysmans References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] GIN temp GRUU X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:29:18 -0000 On 6/30/10 6:09 AM, Martien Huysmans wrote: > In the mailing list also the option of a privacy service provided by the SSP > was suggested, which when acting as B2BUA, would ensure that a party remains anonymous. > No comments were posted on this suggestion. > Can this be a viable alternative? It certainly could be deployed (and we aren't doing anything to prevent it), but I'm extremely loathe to suggest a solution that requires an SBC-based architecture. We need to be able to solve the privacy problem for the general case, not just SBC-based networks. /a From adam@nostrum.com Thu Jul 1 11:33:12 2010 Return-Path: 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 C03463A67A3 for ; Thu, 1 Jul 2010 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001] 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 Sbj15z1yYET1 for ; Thu, 1 Jul 2010 11:33:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 132F13A6A02 for ; Thu, 1 Jul 2010 11:33:06 -0700 (PDT) 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 o61IXFim021404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jul 2010 13:33:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C2CDF6B.8060503@nostrum.com> Date: Thu, 01 Jul 2010 13:33:15 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Impact of friends on martini-gin X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:33:13 -0000 John is 100% correct. This will end up being more than a simple parameter and citation to an external document. We need a proper security analysis of the proposed solution, as well as a discussion about how it interacts with key registration technologies, like GRUU, outbound, 'reg' event, etc. It's a separate solution, and deserves its own document. /a On 7/1/10 2:42 AM, Elwell, John wrote: > We could equally well use a different URI parameter for the federated case, e.g., "bncf". > > John > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans >> Sent: 01 July 2010 07:59 >> To: martini@ietf.org >> Subject: [martini] Impact of friends on martini-gin >> >> In MARTINI Interim V martini-friends was discussed. >> I think there is impact of friends on martini-gin. >> >> Friends makes a distinction between two modes of operation, >> which are called basic and federated. >> The basic mode is described in the current MARTINI-GIN. >> The PBX would announce the used mode by setting the bulk >> contact parameter to either "basic" or "federated". >> This bulk contact parameter could be the bnc parameter. >> >> Regards Martien >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From martien.huysmans@ericsson.com Sun Jul 4 23:18:49 2010 Return-Path: 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 7AE2F3A68C2 for ; Sun, 4 Jul 2010 23:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 eq28M6K71dqP for ; Sun, 4 Jul 2010 23:18:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 942703A68BB for ; Sun, 4 Jul 2010 23:18:48 -0700 (PDT) X-AuditID: c1b4fb39-b7bc4ae000006582-3c-4c31794758de Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BC.B9.25986.749713C4; Mon, 5 Jul 2010 08:18:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.240]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 5 Jul 2010 08:18:48 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Mon, 5 Jul 2010 08:18:47 +0200 Thread-Topic: martini-gin: Typo paramter Thread-Index: Acsano027GJXcmKKQ2u2LYJh1NV+mQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B5CE2B521539624E8364D395B6F76B5C23D430D4E2ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] martini-gin: Typo paramter X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 06:18:49 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C23D430D4E2ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Martini-gin contains a typo in title of chapter 9.2.1 and 9.2.2: paramter Regards Martien --_000_B5CE2B521539624E8364D395B6F76B5C23D430D4E2ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Martini-gin contains a typo in title of chapter 9.2.1 and 9.2.2: param= ter
 
Regards Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C23D430D4E2ESESSCMS0356e_-- From trac@tools.ietf.org Mon Jul 5 12:10:56 2010 Return-Path: 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 F26C73A69FF for ; Mon, 5 Jul 2010 12:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, NO_RELAYS=-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 hE-yWwoIgJGl for ; Mon, 5 Jul 2010 12:10:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6245D3A69FD for ; Mon, 5 Jul 2010 12:10:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OVr48-0005gg-L3; Mon, 05 Jul 2010 12:10:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: martien.huysmans@ericsson.com X-Trac-Project: martini Date: Mon, 05 Jul 2010 19:10:52 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/47 Message-ID: <071.67c62be33910c50eed18f5fa5c3ca5d6@tools.ietf.org> X-Trac-Ticket-ID: 47 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: martien.huysmans@ericsson.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #47: Typo X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 19:10:56 -0000 #47: Typo -------------------------------------------+-------------------------------- Reporter: martien.huysmans@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------------+-------------------------------- Martini-gin contains a typo in title of chapter 9.2.1 and 9.2.2: paramter -- Ticket URL: martini From trac@tools.ietf.org Mon Jul 5 13:11:23 2010 Return-Path: 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 1B8213A69F4 for ; Mon, 5 Jul 2010 13:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, NO_RELAYS=-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 3xv1aDUnsMBb for ; Mon, 5 Jul 2010 13:11:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 399683A69FB for ; Mon, 5 Jul 2010 13:11:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OVs0d-0003es-Sb; Mon, 05 Jul 2010 13:11:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com, hkaplan@acmepacket.com X-Trac-Project: martini Date: Mon, 05 Jul 2010 20:11:19 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/36#comment:3 Message-ID: <085.5a353c686ce82fe75af0f5634d7dcfa8@tools.ietf.org> References: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #36: Reg-event package and individual extension state (section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 20:11:23 -0000 #36: Reg-event package and individual extension state (section 7.2.2) ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Changes (by bernard_aboba@…): * status: reopened => closed * version: => 1.0 * resolution: => fixed Comment: Proposed fix: http://www.ietf.org/mail-archive/web/martini/current/msg01716.html After giving things some thought and reading through the 'reg' event package RFC, I think things will only really work if the SIP-PBX puts the public (i.e. SSP) AOR into the registration document. I propose the following text (which will appear in the next version of GIN unless there is a constructive counter-proposal): When a SIP-PBX receives a registration event subscription addressed to an AOR that has been registered using the bulk registration mechanism described in this document, then the resulting registration information documents SHOULD contain an 'aor' attribute in its element that corresponds to the AOR at the SSP. For example, consider a SIP-PBX that has registered with an SSP that has a domain of "ssp.example.com" The SIP-PBX used a contact of "sip:198.51.100.3:5060;bnc". After such registration is complete, a registration event subscription arriving at the SSP with a Request-URI of "sip:+12145550102 at ssp.example.com" will be re-targeted to the SIP-PBX, with a Request-URI of "sip:+12145550102 at 198.51.100.3:5060". The resulting registration document created by the SIP-PBX would contain a element with an "aor" attribute of "sip:+12145550102 at ssp.example.com". This behavior ensures that subscribers external to the system (and unaware of GIN procedures) will be able to find the relevant information in the registration document (since they will be looking for the publicly-visible AOR, not the address used for sending information from the SSP to the SIP-PBX). Also, based on Paul's comments during Interim V regarding the potential ability for SSPs to form back-end subscriptions to SIP-PBXes for registration state, I propose loosening up the normative requirement about passing through reg event SUBSCRIBEs; everything after the word "unless" is new: If the SSP receives a SUBSCRIBE request for the registration event package with a Request-URI that indicates a contact registered via the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that is would proxy an INVITE bound for that AOR, unless the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (e.g., through an active back-end subscription). Again, this text will appear in the next version of GIN unless there is a constructive counter-proposal. -- Ticket URL: martini From trac@tools.ietf.org Mon Jul 5 13:18:18 2010 Return-Path: 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 5ED983A682A for ; Mon, 5 Jul 2010 13:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, NO_RELAYS=-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 Hgp-ftObLyQT for ; Mon, 5 Jul 2010 13:18:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 77FEF3A6824 for ; Mon, 5 Jul 2010 13:18:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OVs7O-0003V8-CK; Mon, 05 Jul 2010 13:18:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Mon, 05 Jul 2010 20:18:18 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/11#comment:2 Message-ID: <076.82d5c253b6141a490f442186a26b78fb@tools.ietf.org> References: <067.1dc0363dbc71855d1326f8975eb439ff@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <067.1dc0363dbc71855d1326f8975eb439ff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #11: Section 7.3: Outbound Analysis X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 20:18:18 -0000 #11: Section 7.3: Outbound Analysis ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: adam@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Candidate WG Document | Keywords: ---------------------------------------+------------------------------------ Comment(by bernard_aboba@…): Review from Cullen Jennings: http://www.ietf.org/mail-archive/web/martini/current/msg01539.html I sat down read outbound, had some coffee to brace myself for GIN, then read GIN, then convinced myself it would all work, then had more coffee and convinced myself it did not work, then convinced myself GIN was nuts, had more coffee , connived myself outbound was nuts, then had a bunch more coffee and decided that in limited cases, GIN and outbound do work together. But the combination of GIN, outbound, and GRUU do leave me feeling very jittery about if this will all work together (no it's not the coffee). A PBX could be done two ways. In one architecture it would be a proxy and each phone behind it a UA that registers to the PBX. In another architecture, the PBX could be a B2BUA and could look like a single or multiple UA's on the PBX to SSP connection that GIN is concerned with. Let's consider the B2BUA type PBX first as this is probably the most common. If the PBX used the same instance-ID for all the calls on the PBX to SSP side, and that was also used in the GIN registration, as far as I can tell, it would just work for most the cases current PBX are interested in. It seem like it might break stuff on the SSP side that used the +sip.instance in caller prefs as two different phones behind the PBX would have the same +sip.instance value even though they were different phones. In practice, I'm not sure that anything important would require devices outside the PBX to look at the +sip.instance for UA in the PBX. You should run this by Paul K and see if he can think of something this would break. If the PBX wants to use different instance ID for the contacts on the PBX to SSP side, then I don't see how GIN would work but B2BUA based PBX probably don't need to do this. Moving on to proxy based PBXs. I not exactly obvious how GIN and and outbound would work for a proxy based PBX. Probably the best approach would be to have the proxy have an "pseudo UA" that can deal with all the phone numbers and does the single GIN registration from PBX to SSP. Then when a call gets routed from the SSP to a given number at the pseudo UA, the pseudo UA in the PBX forwards the message to the appropriate UA that registered to the PBX. The UA would only register with the PBX and a single pseudo UA on the PBX would register (using GIN and outbound) with the SSP. So all in all, I think for some PBXes, GIN + outbound might work with almost no extra code and for other PBXes it might be a bit more work to get them both working - I can't imagine any solution that is significantly better or less work for the PBX to get both GIN and outbound. It's worth nothing that someone with the credentials to do a GIN registration has the credentials to hijack all the call for that PBX - typically outbound tries to stop one users form getting another users call. However both the designs above only require the PBX, not the phones attached to the PBX, to have that credential so I don't see that as a problem. It should be discussed in the security section. Cullen -- Ticket URL: martini From trac@tools.ietf.org Tue Jul 6 15:31:38 2010 Return-Path: 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 8ABED3A6816 for ; Tue, 6 Jul 2010 15:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-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 aX13wHSF3Ibw for ; Tue, 6 Jul 2010 15:31:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1FD0F3A69FD for ; Tue, 6 Jul 2010 15:31:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWGfx-0001I1-SQ; Tue, 06 Jul 2010 15:31:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Tue, 06 Jul 2010 22:31:37 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/24#comment:2 Message-ID: <067.13efd6f7910f0964887df3daf173dbd1@tools.ietf.org> References: <058.de3f68c3042d5b4ea78b5da154dfecd3@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <058.de3f68c3042d5b4ea78b5da154dfecd3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #24: Security Considerations X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 22:31:38 -0000 #24: Security Considerations --------------------------------+------------------------------------------- Reporter: adam@… | Owner: adam@… Type: defect | Status: closed Priority: major | Milestone: Component: gin | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: Added in -05 -- Ticket URL: martini From trac@tools.ietf.org Tue Jul 6 15:32:07 2010 Return-Path: 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 5570C3A69DE for ; Tue, 6 Jul 2010 15:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-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 bFoBdovQc3u0 for ; Tue, 6 Jul 2010 15:32:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E9CF83A67AF for ; Tue, 6 Jul 2010 15:32:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWGgS-0001IX-2l; Tue, 06 Jul 2010 15:32:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Tue, 06 Jul 2010 22:32:08 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/11#comment:3 Message-ID: <076.30996e0a0bea71bfe82c400b6f5c690d@tools.ietf.org> References: <067.1dc0363dbc71855d1326f8975eb439ff@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <067.1dc0363dbc71855d1326f8975eb439ff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #11: Section 7.3: Outbound Analysis X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 22:32:07 -0000 #11: Section 7.3: Outbound Analysis ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: adam@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Candidate WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: Discussion added in -05 -- Ticket URL: martini From trac@tools.ietf.org Tue Jul 6 15:33:18 2010 Return-Path: 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 E16D23A69FE for ; Tue, 6 Jul 2010 15:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-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 KgYDvI6WCj3T for ; Tue, 6 Jul 2010 15:33:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2305F3A69E1 for ; Tue, 6 Jul 2010 15:32:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWGh7-0001Lm-G9; Tue, 06 Jul 2010 15:32:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Tue, 06 Jul 2010 22:32:49 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/45#comment:2 Message-ID: <085.7b674f34a4fd63af66c40c5d1281e9f5@tools.ietf.org> References: <076.029d6075b6c603127c4415b1da3d855a@tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <076.029d6075b6c603127c4415b1da3d855a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #45: Section 5.3 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 22:33:18 -0000 #45: Section 5.3 ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: adam@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: Fixed in -05, as per discussion on mailing list -- Ticket URL: martini From trac@tools.ietf.org Tue Jul 6 15:33:24 2010 Return-Path: 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 A385D3A69E2 for ; Tue, 6 Jul 2010 15:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-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 405gl81pF9Kx for ; Tue, 6 Jul 2010 15:33:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EE3563A6A09 for ; Tue, 6 Jul 2010 15:33:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWGhR-0001Lz-RW; Tue, 06 Jul 2010 15:33:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Tue, 06 Jul 2010 22:33:09 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/47#comment:1 Message-ID: <080.32ad4f263285be5cf9c22338e8f50590@tools.ietf.org> References: <071.67c62be33910c50eed18f5fa5c3ca5d6@tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <071.67c62be33910c50eed18f5fa5c3ca5d6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #47: Typo X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 22:33:24 -0000 #47: Typo -------------------------------------------+-------------------------------- Reporter: martien.huysmans@… | Owner: Type: defect | Status: closed Priority: trivial | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------------+-------------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: Fixed in -05 -- Ticket URL: martini From adam@nostrum.com Tue Jul 6 15:41:18 2010 Return-Path: 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 0739A3A6816 for ; Tue, 6 Jul 2010 15:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 EXMoLgREpaJ4 for ; Tue, 6 Jul 2010 15:41:17 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D48DB3A67AF for ; Tue, 6 Jul 2010 15:41:16 -0700 (PDT) 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 o66MfIMN057241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Jul 2010 17:41:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C33B10E.8000801@nostrum.com> Date: Tue, 06 Jul 2010 17:41:18 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "martini@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [martini] New gin-05: all tickets closed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 22:41:18 -0000 I have submitted a new version of the GIN document, which I addresses all the currently open tickets: http://www.ietf.org/id/draft-ietf-martini-gin-05.txt That changes are highlighted in this diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-05.txt Pay particular attention to the new sections 7.3 (outbound) and 10 (security). The new text in section 7.2.2 reflects the agreement among the participants at the most recent interim meeting, and is identical to what I proposed some time ago on the mailing list. /a From root@core3.amsl.com Tue Jul 6 15:45:02 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2CCB13A69E1; Tue, 6 Jul 2010 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100706224502.2CCB13A69E1@core3.amsl.com> Date: Tue, 6 Jul 2010 15:45:02 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-gin-05.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 22:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF. Title : Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) Author(s) : A. Roach Filename : draft-ietf-martini-gin-05.txt Pages : 30 Date : 2010-07-06 This document defines a mechanism by which a SIP server acting as a traditional Private Branch Exchange (SIP-PBX) can register with a SIP Service Provider (SSP) to receive phone calls for UAs designated by phone numbers. In order to function properly, this mechanism relies on the fact that the phone numbers are fully qualified and globally unique. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-martini-gin-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-06153319.I-D@ietf.org> --NextPart-- From spencer@wonderhamster.org Tue Jul 6 16:17:05 2010 Return-Path: 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 34DC03A659A for ; Tue, 6 Jul 2010 16:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11] 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 9YwJWG7J-MCh for ; Tue, 6 Jul 2010 16:17:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 310A33A69E1 for ; Tue, 6 Jul 2010 16:16:41 -0700 (PDT) Received: from S73602b (servers.szgwbn.net [211.162.76.113]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LkfVM-1P6RbR2Hoq-00b77t; Tue, 06 Jul 2010 19:16:13 -0400 Message-ID: <3CFA7AAE5D3C459CA9E351876F39F569@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" , References: <4C33B10E.8000801@nostrum.com> Date: Wed, 7 Jul 2010 07:15:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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.5931 X-Provags-ID: V02:K0:jwcs+xbX9ymt7CDT2QeQiBnUG65wWcqvNqC62tBP8iy nspB/qF83oP1eA1kUxp/v2XkB+fyW/qYcUkxhqY6mVfK99J7wk JAxRVinMiIsUd1t5uMURkoFMyzV9XH7nx8xyx0cVTPVRJvjgJP QHiX7fr33hWoDy0eW6gRm2qvLNFSQIxijJPROQ7uOdFR1M/8BX imFnrm97eWzAJVcU8DTS3teoRRZp5g0vU7UCRRlIHI= Subject: Re: [martini] New gin-05: all tickets closed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 23:17:05 -0000 Hi, Adam, > I have submitted a new version of the GIN document, which I addresses > all the currently open tickets: > > http://www.ietf.org/id/draft-ietf-martini-gin-05.txt > > That changes are highlighted in this diff: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-05.txt > > Pay particular attention to the new sections 7.3 (outbound) and 10 > (security). The new text in section 7.2.2 reflects the agreement among > the participants at the most recent interim meeting, and is identical to > what I proposed some time ago on the mailing list. Thank you for your continued commitment to getting this document finished! Spencer From bernard_aboba@hotmail.com Tue Jul 6 22:57:00 2010 Return-Path: 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 409B53A6873 for ; Tue, 6 Jul 2010 22:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.054 X-Spam-Level: * X-Spam-Status: No, score=1.054 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 j8Q2b9duuDRb for ; Tue, 6 Jul 2010 22:56:55 -0700 (PDT) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by core3.amsl.com (Postfix) with ESMTP id 254993A6885 for ; Tue, 6 Jul 2010 22:56:53 -0700 (PDT) Received: from BLU137-W10 ([65.55.111.71]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 22:56:55 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_12711a4f-648a-4b10-94af-7b21d3c851c9_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Tue, 6 Jul 2010 22:56:55 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2010 05:56:55.0796 (UTC) FILETIME=[347C6340:01CB1D99] Subject: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 05:57:00 -0000 --_12711a4f-648a-4b10-94af-7b21d3c851c9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of MARTINI WG last call on "Registration for Multip= le Phone Numbers in the SIP" prior to requesting that the IESG publish the = document as a Proposed Standard.=20 The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt MARTINI WG last call will conclude on Thursday=2C July 22=2C 2010.=20 =20 Please respond to this WG last call=2C whether you=20 have comments or not.=20 =20 If you have no comments=2C please reply to this=20 message and indicate in the body of your message whether you think the document is ready for consideration by=20 the IESG or not.=20 =20 If you have comments=2C please provide them to the WG in one of the following ways:=20 =20 1. If you have an account on the IETF Tools server=2C or can open one=2C please login and enter your issue(s) in the=20 MARTINI Issue tracking database (TRAC)=2C which is=20 available here: http://trac.tools.ietf.org/wg/martini/trac/newticket =20 Note that if you submit an issue in TRAC=2C it will automatically also be posted to the MARTINI WG mailing list.=20 =20 2. If you don't have an account on the IETF Tools=20 server=2C please post your Issue to the MARTINI WG mailing list (martini at=20 ietf.org) in the following format:=20 =20 To: martini at ietf.org Subject: Requirements-Issue: Priority: blocker=2C critical=2C major=2C minor or=20 trivial =20 <Explanation of your issue=2C including a proposal for specific text changes to resolve the issue> = --_12711a4f-648a-4b10-94af-7b21d3c851c9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> This is an announcement of MARTINI WG last call on "Registration for Multip= le Phone Numbers in the SIP" prior to requesting that the IESG publish the = document as a Proposed Standard. <br><br>The document is available for insp= ection here:<br>http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-= 05.txt<br><br>MARTINI WG last call will conclude on Thursday=2C July 22=2C = 2010. <o:p></o:p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">Please respond to this WG last call=2C whether you=20 have comments or not. <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">If you have no comments=2C please reply to this=20 message and indicate in the body of your message whether you<o:p></o:p></p> <p class=3D"MsoNormal">think the document is ready for consideration by=20 the IESG or not. <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">If you have comments=2C please provide them to the W= G in one of the following ways: <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">1. If you have an account on the IETF Tools server= =2C or can open one=2C please login and enter your issue(s) in the <o:p></o:p></p> <p class=3D"MsoNormal">MARTINI Issue tracking database (TRAC)=2C which is=20 available here:<o:p></o:p></p> <p class=3D"MsoNormal">http://trac.tools.ietf.org/wg/martini/trac/newticket= <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">Note that if you submit an issue in TRAC=2C it will automatically also be posted to the MARTINI WG mailing list. <o:p></o:p></p= > <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">2. If you don't have an account on the IETF Tools=20 server=2C please post your<o:p></o:p></p> <p class=3D"MsoNormal">Issue to the MARTINI WG mailing list (martini at=20 ietf.org) in the following format: <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">To: =3B martini at ietf.org<o:p></o:p></p> <p class=3D"MsoNormal">Subject: Requirements-Issue: <=3Btitle of your=20 issue>=3B<o:p></o:p></p> <p class=3D"MsoNormal">Priority: blocker=2C critical=2C major=2C minor or=20 trivial<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <=3BExplanation of your issue=2C including a proposal for specific text changes to resolve the issue>=3B<br> </body> </html>= --_12711a4f-648a-4b10-94af-7b21d3c851c9_-- From adam@nostrum.com Wed Jul 7 07:13:08 2010 Return-Path: <adam@nostrum.com> 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 8A0543A6800 for <martini@core3.amsl.com>; Wed, 7 Jul 2010 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 6AY9mv3xZvDt for <martini@core3.amsl.com>; Wed, 7 Jul 2010 07:13:07 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 103263A67CC for <martini@ietf.org>; Wed, 7 Jul 2010 07:13:06 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o67ED8aR043020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 09:13:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C348B74.5080602@nostrum.com> Date: Wed, 07 Jul 2010 09:13:08 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Bernard Aboba <bernard_aboba@hotmail.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> In-Reply-To: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> Content-Type: multipart/alternative; boundary="------------010605070407080509080305" Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Wed, 07 Jul 2010 14:13:08 -0000 This is a multi-part message in MIME format. --------------010605070407080509080305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/7/10 00:56, Jul 7, Bernard Aboba wrote: > > If you have comments, please provide them to the WG in one of the > following ways... > As an addendum to this -- due to time constraints, I was not able to perform my normal proofreading step before submitting the document. There are likely to be typographical errors in the new text. I would request that any errors you find that do not impact the technical meaning of the document are sent directly to me for correction, rather than opening a tracker ticket on them. Of course, any text that is ambiguous or incorrect from a *technical* viewpoint should have a ticket opened. /a --------------010605070407080509080305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title> On 7/7/10 00:56, Jul 7, Bernard Aboba wrote:

If you have comments, please provide them to the WG in one of the following ways...


As an addendum to this -- due to time constraints, I was not able to perform my normal proofreading step before submitting the document. There are likely to be typographical errors in the new text. I would request that any errors you find that do not impact the technical meaning of the document are sent directly to me for correction, rather than opening a tracker ticket on them.

Of course, any text that is ambiguous or incorrect from a *technical* viewpoint should have a ticket opened.

/a

--------------010605070407080509080305-- From richard@shockey.us Wed Jul 7 08:11:15 2010 Return-Path: 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 084A93A684A for ; Wed, 7 Jul 2010 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 iDi5oMlSG-nn for ; Wed, 7 Jul 2010 08:11:13 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 72B943A6842 for ; Wed, 7 Jul 2010 08:11:10 -0700 (PDT) Received: (qmail 3498 invoked by uid 0); 7 Jul 2010 15:11:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 7 Jul 2010 15:11:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Gq1fyiWAHWUz7dL+f9X0Ctu0g2rOC6oICYpDnUOyirfd1B+cv7sl2YlbLB0v+W40Y/INqflGX7k5FIQlPuF0bwL93TZihPwJQspDd4JZ7fDvO0mhNQhF45ngr5+N+vbw; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OWWHJ-0001UA-5I for martini@ietf.org; Wed, 07 Jul 2010 09:11:13 -0600 From: "Richard Shockey" To: References: In-Reply-To: Date: Wed, 7 Jul 2010 11:11:11 -0400 Message-ID: <00dd01cb1de6$a2eb14f0$e8c13ed0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DE_01CB1DC5.1BD974F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsdmTqRsA6Pu9WyQR2OW2RuchqnMgAQJQaQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 15:11:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DE_01CB1DC5.1BD974F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 for IESG submission. This is baked and ready. And thank you Adam for a excellent job .. From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, July 07, 2010 1:57 AM To: martini@ietf.org Subject: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" This is an announcement of MARTINI WG last call on "Registration for Multiple Phone Numbers in the SIP" prior to requesting that the IESG publish the document as a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt MARTINI WG last call will conclude on Thursday, July 22, 2010. Please respond to this WG last call, whether you have comments or not. If you have no comments, please reply to this message and indicate in the body of your message whether you think the document is ready for consideration by the IESG or not. If you have comments, please provide them to the WG in one of the following ways: 1. If you have an account on the IETF Tools server, or can open one, please login and enter your issue(s) in the MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. 2. If you don't have an account on the IETF Tools server, please post your Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format: To: martini at ietf.org Subject: Requirements-Issue: Priority: blocker, critical, major, minor or trivial <Explanation of your issue, including a proposal for specific text changes to resolve the issue> ------=_NextPart_000_00DE_01CB1DC5.1BD974F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>+1 for IESG submission. This is baked and = ready.<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'> And thank you Adam for a excellent job = ..<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in'> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> = martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] <b>On Behalf Of </b>Bernard Aboba<br> <b>Sent:</b> Wednesday, July 07, 2010 1:57 AM<br> <b>To:</b> martini@ietf.org<br> <b>Subject:</b> [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the = SIP"<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>This is an announcement of MARTINI WG last call on "Registration for = Multiple Phone Numbers in the SIP" prior to requesting that the IESG publish = the document as a Proposed Standard. <br> <br> The document is available for inspection here:<br> http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt<br> <br> MARTINI WG last call will conclude on Thursday, July 22, 2010. = <o:p></o:p></span></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal>Please respond to this WG last call, whether you = have comments or not. <o:p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal>If you have no comments, please reply to this = message and indicate in the body of your message whether you<o:p></o:p></p> <p class=3DMsoNormal>think the document is ready for consideration by = the IESG or not. <o:p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal>If you have comments, please provide them to the WG = in one of the following ways: <o:p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal>1. If you have an account on the IETF Tools server, = or can open one, please login and enter your issue(s) in the <o:p></o:p></p> <p class=3DMsoNormal>MARTINI Issue tracking database (TRAC), which is = available here:<o:p></o:p></p> <p = class=3DMsoNormal>http://trac.tools.ietf.org/wg/martini/trac/newticket<o:= p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal>Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. = <o:p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal>2. If you don't have an account on the IETF Tools = server, please post your<o:p></o:p></p> <p class=3DMsoNormal>Issue to the MARTINI WG mailing list (martini at = ietf.org) in the following format: <o:p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal>To:  martini at ietf.org<o:p></o:p></p> <p class=3DMsoNormal>Subject: Requirements-Issue: <title of your = issue><o:p></o:p></p> <p class=3DMsoNormal>Priority: blocker, critical, major, minor or = trivial<o:p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'><Explana= tion of your issue, including a proposal for specific text changes to resolve = the issue><o:p></o:p></span></p> </div> </body> </html> ------=_NextPart_000_00DE_01CB1DC5.1BD974F0-- From trac@tools.ietf.org Thu Jul 8 00:25:46 2010 Return-Path: <trac@tools.ietf.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 A2AB53A67E9 for <martini@core3.amsl.com>; Thu, 8 Jul 2010 00:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-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 ZxXm-sbEWppJ for <martini@core3.amsl.com>; Thu, 8 Jul 2010 00:25:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8FE683A67B1 for <martini@ietf.org>; Thu, 8 Jul 2010 00:25:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OWlUS-0001J0-NC; Thu, 08 Jul 2010 00:25:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Thu, 08 Jul 2010 07:25:48 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/48 Message-ID: <067.5a22eadd4a3556222a2df4553fbf9f93@tools.ietf.org> X-Trac-Ticket-ID: 48 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #48: Appendix A X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 08 Jul 2010 07:25:46 -0000 #48: Appendix A ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: adam@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Since Appendix A was added the requirements document has changed. The changes include: New text for REQs 4, 5, 10, 14, 15: REQ4 - The mechanism MUST allow UAs attached to a SIP-PBX to register with the SIP-PBX for AORs based on assigned telephone numbers, in order to receive requests targeted at those telephone numbers, without needing to involve the SSP in the registration process. REQ5 - The mechanism MUST allow a SIP-PBX to handle requests originating at its own UAs and targeted at its assigned telephone numbers, without routing those requests to the SSP. REQ10 - The mechanism MUST work in the presence of a sequence of intermediate SIP entities on the SIP-PBX-to-SSP interface (i.e., between the SIP-PBX and the SSP's domain proxy), where those intermediate SIP entities indicated during registration a need to be on the path of inbound requests to the SIP-PBX. REQ14 - The mechanism MUST be able to operate over a transport that provides end-to-end integrity protection and confidentiality between the SIP-PBX and the SSP, e.g., using TLS as specified in [RFC3261]. REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa, e.g., using SIP digest authentication plus TLS server authentication as specified in [RFC3261]. The Requirement 17 presently referenced in Appendix A has been deleted. Requirement 18 is now Requirement 17: REQ17 - The mechanism MUST work over any existing transport specified for SIP, including UDP. DES4 has been deleted. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/48> martini <http://tools.ietf.org/martini/> From martien.huysmans@ericsson.com Thu Jul 8 05:00:19 2010 Return-Path: <martien.huysmans@ericsson.com> 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 64E433A6A85 for <martini@core3.amsl.com>; Thu, 8 Jul 2010 05:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599] 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 ehVMd8gr3-XJ for <martini@core3.amsl.com>; Thu, 8 Jul 2010 05:00:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 326483A69BF for <martini@ietf.org>; Thu, 8 Jul 2010 05:00:17 -0700 (PDT) X-AuditID: c1b4fb39-b7bc4ae000006582-e2-4c35bdd5941a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CE.2F.25986.5DDB53C4; Thu, 8 Jul 2010 14:00:21 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.240]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Jul 2010 14:00:19 +0200 From: Martien Huysmans <martien.huysmans@ericsson.com> To: "martini@ietf.org" <martini@ietf.org> Date: Thu, 8 Jul 2010 14:00:18 +0200 Thread-Topic: [martini] FW: GIN: 'reg' event package proposal Thread-Index: AcsPOmT7shBY3JQhT/yjxSbEz+djZwHhAgaAAADy/FAB9K8zoA== Message-ID: <B5CE2B521539624E8364D395B6F76B5C23D4384B53@ESESSCMS0356.eemea.ericsson.se> References: <B5CE2B521539624E8364D395B6F76B5C23D403A73A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <B5CE2B521539624E8364D395B6F76B5C23D403A73A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] FW: GIN: 'reg' event package proposal 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: Thu, 08 Jul 2010 12:00:19 -0000 Any comments to the questions below? Regards Martien -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Martien Huysmans Sent: Monday, June 28, 2010 3:04 PM To: martini@ietf.org Subject: [martini] FW: GIN: 'reg' event package proposal Forgot to include martini@ietf.org in the To. -----Original Message----- From: Martien Huysmans Sent: Monday, June 28, 2010 2:46 PM To: 'Adam Roach' Subject: RE: [martini] GIN: 'reg' event package proposal Adam Assume that the pbx has a user, say sip:user1@pbx.com with corresponding SS= P identity: sip:+12145550102@ssp.example.com. Then I guess that it's is upto the SIP-PBX to include both, if both are pub= licly-visible? Would the procedure below imply that a SIP-PBX could provide a different re= plies to a SUBSCRIBE for regvent depending on the RURI: - SUBSCRIBE sip:+12145550102@ssp.example.com as described below - SUBSCRIBE sip:user1@pbx.com with all AOR's included ? Do you see a similar rule for the Contact's included in the registration do= cument? Regards Martien -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Saturday, June 19, 2010 1:03 AM To: martini@ietf.org Subject: [martini] GIN: 'reg' event package proposal After giving things some thought and reading through the 'reg' event packag= e RFC, I think things will only really work if the SIP-PBX puts the public = (i.e. SSP) AOR into the registration document. I propose the following text= (which will appear in the next version of GIN unless there is a constructi= ve counter-proposal): When a SIP-PBX receives a registration event subscription addressed to an AOR that has been registered using the bulk registration mechanism described in this document, then the resulting registration information documents SHOULD contain an 'aor' attribute in its <registr= ation/> element that corresponds to the AOR at the SSP. For example, consider a SIP-PBX that has registered with an SSP that has a domain of "ssp.example.com" The SIP-PBX used a contact of "sip:198.51.100.3:5060;bnc". After such registration is complete, a registration event subscription arriving at the SSP with a Request-URI of "sip:+12145550102@ssp.example.com" will be re-targeted to the SIP-PBX, with a Request-URI of "sip:+12145550102@198.51.100.3:5060". The resulting registration document created by the SIP-PBX would contain a <registration/> element with an "aor" attribute of "sip:+12145550102@ssp.example.com". This behavior ensures that subscribers external to the system (and unaware of GIN procedures) will be able to find the relevant information in the registration document (since they will be looking for the publicly-visible AOR, not the address used for sending information from the SSP to the SIP-PBX). Also, based on Paul's comments during Interim V regarding the potential abi= lity for SSPs to form back-end subscriptions to SIP-PBXes for registration = state, I propose loosening up the normative requirement about passing throu= gh reg event SUBSCRIBEs; everything after the word "unless" is new: If the SSP receives a SUBSCRIBE request for the registration event package with a Request-URI that indicates a contact registered via the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that is would proxy an INVITE bound for that AOR, unless the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (e.g., through an active back-end subscription). Again, this text will appear in the next version of GIN unless there is a c= onstructive counter-proposal. /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From JSBURTON@cablevision.com Thu Jul 8 08:19:19 2010 Return-Path: <JSBURTON@cablevision.com> 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 9487F3A6877 for <martini@core3.amsl.com>; Thu, 8 Jul 2010 08:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.138 X-Spam-Level: ** X-Spam-Status: No, score=2.138 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 K7BIR0E+lOYL for <martini@core3.amsl.com>; Thu, 8 Jul 2010 08:19:17 -0700 (PDT) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 8394B3A67F9 for <martini@ietf.org>; Thu, 8 Jul 2010 08:19:16 -0700 (PDT) Received: from c3gwiaoutvs.cablevision.com (c3gwiaoutvs.cablevision.com [10.128.36.189]) by cscpsmout01.cablevision.com (Sentrion-MTA-4.0.2/Sentrion-MTA-4.0.2) with ESMTP id o68FJK0v009377 for <martini@ietf.org>; Thu, 8 Jul 2010 11:19:20 -0400 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o68FJK0v009377 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1278602360; bh=Wp/zc0q+whza6Bvw+/QYppVWYqToamihpo7+WfP dByg=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=SLspHRMdKKZQ1mr9t4uaJv1iJtVNeTIWxH1Pr IFuo99bTx2N3OfjcrWwbdFFS37+oEV7SM6UFF7oQZ8Xrwpa2ioC9vqZifDebbnjaZj0 acylu+eMUf5oD6bMv3Efn3Mi/IHmEdz0MrBgt4RC+1TxPoCLeFUDEzAOfu2SWC7z8NE = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Thu, 08 Jul 2010 11:19:20 -0400 Message-Id: <4C35B430.38CD.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.4 Date: Thu, 08 Jul 2010 11:19:12 -0400 From: "Jack Burton" <JSBURTON@cablevision.com> To: <martini@ietf.org> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> In-Reply-To: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part9DB0E960.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Thu, 08 Jul 2010 15:19:20 -0000 --=__Part9DB0E960.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit +1 (Ready for Consideration) Jack Burton Jack Burton Dir. Systems Engineering Cablevision jsburton@cablevision.com 516-803-9733 >>> Bernard Aboba <bernard_aboba@hotmail.com> 7/7/2010 01:56 >>> This is an announcement of MARTINI WG last call on "Registration for Multiple Phone Numbers in the SIP" prior to requesting that the IESG publish the document as a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt MARTINI WG last call will conclude on Thursday, July 22, 2010. Please respond to this WG last call, whether you have comments or not. If you have no comments, please reply to this message and indicate in the body of your message whether you think the document is ready for consideration by the IESG or not. If you have comments, please provide them to the WG in one of the following ways: 1. If you have an account on the IETF Tools server, or can open one, please login and enter your issue(s) in the MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. 2. If you don't have an account on the IETF Tools server, please post your Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format: To: martini at ietf.org Subject: Requirements-Issue: <title of your issue> Priority: blocker, critical, major, minor or trivial <Explanation of your issue, including a proposal for specific text changes to resolve the issue> -------------------------------------------------------- The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. -------------------------------------------------------- --=__Part9DB0E960.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML <HTML><HEAD> <STYLE><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Verdana } --></STYLE> <META content="text/html; charset=iso-8859-15" http-equiv=Content-Type> <META name=GENERATOR content="MSHTML 8.00.6001.18928"></HEAD> <BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma" class=hmmessage> <DIV>+1  (Ready for Consideration)</DIV> <DIV>Jack Burton</DIV> <DIV> </DIV> <DIV><FONT color=#000080 size=2 face=Tahoma>Jack Burton<BR>Dir. Systems Engineering<BR>Cablevision<BR>jsburton@cablevision.com<BR>516-803-9733</FONT> <BR><BR>>>> Bernard Aboba <bernard_aboba@hotmail.com> 7/7/2010 01:56 >>><BR>This is an announcement of MARTINI WG last call on "Registration for Multiple Phone Numbers in the SIP" prior to requesting that the IESG publish the document as a Proposed Standard. <BR><BR>The document is available for inspection here:<BR>http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt<BR><BR>MARTINI WG last call will conclude on Thursday, July 22, 2010. <O:P></O:P></DIV> <P class=MsoNormal><O:P></O:P></P> <P class=MsoNormal>Please respond to this WG last call, whether you have comments or not. <O:P></O:P></P> <P class=MsoNormal><O:P></O:P></P> <P class=MsoNormal>If you have no comments, please reply to this message and indicate in the body of your message whether you<O:P></O:P></P> <P class=MsoNormal>think the document is ready for consideration by the IESG or not. <O:P></O:P></P> <P class=MsoNormal><O:P></O:P></P> <P class=MsoNormal>If you have comments, please provide them to the WG in one of the following ways: <O:P></O:P></P> <P class=MsoNormal><O:P></O:P></P> <P class=MsoNormal>1. If you have an account on the IETF Tools server, or can open one, please login and enter your issue(s) in the <O:P></O:P></P> <P class=MsoNormal>MARTINI Issue tracking database (TRAC), which is available here:<O:P></O:P></P> <P class=MsoNormal>http://trac.tools.ietf.org/wg/martini/trac/newticket<O:P></O:P></P> <P class=MsoNormal><O:P></O:P></P> <P class=MsoNormal>Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. <O:P></O:P></P> <P class=MsoNormal><O:P></O:P></P> <P class=MsoNormal>2. If you don't have an account on the IETF Tools server, please post your<O:P></O:P></P> <P class=MsoNormal>Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format: <O:P></O:P></P> <P class=MsoNormal><O:P></O:P></P> <P class=MsoNormal>To:  martini at ietf.org<O:P></O:P></P> <P class=MsoNormal>Subject: Requirements-Issue: <title of your issue><O:P></O:P></P> <P class=MsoNormal>Priority: blocker, critical, major, minor or trivial<O:P></O:P></P> <P class=MsoNormal><O:P></O:P></P><Explanation of your issue, including a proposal for specific text changes to resolve the issue><BR></BODY></HTML> <br> -------------------------------------------------------- <br> The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.<br> -------------------------------------------------------- --=__Part9DB0E960.0__=-- From bernard_aboba@hotmail.com Sun Jul 11 23:19:07 2010 Return-Path: <bernard_aboba@hotmail.com> 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 582B73A67C2 for <martini@core3.amsl.com>; Sun, 11 Jul 2010 23:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 mx7h6-i9QY3f for <martini@core3.amsl.com>; Sun, 11 Jul 2010 23:19:06 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by core3.amsl.com (Postfix) with ESMTP id 1DDF73A6A30 for <martini@ietf.org>; Sun, 11 Jul 2010 23:19:06 -0700 (PDT) Received: from BLU137-W25 ([65.55.111.71]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 23:19:13 -0700 Message-ID: <BLU137-W2505314B9A10793C1BFEFB93B80@phx.gbl> Content-Type: multipart/alternative; boundary="_2256455a-41c4-4cb6-a705-cf377beefc3f_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <martini@ietf.org> Date: Sun, 11 Jul 2010 23:19:13 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2010 06:19:13.0152 (UTC) FILETIME=[25AD7800:01CB218A] Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 12 Jul 2010 06:19:07 -0000 --_2256455a-41c4-4cb6-a705-cf377beefc3f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FWIW=2C I also think the document is ready for consideration as a Proposed = Standard (modulo the issues I've submitted).=20 Jack Burton said: +1 (Ready for Consideration) Jack Burton =20 Jack Burton Dir.=20 Systems Engineering Cablevision jsburton at cablevision.com 516-803-9733 =20 = --_2256455a-41c4-4cb6-a705-cf377beefc3f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> FWIW=2C I also think the document is ready for consideration as a Proposed = Standard (modulo the issues I've submitted). <br><br>Jack Burton said:<br><= br><div>+1 =3B (Ready for Consideration)</div> <div>Jack Burton</div> <div> =3B</div> <font style=3D"font-size: 10pt=3B" color=3D"#000080" face=3D"Tahoma" size= =3D"2">Jack Burton<br>Dir.=20 Systems Engineering<br>Cablevision<br>jsburton at cablevision.com<br>516-80= 3-9733</font> <br> </body> </html>= --_2256455a-41c4-4cb6-a705-cf377beefc3f_-- From john.elwell@siemens-enterprise.com Mon Jul 12 02:25:08 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 DAA153A6403 for <martini@core3.amsl.com>; Mon, 12 Jul 2010 02:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_40=-0.185] 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 FeSCHYtvLPK2 for <martini@core3.amsl.com>; Mon, 12 Jul 2010 02:25:07 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AF79C3A659B for <martini@ietf.org>; Mon, 12 Jul 2010 02:25:06 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-818732; Mon, 12 Jul 2010 11:25:13 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 45EB523F028E; Mon, 12 Jul 2010 11:25:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 12 Jul 2010 11:25:13 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Date: Mon, 12 Jul 2010 11:25:11 +0200 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsdmTyLqkCpUCxdS9qnnKfrbtTnTgBpjtvg Message-ID: <A444A0F8084434499206E78C106220CAECA8AAE4@MCHP058A.global-ad.net> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> Keywords: MARTINI In-Reply-To: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 12 Jul 2010 09:25:09 -0000 I have reviewed this document and it is ready to go, apart from the followi= ng minor issues and nits that should be corrected. 1. "A registrar that receives a Contact URI with both a "bnc" parameter and a user portion MUST either discard the user portion and process the request as if the parameter were not present or ..." It doesn't make sense. If the parameter were not present, one would expect = a user portion to be present. I think this should say : "A registrar that receives a Contact URI with both a "bnc" parameter and a user portion MUST either discard the user portion and process the request as if the user portion were not present or ..." ^^^^^^^^^^^^ 2. "Currently, the descriptions are somewhat informal, and omit some details for the sake of brevity. If the MARTINI working group expresses interest in furthering the mechanism described by this document, they will be fleshed out with more detail and formality." This seems to be historic and should be deleted. 3. " When a UA registers with the SIP-PBX using GRUU procedures for a Contact, the SIP-PBX adds an "sg" parameter to the GRUU parameter it received from the SSP. This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route the request to the proper user agent." This isn't terribly clear. Rewording as follows might help: "When a UA registers a contact with the SIP-PBX using GRUU procedures, the = SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter= to the GRUU parameter it received from the SSP. This "sg" parameter conta= ins a disambiguation token that the SIP-PBX can use to route inbound reques= ts to the proper UA." 4. "The SSP registrar then maps I_i to the "bnc" AOR template and instance ID using the database, a persistent hash-map or similar technology." This is the first use of the expression "AOR template and instance ID". We = could do with some clarification, but I don't have a proposal. We have some= thing that could be described as a template, but I would have considered th= at to be a contact template rather than an AOR template. 5. "(1) The SIP-PBX registers with the SSP for a range of AORs. It includes the URI it expects to receive in the Request-URI in its "Contact" header field, and includes information that routes to the SIP-PBX in the "Path" header field." I think "the URI" should be changed to "the domain". Only the domain part o= f the REGISTER request's Contact header field will appear in the Request-UR= I of the inbound request. Nits: N1. "in the same way that is would "=20 Change "is" to "it". N2. "then the resulting registration information documents SHOULD contain an 'aor' attribute in its <registration/> element" Change "documents" to "document", or alternatively add "each" after "SHOULD= ". N3. "for all the potentially effected users" Change "effected" to "affected". N4. "The ability to learn the identity and registration state of every use on the PBX " Change "use" to "user". N5. "These are being defined in the MARTINI requirements document [8]." Delete "being". N6. " Further, the term "SSP" is meant as an acronym for a "SIP Service Provider," while " Move the comma outside the quotes. N7. Perhaps it is a matter of taste (ignore if you wish), but there are sev= eral places where we talk about REGISTER message or just REGISTER when we p= erhaps mean REGISTER request. N8. Again a mater of taste, but in several places the word "multitude" is u= sed, which suggests the number is always very large. Perhaps "multiplicity"= might be better. N9. " that User Agents services by the SIP-PBX can acquire and use GRUUs for their own use." Change "services" to "serviced". N10. "sent the following Contact header field in its register" Change "register" to "REGISTER request". N11. "When the SSP registrar creates the first temporary GRUU for a particular SIP-PBX and instance ID..." This is the first time "instance ID" has been mentioned - should we have a = reference to RFC 5627 at this point? N12. "temp-gruu-cookie =3D base64enc(I_i || SA)" We should add "where || denotes concatenation." (the same as in 7.1.2.2) N13: "This allows the SSP to designate a domain on the incoming Request URI that does not necessarily resolve to the SIP-PBX from when the SSP applies RFC 3263 procedures to it." I think the word "from" should be deleted. N14: "This document registers a new SIP option tag to indicate support for the mechanism it defines, plus two new SIP URI parameters." We should also mention the new header field parameter defined in 9.3. N15: "more than on AOR" Chance "on" to "one". John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: 07 July 2010 06:57 > To: martini@ietf.org > Subject: [martini] Announcement of MARTINI WG last Call on=20 > "Registration for Multiple Phone Numbers in the SIP" >=20 > This is an announcement of MARTINI WG last call on=20 > "Registration for Multiple Phone Numbers in the SIP" prior to=20 > requesting that the IESG publish the document as a Proposed Standard.=20 >=20 > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt >=20 > MARTINI WG last call will conclude on Thursday, July 22, 2010.=20 >=20 > Please respond to this WG last call, whether you have=20 > comments or not.=20 >=20 > If you have no comments, please reply to this message and=20 > indicate in the body of your message whether you >=20 > think the document is ready for consideration by the IESG or not.=20 >=20 > If you have comments, please provide them to the WG in one of=20 > the following ways:=20 >=20 > 1. If you have an account on the IETF Tools server, or can=20 > open one, please login and enter your issue(s) in the=20 >=20 > MARTINI Issue tracking database (TRAC), which is available here: >=20 > http://trac.tools.ietf.org/wg/martini/trac/newticket >=20 > Note that if you submit an issue in TRAC, it will=20 > automatically also be posted to the MARTINI WG mailing list.=20 >=20 > 2. If you don't have an account on the IETF Tools server,=20 > please post your >=20 > Issue to the MARTINI WG mailing list (martini at ietf.org) in=20 > the following format:=20 >=20 > To: martini at ietf.org >=20 > Subject: Requirements-Issue: <title of your issue> >=20 > Priority: blocker, critical, major, minor or trivial >=20 > <Explanation of your issue, including a proposal for specific=20 > text changes to resolve the issue> >=20 > = From trac@tools.ietf.org Mon Jul 12 06:26:19 2010 Return-Path: <trac@tools.ietf.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 C21643A6358 for <martini@core3.amsl.com>; Mon, 12 Jul 2010 06:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-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 emjrjKm24UYa for <martini@core3.amsl.com>; Mon, 12 Jul 2010 06:26:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ED4653A67A7 for <martini@ietf.org>; Mon, 12 Jul 2010 06:26:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OYJ1e-0003f1-OJ; Mon, 12 Jul 2010 06:26:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 12 Jul 2010 13:26:26 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/49 Message-ID: <076.6b72e55767e3af8f26fa131f1691fb80@tools.ietf.org> X-Trac-Ticket-ID: 49 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #49: NITs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 12 Jul 2010 13:26:19 -0000 #49: NITs ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- Nits: N1. "in the same way that is would " Change "is" to "it". N2. "then the resulting registration information documents SHOULD contain an 'aor' attribute in its <registration/> element" Change "documents" to "document", or alternatively add "each" after "SHOULD". N3. "for all the potentially effected users" Change "effected" to "affected". N4. "The ability to learn the identity and registration state of every use on the PBX " Change "use" to "user". N5. "These are being defined in the MARTINI requirements document [8]." Delete "being". N6. " Further, the term "SSP" is meant as an acronym for a "SIP Service Provider," while " Move the comma outside the quotes. N7. Perhaps it is a matter of taste (ignore if you wish), but there are several places where we talk about REGISTER message or just REGISTER when we perhaps mean REGISTER request. N8. Again a mater of taste, but in several places the word "multitude" is used, which suggests the number is always very large. Perhaps "multiplicity" might be better. N9. " that User Agents services by the SIP-PBX can acquire and use GRUUs for their own use." Change "services" to "serviced". N10. "sent the following Contact header field in its register" Change "register" to "REGISTER request". N11. "When the SSP registrar creates the first temporary GRUU for a particular SIP-PBX and instance ID..." This is the first time "instance ID" has been mentioned - should we have a reference to RFC 5627 at this point? N12. "temp-gruu-cookie = base64enc(I_i || SA)" We should add "where || denotes concatenation." (the same as in 7.1.2.2) N13: "This allows the SSP to designate a domain on the incoming Request URI that does not necessarily resolve to the SIP-PBX from when the SSP applies RFC 3263 procedures to it." I think the word "from" should be deleted. N14: "This document registers a new SIP option tag to indicate support for the mechanism it defines, plus two new SIP URI parameters." We should also mention the new header field parameter defined in 9.3. N15: "more than on AOR" Chance "on" to "one". -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/49> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Mon Jul 12 06:28:08 2010 Return-Path: <trac@tools.ietf.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 C40DA3A67A7 for <martini@core3.amsl.com>; Mon, 12 Jul 2010 06:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-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 7s3La36xGMD5 for <martini@core3.amsl.com>; Mon, 12 Jul 2010 06:28:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CD8573A68AD for <martini@ietf.org>; Mon, 12 Jul 2010 06:28:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OYJ3P-0005fh-VA; Mon, 12 Jul 2010 06:28:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 12 Jul 2010 13:28:15 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/50 Message-ID: <076.43826a138084943589b9f210badb7f38@tools.ietf.org> X-Trac-Ticket-ID: 50 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #50: Review X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 12 Jul 2010 13:28:08 -0000 #50: Review ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- I have reviewed this document and it is ready to go, apart from the following minor issues and nits that should be corrected. 1. "A registrar that receives a Contact URI with both a "bnc" parameter and a user portion MUST either discard the user portion and process the request as if the parameter were not present or ..." It doesn't make sense. If the parameter were not present, one would expect a user portion to be present. I think this should say : "A registrar that receives a Contact URI with both a "bnc" parameter and a user portion MUST either discard the user portion and process the request as if the user portion were not present or ..." ^^^^^^^^^^^^ 2. "Currently, the descriptions are somewhat informal, and omit some details for the sake of brevity. If the MARTINI working group expresses interest in furthering the mechanism described by this document, they will be fleshed out with more detail and formality." This seems to be historic and should be deleted. 3. " When a UA registers with the SIP-PBX using GRUU procedures for a Contact, the SIP-PBX adds an "sg" parameter to the GRUU parameter it received from the SSP. This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route the request to the proper user agent." This isn't terribly clear. Rewording as follows might help: "When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter to the GRUU parameter it received from the SSP. This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route inbound requests to the proper UA." 4. "The SSP registrar then maps I_i to the "bnc" AOR template and instance ID using the database, a persistent hash-map or similar technology." This is the first use of the expression "AOR template and instance ID". We could do with some clarification, but I don't have a proposal. We have something that could be described as a template, but I would have considered that to be a contact template rather than an AOR template. 5. "(1) The SIP-PBX registers with the SSP for a range of AORs. It includes the URI it expects to receive in the Request-URI in its "Contact" header field, and includes information that routes to the SIP-PBX in the "Path" header field." I think "the URI" should be changed to "the domain". Only the domain part of the REGISTER request's Contact header field will appear in the Request- URI of the inbound request. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/50> martini <http://tools.ietf.org/martini/> From bernard_aboba@hotmail.com Mon Jul 12 06:45:33 2010 Return-Path: <bernard_aboba@hotmail.com> 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 B11493A6840; Mon, 12 Jul 2010 06:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] 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 28-WEmkMxcfr; Mon, 12 Jul 2010 06:45:32 -0700 (PDT) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by core3.amsl.com (Postfix) with ESMTP id 8C9583A681E; Mon, 12 Jul 2010 06:45:32 -0700 (PDT) Received: from BLU137-W16 ([65.55.116.74]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 06:45:40 -0700 Message-ID: <BLU137-W16621D6D0053464824C2AE93B80@phx.gbl> Content-Type: multipart/alternative; boundary="_2b0d1bf0-53f6-42cf-b20b-361f43738d36_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <john.elwell@siemens-enterprise.com>, <alexey.melnikov@isode.com>, "iesg@ietf.org" <iesg@ietf.org> Date: Mon, 12 Jul 2010 06:45:39 -0700 Importance: Normal In-Reply-To: <A444A0F8084434499206E78C106220CAECA8A9CE@MCHP058A.global-ad.net> References: <20100711184627.DB9D33A69F5@core3.amsl.com>, <A444A0F8084434499206E78C106220CAECA8A9CE@MCHP058A.global-ad.net> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2010 13:45:40.0235 (UTC) FILETIME=[8405F5B0:01CB21C8] Cc: martini@ietf.org, draft-ietf-martini-reqs@tools.ietf.org, martini-chairs@tools.ietf.org Subject: Re: [martini] COMMENT: draft-ietf-martini-reqs 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: Mon, 12 Jul 2010 13:45:33 -0000 --_2b0d1bf0-53f6-42cf-b20b-361f43738d36_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Since Section 3 attempts to provide a general overview of several different= approaches=2C a diagram could only show the general concept=2C since the d= etails would be different for each approach. As subsequent sections note= =2C there are some major substantive differences between the approaches tha= t are important to understand. Adam had put together some diagrams illustr= ating some of the differences which were instructive=2C but also voluminous= . I'll leave it to the WG to discuss whether addition of diagrams would be= helpful or not.=20 I agree with John that diagraming (or elaborating on) non-standard behavior= in 3.1=2C 3..2 and 3.3 would not be helpful. =20 > From: john.elwell@siemens-enterprise.com > To: alexey.melnikov@isode.com=3B iesg@ietf.org > CC: martini-chairs@tools.ietf.org=3B draft-ietf-martini-reqs@tools.ietf.o= rg > Date: Mon=2C 12 Jul 2010 08:59:33 +0200 > Subject: RE: COMMENT: draft-ietf-martini-reqs=20 >=20 > I could put a single=2C generic=2C diagram in section 3 itself=2C showing= a REGISTER request/response between a SIP-PBX and an SSP=2C but this would= seem rather trivial. Perhaps the diagram could also show several UAs behin= d the SIP-PBX=2C each registering with the SIP-PBX. I am against putting s = whole lot of diagrams showing current practice in 3.1=2C 3.2 and 3.3 and th= eir subsections=2C because they would show non-standard behaviour and might= be misleading. Also it would considerably expand the document. I await gui= dance from chairs / ADs before proceeding. >=20 > John >=20 > > -----Original Message----- > > From: wwwrun@core3.amsl.com [mailto:wwwrun@core3.amsl.com] On=20 > > Behalf Of Alexey Melnikov > > Sent: 11 July 2010 19:46 > > To: iesg@ietf.org > > Cc: martini-chairs@tools.ietf.org=3B=20 > > draft-ietf-martini-reqs@tools.ietf.org > > Subject: COMMENT: draft-ietf-martini-reqs=20 > >=20 > > Comment: > > Section 3 is hard to follow for somebody not involved with=20 > > SIP on a daily basis. I suggest adding some ASCII art to=20 > > demonstrate relationship between entities and possibly some=20 > > examples of messages demonstrating issues. > >=20 > >=20 = --_2b0d1bf0-53f6-42cf-b20b-361f43738d36_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> Since Section 3 attempts to provide a general overview of several different= approaches=2C a diagram could only show the general concept=2C since the d= etails would be different for each approach. =3B As subsequent sections= note=2C there are some major substantive differences between the approache= s that are important to understand. =3B Adam had put together some diag= rams illustrating some of the differences which were instructive=2C but als= o voluminous. =3B I'll leave it to the WG to discuss whether addition o= f diagrams would be helpful or not. <br><br>I agree with John that diagrami= ng (or elaborating on) non-standard behavior in 3.1=2C 3..2 and 3.3 would n= ot be helpful. =3B <br><br>>=3B From: john.elwell@siemens-enterprise.= com<br>>=3B To: alexey.melnikov@isode.com=3B iesg@ietf.org<br>>=3B CC: = martini-chairs@tools.ietf.org=3B draft-ietf-martini-reqs@tools.ietf.org<br>= >=3B Date: Mon=2C 12 Jul 2010 08:59:33 +0200<br>>=3B Subject: RE: COMME= NT: draft-ietf-martini-reqs <br>>=3B <br>>=3B I could put a single=2C g= eneric=2C diagram in section 3 itself=2C showing a REGISTER request/respons= e between a SIP-PBX and an SSP=2C but this would seem rather trivial. Perha= ps the diagram could also show several UAs behind the SIP-PBX=2C each regis= tering with the SIP-PBX. I am against putting s whole lot of diagrams showi= ng current practice in 3.1=2C 3.2 and 3.3 and their subsections=2C because = they would show non-standard behaviour and might be misleading. Also it wou= ld considerably expand the document. I await guidance from chairs / ADs bef= ore proceeding.<br>>=3B <br>>=3B John<br>>=3B <br>>=3B >=3B -----= Original Message-----<br>>=3B >=3B From: wwwrun@core3.amsl.com [mailto:= wwwrun@core3.amsl.com] On <br>>=3B >=3B Behalf Of Alexey Melnikov<br>&g= t=3B >=3B Sent: 11 July 2010 19:46<br>>=3B >=3B To: iesg@ietf.org<br>= >=3B >=3B Cc: martini-chairs@tools.ietf.org=3B <br>>=3B >=3B draft-= ietf-martini-reqs@tools.ietf.org<br>>=3B >=3B Subject: COMMENT: draft-i= etf-martini-reqs <br>>=3B >=3B <br>>=3B >=3B Comment:<br>>=3B >= =3B Section 3 is hard to follow for somebody not involved with <br>>=3B &= gt=3B SIP on a daily basis. I suggest adding some ASCII art to <br>>=3B &= gt=3B demonstrate relationship between entities and possibly some <br>>= =3B >=3B examples of messages demonstrating issues.<br>>=3B >=3B <br>= >=3B >=3B <br> </body> </html>= --_2b0d1bf0-53f6-42cf-b20b-361f43738d36_-- From bernard_aboba@hotmail.com Thu Jul 15 10:56:43 2010 Return-Path: <bernard_aboba@hotmail.com> 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 BEFEC3A6B5C for <martini@core3.amsl.com>; Thu, 15 Jul 2010 10:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.031 X-Spam-Level: X-Spam-Status: No, score=0.031 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 qye+pSZhZfw1 for <martini@core3.amsl.com>; Thu, 15 Jul 2010 10:56:42 -0700 (PDT) Received: from blu0-omc2-s19.blu0.hotmail.com (blu0-omc2-s19.blu0.hotmail.com [65.55.111.94]) by core3.amsl.com (Postfix) with ESMTP id 6A03D3A6A43 for <martini@ietf.org>; Thu, 15 Jul 2010 10:56:42 -0700 (PDT) Received: from BLU137-W16 ([65.55.111.73]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 10:56:52 -0700 Message-ID: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl> Content-Type: multipart/alternative; boundary="_70747745-466b-4335-8256-12fefaf81eee_" X-Originating-IP: [131.107.0.106] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <martini@ietf.org> Date: Thu, 15 Jul 2010 10:56:52 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jul 2010 17:56:52.0573 (UTC) FILETIME=[1B1378D0:01CB2447] Subject: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Thu, 15 Jul 2010 17:56:43 -0000 --_70747745-466b-4335-8256-12fefaf81eee_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a reminder of an ongoing MARTINI WG last call on "Registration for= =20 Multiple Phone Numbers in the SIP" prior to requesting that the IESG=20 publish the document as a Proposed Standard.=20 The document is=20 available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt MARTINI WG last call will conclude on Thursday=2C July 22=2C 2010.=20 =20 Please respond to this WG last call=2C whether you=20 have comments or not.=20 =20 If you have no comments=2C please reply to this=20 message and indicate in the body of your message whether you think the document is ready for consideration by=20 the IESG or not.=20 =20 If you have comments=2C please provide them to the WG in one of the following ways:=20 =20 1. If you have an account on the IETF Tools server=2C or can open one=2C please login and enter your issue(s) in the=20 MARTINI Issue tracking database (TRAC)=2C which is=20 available here: http://trac.tools.ietf.org/wg/martini/trac/newticket =20 Note that if you submit an issue in TRAC=2C it will automatically also be posted to the MARTINI WG mailing list.=20 =20 2. If you don't have an account on the IETF Tools=20 server=2C please post your Issue to the MARTINI WG mailing list (martini at=20 ietf.org) in the following format:=20 =20 To: martini at ietf.org Subject: Requirements-Issue: <title of your=20 issue> Priority: blocker=2C critical=2C major=2C minor or=20 trivial =20 <Explanation of your issue=2C including a proposal for specific text changes to resolve the issue> = --_70747745-466b-4335-8256-12fefaf81eee_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> This is a reminder of an ongoing MARTINI WG last call on "Registration for= =20 Multiple Phone Numbers in the SIP" prior to requesting that the IESG=20 publish the document as a Proposed Standard. <br><br>The document is=20 available for inspection here:<br>http://www.ietf.org/internet-drafts/draft= -ietf-martini-gin-05.txt<br><br>MARTINI WG last call will conclude on Thursday=2C July 22=2C 2010. <o:p></o:p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">Please respond to this WG last call=2C whether you=20 have comments or not. <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">If you have no comments=2C please reply to this=20 message and indicate in the body of your message whether you<o:p></o:p></p> <p class=3D"MsoNormal">think the document is ready for consideration by=20 the IESG or not. <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">If you have comments=2C please provide them to the W= G in one of the following ways: <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">1. If you have an account on the IETF Tools server= =2C or can open one=2C please login and enter your issue(s) in the <o:p></o:p></p> <p class=3D"MsoNormal">MARTINI Issue tracking database (TRAC)=2C which is=20 available here:<o:p></o:p></p> <p class=3D"MsoNormal">http://trac.tools.ietf.org/wg/martini/trac/newticket= <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">Note that if you submit an issue in TRAC=2C it will automatically also be posted to the MARTINI WG mailing list. <o:p></o:p></p= > <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">2. If you don't have an account on the IETF Tools=20 server=2C please post your<o:p></o:p></p> <p class=3D"MsoNormal">Issue to the MARTINI WG mailing list (martini at=20 ietf.org) in the following format: <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">To: =3B martini at ietf.org<o:p></o:p></p> <p class=3D"MsoNormal">Subject: Requirements-Issue: <=3Btitle of your=20 issue>=3B<o:p></o:p></p> <p class=3D"MsoNormal">Priority: blocker=2C critical=2C major=2C minor or=20 trivial<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <=3BExplanation of your issue=2C including a proposal for specific text changes to resolve the issue>=3B </body> </html>= --_70747745-466b-4335-8256-12fefaf81eee_-- From bernard_aboba@hotmail.com Thu Jul 15 20:32:24 2010 Return-Path: <bernard_aboba@hotmail.com> 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 E1F133A67B8 for <martini@core3.amsl.com>; Thu, 15 Jul 2010 20:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.03 X-Spam-Level: X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 wlhtyL+lM7Hc for <martini@core3.amsl.com>; Thu, 15 Jul 2010 20:32:22 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id B369B3A677C for <martini@ietf.org>; Thu, 15 Jul 2010 20:32:22 -0700 (PDT) Received: from BLU137-W20 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 20:32:33 -0700 Message-ID: <BLU137-W20B981688567CBA2857AF793BC0@phx.gbl> Content-Type: multipart/alternative; boundary="_706d5ebd-f0ac-459d-8f0b-155d18432f34_" X-Originating-IP: [206.188.60.75] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <martini@ietf.org> Date: Thu, 15 Jul 2010 20:32:33 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2010 03:32:33.0389 (UTC) FILETIME=[8701B9D0:01CB2497] Subject: [martini] IETF 78 MARTINI WG Agenda 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: Fri, 16 Jul 2010 03:32:25 -0000 --_706d5ebd-f0ac-459d-8f0b-155d18432f34_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MARTINI WG IETF 78 Agenda Chairs:Bernard Aboba <bernard_aboba at hotmail.co= m>Spencer Dawkins <spencer at wonderhamster.org> Jabber room: =20 martini at jabber.ietf.org (Please join) Thursday=2C July=20 29=2C 201009:00 - 11:302.1 Colorado Room 09:00 - 9:10=2C=20 Preliminaries Note Well =20 Note Takers Jabber scribe Agenda bash =20 Document Status Solution Updates (40 minutes) 9:10 =96 9:50=2C=20 MARTINI with Globally Identifiable Numbers=2C Adam Roach (40 minutes)http:/= /tools.ietf.org/html/draft-ietf-martini-gin Individual=20 Submissions (60 minutes) 9:50 =96 10:20=2C AM Other Logical Identifier Valu= es=20 (OLIVE)=2C Hadriel Kaplan (30 minutes)http://tools.ietf.org/html/draft-kapl= an-martini-with-olive 10:20 - 10:50 AM MARTINI Event Package for=20 Registration (VERMOUTH)=2C Hadriel Kaplan (30 minutes) http://tools.ietf.org/html/draft-kaplan-martini-vermouth =20 Discussion and=20 Wrap-up (50 minutes) 10:50 =96 11:10=2C Discussion: Participants (20 minut= es)11:10 - 11:20=2C Hums: WG Chairs (10 minutes)11:20 =96 11:30=2C Next St= eps: WG Chairs & ADs (10=20 minutes) Thursday=2C July 29=2C 201015:10 - 16:102.1 Colorado Room 15:10 - = 15:20=2C Preliminaries Note Well Note Takers =20 Jabber scribe Agenda bash 15:20 - 16:10 Followup as needed from morni= ng session (50 minutes) = --_706d5ebd-f0ac-459d-8f0b-155d18432f34_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> <p class=3D"MsoNormal">MARTINI WG IETF 78 Agenda<o:p></o:p></p><p class=3D"= MsoNormal"><o:p> =3B</o:p></p><p class=3D"MsoNormal">Chairs:<o:p></o:p>= </p><p class=3D"MsoNormal">Bernard Aboba <=3Bbernard_aboba at hotmail.com= >=3B<o:p></o:p></p><p class=3D"MsoNormal">Spencer Dawkins <=3Bspencer a= t wonderhamster.org>=3B<o:p></o:p></p><p class=3D"MsoNormal"><o:p> = =3B</o:p></p><p class=3D"MsoNormal">Jabber room: =3B=20 martini at jabber.ietf.org (Please join)<o:p></o:p></p><p class=3D"MsoNorma= l"><o:p> =3B</o:p></p><p class=3D"MsoNormal">Thursday=2C July=20 29=2C 2010<o:p></o:p></p><p class=3D"MsoNormal">09:00 - 11:30<o:p></o:p></p= ><p class=3D"MsoNormal">2.1 Colorado Room<o:p></o:p></p><p class=3D"MsoNorm= al"><o:p> =3B</o:p></p><p class=3D"MsoNormal">09:00 - 9:10=2C=20 Preliminaries<o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B</o:p></p><= p class=3D"MsoNormal"> =3B =3B =3B =3B Note Well<o:p></o:p>= </p><p class=3D"MsoNormal"> =3B =3B =3B =3B Note Takers<o:p></o:p></p><p class=3D"MsoNormal"> =3B =3B =3B&= nbsp=3B Jabber scribe<o:p></o:p></p><p class=3D"MsoNormal"> =3B =3B=  =3B =3B Agenda bash<o:p></o:p></p><p class=3D"MsoNormal"> =3B&= nbsp=3B =3B =3B Document Status<o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B</o:p></= p><p class=3D"MsoNormal">Solution Updates (40 minutes)<o:p></o:p></p><p cla= ss=3D"MsoNormal"><o:p> =3B</o:p></p><p class=3D"MsoNormal">9:10 =96 9:5= 0=2C=20 MARTINI with Globally Identifiable Numbers=2C Adam Roach (40 minutes)<o:p><= /o:p></p><p class=3D"MsoNormal"><a rel=3D"nofollow" href=3D"http://tools.ie= tf.org/html/draft-ietf-martini-gin">http://tools.ietf.org/html/draft-ietf-m= artini-gin</a><o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B</o:p></p>= <p class=3D"MsoNormal">Individual=20 Submissions (60 minutes)<o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B= </o:p></p><p class=3D"MsoNormal">9:50 =96 10:20=2C AM Other Logical Identif= ier Values=20 (OLIVE)=2C Hadriel Kaplan (30 minutes)<o:p></o:p></p><p class=3D"MsoNormal"= ><a rel=3D"nofollow" href=3D"http://tools.ietf.org/html/draft-kaplan-martin= i-with-olive">http://tools.ietf.org/html/draft-kaplan-martini-with-olive</a= ><o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B</o:p></p><p class=3D"M= soNormal">10:20 - 10:50 AM MARTINI Event Package for=20 Registration (VERMOUTH)=2C Hadriel Kaplan (30 minutes)<o:p></o:p></p> <p class=3D"MsoNormal"><a rel=3D"nofollow" href=3D"http://tools.ietf.org/ht= ml/draft-kaplan-martini-vermouth">http://tools.ietf.org/html/draft-kaplan-m= artini-vermouth</a><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">Discussion and=20 Wrap-up (50 minutes)<o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B</o:= p></p><p class=3D"MsoNormal">10:50 =96 11:10=2C Discussion: =3B Partici= pants (20 minutes)<o:p></o:p></p><p class=3D"MsoNormal">11:10 - 11:20=2C Hu= ms: =3B WG Chairs (10 minutes)<o:p></o:p></p><p class=3D"MsoNormal">11:= 20 =96 11:30=2C Next Steps: =3B WG Chairs &=3B ADs (10=20 minutes)<o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B</o:p></p><p cla= ss=3D"MsoNormal">Thursday=2C July 29=2C 2010<o:p></o:p></p><p class=3D"MsoN= ormal">15:10 - 16:10<o:p></o:p></p><p class=3D"MsoNormal">2.1 Colorado Room= <o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B</o:p></p><p class=3D"Ms= oNormal">15:10 - 15:20=2C Preliminaries<o:p></o:p></p><p class=3D"MsoNormal= "><o:p> =3B</o:p></p><p class=3D"MsoNormal"> =3B =3B =3B&nb= sp=3B Note Well<o:p></o:p></p><p class=3D"MsoNormal"> =3B =3B = =3B =3B Note Takers<o:p></o:p></p><p class=3D"MsoNormal"> =3B = =3B =3B =3B Jabber scribe<o:p></o:p></p><p class=3D"MsoNormal"> =3B =3B = =3B =3B Agenda bash<o:p></o:p></p><p class=3D"MsoNormal"><o:p> =3B<= /o:p></p><p class=3D"MsoNormal">15:20 - 16:10 =3B Followup as needed fr= om morning session (50 minutes)<br></p> </body> </html>= --_706d5ebd-f0ac-459d-8f0b-155d18432f34_-- From HKaplan@acmepacket.com Fri Jul 16 08:37:04 2010 Return-Path: <HKaplan@acmepacket.com> 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 A252E3A68A2 for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_20=-0.74] 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 7YdROOVuKe3O for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:37:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 790A93A6821 for <martini@ietf.org>; Fri, 16 Jul 2010 08:37:03 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 16 Jul 2010 11:37:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Jul 2010 11:37:14 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Date: Fri, 16 Jul 2010 11:37:07 -0400 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsdmUew8PdE1pujT9S8ZGk7hxSBuQHWgTRg Message-ID: <430FC6BDED356B4C8498F634416644A921187F7251@mail> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> In-Reply-To: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Fri, 16 Jul 2010 15:37:04 -0000 Howdy, I've reviewed the latest gin draft and think it is ready for consideration = by the IESG, if the following changes/comments are made/addressed (these wi= ll also be added in the tools database): 1) Section 5.2 says: A registrar that receives a Contact URI with both a "bnc" parameter and a user portion MUST either discard the user portion and process the request as if the parameter were not present or return a 400 (Bad Request) error in response (unless some other error code is more appropriate). Section 5.3 says: When a SIP-PBX registers with an SSP using a "bnc" contact, that contact MUST NOT include a "user" parameter. An SSP registrar that receives a Contact URI with both a "bnc" parameter and a "user" parameter MUST either discard the "user" parameter and process the request as if the parameter were not present or return a 400 (Bad Request) error in response (unless some other error code is more appropriate). I think we need to pick one and only one behavior - having some Registrars = accept these and others not leads to inconsistent interoperability among ve= ndor equipment. Since at some future time we may find a need for the user = portion, but will probably want backwards-compatibility without failure at = that time, I recommend for 5.2 we stipulate a Registrar compliant to this d= raft MUST discard and ignore the user portion and process the request as if= the user portion were not present; and for 5.3 the same for a "user" param= . This would also follow the mantra of strict on send, liberal on receipt. 2) Section 7 says: Currently, the descriptions are somewhat informal, and omit some details for the sake of brevity. If the MARTINI working group expresses interest in furthering the mechanism described by this document, they will be fleshed out with more detail and formality. Since this document is being sent to IESG, presumably this paragraph no lon= ger applies and should be removed. 3) Section 7.1 says: ... with the mechanism defined by this document -- that is, that User Agents services by the SIP-PBX can acquire and use GRUUs for their own use. It should be "-- that is, that User Agents serviced ..." 4) Section 7.1.1 says: When an incoming request arrives at the SSP for a GRUU corresponding to a bulk number contact ("bnc"), the SSP performs slightly different processing for the GRUU than a Proxy/Registrar would. The end of that sentence should be "... for that GRUU than it would for non= -bnc GRUUs." (or at least not say "than a Proxy/Registrar would") 5) Section 7.2.1 says: In particular, the "bnc" parameter is forbidden from appearing in the body of a reg-event notify. Something about that statement rings warning bells in my head. I don't kno= w what that something is, but it seems wrong to me. :) Are we absolutely s= ure this is a normative statement we want, forever? -hadriel From trac@tools.ietf.org Fri Jul 16 08:41:20 2010 Return-Path: <trac@tools.ietf.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 BFAC53A682A for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-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 f7K7mTOB+YMa for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:41:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A058F3A67F3 for <martini@ietf.org>; Fri, 16 Jul 2010 08:41:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OZn2Z-0003qM-AA; Fri, 16 Jul 2010 08:41:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Fri, 16 Jul 2010 15:41:31 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/51 Message-ID: <064.d6295c939ebe5a8090934dcf70e61119@tools.ietf.org> X-Trac-Ticket-ID: 51 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #51: Pick one Registrar processing behavior for received user portion in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 16 Jul 2010 15:41:20 -0000 #51: Pick one Registrar processing behavior for received user portion in REGISTER ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Section 5.2 says: A registrar that receives a Contact URI with both a "bnc" parameter and a user portion MUST either discard the user portion and process the request as if the parameter were not present or return a 400 (Bad Request) error in response (unless some other error code is more appropriate). Section 5.3 says: When a SIP-PBX registers with an SSP using a "bnc" contact, that contact MUST NOT include a "user" parameter. An SSP registrar that receives a Contact URI with both a "bnc" parameter and a "user" parameter MUST either discard the "user" parameter and process the request as if the parameter were not present or return a 400 (Bad Request) error in response (unless some other error code is more appropriate). I think we need to pick one and only one behavior - having some Registrars accept these and others not leads to inconsistent interoperability among vendor equipment. Since at some future time we may find a need for the user portion, but will probably want backwards-compatibility without failure at that time, I recommend for 5.2 we stipulate a Registrar compliant to this draft MUST discard and ignore the user portion and process the request as if the user portion were not present; and for 5.3 the same for a "user" param. This would also follow the mantra of strict on send, liberal on receipt. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/51> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Fri Jul 16 08:43:29 2010 Return-Path: <trac@tools.ietf.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 D6F783A6A3F for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-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 bO-1oHnMXE1i for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:43:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8A5C73A69FF for <martini@ietf.org>; Fri, 16 Jul 2010 08:43:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OZn4Y-0003u2-HH; Fri, 16 Jul 2010 08:43:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Fri, 16 Jul 2010 15:43:34 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/52 Message-ID: <064.23d267439a95e7102b076deb61eb89a5@tools.ietf.org> X-Trac-Ticket-ID: 52 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #52: Out-of-date paragraph from prior to being a WG doc X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 16 Jul 2010 15:43:30 -0000 #52: Out-of-date paragraph from prior to being a WG doc ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Section 7 says: Currently, the descriptions are somewhat informal, and omit some details for the sake of brevity. If the MARTINI working group expresses interest in furthering the mechanism described by this document, they will be fleshed out with more detail and formality. Since this document is being sent to IESG, presumably this paragraph no longer applies and should be removed. -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/52> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Fri Jul 16 08:44:26 2010 Return-Path: <trac@tools.ietf.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 B734D3A6A53 for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-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 NJhwJRPo9Dcg for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:44:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A47E73A67F3 for <martini@ietf.org>; Fri, 16 Jul 2010 08:44:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OZn5S-0003vv-Fo; Fri, 16 Jul 2010 08:44:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Fri, 16 Jul 2010 15:44:30 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/53 Message-ID: <064.8865c7a053f56bdcbdb5e37bd0581f82@tools.ietf.org> X-Trac-Ticket-ID: 53 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #53: Editorial: typo in section 7.1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 16 Jul 2010 15:44:27 -0000 #53: Editorial: typo in section 7.1 ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Section 7.1 says: ... with the mechanism defined by this document -- that is, that User Agents services by the SIP-PBX can acquire and use GRUUs for their own use. It should be "-- that is, that User Agents serviced ..." -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/53> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Fri Jul 16 08:46:12 2010 Return-Path: <trac@tools.ietf.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 B7D5F3A67C2 for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-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 gccnY0gmaseI for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:46:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EEBB03A67AF for <martini@ietf.org>; Fri, 16 Jul 2010 08:46:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OZn7H-0004Kj-Tp; Fri, 16 Jul 2010 08:46:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Fri, 16 Jul 2010 15:46:23 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/54 Message-ID: <064.6ad6ce5e24154d457fa702edb0fe41e5@tools.ietf.org> X-Trac-Ticket-ID: 54 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #54: Editorial error section 7.1.1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 16 Jul 2010 15:46:12 -0000 #54: Editorial error section 7.1.1 ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Section 7.1.1 says: When an incoming request arrives at the SSP for a GRUU corresponding to a bulk number contact ("bnc"), the SSP performs slightly different processing for the GRUU than a Proxy/Registrar would. The end of that sentence should be "... for that GRUU than it would for non-bnc GRUUs." (or at least not say "than a Proxy/Registrar would") -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/54> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Fri Jul 16 08:47:08 2010 Return-Path: <trac@tools.ietf.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 8CF133A67AF for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-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 b0Y8IBAscRiF for <martini@core3.amsl.com>; Fri, 16 Jul 2010 08:47:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A4CF93A67A1 for <martini@ietf.org>; Fri, 16 Jul 2010 08:47:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OZn8B-0006eM-9v; Fri, 16 Jul 2010 08:47:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Fri, 16 Jul 2010 15:47:19 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/55 Message-ID: <064.5bd02a7c557bf8138805370cfccc909a@tools.ietf.org> X-Trac-Ticket-ID: 55 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #55: Forbidding "bnc" from being in Notify XML body seems wrong X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 16 Jul 2010 15:47:08 -0000 #55: Forbidding "bnc" from being in Notify XML body seems wrong ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Section 7.2.1 says: In particular, the "bnc" parameter is forbidden from appearing in the body of a reg-event notify. Something about that statement rings warning bells in my head. I don't know what that something is, but it seems wrong to me. :) Are we absolutely sure this is a normative statement we want, forever? -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/55> martini <http://tools.ietf.org/martini/> From john.elwell@siemens-enterprise.com Fri Jul 16 10:28:03 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 BF05A3A6AA2 for <martini@core3.amsl.com>; Fri, 16 Jul 2010 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] 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 dNFGH5pvjRNX for <martini@core3.amsl.com>; Fri, 16 Jul 2010 10:28:03 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9DC653A6AA7 for <martini@ietf.org>; Fri, 16 Jul 2010 10:28:02 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-881354; Fri, 16 Jul 2010 19:28:13 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id A46CD23F0278; Fri, 16 Jul 2010 19:28:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 16 Jul 2010 19:28:13 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Hadriel Kaplan <HKaplan@acmepacket.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Date: Fri, 16 Jul 2010 19:28:12 +0200 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsdmUew8PdE1pujT9S8ZGk7hxSBuQHWgTRgAAY4SiA= Message-ID: <A444A0F8084434499206E78C106220CAECB2FD96@MCHP058A.global-ad.net> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <430FC6BDED356B4C8498F634416644A921187F7251@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A921187F7251@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Fri, 16 Jul 2010 17:28:03 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 16 July 2010 16:37 > To: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Announcement of MARTINI WG last Call=20 > on "Registration for Multiple Phone Numbers in the SIP" >=20 >=20 > Howdy, > I've reviewed the latest gin draft and think it is ready for=20 > consideration by the IESG, if the following changes/comments=20 > are made/addressed (these will also be added in the tools database): >=20 > 1) Section 5.2 says: > A registrar that receives a Contact URI with both a "bnc" parameter > and a user portion MUST either discard the user portion and process > the request as if the parameter were not present or return=20 > a 400 (Bad > Request) error in response (unless some other error code is more > appropriate). >=20 > Section 5.3 says: > When a SIP-PBX registers with an SSP using a "bnc" contact, that > contact MUST NOT include a "user" parameter. An SSP registrar that > receives a Contact URI with both a "bnc" parameter and a "user" > parameter MUST either discard the "user" parameter and process the > request as if the parameter were not present or return a 400 (Bad > Request) error in response (unless some other error code is more > appropriate). >=20 > I think we need to pick one and only one behavior - having=20 > some Registrars accept these and others not leads to=20 > inconsistent interoperability among vendor equipment. Since=20 > at some future time we may find a need for the user portion,=20 > but will probably want backwards-compatibility without=20 > failure at that time, I recommend for 5.2 we stipulate a=20 > Registrar compliant to this draft MUST discard and ignore the=20 > user portion and process the request as if the user portion=20 > were not present; and for 5.3 the same for a "user" param. =20 > This would also follow the mantra of strict on send, liberal=20 > on receipt. [JRE] Sounds reasonable to me. John From trac@tools.ietf.org Fri Jul 16 10:32:09 2010 Return-Path: <trac@tools.ietf.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 203083A69A0 for <martini@core3.amsl.com>; Fri, 16 Jul 2010 10:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-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 13jfBOFoXLmF for <martini@core3.amsl.com>; Fri, 16 Jul 2010 10:32:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6221E3A6970 for <martini@ietf.org>; Fri, 16 Jul 2010 10:32:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OZoln-0004mN-12; Fri, 16 Jul 2010 10:32:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: rbarnes@bbn.com X-Trac-Project: martini Date: Fri, 16 Jul 2010 17:32:18 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/56 Message-ID: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-Trac-Ticket-ID: 56 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rbarnes@bbn.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #56: GRUU mechanism security review X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 16 Jul 2010 17:32:09 -0000 #56: GRUU mechanism security review -----------------------------+---------------------------------------------- Reporter: rbarnes@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Just took a look at the GIN GRUU construction. It looks correct to me, and the split between required and optional seems sensible. My summary of the algorithm is below, in case it's helpful. The security requirements 2 and 3 in 7.1.2.1 seem poorly specified (1, 4, and 5 seem obvious enough). W.r.t. 2: It seems like the risk here is that a PBX might be able to make GRUUs that route to another PBX, which is the opposite of what this says. W.r.t. 3: The current algorithm doesn't protect against this; it would need something related to time. ===== KEYS ===== Key Type Known to SK_SSP HMAC key SSP pk_SSP Private key SSP Pk_SSP Public key SSP, PBX SK_PBX HMAC key PBX ===== GENERATION ===== SSP (general): cookie = [ random; identifies PBX; fixed-length ] SSP (optional): I = [ identifier for PBX ] J = HMAC(SK_SSP, I) // Prevents spoofing cookies if I is known but not SK_SSP cookie = I || J SSP -> PBX: cookie PBX: D = [ per-temp-GRUU random ] M = cookie || D E = RSA_Encrypt(Pk_SSP, M) PA = HMAC(SK_PBX, E) PBX -> UA: temp-gruu = [ E, PA ] ===== VALIDATION ===== UA' -> SSP: temp-gruu = [ E, PA ] SSP (general): M' = RSA_Decrypt(pk_SSP, E) cookie' = [ truncated M' ] cookie-valid = [ proprietary ] SSP(optional) M' = RSA_Decrypt(pk_SSP, E) cookie' = [ truncated M' ] I', J' = [ split cookie' ] cookie-valid = (J' == HMAC(SK_SSP, I')); SSP (general): if (cookie-valid) generated by SSP for PBX identified by I' SSP -> PBX: temp-gruu' = [ E, PA ] PBX: if (PA == HMAC(SK_PBX, E)) generated by PBX for UA identified by 'gr' -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/56> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Fri Jul 16 15:15:54 2010 Return-Path: <trac@tools.ietf.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 6FF463A6940 for <martini@core3.amsl.com>; Fri, 16 Jul 2010 15:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-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 HCre4LFXMAyl for <martini@core3.amsl.com>; Fri, 16 Jul 2010 15:15:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 826133A6823 for <martini@ietf.org>; Fri, 16 Jul 2010 15:15:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OZtCM-0004yH-Bm; Fri, 16 Jul 2010 15:16:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Fri, 16 Jul 2010 22:16:02 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/56#comment:1 Message-ID: <066.76eeb32e1df71e2c3b69a49087cda727@tools.ietf.org> References: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #56: GRUU mechanism security review X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 16 Jul 2010 22:15:54 -0000 #56: GRUU mechanism security review -----------------------------+---------------------------------------------- Reporter: rbarnes@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Comment(by adam@…): More from Richard: I guess the attack you can accomplish by sending messages to another PBX is a DoS, when SSP-capability > PBX-capability. To that extent, it makes sense to have the HMAC on I. The countervailing risk is that you could overwhelm the SSP server with HMAC computations by sending bogus HMACs, but HMACs are so cheap that seems unlikely -- it would get overwhelmed by the RSA decryptions first. (Actually, that risk might be worth documenting in the Security Considerations; might want to rate-limit requests to temp-GRUUs. No, I haven't looked to see if it's already there) I don't see any harm in removing 2 and 3, in any case. -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/56#comment:1> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Fri Jul 16 15:16:03 2010 Return-Path: <trac@tools.ietf.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 02BE63A6940 for <martini@core3.amsl.com>; Fri, 16 Jul 2010 15:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-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 AOO8EItxbrLT for <martini@core3.amsl.com>; Fri, 16 Jul 2010 15:16:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AD5DB3A6823 for <martini@ietf.org>; Fri, 16 Jul 2010 15:16:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OZtCV-0005Bt-1D; Fri, 16 Jul 2010 15:16:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Fri, 16 Jul 2010 22:16:10 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/56#comment:2 Message-ID: <066.bf5f4f69b1232466c31f3605941f7aa4@tools.ietf.org> References: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #56: GRUU mechanism security review X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 16 Jul 2010 22:16:03 -0000 #56: GRUU mechanism security review -----------------------------+---------------------------------------------- Reporter: rbarnes@… | Owner: adam@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Changes (by adam@…): * owner: => adam@… -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/56#comment:2> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Sat Jul 17 08:09:06 2010 Return-Path: <trac@tools.ietf.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 109D23A699E for <martini@core3.amsl.com>; Sat, 17 Jul 2010 08:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-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 SJwDxLDy0LcC for <martini@core3.amsl.com>; Sat, 17 Jul 2010 08:09:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BCCA93A699A for <martini@ietf.org>; Sat, 17 Jul 2010 08:09:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1Oa90r-0006zL-S5; Sat, 17 Jul 2010 08:09:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Sat, 17 Jul 2010 15:09:13 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/56#comment:3 Message-ID: <066.d9e1f362baf76b05905b70faa7324316@tools.ietf.org> References: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #56: GRUU mechanism security review X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 17 Jul 2010 15:09:06 -0000 #56: GRUU mechanism security review -----------------------------+---------------------------------------------- Reporter: rbarnes@… | Owner: adam@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: I can't for the life of me work out what attack I thought I was preventing here. You are correct that being able to mint valid cookies would allow one PBX to send out GRUUs that routed to another PBX, but that's hardly a useful attack. It could just as easily hand out normal URIs in its contact that route to another PBX -- or, for that matter, GRUUs that it had received from another PBX. And, with GRUUs, even if it could mint its own ones that route elsewhere, they wouldn't pass the final validation step at the targeted PBX anyway. So I don't think there's anything there we need to worry about. That said, protecting I with an HMAC may still have some value -- although I can't construct an attack based on being able to generate these somewhere other than the SSP. I propose removing 2 and 3, as they're not desirable (as far as I can tell). -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/56#comment:3> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Sat Jul 17 08:48:33 2010 Return-Path: <trac@tools.ietf.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 DF9013A691B for <martini@core3.amsl.com>; Sat, 17 Jul 2010 08:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-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 YbLFjNNkuFj9 for <martini@core3.amsl.com>; Sat, 17 Jul 2010 08:48:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 113E33A6908 for <martini@ietf.org>; Sat, 17 Jul 2010 08:48:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1Oa9d6-0006lW-UJ; Sat, 17 Jul 2010 08:48:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Sat, 17 Jul 2010 15:48:44 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/56#comment:4 Message-ID: <066.2b7e8a93d7fee8082e0d3b1536320622@tools.ietf.org> References: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #56: GRUU mechanism security review X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 17 Jul 2010 15:48:34 -0000 #56: GRUU mechanism security review -----------------------------+---------------------------------------------- Reporter: rbarnes@… | Owner: adam@… Type: defect | Status: reopened Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+---------------------------------------------- Changes (by adam@…): * status: closed => reopened * resolution: fixed => Comment: Reopening: there are some changes indicated by the security review -- removing properties 2 and 3 from the list, and including Richard's concern in the Security Considerations section. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/56#comment:4> martini <http://tools.ietf.org/martini/> From fluffy@cisco.com Sun Jul 18 10:02:23 2010 Return-Path: <fluffy@cisco.com> 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 0E64F3A6821 for <martini@core3.amsl.com>; Sun, 18 Jul 2010 10:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 EfIqtoHeG+Nu for <martini@core3.amsl.com>; Sun, 18 Jul 2010 10:02:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 53DE93A6781 for <martini@ietf.org>; Sun, 18 Jul 2010 10:02:22 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFAN/QQkyrR7Hu/2dsb2JhbACTNow5caQvmWKFJQSEAIRX X-IronPort-AV: E=Sophos;i="4.55,223,1278288000"; d="scan'208";a="344941525" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Jul 2010 17:02:24 +0000 Received: from sjc-vpn5-1880.cisco.com (sjc-vpn5-1880.cisco.com [10.21.95.88]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6IH2NXs016604 for <martini@ietf.org>; Sun, 18 Jul 2010 17:02:24 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> Date: Sun, 18 Jul 2010 10:02:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> To: martini@ietf.org X-Mailer: Apple Mail (2.1081) Subject: [martini] WGLC comments on draft-ietf-martini-gin 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: Sun, 18 Jul 2010 17:02:23 -0000 Looks like a fully formed sausage - I like it. Two issues when I skimmed = it.=20 The support for temp gruus seems to be optional. I think it should be = mandatory to implement. The exact deployment models where we want to use = this are the places where many people believe there is a legal = requirement to support anonymous calls and implementing this put us into = the situation where there are pretty much no alternatives way to do it.=20= Please change "must" to "MUST" in section 5.1=20 First, it must contain an option tag of "gin" in both a "Require" header field and a "Proxy-Require" header field. You might want to consider "must" in the next sentence too.=20 Cullen PS - Thank you to Richard for pointing out this to me - I had missed it = because I filter on WGLC on the subject lines.=20 From trac@tools.ietf.org Sun Jul 18 13:39:03 2010 Return-Path: <trac@tools.ietf.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 D85C13A696F for <martini@core3.amsl.com>; Sun, 18 Jul 2010 13:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-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 PxRN8bh1ga4G for <martini@core3.amsl.com>; Sun, 18 Jul 2010 13:39:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 153AE3A67EC for <martini@ietf.org>; Sun, 18 Jul 2010 13:39:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1Oaadn-0004A1-Ty; Sun, 18 Jul 2010 13:39:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, fluffy@cisco.com X-Trac-Project: martini Date: Sun, 18 Jul 2010 20:39:15 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/57 Message-ID: <058.d5678517e5fce3f08759636bf3566398@tools.ietf.org> X-Trac-Ticket-ID: 57 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, fluffy@cisco.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #57: WGLC comments X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 18 Jul 2010 20:39:04 -0000 #57: WGLC comments ------------------------------+--------------------------------------------- Reporter: fluffy@… | Owner: adam@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------+--------------------------------------------- The support for temp gruus seems to be optional. I think it should be mandatory to implement. The exact deployment models where we want to use this are the places where many people believe there is a legal requirement to support anonymous calls and implementing this put us into the situation where there are pretty much no alternatives way to do it. Please change "must" to "MUST" in section 5.1 First, it must contain an option tag of "gin" in both a "Require" header field and a "Proxy-Require" header field. You might want to consider "must" in the next sentence too. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/57> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Mon Jul 19 05:39:51 2010 Return-Path: <trac@tools.ietf.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 D44123A6895 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 05:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-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 d4J-4z55bfTU for <martini@core3.amsl.com>; Mon, 19 Jul 2010 05:39:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F20883A67F4 for <martini@ietf.org>; Mon, 19 Jul 2010 05:39:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OapdV-0005lA-8F; Mon, 19 Jul 2010 05:39:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com, henrik@levkowetz.com X-Trac-Project: martini Date: Mon, 19 Jul 2010 12:39:57 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/56#comment:5 Message-ID: <066.fbe906d86880286d1f4c6b725e32ebc2@tools.ietf.org> References: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, henrik@levkowetz.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #56: GRUU mechanism security review X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 19 Jul 2010 12:39:52 -0000 #56: GRUU mechanism security review -----------------------------+---------------------------------------------- Reporter: rbarnes@… | Owner: adam@… Type: defect | Status: reopened Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+---------------------------------------------- Old description: > Just took a look at the GIN GRUU construction. It looks correct to > me, and the split between required and optional seems sensible. My > summary of the algorithm is below, in case it's helpful. > > The security requirements 2 and 3 in 7.1.2.1 seem poorly specified (1, > 4, and 5 seem obvious enough). W.r.t. 2: It seems like the risk here > is that a PBX might be able to make GRUUs that route to another PBX, > which is the opposite of what this says. W.r.t. 3: The current > algorithm doesn't protect against this; it would need something > related to time. > > ===== KEYS ===== > > Key Type Known to > SK_SSP HMAC key SSP > pk_SSP Private key SSP > Pk_SSP Public key SSP, PBX > SK_PBX HMAC key PBX > > ===== GENERATION ===== > > SSP (general): > cookie = [ random; identifies PBX; fixed-length ] > > SSP (optional): > I = [ identifier for PBX ] > J = HMAC(SK_SSP, I) // Prevents spoofing cookies if I is known but > not SK_SSP > cookie = I || J > > SSP -> PBX: > cookie > > PBX: > D = [ per-temp-GRUU random ] > M = cookie || D > E = RSA_Encrypt(Pk_SSP, M) > PA = HMAC(SK_PBX, E) > > PBX -> UA: > temp-gruu = [ E, PA ] > > ===== VALIDATION ===== > > UA' -> SSP: > temp-gruu = [ E, PA ] > > SSP (general): > M' = RSA_Decrypt(pk_SSP, E) > cookie' = [ truncated M' ] > cookie-valid = [ proprietary ] > > SSP(optional) > M' = RSA_Decrypt(pk_SSP, E) > cookie' = [ truncated M' ] > I', J' = [ split cookie' ] > cookie-valid = (J' == HMAC(SK_SSP, I')); > > SSP (general): > if (cookie-valid) > generated by SSP for PBX identified by I' > > SSP -> PBX: > temp-gruu' = [ E, PA ] > > PBX: > if (PA == HMAC(SK_PBX, E)) > generated by PBX for UA identified by 'gr' New description: Just took a look at the GIN GRUU construction. It looks correct to me, and the split between required and optional seems sensible. My summary of the algorithm is below, in case it's helpful. The security requirements 2 and 3 in 7.1.2.1 seem poorly specified (1, 4, and 5 seem obvious enough). W.r.t. 2: It seems like the risk here is that a PBX might be able to make GRUUs that route to another PBX, which is the opposite of what this says. W.r.t. 3: The current algorithm doesn't protect against this; it would need something related to time. {{{ ===== KEYS ===== Key Type Known to SK_SSP HMAC key SSP pk_SSP Private key SSP Pk_SSP Public key SSP, PBX SK_PBX HMAC key PBX ===== GENERATION ===== SSP (general): cookie = [ random; identifies PBX; fixed-length ] SSP (optional): I = [ identifier for PBX ] J = HMAC(SK_SSP, I) // Prevents spoofing cookies if I is known but not SK_SSP cookie = I || J SSP -> PBX: cookie PBX: D = [ per-temp-GRUU random ] M = cookie || D E = RSA_Encrypt(Pk_SSP, M) PA = HMAC(SK_PBX, E) PBX -> UA: temp-gruu = [ E, PA ] ===== VALIDATION ===== UA' -> SSP: temp-gruu = [ E, PA ] SSP (general): M' = RSA_Decrypt(pk_SSP, E) cookie' = [ truncated M' ] cookie-valid = [ proprietary ] SSP(optional) M' = RSA_Decrypt(pk_SSP, E) cookie' = [ truncated M' ] I', J' = [ split cookie' ] cookie-valid = (J' == HMAC(SK_SSP, I')); SSP (general): if (cookie-valid) generated by SSP for PBX identified by I' SSP -> PBX: temp-gruu' = [ E, PA ] PBX: if (PA == HMAC(SK_PBX, E)) generated by PBX for UA identified by 'gr' }}} -- Comment(by henrik@…): ( Made the wiki markup engine treat part of the description as literal text, to avoid the weird formatting we got when it tried to apply markup rules ... ) -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/56#comment:5> martini <http://tools.ietf.org/martini/> From bruno.chatras@orange-ftgroup.com Mon Jul 19 06:00:55 2010 Return-Path: <bruno.chatras@orange-ftgroup.com> 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 718103A6895 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 06:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Q90DcRzRyRnk for <martini@core3.amsl.com>; Mon, 19 Jul 2010 06:00:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id CF72B3A689B for <martini@ietf.org>; Mon, 19 Jul 2010 06:00:53 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 27460760005; Mon, 19 Jul 2010 15:03:16 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1E427760004; Mon, 19 Jul 2010 15:03:16 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 15:01:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2742.735E66FF" Date: Mon, 19 Jul 2010 15:01:06 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcskRx7iGkoyBz7lTz2mZXYyzjco+AC+tGTg References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl> From: <bruno.chatras@orange-ftgroup.com> To: <bernard_aboba@hotmail.com>, <martini@ietf.org> X-OriginalArrivalTime: 19 Jul 2010 13:01:07.0891 (UTC) FILETIME=[7412E030:01CB2742] Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 19 Jul 2010 13:00:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2742.735E66FF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking to the minutes of the MARTINI Interim V virtual meeting, it = seems that the discussion about "draft-vanelburg-martini-friends-00" was = inconclusive as to whether a change was required to the "gin" draft. I = don't think the WGLC can be completed before we have clarified the = interactions between "gin" and "friends". Bruno ________________________________ De : martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] De la = part de Bernard Aboba Envoy=E9 : jeudi 15 juillet 2010 19:57 =C0 : martini@ietf.org Objet : [martini] REMINDER: Ongoing MARTINI WG last Call on = "Registration for Multiple Phone Numbers in the SIP" =09 =09 This is a reminder of an ongoing MARTINI WG last call on "Registration = for Multiple Phone Numbers in the SIP" prior to requesting that the IESG = publish the document as a Proposed Standard.=20 =09 The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt =09 MARTINI WG last call will conclude on Thursday, July 22, 2010.=20 =09 Please respond to this WG last call, whether you have comments or not.=20 =09 If you have no comments, please reply to this message and indicate in = the body of your message whether you think the document is ready for consideration by the IESG or not.=20 =09 If you have comments, please provide them to the WG in one of the = following ways:=20 =09 1. If you have an account on the IETF Tools server, or can open one, = please login and enter your issue(s) in the=20 MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket =09 Note that if you submit an issue in TRAC, it will automatically also be = posted to the MARTINI WG mailing list.=20 =09 2. If you don't have an account on the IETF Tools server, please post = your Issue to the MARTINI WG mailing list (martini at ietf.org) in the = following format:=20 =09 To: martini at ietf.org Subject: Requirements-Issue: <title of your issue> Priority: blocker, critical, major, minor or trivial =09 <Explanation of your issue, including a proposal for specific text = changes to resolve the issue>=20 ------_=_NextPart_001_01CB2742.735E66FF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <STYLE>.hmmessage P { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: = 0px; PADDING-TOP: 0px } BODY.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY: Verdana } </STYLE> <META content=3D"MSHTML 6.00.2900.3660" name=3DGENERATOR></HEAD> <BODY class=3Dhmmessage> <DIV dir=3Dltr align=3Dleft> <P>Looking to the minutes of the MARTINI Interim V virtual meeting, it = seems=20 that the discussion about "draft-vanelburg-martini-friends-00" was = inconclusive=20 as to whether a change was required to the "gin"<SPAN = class=3D183275712-19072010>=20 draft</SPAN>. I don't think the WGLC can be completed before we have = clarified=20 the interactions between "gin" and "friends".</P> <P><SPAN class=3D183275712-19072010>Bruno</SPAN></P></DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Dfr dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma><B>De :</B> martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] <B>De la part de</B> Bernard=20 Aboba<BR><B>Envoy=E9 :</B> jeudi 15 juillet 2010 = 19:57<BR><B>=C0 :</B>=20 martini@ietf.org<BR><B>Objet :</B> [martini] REMINDER: Ongoing = MARTINI WG=20 last Call on "Registration for Multiple Phone Numbers in the=20 SIP"<BR></FONT><BR></DIV> <DIV></DIV>This is a reminder of an ongoing MARTINI WG last call on=20 "Registration for Multiple Phone Numbers in the SIP" prior to = requesting that=20 the IESG publish the document as a Proposed Standard. <BR><BR>The = document is=20 available for inspection=20 = here:<BR>http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.tx= t<BR><BR>MARTINI=20 WG last call will conclude on Thursday, July 22, 2010. <O:P></O:P> <P class=3DMsoNormal><O:P></O:P></P> <P class=3DMsoNormal>Please respond to this WG last call, whether you = have=20 comments or not. <O:P></O:P></P> <P class=3DMsoNormal><O:P></O:P></P> <P class=3DMsoNormal>If you have no comments, please reply to this = message and=20 indicate in the body of your message whether you<O:P></O:P></P> <P class=3DMsoNormal>think the document is ready for consideration by = the IESG=20 or not. <O:P></O:P></P> <P class=3DMsoNormal><O:P></O:P></P> <P class=3DMsoNormal>If you have comments, please provide them to the = WG in one=20 of the following ways: <O:P></O:P></P> <P class=3DMsoNormal><O:P></O:P></P> <P class=3DMsoNormal>1. If you have an account on the IETF Tools = server, or can=20 open one, please login and enter your issue(s) in the <O:P></O:P></P> <P class=3DMsoNormal>MARTINI Issue tracking database (TRAC), which is = available=20 here:<O:P></O:P></P> <P=20 = class=3DMsoNormal>http://trac.tools.ietf.org/wg/martini/trac/newticket<O:= P></O:P></P> <P class=3DMsoNormal><O:P></O:P></P> <P class=3DMsoNormal>Note that if you submit an issue in TRAC, it will = automatically also be posted to the MARTINI WG mailing list. = <O:P></O:P></P> <P class=3DMsoNormal><O:P></O:P></P> <P class=3DMsoNormal>2. If you don't have an account on the IETF Tools = server,=20 please post your<O:P></O:P></P> <P class=3DMsoNormal>Issue to the MARTINI WG mailing list (martini at = ietf.org)=20 in the following format: <O:P></O:P></P> <P class=3DMsoNormal><O:P></O:P></P> <P class=3DMsoNormal>To:  martini at ietf.org<O:P></O:P></P> <P class=3DMsoNormal>Subject: Requirements-Issue: <title of your=20 issue><O:P></O:P></P> <P class=3DMsoNormal>Priority: blocker, critical, major, minor or=20 trivial<O:P></O:P></P> <P class=3DMsoNormal><O:P></O:P></P><Explanation of your issue, = including a=20 proposal for specific text changes to resolve the issue>=20 </BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01CB2742.735E66FF-- From brian.lindsay@genband.com Mon Jul 19 06:26:42 2010 Return-Path: <brian.lindsay@genband.com> 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 AD7FE3A6829 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 06:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8w7YWc1FLcAM for <martini@core3.amsl.com>; Mon, 19 Jul 2010 06:26:39 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 7B98A3A659B for <martini@ietf.org>; Mon, 19 Jul 2010 06:26:39 -0700 (PDT) Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTERSnN9A1p5Cf5QlddvCcWJce40iva4r@postini.com; Mon, 19 Jul 2010 06:26:54 PDT Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 08:26:44 -0500 Received: from GBPLMAIL01.genband.com ([fe80::5527:203:6352:79a0]) by GBEX01.genband.com ([fe80::8063:55ef:b7ab:3543%14]) with mapi; Mon, 19 Jul 2010 08:26:44 -0500 From: Brian Lindsay <brian.lindsay@genband.com> To: Cullen Jennings <fluffy@cisco.com>, "martini@ietf.org" <martini@ietf.org> Thread-Topic: [martini] WGLC comments on draft-ietf-martini-gin Thread-Index: AQHLJpsgpdp9jmQ5tkKJSutf85I+M5K4LD/Q Date: Mon, 19 Jul 2010 13:26:40 +0000 Message-ID: <F1A0ED6425368141998E077AC43334E4037905@gbplmail01.genband.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> In-Reply-To: <D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2010 13:26:44.0709 (UTC) FILETIME=[0816B150:01CB2746] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.000.1038-17514.007 X-TM-AS-Result: No--24.776400-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 13:26:43 -0000 Hi, I'd disagree with making temp gruu's mandatory to implement in this draf= t. Some SSP's may have architectures/privacy functions that would not requi= re this to support anonimity (e.g. using B2BUA's). I'd prefer to keep the t= ext as is for temp-gruu's. Thanks, Brian ------------- Brian Lindsay Sr. Architect, System Architecture GENBAND Office: +1.613.763.3459=09 www.genband.com -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Cullen Jennings Sent: Sunday, July 18, 2010 1:02 PM To: martini@ietf.org Subject: [martini] WGLC comments on draft-ietf-martini-gin Looks like a fully formed sausage - I like it. Two issues when I skimmed it= .=20 The support for temp gruus seems to be optional. I think it should be manda= tory to implement. The exact deployment models where we want to use this ar= e the places where many people believe there is a legal requirement to supp= ort anonymous calls and implementing this put us into the situation where t= here are pretty much no alternatives way to do it.=20 Please change "must" to "MUST" in section 5.1=20 First, it must contain an option tag of "gin" in both a "Require" header field and a "Proxy-Require" header field. You might want to consider "must" in the next sentence too.=20 Cullen PS - Thank you to Richard for pointing out this to me - I had missed it bec= ause I filter on WGLC on the subject lines.=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Mon Jul 19 07:56:48 2010 Return-Path: <pkyzivat@cisco.com> 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 E45BC3A68EC for <martini@core3.amsl.com>; Mon, 19 Jul 2010 07:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 r9rHw0tdYoJd for <martini@core3.amsl.com>; Mon, 19 Jul 2010 07:56:47 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A54593A68B5 for <martini@ietf.org>; Mon, 19 Jul 2010 07:56:47 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,227,1278288000"; d="scan'208";a="134183741" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Jul 2010 14:57:02 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6JEv1qk009191; Mon, 19 Jul 2010 14:57:01 GMT Message-ID: <4C4467BD.5060505@cisco.com> Date: Mon, 19 Jul 2010 10:57:01 -0400 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Lindsay <brian.lindsay@genband.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> <F1A0ED6425368141998E077AC43334E4037905@gbplmail01.genband.com> In-Reply-To: <F1A0ED6425368141998E077AC43334E4037905@gbplmail01.genband.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 14:56:49 -0000 IMO the optionality of GRUUs, and of temp gruus, was always a dicy thing. The question is what the client is to do if it has functionality that requires GRUU but GRUU isn't supported by the registrar? In the current context, I think this might come down to confidentiality features in the PBX. It (or the phones it serves) is likely to be designed to use temp-gruu to implement those features, since for it there aren't a lot of alternatives. So if in a particular deployment the SSP registrar doesn't support temp-gruus, what is the pbx/phone to do about those features? I think about all it can do is disable them - eliminating possibility of anonymous calls. Now it may be that the SSP has some alternative mechanism for anonymity. But how will the PBX know to use that? Also, such a mechanism wouldn't support anonymity on calls within the PBX. Maybe that is as it must be. But I think we must consider this carefully before deciding. Thanks, Paul Brian Lindsay wrote: > Hi, > > I'd disagree with making temp gruu's mandatory to implement in this draft. Some SSP's may have architectures/privacy functions that would not require this to support anonimity (e.g. using B2BUA's). I'd prefer to keep the text as is for temp-gruu's. > > > Thanks, > Brian > > ------------- > Brian Lindsay > Sr. Architect, System Architecture > GENBAND > Office: +1.613.763.3459 > www.genband.com > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Sunday, July 18, 2010 1:02 PM > To: martini@ietf.org > Subject: [martini] WGLC comments on draft-ietf-martini-gin > > > Looks like a fully formed sausage - I like it. Two issues when I skimmed it. > > The support for temp gruus seems to be optional. I think it should be mandatory to implement. The exact deployment models where we want to use this are the places where many people believe there is a legal requirement to support anonymous calls and implementing this put us into the situation where there are pretty much no alternatives way to do it. > > Please change "must" to "MUST" in section 5.1 > First, it must contain an option tag of "gin" in > both a "Require" header field and a "Proxy-Require" header field. > You might want to consider "must" in the next sentence too. > > Cullen > > > PS - Thank you to Richard for pointing out this to me - I had missed it because I filter on WGLC on the subject lines. > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From richard@shockey.us Mon Jul 19 08:39:37 2010 Return-Path: <richard@shockey.us> 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 817AA3A6912 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 08:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 BdLjDeFl7Jkm for <martini@core3.amsl.com>; Mon, 19 Jul 2010 08:39:31 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 759483A6901 for <martini@ietf.org>; Mon, 19 Jul 2010 08:39:31 -0700 (PDT) Received: (qmail 19785 invoked by uid 0); 19 Jul 2010 15:39:45 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 19 Jul 2010 15:39:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Obxn2mMQVQpw57u/4sl4vq9lTpUynt0S1HF8Jx9KNdLC1mmJ/Wq61ZhyHuAcDHxsdeM0G4Logw9l7MQtycTv0xJeVWjwNpxKpoYLiiQvvfvCPE/zFLs+uSqbJ1uyhjpd; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1OasRV-0004Yg-1T; Mon, 19 Jul 2010 09:39:45 -0600 From: "Richard Shockey" <richard@shockey.us> To: <bruno.chatras@orange-ftgroup.com>, <bernard_aboba@hotmail.com>, <martini@ietf.org> References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl> <9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr> Date: Mon, 19 Jul 2010 11:39:43 -0400 Message-ID: <000001cb2758$9c977cd0$d5c67670$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CB2737.1585DCD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcskRx7iGkoyBz7lTz2mZXYyzjco+AC+tGTgAAWCwqA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 19 Jul 2010 15:39:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CB2737.1585DCD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My memory of the conversation was quite clear. The two approaches are orthogonal. Gin is NOT dependant on FRIENDS or the other way around. = Each approach should have its own option tag. There is NOT a one size fits = all solution.=20 =20 The friends solution can certainly propose a option tag on its own in = the usual way IETG WG way but the two are NOT part of a single draft. =20 As far as I=92m concerned the WGLC should proceed as normal. =20 From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Monday, July 19, 2010 9:01 AM To: bernard_aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" =20 Looking to the minutes of the MARTINI Interim V virtual meeting, it = seems that the discussion about "draft-vanelburg-martini-friends-00" was inconclusive as to whether a change was required to the "gin" draft. I = don't think the WGLC can be completed before we have clarified the = interactions between "gin" and "friends". Bruno =20 _____ =20 De : martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] De la = part de Bernard Aboba Envoy=E9 : jeudi 15 juillet 2010 19:57 =C0 : martini@ietf.org Objet : [martini] REMINDER: Ongoing MARTINI WG last Call on = "Registration for Multiple Phone Numbers in the SIP" This is a reminder of an ongoing MARTINI WG last call on "Registration = for Multiple Phone Numbers in the SIP" prior to requesting that the IESG = publish the document as a Proposed Standard.=20 The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt MARTINI WG last call will conclude on Thursday, July 22, 2010.=20 Please respond to this WG last call, whether you have comments or not.=20 If you have no comments, please reply to this message and indicate in = the body of your message whether you think the document is ready for consideration by the IESG or not.=20 If you have comments, please provide them to the WG in one of the = following ways:=20 1. If you have an account on the IETF Tools server, or can open one, = please login and enter your issue(s) in the=20 MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list.=20 2. If you don't have an account on the IETF Tools server, please post = your Issue to the MARTINI WG mailing list (martini at ietf.org) in the = following format:=20 To: martini at ietf.org Subject: Requirements-Issue: <title of your issue> Priority: blocker, critical, major, minor or trivial <Explanation of your issue, including a proposal for specific text = changes to resolve the issue>=20 ------=_NextPart_000_0001_01CB2737.1585DCD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>My memory of the conversation was quite clear.=A0 The two = approaches are orthogonal. Gin is NOT dependant on FRIENDS or the other way around. = Each approach should have its own option tag. There is NOT a one size fits = all solution. <o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>The friends solution can certainly propose a option tag = on its own in the usual way IETG WG way but the two are NOT part of a single = draft.<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>As far as I’m concerned the WGLC should proceed as = normal.<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in'> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] <b>On Behalf = Of </b>bruno.chatras@orange-ftgroup.com<br> <b>Sent:</b> Monday, July 19, 2010 9:01 AM<br> <b>To:</b> bernard_aboba@hotmail.com; martini@ietf.org<br> <b>Subject:</b> Re: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the = SIP"<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>Looking to the minutes of the MARTINI Interim V virtual meeting, it seems that = the discussion about "draft-vanelburg-martini-friends-00" was inconclusive as to whether a change was required to the "gin" = draft. I don't think the WGLC can be completed before we have clarified the interactions between "gin" and = "friends".<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>Bruno<o:p><= /o:p></span></p> <blockquote style=3D'border:none;border-left:solid blue = 1.5pt;padding:0in 0in 0in 3.0pt; margin-left:3.0pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>= <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p> = </o:p></span></p> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span = lang=3DFR style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'> <hr size=3D3 width=3D"100%" align=3Dcenter> </span></div> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span lang=3DFR style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>De :</s= pan></b><span lang=3DFR style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] <b>De la part = de</b> Bernard Aboba<br> <b>Envoy=E9 :</b> jeudi 15 juillet 2010 19:57<br> <b>=C0 :</b> martini@ietf.org<br> <b>Objet :</b> [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the = SIP"</span><span lang=3DFR = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p>= </span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>This is a reminder of an ongoing MARTINI WG last call on "Registration = for Multiple Phone Numbers in the SIP" prior to requesting that the = IESG publish the document as a Proposed Standard. <br> <br> The document is available for inspection here:<br> http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt<br> <br> MARTINI WG last call will conclude on Thursday, July 22, 2010. = <o:p></o:p></span></p> <p class=3DMsoNormal>Please respond to this WG last call, whether you = have comments or not. <o:p></o:p></p> <p class=3DMsoNormal>If you have no comments, please reply to this = message and indicate in the body of your message whether you<o:p></o:p></p> <p class=3DMsoNormal>think the document is ready for consideration by = the IESG or not. <o:p></o:p></p> <p class=3DMsoNormal>If you have comments, please provide them to the WG = in one of the following ways: <o:p></o:p></p> <p class=3DMsoNormal>1. If you have an account on the IETF Tools server, = or can open one, please login and enter your issue(s) in the <o:p></o:p></p> <p class=3DMsoNormal>MARTINI Issue tracking database (TRAC), which is = available here:<o:p></o:p></p> <p = class=3DMsoNormal>http://trac.tools.ietf.org/wg/martini/trac/newticket<o:= p></o:p></p> <p class=3DMsoNormal>Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. = <o:p></o:p></p> <p class=3DMsoNormal>2. If you don't have an account on the IETF Tools = server, please post your<o:p></o:p></p> <p class=3DMsoNormal>Issue to the MARTINI WG mailing list (martini at = ietf.org) in the following format: <o:p></o:p></p> <p class=3DMsoNormal>To:  martini at ietf.org<o:p></o:p></p> <p class=3DMsoNormal>Subject: Requirements-Issue: <title of your = issue><o:p></o:p></p> <p class=3DMsoNormal>Priority: blocker, critical, major, minor or = trivial<o:p></o:p></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'><Explana= tion of your issue, including a proposal for specific text changes to resolve = the issue> <o:p></o:p></span></p> </blockquote> </div> </body> </html> ------=_NextPart_000_0001_01CB2737.1585DCD0-- From john.elwell@siemens-enterprise.com Mon Jul 19 09:09:37 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 2DF673A686E for <martini@core3.amsl.com>; Mon, 19 Jul 2010 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] 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 gIkzMYmhTsLc for <martini@core3.amsl.com>; Mon, 19 Jul 2010 09:09:30 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7F0783A694D for <martini@ietf.org>; Mon, 19 Jul 2010 09:09:29 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-898233; Mon, 19 Jul 2010 18:09:42 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id E775823F0296; Mon, 19 Jul 2010 18:09:42 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 19 Jul 2010 18:09:42 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Richard Shockey <richard@shockey.us>, "bruno.chatras@orange-ftgroup.com" <bruno.chatras@orange-ftgroup.com>, "bernard_aboba@hotmail.com" <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Date: Mon, 19 Jul 2010 18:09:41 +0200 Thread-Topic: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcskRx7iGkoyBz7lTz2mZXYyzjco+AC+tGTgAAWCwqAAASREgA== Message-ID: <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl> <9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr> <000001cb2758$9c977cd0$d5c67670$@us> In-Reply-To: <000001cb2758$9c977cd0$d5c67670$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 19 Jul 2010 16:09:37 -0000 I agree with Richard. My recollection of the discussion was that it leaned = towards there not being a dependency between the two drafts - the two can p= roceed at their own rates. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: 19 July 2010 16:40 > To: bruno.chatras@orange-ftgroup.com;=20 > bernard_aboba@hotmail.com; martini@ietf.org > Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call=20 > on "Registration for Multiple Phone Numbers in the SIP" >=20 > My memory of the conversation was quite clear. The two=20 > approaches are orthogonal. Gin is NOT dependant on FRIENDS or=20 > the other way around. Each approach should have its own=20 > option tag. There is NOT a one size fits all solution.=20 >=20 > =20 >=20 > The friends solution can certainly propose a option tag on=20 > its own in the usual way IETG WG way but the two are NOT part=20 > of a single draft. >=20 > =20 >=20 > As far as I'm concerned the WGLC should proceed as normal. >=20 > =20 >=20 > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Monday, July 19, 2010 9:01 AM > To: bernard_aboba@hotmail.com; martini@ietf.org > Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call=20 > on "Registration for Multiple Phone Numbers in the SIP" >=20 > =20 >=20 > Looking to the minutes of the MARTINI Interim V virtual=20 > meeting, it seems that the discussion about=20 > "draft-vanelburg-martini-friends-00" was inconclusive as to=20 > whether a change was required to the "gin" draft. I don't=20 > think the WGLC can be completed before we have clarified the=20 > interactions between "gin" and "friends". >=20 > Bruno >=20 > =20 >=20 > ________________________________ >=20 > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Bernard Aboba > Envoy=E9 : jeudi 15 juillet 2010 19:57 > =C0 : martini@ietf.org > Objet : [martini] REMINDER: Ongoing MARTINI WG last=20 > Call on "Registration for Multiple Phone Numbers in the SIP" >=20 > This is a reminder of an ongoing MARTINI WG last call=20 > on "Registration for Multiple Phone Numbers in the SIP" prior=20 > to requesting that the IESG publish the document as a=20 > Proposed Standard.=20 > =09 > The document is available for inspection here: > =09 > http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt > =09 > MARTINI WG last call will conclude on Thursday, July 22, 2010.=20 >=20 > Please respond to this WG last call, whether you have=20 > comments or not.=20 >=20 > If you have no comments, please reply to this message=20 > and indicate in the body of your message whether you >=20 > think the document is ready for consideration by the=20 > IESG or not.=20 >=20 > If you have comments, please provide them to the WG in=20 > one of the following ways:=20 >=20 > 1. If you have an account on the IETF Tools server, or=20 > can open one, please login and enter your issue(s) in the=20 >=20 > MARTINI Issue tracking database (TRAC), which is available here: >=20 > http://trac.tools.ietf.org/wg/martini/trac/newticket >=20 > Note that if you submit an issue in TRAC, it will=20 > automatically also be posted to the MARTINI WG mailing list.=20 >=20 > 2. If you don't have an account on the IETF Tools=20 > server, please post your >=20 > Issue to the MARTINI WG mailing list (martini at=20 > ietf.org) in the following format:=20 >=20 > To: martini at ietf.org >=20 > Subject: Requirements-Issue: <title of your issue> >=20 > Priority: blocker, critical, major, minor or trivial >=20 > <Explanation of your issue, including a proposal for=20 > specific text changes to resolve the issue>=20 >=20 > = From brian.lindsay@genband.com Mon Jul 19 10:06:25 2010 Return-Path: <brian.lindsay@genband.com> 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 787803A6992 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 10:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5HNPwrpDyZb0 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 10:06:24 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id CD6363A68A4 for <martini@ietf.org>; Mon, 19 Jul 2010 10:06:23 -0700 (PDT) Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTESGHexo32wEKEzMZsU6IV3E4VIaHnEc@postini.com; Mon, 19 Jul 2010 10:06:38 PDT Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 12:00:54 -0500 Received: from GBPLMAIL01.genband.com ([fe80::5527:203:6352:79a0]) by GBEX01.genband.com ([fe80::8063:55ef:b7ab:3543%14]) with mapi; Mon, 19 Jul 2010 12:00:53 -0500 From: Brian Lindsay <brian.lindsay@genband.com> To: Paul Kyzivat <pkyzivat@cisco.com> Thread-Topic: [martini] WGLC comments on draft-ietf-martini-gin Thread-Index: AQHLJ1Kkpdp9jmQ5tkKJSutf85I+M5K4aQww Date: Mon, 19 Jul 2010 17:00:52 +0000 Message-ID: <F1A0ED6425368141998E077AC43334E4037A11@gbplmail01.genband.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> <F1A0ED6425368141998E077AC43334E4037905@gbplmail01.genband.com> <4C4467BD.5060505@cisco.com> In-Reply-To: <4C4467BD.5060505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2010 17:00:54.0365 (UTC) FILETIME=[F31498D0:01CB2763] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.000.1038-17516.000 X-TM-AS-Result: No--35.403500-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 17:06:25 -0000 Hi Paul, Perhaps to add to your first point, I think temporary GRUUs aren't even = mandatory to implement in RFC 5627? I think the draft currently has the right balance: it defines how GRUUs/= Temp-GRUUs work with the "gin" registration mechanism (and defines the nece= ssary extensions for this), but doesn't mandate them. Mandating/coupling ar= gueably goes beyond the scope of the MARTINI requirements. Temp-GRUUs by th= emselves also aren't necessarily sufficient for full anonymity (e.g. SDP in= fo could be used for correlation) and it hasn't been in the scope of the wo= rk to mandate a full solution for anonymity.=20 In the absence of availability a temp-gruu - presumeably the PBX would h= ave to anonymize the request to the extent possible and the network may pro= vide additional privacy capabilities of course (e.g. RFC3323/3325). Thanks, Brian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, July 19, 2010 10:57 AM To: Brian Lindsay Cc: Cullen Jennings; martini@ietf.org Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin IMO the optionality of GRUUs, and of temp gruus, was always a dicy thing. The question is what the client is to do if it has functionality that requi= res GRUU but GRUU isn't supported by the registrar? In the current context, I think this might come down to confidentiality fea= tures in the PBX. It (or the phones it serves) is likely to be designed to = use temp-gruu to implement those features, since for it there aren't a lot = of alternatives. So if in a particular deployment the SSP registrar doesn't= support temp-gruus, what is the pbx/phone to do about those features? I th= ink about all it can do is disable them - eliminating possibility of anonym= ous calls. Now it may be that the SSP has some alternative mechanism for anonymity.=20 But how will the PBX know to use that? Also, such a mechanism wouldn't supp= ort anonymity on calls within the PBX. Maybe that is as it must be. But I think we must consider this carefully be= fore deciding. Thanks, Paul Brian Lindsay wrote: > Hi, >=20 > I'd disagree with making temp gruu's mandatory to implement in this dr= aft. Some SSP's may have architectures/privacy functions that would not req= uire this to support anonimity (e.g. using B2BUA's). I'd prefer to keep the= text as is for temp-gruu's. >=20 >=20 > Thanks, > Brian >=20 > ------------- > Brian Lindsay > Sr. Architect, System Architecture > GENBAND > Office: +1.613.763.3459=09 > www.genband.com >=20 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > Behalf Of Cullen Jennings > Sent: Sunday, July 18, 2010 1:02 PM > To: martini@ietf.org > Subject: [martini] WGLC comments on draft-ietf-martini-gin >=20 >=20 > Looks like a fully formed sausage - I like it. Two issues when I skimmed = it.=20 >=20 > The support for temp gruus seems to be optional. I think it should be man= datory to implement. The exact deployment models where we want to use this = are the places where many people believe there is a legal requirement to su= pport anonymous calls and implementing this put us into the situation where= there are pretty much no alternatives way to do it.=20 >=20 > Please change "must" to "MUST" in section 5.1=20 > First, it must contain an option tag of "gin" in > both a "Require" header field and a "Proxy-Require" header field. > You might want to consider "must" in the next sentence too.=20 >=20 > Cullen >=20 >=20 > PS - Thank you to Richard for pointing out this to me - I had missed it b= ecause I filter on WGLC on the subject lines.=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From adam@nostrum.com Mon Jul 19 11:22:17 2010 Return-Path: <adam@nostrum.com> 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 902843A67A1 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 11:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 eL0DRYEuoarJ for <martini@core3.amsl.com>; Mon, 19 Jul 2010 11:22:14 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1CBD03A67CC for <martini@ietf.org>; Mon, 19 Jul 2010 11:22:13 -0700 (PDT) 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 o6JIMOia099389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 13:22:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C449818.8000206@nostrum.com> Date: Mon, 19 Jul 2010 13:23:20 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Elwell, John" <john.elwell@siemens-enterprise.com> References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl> <9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr> <000001cb2758$9c977cd0$d5c67670$@us> <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "bernard_aboba@hotmail.com" <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 19 Jul 2010 18:22:17 -0000 Yes, this matches my understanding as well. I've posted what I think are well-reasoned arguments on the list in support of this position. There have been no counter-arguments that attempt to explain why the combination would be anything but detrimental. /a On 7/19/10 11:09 AM, Elwell, John wrote: > I agree with Richard. My recollection of the discussion was that it leaned towards there not being a dependency between the two drafts - the two can proceed at their own rates. > > John > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Richard Shockey >> Sent: 19 July 2010 16:40 >> To: bruno.chatras@orange-ftgroup.com; >> bernard_aboba@hotmail.com; martini@ietf.org >> Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call >> on "Registration for Multiple Phone Numbers in the SIP" >> >> My memory of the conversation was quite clear. The two >> approaches are orthogonal. Gin is NOT dependant on FRIENDS or >> the other way around. Each approach should have its own >> option tag. There is NOT a one size fits all solution. >> >> >> >> The friends solution can certainly propose a option tag on >> its own in the usual way IETG WG way but the two are NOT part >> of a single draft. >> >> >> >> As far as I'm concerned the WGLC should proceed as normal. >> >> >> >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of >> bruno.chatras@orange-ftgroup.com >> Sent: Monday, July 19, 2010 9:01 AM >> To: bernard_aboba@hotmail.com; martini@ietf.org >> Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call >> on "Registration for Multiple Phone Numbers in the SIP" >> >> >> >> Looking to the minutes of the MARTINI Interim V virtual >> meeting, it seems that the discussion about >> "draft-vanelburg-martini-friends-00" was inconclusive as to >> whether a change was required to the "gin" draft. I don't >> think the WGLC can be completed before we have clarified the >> interactions between "gin" and "friends". >> >> Bruno >> >> >> >> ________________________________ >> >> De : martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] De la part de Bernard Aboba >> Envoyé : jeudi 15 juillet 2010 19:57 >> À : martini@ietf.org >> Objet : [martini] REMINDER: Ongoing MARTINI WG last >> Call on "Registration for Multiple Phone Numbers in the SIP" >> >> This is a reminder of an ongoing MARTINI WG last call >> on "Registration for Multiple Phone Numbers in the SIP" prior >> to requesting that the IESG publish the document as a >> Proposed Standard. >> >> The document is available for inspection here: >> >> http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt >> >> MARTINI WG last call will conclude on Thursday, July 22, 2010. >> >> Please respond to this WG last call, whether you have >> comments or not. >> >> If you have no comments, please reply to this message >> and indicate in the body of your message whether you >> >> think the document is ready for consideration by the >> IESG or not. >> >> If you have comments, please provide them to the WG in >> one of the following ways: >> >> 1. If you have an account on the IETF Tools server, or >> can open one, please login and enter your issue(s) in the >> >> MARTINI Issue tracking database (TRAC), which is available here: >> >> http://trac.tools.ietf.org/wg/martini/trac/newticket >> >> Note that if you submit an issue in TRAC, it will >> automatically also be posted to the MARTINI WG mailing list. >> >> 2. If you don't have an account on the IETF Tools >> server, please post your >> >> Issue to the MARTINI WG mailing list (martini at >> ietf.org) in the following format: >> >> To: martini at ietf.org >> >> Subject: Requirements-Issue:<title of your issue> >> >> Priority: blocker, critical, major, minor or trivial >> >> <Explanation of your issue, including a proposal for >> specific text changes to resolve the issue> >> >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From fluffy@cisco.com Mon Jul 19 11:30:15 2010 Return-Path: <fluffy@cisco.com> 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 9195B3A6949 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 11:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kc0IrC+YzlOT for <martini@core3.amsl.com>; Mon, 19 Jul 2010 11:30:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B47063A67A1 for <martini@ietf.org>; Mon, 19 Jul 2010 11:30:11 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="228520434" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2010 18:30:22 +0000 Received: from sjc-vpn2-1198.cisco.com (sjc-vpn2-1198.cisco.com [10.21.116.174]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6JIULfo017787; Mon, 19 Jul 2010 18:30:22 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <F1A0ED6425368141998E077AC43334E4037A11@gbplmail01.genband.com> Date: Mon, 19 Jul 2010 11:30:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E65E5ED-2DFB-4287-9713-E4CB2E71F204@cisco.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl><D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> <F1A0ED6425368141998E077AC43334E4037905@gbplmail01.genband.com> <4C4467BD.5060505@cisco.com> <F1A0ED6425368141998E077AC43334E4037A11@gbplmail01.genband.com> To: "Brian Lindsay" <brian.lindsay@genband.com> X-Mailer: Apple Mail (2.1081) Cc: martini@ietf.org Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 18:30:15 -0000 Well - the first question is if we agree that non temp GRUUs are = mandatory to implement on the SSP side? If we don't agree on this we = are not going to get far on the temp conversation.=20 On Jul 19, 2010, at 10:00 , Brian Lindsay wrote: > Hi Paul, >=20 > Perhaps to add to your first point, I think temporary GRUUs aren't = even mandatory to implement in RFC 5627? >=20 > I think the draft currently has the right balance: it defines how = GRUUs/Temp-GRUUs work with the "gin" registration mechanism (and defines = the necessary extensions for this), but doesn't mandate them. = Mandating/coupling argueably goes beyond the scope of the MARTINI = requirements. Temp-GRUUs by themselves also aren't necessarily = sufficient for full anonymity (e.g. SDP info could be used for = correlation) and it hasn't been in the scope of the work to mandate a = full solution for anonymity. >=20 > In the absence of availability a temp-gruu - presumeably the PBX = would have to anonymize the request to the extent possible and the = network may provide additional privacy capabilities of course (e.g. = RFC3323/3325). >=20 > Thanks, > Brian >=20 >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, July 19, 2010 10:57 AM > To: Brian Lindsay > Cc: Cullen Jennings; martini@ietf.org > Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin >=20 > IMO the optionality of GRUUs, and of temp gruus, was always a dicy = thing. >=20 > The question is what the client is to do if it has functionality that = requires GRUU but GRUU isn't supported by the registrar? >=20 > In the current context, I think this might come down to = confidentiality features in the PBX. It (or the phones it serves) is = likely to be designed to use temp-gruu to implement those features, = since for it there aren't a lot of alternatives. So if in a particular = deployment the SSP registrar doesn't support temp-gruus, what is the = pbx/phone to do about those features? I think about all it can do is = disable them - eliminating possibility of anonymous calls. >=20 > Now it may be that the SSP has some alternative mechanism for = anonymity. > But how will the PBX know to use that? Also, such a mechanism wouldn't = support anonymity on calls within the PBX. >=20 > Maybe that is as it must be. But I think we must consider this = carefully before deciding. >=20 > Thanks, > Paul >=20 > Brian Lindsay wrote: > > Hi, > > > > I'd disagree with making temp gruu's mandatory to implement in = this draft. Some SSP's may have architectures/privacy functions that = would not require this to support anonimity (e.g. using B2BUA's). I'd = prefer to keep the text as is for temp-gruu's. > > > > > > Thanks, > > Brian > > > > ------------- > > Brian Lindsay > > Sr. Architect, System Architecture > > GENBAND > > Office: +1.613.763.3459 =20 > > www.genband.com > > > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > > Behalf Of Cullen Jennings > > Sent: Sunday, July 18, 2010 1:02 PM > > To: martini@ietf.org > > Subject: [martini] WGLC comments on draft-ietf-martini-gin > > > > > > Looks like a fully formed sausage - I like it. Two issues when I = skimmed it. > > > > The support for temp gruus seems to be optional. I think it should = be mandatory to implement. The exact deployment models where we want to = use this are the places where many people believe there is a legal = requirement to support anonymous calls and implementing this put us into = the situation where there are pretty much no alternatives way to do it. > > > > Please change "must" to "MUST" in section 5.1 > > First, it must contain an option tag of "gin" in > > both a "Require" header field and a "Proxy-Require" header field. > > You might want to consider "must" in the next sentence too. > > > > Cullen > > > > > > PS - Thank you to Richard for pointing out this to me - I had missed = it because I filter on WGLC on the subject lines. > > > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From alan.b.johnston@gmail.com Mon Jul 19 11:49:18 2010 Return-Path: <alan.b.johnston@gmail.com> 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 60C723A67A1 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 11:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1IzMAwjJg3Pb for <martini@core3.amsl.com>; Mon, 19 Jul 2010 11:49:17 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 48E833A68D5 for <martini@ietf.org>; Mon, 19 Jul 2010 11:49:17 -0700 (PDT) Received: by wwb39 with SMTP id 39so402702wwb.13 for <martini@ietf.org>; Mon, 19 Jul 2010 11:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=0ZtiNpZ81xzjv9QuYLTAGR1tSuwPgZQzuv8lgyYJYoI=; b=lw4EibF13Zg9VpNpspf2xApG3a9zag8Gb31O5O2GqCg1zst+2XPqNj+R9AvXj2cgqt owdkRd6GBbSA5Itm23FiNJ44FzXDcJQESEsOSWQS3cvdA2Ro1XL+Qt4JuQZyJX+THgby iDz+P7lH7AEomXs+SVJC4o9iaX+ujPsxdEbTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=fyk2ePEwK2Mmg0fdw6pAPQ1kWGQybm5GVX2/JZvjZzBpihhzZxSSx/Ug0Gxo7nv88G 1mAtZrGMYIjy4yUZFGFgKAE1TCyhOCKqj5qv/+uy+B2lBCRzcqH+72KrM+/WfhfzVYeV c7PXYwj9JXNEB5fW4NcKEm+ioNrZFRPil9W1o= Received: by 10.227.138.6 with SMTP id y6mr4432065wbt.162.1279565371086; Mon, 19 Jul 2010 11:49:31 -0700 (PDT) Received: from Alans-PowerBook-G4-17.local (99-58-71-98.lightspeed.stlsmo.sbcglobal.net [99.58.71.98]) by mx.google.com with ESMTPS id g37sm42943874wbg.21.2010.07.19.11.49.29 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 11:49:30 -0700 (PDT) Message-ID: <4C449E38.2060200@gmail.com> Date: Mon, 19 Jul 2010 13:49:28 -0500 From: Alan Johnston <alan.b.johnston@gmail.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "martini@ietf.org" <martini@ietf.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 18:49:18 -0000 I have reviewed the document and believe it is ready to progress with no technical issues. A few minor issues are noted below that could be addressed to improve the document, but aren't worth entering into the tracker. - Alan - Section 5.1: The first time the bnc parameter is introduced, it might be worth explaining it stands for Bulk Number Contact - the first time I read it I thought it stood for Bayonet Neill-Concelman... Section 5.1: There are a couple of "must"s that probably are "MUST"s. Section 5.2: There is some justification why the SIP-PBX MUST support Path, but none is given here why the Registrar MUST support it. Is it for the same reason? Section 5.2: While the SIP-PBX MUST include Proxy-Require:gin, it is possible a registration might arrive at a Registrar with a bnc but no Proxy-Require:gin. Should we define the correct behavior of the Registrar for this case? From adam@nostrum.com Mon Jul 19 12:02:06 2010 Return-Path: <adam@nostrum.com> 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 F21263A6B5A for <martini@core3.amsl.com>; Mon, 19 Jul 2010 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 k0rqzI4zx82x for <martini@core3.amsl.com>; Mon, 19 Jul 2010 12:02:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2090A3A6B6A for <martini@ietf.org>; Mon, 19 Jul 2010 12:01:49 -0700 (PDT) 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 o6JJ22w3002915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 14:02:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C44A163.5020801@nostrum.com> Date: Mon, 19 Jul 2010 14:02:59 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Alan Johnston <alan.b.johnston@gmail.com> References: <4C449E38.2060200@gmail.com> In-Reply-To: <4C449E38.2060200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 19:02:06 -0000 On 7/19/10 1:49 PM, Alan Johnston wrote: > I have reviewed the document and believe it is ready to progress with no > technical issues. A few minor issues are noted below that could be > addressed to improve the document, but aren't worth entering into the > tracker. > > - Alan - > > Section 5.1: > > The first time the bnc parameter is introduced, it might be worth > explaining it stands for Bulk Number Contact - the first time I read it > I thought it stood for Bayonet Neill-Concelman... Good point. > Section 5.1: > > There are a couple of "must"s that probably are "MUST"s. That's correct -- these are in the tracker. > Section 5.2: > > There is some justification why the SIP-PBX MUST support Path, but none > is given here why the Registrar MUST support it. Is it for the same reason? Yes. Unless the registrar supports it, including support in the PBX isn't particularly useful. > Section 5.2: > > While the SIP-PBX MUST include Proxy-Require:gin, it is possible a > registration might arrive at a Registrar with a bnc but no > Proxy-Require:gin. Should we define the correct behavior of the > Registrar for this case? How would that happen? /a From alan.b.johnston@gmail.com Mon Jul 19 12:43:14 2010 Return-Path: <alan.b.johnston@gmail.com> 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 943BC3A6902 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 12:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 aRA8QLB+DPFX for <martini@core3.amsl.com>; Mon, 19 Jul 2010 12:43:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1FF113A65A5 for <martini@ietf.org>; Mon, 19 Jul 2010 12:43:12 -0700 (PDT) Received: by wyf22 with SMTP id 22so500293wyf.31 for <martini@ietf.org>; Mon, 19 Jul 2010 12:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=crhKY9enFH3kOUpIWHK1PzX5yZ1rh+9dSka2kzlFask=; b=m2dff8ghlEmp/I7KAuI2p19ySvjRlrBhcAkw4lBrXafPCtwfGfadTn9n82pdVcxARr /VWcrU6h/K0gNGHZfb4dPxAUUUT6y/y+JCgjs3jMCXYvE2FOL3qwdD4L/nLCcPnJOKIu xHa5rGimPMpVHDuNugetTr5oKFesFbo4SF7u0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=q8BMDnSs1aOtMDtQmERDdTqQhsoFDtPs9eyKeJe7Jn/M9xmtIX7YMppPE7awyL/Fe7 AdeGOqsBrbTsAPYVw9bhmyNqzcfnQx/ok6R0pAddIttLla5im0ZttXA6b2kEPXpkuIeP Om5ThsK25JMb1RMp8tNImMSaf0z22SYE8lPXE= Received: by 10.227.157.200 with SMTP id c8mr3077119wbx.69.1279568601700; Mon, 19 Jul 2010 12:43:21 -0700 (PDT) Received: from Alans-PowerBook-G4-17.local (99-58-71-98.lightspeed.stlsmo.sbcglobal.net [99.58.71.98]) by mx.google.com with ESMTPS id 2sm2482879wey.0.2010.07.19.12.43.19 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 12:43:20 -0700 (PDT) Message-ID: <4C44AAD6.9010106@gmail.com> Date: Mon, 19 Jul 2010 14:43:18 -0500 From: Alan Johnston <alan.b.johnston@gmail.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Adam Roach <adam@nostrum.com> References: <4C449E38.2060200@gmail.com> <4C44A163.5020801@nostrum.com> In-Reply-To: <4C44A163.5020801@nostrum.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 19:43:14 -0000 On 7/19/10 2:02 PM, Adam Roach wrote: > >> Section 5.2: >> >> While the SIP-PBX MUST include Proxy-Require:gin, it is possible a >> registration might arrive at a Registrar with a bnc but no >> Proxy-Require:gin. Should we define the correct behavior of the >> Registrar for this case? > > How would that happen? Could be misconfiguration or other error. Or someone might turn off Proxy-Require in order to get the registration to work through some ALG or proxy. I guess I'm asking if the Registrar should process or reject a bnc registration if the Proxy-Require isn't present. - Alan - > > /a > From adam@nostrum.com Mon Jul 19 13:03:28 2010 Return-Path: <adam@nostrum.com> 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 32EB63A68C7 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 13:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, SPF_PASS=-0.001] 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 EStAi227ViBj for <martini@core3.amsl.com>; Mon, 19 Jul 2010 13:03:25 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 24A833A67FB for <martini@ietf.org>; Mon, 19 Jul 2010 13:03:24 -0700 (PDT) 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 o6JK3cRC008117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 15:03:38 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C44AFD3.3000403@nostrum.com> Date: Mon, 19 Jul 2010 15:04:35 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Elwell, John" <john.elwell@siemens-enterprise.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <A444A0F8084434499206E78C106220CAECA8AAE4@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAECA8AAE4@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 19 Jul 2010 20:03:28 -0000 In general, I agree that all these nits are in need of fixing, save one: On 7/12/10 4:25 AM, Elwell, John wrote: > N6. " Further, the term "SSP" is meant as an acronym for a "SIP Service > Provider," while " > Move the comma outside the quotes. This is a matter of U.S. versus U.K. English. In the U.S., punctuation always goes inside quotes according to most style guides (cf. Chicago Manual of Style, section 6.8). The lore around this dates back to typographical convention: apparently, the tiny dies that held commas and periods tended to be knocked out of position easily -- a problem that could be solved by wedging them between a letter and a quotation mark. For more detail, see http://en.wikipedia.org/wiki/Quotation_mark#Typographical_considerations /a From brian.lindsay@genband.com Mon Jul 19 13:12:01 2010 Return-Path: <brian.lindsay@genband.com> 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 3EC7C3A6809 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 13:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hKKVKWhYKZ4r for <martini@core3.amsl.com>; Mon, 19 Jul 2010 13:11:59 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 159A03A68AD for <martini@ietf.org>; Mon, 19 Jul 2010 13:11:59 -0700 (PDT) Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTESxnB9k2K/rW/UyBbNdhPhoBjhoXf9P@postini.com; Mon, 19 Jul 2010 13:12:14 PDT Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 15:10:03 -0500 Received: from GBPLMAIL01.genband.com ([fe80::5527:203:6352:79a0]) by GBEX01.genband.com ([fe80::8063:55ef:b7ab:3543%14]) with mapi; Mon, 19 Jul 2010 15:10:03 -0500 From: Brian Lindsay <brian.lindsay@genband.com> To: Cullen Jennings <fluffy@cisco.com> Thread-Topic: [martini] WGLC comments on draft-ietf-martini-gin Thread-Index: AQHLJ3Bxpdp9jmQ5tkKJSutf85I+M5K4qNRg Date: Mon, 19 Jul 2010 20:10:00 +0000 Message-ID: <F1A0ED6425368141998E077AC43334E4037AF3@gbplmail01.genband.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl><D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> <F1A0ED6425368141998E077AC43334E4037905@gbplmail01.genband.com> <4C4467BD.5060505@cisco.com> <F1A0ED6425368141998E077AC43334E4037A11@gbplmail01.genband.com> <8E65E5ED-2DFB-4287-9713-E4CB2E71F204@cisco.com> In-Reply-To: <8E65E5ED-2DFB-4287-9713-E4CB2E71F204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2010 20:10:03.0254 (UTC) FILETIME=[5F8BA160:01CB277E] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.000.1038-17516.001 X-TM-AS-Result: No--47.565100-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 20:12:01 -0000 Hi, My preferance is to keep the text in the draft "as is" for GRUUs in gener= al: describe how the GRUU mechanism works with gin, but don't couple/requir= e that a gin registration implementation must implement the GRUU mechanism. Regards Brian -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Monday, July 19, 2010 2:30 PM To: Brian Lindsay Cc: Paul Kyzivat (pkyzivat); martini@ietf.org Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin Well - the first question is if we agree that non temp GRUUs are mandatory = to implement on the SSP side? If we don't agree on this we are not going t= o get far on the temp conversation.=20 On Jul 19, 2010, at 10:00 , Brian Lindsay wrote: > Hi Paul, >=20 > Perhaps to add to your first point, I think temporary GRUUs aren't eve= n mandatory to implement in RFC 5627? >=20 > I think the draft currently has the right balance: it defines how GRUU= s/Temp-GRUUs work with the "gin" registration mechanism (and defines the ne= cessary extensions for this), but doesn't mandate them. Mandating/coupling = argueably goes beyond the scope of the MARTINI requirements. Temp-GRUUs by = themselves also aren't necessarily sufficient for full anonymity (e.g. SDP = info could be used for correlation) and it hasn't been in the scope of the = work to mandate a full solution for anonymity. >=20 > In the absence of availability a temp-gruu - presumeably the PBX would= have to anonymize the request to the extent possible and the network may p= rovide additional privacy capabilities of course (e.g. RFC3323/3325). >=20 > Thanks, > Brian >=20 >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, July 19, 2010 10:57 AM > To: Brian Lindsay > Cc: Cullen Jennings; martini@ietf.org > Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin >=20 > IMO the optionality of GRUUs, and of temp gruus, was always a dicy thing. >=20 > The question is what the client is to do if it has functionality that req= uires GRUU but GRUU isn't supported by the registrar? >=20 > In the current context, I think this might come down to confidentiality f= eatures in the PBX. It (or the phones it serves) is likely to be designed t= o use temp-gruu to implement those features, since for it there aren't a lo= t of alternatives. So if in a particular deployment the SSP registrar doesn= 't support temp-gruus, what is the pbx/phone to do about those features? I = think about all it can do is disable them - eliminating possibility of anon= ymous calls. >=20 > Now it may be that the SSP has some alternative mechanism for anonymity. > But how will the PBX know to use that? Also, such a mechanism wouldn't su= pport anonymity on calls within the PBX. >=20 > Maybe that is as it must be. But I think we must consider this carefully = before deciding. >=20 > Thanks, > Paul >=20 > Brian Lindsay wrote: > > Hi, > > > > I'd disagree with making temp gruu's mandatory to implement in this = draft. Some SSP's may have architectures/privacy functions that would not r= equire this to support anonimity (e.g. using B2BUA's). I'd prefer to keep t= he text as is for temp-gruu's. > > > > > > Thanks, > > Brian > > > > ------------- > > Brian Lindsay > > Sr. Architect, System Architecture > > GENBAND > > Office: +1.613.763.3459 =20 > > www.genband.com > > > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of Cullen Jennings > > Sent: Sunday, July 18, 2010 1:02 PM > > To: martini@ietf.org > > Subject: [martini] WGLC comments on draft-ietf-martini-gin > > > > > > Looks like a fully formed sausage - I like it. Two issues when I skimme= d it. > > > > The support for temp gruus seems to be optional. I think it should be m= andatory to implement. The exact deployment models where we want to use thi= s are the places where many people believe there is a legal requirement to = support anonymous calls and implementing this put us into the situation whe= re there are pretty much no alternatives way to do it. > > > > Please change "must" to "MUST" in section 5.1 > > First, it must contain an option tag of "gin" in > > both a "Require" header field and a "Proxy-Require" header field. > > You might want to consider "must" in the next sentence too. > > > > Cullen > > > > > > PS - Thank you to Richard for pointing out this to me - I had missed it= because I filter on WGLC on the subject lines. > > > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adam@nostrum.com Mon Jul 19 13:23:40 2010 Return-Path: <adam@nostrum.com> 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 90C2E3A6B76 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 13:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, SPF_PASS=-0.001] 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 jALguWUV3G8u for <martini@core3.amsl.com>; Mon, 19 Jul 2010 13:23:39 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1FDC33A6B7A for <martini@ietf.org>; Mon, 19 Jul 2010 13:23:38 -0700 (PDT) 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 o6JKNqgb009790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 15:23:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C44B492.7060000@nostrum.com> Date: Mon, 19 Jul 2010 15:24:50 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Elwell, John" <john.elwell@siemens-enterprise.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <A444A0F8084434499206E78C106220CAECA8AAE4@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAECA8AAE4@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 19 Jul 2010 20:23:40 -0000 On 7/12/10 4:25 AM, Elwell, John wrote: > 1. "A registrar that receives a Contact URI with both a "bnc" parameter > and a user portion MUST either discard the user portion and process > the request as if the parameter were not present or ..." > It doesn't make sense. If the parameter were not present, one would expect a user portion to be present. I think this should say : > "A registrar that receives a Contact URI with both a "bnc" parameter > and a user portion MUST either discard the user portion and process > the request as if the user portion were not present or ..." > ^^^^^^^^^^^^ Agreed. > 2. "Currently, the descriptions are somewhat informal, and omit some > details for the sake of brevity. If the MARTINI working group > expresses interest in furthering the mechanism described by this > document, they will be fleshed out with more detail and formality." > This seems to be historic and should be deleted. Agreed. > 3. " When a UA registers with the SIP-PBX using GRUU procedures for a > Contact, the SIP-PBX adds an "sg" parameter to the GRUU parameter it > received from the SSP. This "sg" parameter contains a disambiguation > token that the SIP-PBX can use to route the request to the proper > user agent." > This isn't terribly clear. Rewording as follows might help: > "When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter to the GRUU parameter it received from the SSP. This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route inbound requests to the proper UA." I like the rewording. > 4. "The SSP registrar then maps I_i to the "bnc" AOR template and > instance ID using the database, a persistent hash-map or similar > technology." > This is the first use of the expression "AOR template and instance ID". We could do with some clarification, but I don't have a proposal. We have something that could be described as a template, but I would have considered that to be a contact template rather than an AOR template. > I propose "...maps I_i to the contact and instance ID using the database...." > 5. "(1) The SIP-PBX registers with the SSP for a range of AORs. > It includes the URI it expects to receive in the Request-URI > in its "Contact" header field, and includes information that > routes to the SIP-PBX in the "Path" header field." > I think "the URI" should be changed to "the domain". Only the domain part of the REGISTER request's Contact header field will appear in the Request-URI of the inbound request. But it's not really just the domain -- it can have parameters. Perhaps 'It indicates the form of the URI it expects to receive in the Request-URI in its "Contact" header field....' /a From trac@tools.ietf.org Mon Jul 19 14:25:17 2010 Return-Path: <trac@tools.ietf.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 C3B3A3A6B07 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 14:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-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 VkYONIeF86TX for <martini@core3.amsl.com>; Mon, 19 Jul 2010 14:25:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F30553A6A7F for <martini@ietf.org>; Mon, 19 Jul 2010 14:25:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1Oaxq7-0000Ro-PT; Mon, 19 Jul 2010 14:25:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Jul 2010 21:25:31 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/52#comment:1 Message-ID: <073.9234ac89e474caf8e491ef48ad282be5@tools.ietf.org> References: <064.23d267439a95e7102b076deb61eb89a5@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <064.23d267439a95e7102b076deb61eb89a5@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #52: Out-of-date paragraph from prior to being a WG doc X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 19 Jul 2010 21:25:17 -0000 #52: Out-of-date paragraph from prior to being a WG doc ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Resolution: duplicate Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => duplicate Comment: Duplicate of ticket #50, point #2. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/52#comment:1> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Mon Jul 19 14:26:19 2010 Return-Path: <trac@tools.ietf.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 862883A6B27 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-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 Ffe88KWEHEhC for <martini@core3.amsl.com>; Mon, 19 Jul 2010 14:26:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9B3263A6A7F for <martini@ietf.org>; Mon, 19 Jul 2010 14:26:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1Oaxr7-0003uX-LI; Mon, 19 Jul 2010 14:26:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Jul 2010 21:26:33 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/53#comment:1 Message-ID: <073.59034e6c448969f8fdf08056d9cca5e8@tools.ietf.org> References: <064.8865c7a053f56bdcbdb5e37bd0581f82@tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <064.8865c7a053f56bdcbdb5e37bd0581f82@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #53: Editorial: typo in section 7.1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 19 Jul 2010 21:26:19 -0000 #53: Editorial: typo in section 7.1 ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: closed Priority: trivial | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Resolution: duplicate Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => duplicate Comment: Duplicate of ticket #49, point N.9 -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/53#comment:1> martini <http://tools.ietf.org/martini/> From pkyzivat@cisco.com Mon Jul 19 15:22:40 2010 Return-Path: <pkyzivat@cisco.com> 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 A72613A6B9A for <martini@core3.amsl.com>; Mon, 19 Jul 2010 15:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Rm1AsBADnH+Q for <martini@core3.amsl.com>; Mon, 19 Jul 2010 15:22:38 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 719403A6B9B for <martini@ietf.org>; Mon, 19 Jul 2010 15:22:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="134358151" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Jul 2010 22:22:52 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6JMMqdg012886; Mon, 19 Jul 2010 22:22:52 GMT Message-ID: <4C44D03C.1080009@cisco.com> Date: Mon, 19 Jul 2010 18:22:52 -0400 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Lindsay <brian.lindsay@genband.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> <F1A0ED6425368141998E077AC43334E4037905@gbplmail01.genband.com> <4C4467BD.5060505@cisco.com> <F1A0ED6425368141998E077AC43334E4037A11@gbplmail01.genband.com> In-Reply-To: <F1A0ED6425368141998E077AC43334E4037A11@gbplmail01.genband.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 22:22:40 -0000 Brian Lindsay wrote: > Hi Paul, > > Perhaps to add to your first point, I think temporary GRUUs aren't even mandatory to implement in RFC 5627? Neither kind is mandatory to implement. > I think the draft currently has the right balance: it defines how GRUUs/Temp-GRUUs work with the "gin" registration mechanism (and defines the necessary extensions for this), but doesn't mandate them. Mandating/coupling argueably goes beyond the scope of the MARTINI requirements. Temp-GRUUs by themselves also aren't necessarily sufficient for full anonymity (e.g. SDP info could be used for correlation) and it hasn't been in the scope of the work to mandate a full solution for anonymity. > > In the absence of availability a temp-gruu - presumeably the PBX would have to anonymize the request to the extent possible and the network may provide additional privacy capabilities of course (e.g. RFC3323/3325). If the PBX can provide an acceptable anonymity service without temp gruu, then it won't ever need it. (It seems dubious that it would offer the same service at two levels of anonymity.) This is the same problem that a plain sip phone has depending on whether the registrar supports gruu. But PBXs are typically expected to offer a higher level of service. Still, I'm ambivalent about this. Thanks, Paul > Thanks, > Brian > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, July 19, 2010 10:57 AM > To: Brian Lindsay > Cc: Cullen Jennings; martini@ietf.org > Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin > > IMO the optionality of GRUUs, and of temp gruus, was always a dicy thing. > > The question is what the client is to do if it has functionality that requires GRUU but GRUU isn't supported by the registrar? > > In the current context, I think this might come down to confidentiality features in the PBX. It (or the phones it serves) is likely to be designed to use temp-gruu to implement those features, since for it there aren't a lot of alternatives. So if in a particular deployment the SSP registrar doesn't support temp-gruus, what is the pbx/phone to do about those features? I think about all it can do is disable them - eliminating possibility of anonymous calls. > > Now it may be that the SSP has some alternative mechanism for anonymity. > But how will the PBX know to use that? Also, such a mechanism wouldn't support anonymity on calls within the PBX. > > Maybe that is as it must be. But I think we must consider this carefully before deciding. > > Thanks, > Paul > > Brian Lindsay wrote: >> Hi, >> >> I'd disagree with making temp gruu's mandatory to implement in this draft. Some SSP's may have architectures/privacy functions that would not require this to support anonimity (e.g. using B2BUA's). I'd prefer to keep the text as is for temp-gruu's. >> >> >> Thanks, >> Brian >> >> ------------- >> Brian Lindsay >> Sr. Architect, System Architecture >> GENBAND >> Office: +1.613.763.3459 >> www.genband.com >> >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: Sunday, July 18, 2010 1:02 PM >> To: martini@ietf.org >> Subject: [martini] WGLC comments on draft-ietf-martini-gin >> >> >> Looks like a fully formed sausage - I like it. Two issues when I skimmed it. >> >> The support for temp gruus seems to be optional. I think it should be mandatory to implement. The exact deployment models where we want to use this are the places where many people believe there is a legal requirement to support anonymous calls and implementing this put us into the situation where there are pretty much no alternatives way to do it. >> >> Please change "must" to "MUST" in section 5.1 >> First, it must contain an option tag of "gin" in >> both a "Require" header field and a "Proxy-Require" header field. >> You might want to consider "must" in the next sentence too. >> >> Cullen >> >> >> PS - Thank you to Richard for pointing out this to me - I had missed it because I filter on WGLC on the subject lines. >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > From adam@nostrum.com Mon Jul 19 16:21:51 2010 Return-Path: <adam@nostrum.com> 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 D57A43A695D for <martini@core3.amsl.com>; Mon, 19 Jul 2010 16:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, SPF_PASS=-0.001] 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 2+4e2w84L-lH for <martini@core3.amsl.com>; Mon, 19 Jul 2010 16:21:51 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A8A8E3A6947 for <martini@ietf.org>; Mon, 19 Jul 2010 16:21:50 -0700 (PDT) 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 o6JNLvR5024043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 18:21:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C44DE51.2030305@nostrum.com> Date: Mon, 19 Jul 2010 18:22:57 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Hadriel Kaplan <HKaplan@acmepacket.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <430FC6BDED356B4C8498F634416644A921187F7251@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A921187F7251@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Mon, 19 Jul 2010 23:21:51 -0000 On 7/16/10 10:37 AM, Hadriel Kaplan wrote: > 5) Section 7.2.1 says: > In particular, the "bnc" parameter is forbidden from appearing in the > body of a reg-event notify. > > Something about that statement rings warning bells in my head. I don't know what that something is, but it seems wrong to me. :) Are we absolutely sure this is a normative statement we want, forever? The logic here is that subscribers to the event package won't necessarily know about the GIN extension. If you send them a "bnc" URI, they're going to have no clue that it's not just a normal URI. Now, I don't think this prohibition is a "forever" thing. There's certainly nothing that says that another extension (say, VERMOUTH) is prohibited from overriding this prohibition with another behavior -- so long as the subscriber indicates that it would know what to do with a "bnc" URI. Would the following change address your concern? In particular, the "bnc" parameter is forbidden from appearing in the body of a reg-event notify unless the subscriber has indicated knowledge of the semantics of the "bnc" parameter. The means for indicating this support are out of scope of this document. /a From adam@nostrum.com Mon Jul 19 16:27:54 2010 Return-Path: <adam@nostrum.com> 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 4C4703A6BB2 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 16:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, SPF_PASS=-0.001] 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 YqOp5FcNydf9 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 16:27:53 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 68C1D3A6B8D for <martini@ietf.org>; Mon, 19 Jul 2010 16:27:52 -0700 (PDT) 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 o6JNS2S1024505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 18:28:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C44DFBE.7020009@nostrum.com> Date: Mon, 19 Jul 2010 18:29:02 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Martien Huysmans <martien.huysmans@ericsson.com> References: <B5CE2B521539624E8364D395B6F76B5C23D403A73A@ESESSCMS0356.eemea.ericsson.se> <B5CE2B521539624E8364D395B6F76B5C23D4384B53@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <B5CE2B521539624E8364D395B6F76B5C23D4384B53@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] FW: GIN: 'reg' event package proposal 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: Mon, 19 Jul 2010 23:27:54 -0000 Martien: I'm afraid I don't understand your question. You're assuming some very specific network architecture that isn't immediately obvious to me. Who is "user1"? Is that some kind of internal identifier for a user? Is it their contact on their phone, or their AOR at the SIP-PBX (or both)? Are you imaging +12145550102 to be a regular extension on the PBX, or the PBX identifier (or both)? You've thrown a bunch of identifiers into your question without explaining what they identify. /a On 7/8/10 7:00 AM, Martien Huysmans wrote: > Any comments to the questions below? > > Regards Martien > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > Sent: Monday, June 28, 2010 3:04 PM > To: martini@ietf.org > Subject: [martini] FW: GIN: 'reg' event package proposal > > Forgot to include martini@ietf.org in the To. > > -----Original Message----- > From: Martien Huysmans > Sent: Monday, June 28, 2010 2:46 PM > To: 'Adam Roach' > Subject: RE: [martini] GIN: 'reg' event package proposal > > Adam > > Assume that the pbx has a user, say sip:user1@pbx.com with corresponding SSP identity: sip:+12145550102@ssp.example.com. > Then I guess that it's is upto the SIP-PBX to include both, if both are publicly-visible? > > Would the procedure below imply that a SIP-PBX could provide a different replies to a SUBSCRIBE for regvent depending on the RURI: > - SUBSCRIBE sip:+12145550102@ssp.example.com as described below > - SUBSCRIBE sip:user1@pbx.com with all AOR's included ? > > Do you see a similar rule for the Contact's included in the registration document? > > Regards Martien > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Saturday, June 19, 2010 1:03 AM > To: martini@ietf.org > Subject: [martini] GIN: 'reg' event package proposal > > After giving things some thought and reading through the 'reg' event package RFC, I think things will only really work if the SIP-PBX puts the public (i.e. SSP) AOR into the registration document. I propose the following text (which will appear in the next version of GIN unless there is a constructive counter-proposal): > > When a SIP-PBX receives a registration event subscription addressed > to an AOR that has been registered using the bulk registration > mechanism described in this document, then the resulting registration > information documents SHOULD contain an 'aor' attribute in its<registration/> element that corresponds to the AOR at the SSP. > > For example, consider a SIP-PBX that has registered with an SSP > that has a domain of "ssp.example.com" The SIP-PBX used a contact > of "sip:198.51.100.3:5060;bnc". After such registration is > complete, a registration event subscription arriving at the SSP > with a Request-URI of "sip:+12145550102@ssp.example.com" will be > re-targeted to the SIP-PBX, with a Request-URI of > "sip:+12145550102@198.51.100.3:5060". The resulting registration > document created by the SIP-PBX would contain a<registration/> > element with an "aor" attribute of > "sip:+12145550102@ssp.example.com". > > This behavior ensures that subscribers external to the system (and > unaware of GIN procedures) will be able to find the relevant > information in the registration document (since they will be > looking for the publicly-visible AOR, not the address used for > sending information from the SSP to the SIP-PBX). > > Also, based on Paul's comments during Interim V regarding the potential ability for SSPs to form back-end subscriptions to SIP-PBXes for registration state, I propose loosening up the normative requirement about passing through reg event SUBSCRIBEs; everything after the word "unless" is new: > > If the SSP receives a SUBSCRIBE request for the registration event > package with a Request-URI that indicates a contact registered via > the "Bulk Number Contact" mechanism defined in this document, then > the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that > is would proxy an INVITE bound for that AOR, unless the SSP has and > can maintain a copy of complete, accurate, and up-to-date information > from the SIP-PBX (e.g., through an active back-end subscription). > > Again, this text will appear in the next version of GIN unless there is a constructive counter-proposal. > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Mon Jul 19 16:39:25 2010 Return-Path: <adam@nostrum.com> 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 B89AA3A6BC2 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 16:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, SPF_PASS=-0.001] 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 mDcyQQxpMrI5 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 16:35:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1BDFA3A6BB7 for <martini@ietf.org>; Mon, 19 Jul 2010 16:33:41 -0700 (PDT) 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 o6JNXeuh024924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 18:33:40 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C44E110.8010109@nostrum.com> Date: Mon, 19 Jul 2010 18:34:40 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Alan Johnston <alan.b.johnston@gmail.com> References: <4C449E38.2060200@gmail.com> <4C44A163.5020801@nostrum.com> <4C44AAD6.9010106@gmail.com> In-Reply-To: <4C44AAD6.9010106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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: Mon, 19 Jul 2010 23:39:29 -0000 On 7/19/10 2:43 PM, Alan Johnston wrote: > > On 7/19/10 2:02 PM, Adam Roach wrote: >>> Section 5.2: >>> >>> While the SIP-PBX MUST include Proxy-Require:gin, it is possible a >>> registration might arrive at a Registrar with a bnc but no >>> Proxy-Require:gin. Should we define the correct behavior of the >>> Registrar for this case? >> How would that happen? > Could be misconfiguration or other error. Or someone might turn off > Proxy-Require in order to get the registration to work through some ALG > or proxy. I don't think we need to make explicit accommodations for failures borne of attempts to defeat the protocol itself. > I guess I'm asking if the Registrar should process or reject a bnc > registration if the Proxy-Require isn't present. I don't think so. If the Registrar isn't proxying the request, then it should ignore "Proxy-Require" as vigorously as possible. /a From john.elwell@siemens-enterprise.com Mon Jul 19 23:27:41 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 C8D483A6BD9 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 23:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] 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 ek43u17JG+Yy for <martini@core3.amsl.com>; Mon, 19 Jul 2010 23:27:41 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AADFA3A6BB4 for <martini@ietf.org>; Mon, 19 Jul 2010 23:27:40 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-904084; Tue, 20 Jul 2010 08:27:54 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4B02523F0278; Tue, 20 Jul 2010 08:27:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Jul 2010 08:27:54 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Adam Roach <adam@nostrum.com> Date: Tue, 20 Jul 2010 08:27:52 +0200 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsngFDsac2Jv5glSeOzY4ZRF8R4ygAVCIMQ Message-ID: <A444A0F8084434499206E78C106220CAECBA4BBF@MCHP058A.global-ad.net> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <A444A0F8084434499206E78C106220CAECA8AAE4@MCHP058A.global-ad.net> <4C44B492.7060000@nostrum.com> In-Reply-To: <4C44B492.7060000@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 06:27:42 -0000 =20 >=20 > > 4. "The SSP registrar then maps I_i to the "bnc" AOR template and > > instance ID using the database, a persistent=20 > hash-map or similar > > technology." > > This is the first use of the expression "AOR template and=20 > instance ID". We could do with some clarification, but I=20 > don't have a proposal. We have something that could be=20 > described as a template, but I would have considered that to=20 > be a contact template rather than an AOR template. > > >=20 > I propose "...maps I_i to the contact and instance ID using the=20 > database...." [JRE] OK. Don't forget there are two more instances of "AOR template" that = need fixing. >=20 > > 5. "(1) The SIP-PBX registers with the SSP for a range of AORs. > > It includes the URI it expects to receive in the Request-URI > > in its "Contact" header field, and includes information that > > routes to the SIP-PBX in the "Path" header field." > > I think "the URI" should be changed to "the domain". Only=20 > the domain part of the REGISTER request's Contact header=20 > field will appear in the Request-URI of the inbound request. >=20 > But it's not really just the domain -- it can have=20 > parameters. Perhaps=20 > 'It indicates the form of the URI it expects to receive in the=20 > Request-URI in its "Contact" header field....' [JRE] That would be better. John >=20 > /a > = From john.elwell@siemens-enterprise.com Mon Jul 19 23:41:30 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 4CB553A6BE3 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 23:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] 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 sWhEZChlJkSa for <martini@core3.amsl.com>; Mon, 19 Jul 2010 23:41:25 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F07773A6922 for <martini@ietf.org>; Mon, 19 Jul 2010 23:40:57 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-902065; Tue, 20 Jul 2010 08:41:12 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 654321EB82AB; Tue, 20 Jul 2010 08:41:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 20 Jul 2010 08:41:12 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Alan Johnston <alan.b.johnston@gmail.com>, Adam Roach <adam@nostrum.com> Date: Tue, 20 Jul 2010 08:41:10 +0200 Thread-Topic: [martini] WGLC comments on draft-ietf-martini-gin Thread-Index: Acsnequ1DMpdThBsTmGNogRuWeEEeAAWt7Kw Message-ID: <A444A0F8084434499206E78C106220CAECBA4BC7@MCHP058A.global-ad.net> References: <4C449E38.2060200@gmail.com> <4C44A163.5020801@nostrum.com> <4C44AAD6.9010106@gmail.com> In-Reply-To: <4C44AAD6.9010106@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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, 20 Jul 2010 06:41:30 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: 19 July 2010 20:43 > To: Adam Roach > Cc: martini@ietf.org > Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin >=20 >=20 >=20 > On 7/19/10 2:02 PM, Adam Roach wrote: > >=20 > >> Section 5.2: > >> > >> While the SIP-PBX MUST include Proxy-Require:gin, it is possible a > >> registration might arrive at a Registrar with a bnc but no > >> Proxy-Require:gin. Should we define the correct behavior of the > >> Registrar for this case? > >=20 > > How would that happen? >=20 > Could be misconfiguration or other error. Or someone might turn off > Proxy-Require in order to get the registration to work=20 > through some ALG > or proxy. >=20 > I guess I'm asking if the Registrar should process or reject a bnc > registration if the Proxy-Require isn't present. [JRE] One could also ask the same question about the absence of Require. I = believe it is unusual to specify that an entity that supports extension X m= ust check for the absence of Require/Proxy-Require: X. The purpose of those= header fields is to force an entity that does NOT support extension X to e= xhibit a certain behaviour. The bnc contact URI parameter is the important = item of information for a registrar that supports gin. John >=20 > - Alan - >=20 >=20 > >=20 > > /a > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From alan.b.johnston@gmail.com Tue Jul 20 07:17:38 2010 Return-Path: <alan.b.johnston@gmail.com> 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 AD0443A6B1A for <martini@core3.amsl.com>; Tue, 20 Jul 2010 07:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 h+vvLZqLUyIz for <martini@core3.amsl.com>; Tue, 20 Jul 2010 07:17:37 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 885C83A6989 for <martini@ietf.org>; Tue, 20 Jul 2010 07:17:37 -0700 (PDT) Received: by ewy22 with SMTP id 22so1979557ewy.31 for <martini@ietf.org>; Tue, 20 Jul 2010 07:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=jQ50mMeOdCSyRDJ6AjtrxWqyIonB3bOUFlc0yXZu6wQ=; b=dcyM8IcvIaA3yGRKqj/uNoithkN+VUfqGikxqSLlPfQazJZ4Q5mKNUvQXfyB6B7Jyy uX+RPf2Lx2PQqeQQg/enJzFZNuFGjnliVk7e2Uh9kBclwtV1oo4hMxMG1ylAAwrAzPpX vKa9YzgcMVY8pz5Yr3WPCcDKaGc0dlWvcs5dA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Io3c0M7WK2PSAWeTG4WVKBIPSmfVKR+c2gJ7ikoJdnTMzOwU0TH7jvIbtMtCxjfgDi g58h+1/Ztw/X5epuU4fmt5eOXctym+RUUJ27pOD7a6ZGfFOiicLauRIrJxkQmjVqcIgP gCtVCiMyh+AGlMXzEJRYNOmGA54p6cZkTVwww= Received: by 10.227.138.5 with SMTP id y5mr5569872wbt.204.1279635472277; Tue, 20 Jul 2010 07:17:52 -0700 (PDT) Received: from Alans-PowerBook-G4-17.local (99-58-71-98.lightspeed.stlsmo.sbcglobal.net [99.58.71.98]) by mx.google.com with ESMTPS id a27sm47427269wbe.12.2010.07.20.07.17.49 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 07:17:50 -0700 (PDT) Message-ID: <4C45B00B.6000409@gmail.com> Date: Tue, 20 Jul 2010 09:17:47 -0500 From: Alan Johnston <alan.b.johnston@gmail.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Elwell, John" <john.elwell@siemens-enterprise.com> References: <4C449E38.2060200@gmail.com> <4C44A163.5020801@nostrum.com> <4C44AAD6.9010106@gmail.com> <A444A0F8084434499206E78C106220CAECBA4BC7@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAECBA4BC7@MCHP058A.global-ad.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin 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, 20 Jul 2010 14:17:38 -0000 On 7/20/10 1:41 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Alan Johnston >> Sent: 19 July 2010 20:43 >> To: Adam Roach >> Cc: martini@ietf.org >> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin >> >> >> >> On 7/19/10 2:02 PM, Adam Roach wrote: >>> >>>> Section 5.2: >>>> >>>> While the SIP-PBX MUST include Proxy-Require:gin, it is possible a >>>> registration might arrive at a Registrar with a bnc but no >>>> Proxy-Require:gin. Should we define the correct behavior of the >>>> Registrar for this case? >>> >>> How would that happen? >> >> Could be misconfiguration or other error. Or someone might turn off >> Proxy-Require in order to get the registration to work >> through some ALG >> or proxy. >> >> I guess I'm asking if the Registrar should process or reject a bnc >> registration if the Proxy-Require isn't present. > [JRE] One could also ask the same question about the absence of Require. I believe it is unusual to specify that an entity that supports extension X must check for the absence of Require/Proxy-Require: X. The purpose of those header fields is to force an entity that does NOT support extension X to exhibit a certain behaviour. The bnc contact URI parameter is the important item of information for a registrar that supports gin. > Require is probably more relevant than Proxy-Require. I agree with your answer - the Registrar looks for the presence of the bnc parameter. - Alan - > John > >> >> - Alan - >> >> >>> >>> /a >>> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> From spencer@wonderhamster.org Tue Jul 20 08:10:53 2010 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 DC1A83A68B5 for <martini@core3.amsl.com>; Tue, 20 Jul 2010 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=1.478, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 v+gIj1dQIdHv for <martini@core3.amsl.com>; Tue, 20 Jul 2010 08:10:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 0DE2E3A6B1A for <martini@ietf.org>; Tue, 20 Jul 2010 08:10:52 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQRKW-1OTYSa3gSK-00TsrH; Tue, 20 Jul 2010 11:11:04 -0400 Message-ID: <B011440129B84B30978779D2BCA75D18@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "Richard Shockey" <richard@shockey.us>, <bruno.chatras@orange-ftgroup.com>, <bernard_aboba@hotmail.com>, <martini@ietf.org> References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us> <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> Date: Tue, 20 Jul 2010 10:10:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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.5931 X-Provags-ID: V02:K0:VhATGFVcfAyyBud3HdZMPGa9IdrYUjj2SFeANZDEpru WjXX27Hy1dDpKnFjllRe7Smz5S47h3XgE5FVJLD2mYkDaEKEY9 ea3b942hUQCb5nV6dIXaOBqL9oE1niNYPkLO61ntQcFbphISw3 I5jL84fXf8BX8m0e0oL8vrhHSMYzHfugnFiF/9RbR12pWQzj69 SzYaaKhIit99Zi9FdJwi5cgpjtsBtIa3l7nR51vxSQ= Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 15:10:54 -0000 Hi, Bruno, Speaking as co-chair, What Bernard and I told Gonzalo was that we expected to have 3GPP CT1 send a request to the ADs requesting guidance on how to get a second option tag allocated, and let the ADs provide guidance from that point. I can't imagine that we're talking about doing anything beyond an additional IANA allocation in the IETF, so I'm not seeing this as gating for WGLC of the GIN protocol specification. Thanks, Spencer ----- Original Message ----- From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "Richard Shockey" <richard@shockey.us>; <bruno.chatras@orange-ftgroup.com>; <bernard_aboba@hotmail.com>; <martini@ietf.org> Sent: Monday, July 19, 2010 11:09 AM Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" I agree with Richard. My recollection of the discussion was that it leaned towards there not being a dependency between the two drafts - the two can proceed at their own rates. John > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: 19 July 2010 16:40 > To: bruno.chatras@orange-ftgroup.com; > bernard_aboba@hotmail.com; martini@ietf.org > Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call > on "Registration for Multiple Phone Numbers in the SIP" > > My memory of the conversation was quite clear. The two > approaches are orthogonal. Gin is NOT dependant on FRIENDS or > the other way around. Each approach should have its own > option tag. There is NOT a one size fits all solution. > > > > The friends solution can certainly propose a option tag on > its own in the usual way IETG WG way but the two are NOT part > of a single draft. > > > > As far as I'm concerned the WGLC should proceed as normal. > > > > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of > bruno.chatras@orange-ftgroup.com > Sent: Monday, July 19, 2010 9:01 AM > To: bernard_aboba@hotmail.com; martini@ietf.org > Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call > on "Registration for Multiple Phone Numbers in the SIP" > > > > Looking to the minutes of the MARTINI Interim V virtual > meeting, it seems that the discussion about > "draft-vanelburg-martini-friends-00" was inconclusive as to > whether a change was required to the "gin" draft. I don't > think the WGLC can be completed before we have clarified the > interactions between "gin" and "friends". > > Bruno > > > > ________________________________ > > De : martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] De la part de Bernard Aboba > Envoyé : jeudi 15 juillet 2010 19:57 > À : martini@ietf.org > Objet : [martini] REMINDER: Ongoing MARTINI WG last > Call on "Registration for Multiple Phone Numbers in the SIP" > > This is a reminder of an ongoing MARTINI WG last call > on "Registration for Multiple Phone Numbers in the SIP" prior > to requesting that the IESG publish the document as a > Proposed Standard. > > The document is available for inspection here: > > http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt > > MARTINI WG last call will conclude on Thursday, July 22, 2010. > > Please respond to this WG last call, whether you have > comments or not. > > If you have no comments, please reply to this message > and indicate in the body of your message whether you > > think the document is ready for consideration by the > IESG or not. > > If you have comments, please provide them to the WG in > one of the following ways: > > 1. If you have an account on the IETF Tools server, or > can open one, please login and enter your issue(s) in the > > MARTINI Issue tracking database (TRAC), which is available here: > > http://trac.tools.ietf.org/wg/martini/trac/newticket > > Note that if you submit an issue in TRAC, it will > automatically also be posted to the MARTINI WG mailing list. > > 2. If you don't have an account on the IETF Tools > server, please post your > > Issue to the MARTINI WG mailing list (martini at > ietf.org) in the following format: > > To: martini at ietf.org > > Subject: Requirements-Issue: <title of your issue> > > Priority: blocker, critical, major, minor or trivial > > <Explanation of your issue, including a proposal for > specific text changes to resolve the issue> > > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From bruno.chatras@orange-ftgroup.com Tue Jul 20 08:26:53 2010 Return-Path: <bruno.chatras@orange-ftgroup.com> 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 5346B3A6887 for <martini@core3.amsl.com>; Tue, 20 Jul 2010 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 KLBBKgmi-nnR for <martini@core3.amsl.com>; Tue, 20 Jul 2010 08:26:51 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 59C453A6831 for <martini@ietf.org>; Tue, 20 Jul 2010 08:26:51 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BFE1376000A; Tue, 20 Jul 2010 17:29:15 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id ABACE760011; Tue, 20 Jul 2010 17:29:15 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 17:24:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 17:24:53 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <B011440129B84B30978779D2BCA75D18@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsoHckGnklqvYl3Sc6LhaPUc2GZ4AAAOmbA References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us> <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> <B011440129B84B30978779D2BCA75D18@china.huawei.com> From: <bruno.chatras@orange-ftgroup.com> To: <spencer@wonderhamster.org>, <john.elwell@siemens-enterprise.com>, <richard@shockey.us>, <bernard_aboba@hotmail.com>, <martini@ietf.org> X-OriginalArrivalTime: 20 Jul 2010 15:24:55.0705 (UTC) FILETIME=[B5109090:01CB281F] Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 15:26:53 -0000 Hi Spencer, I think the applicability of the 'friends' solution is wider than just = 3GPP IMS networks. This solution is required when non-E.164 numbers or = email-style URI have to be supported and/or when the involved PBXs = expect the Request-URI to contain the actual target identity rather than = something based on a contact address. The criteria for a PBX to decide = whether to send one tag or the other or both need to be documented = somewhere. Same for the SSP behavior when both tags are received and = both mechanisms are supported. Best Regards, Bruno > -----Message d'origine----- > De : Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Envoy=E9 : mardi 20 juillet 2010 17:11 > =C0 : Elwell, John; Richard Shockey; CHATRAS Bruno RD-CORE-ISS;=20 > bernard_aboba@hotmail.com; martini@ietf.org > Objet : Re: [martini] REMINDER: Ongoing MARTINI WG lastCall=20 > on "Registration for Multiple Phone Numbers in the SIP" >=20 > Hi, Bruno, >=20 > Speaking as co-chair, >=20 > What Bernard and I told Gonzalo was that we expected to have=20 > 3GPP CT1 send a request to the ADs requesting guidance on how=20 > to get a second option tag allocated, and let the ADs provide=20 > guidance from that point. >=20 > I can't imagine that we're talking about doing anything=20 > beyond an additional IANA allocation in the IETF, so I'm not=20 > seeing this as gating for WGLC of the GIN protocol specification. >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message ----- > From: "Elwell, John" <john.elwell@siemens-enterprise.com> > To: "Richard Shockey" <richard@shockey.us>;=20 > <bruno.chatras@orange-ftgroup.com>;=20 > <bernard_aboba@hotmail.com>; <martini@ietf.org> > Sent: Monday, July 19, 2010 11:09 AM > Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall=20 > on "Registration for Multiple Phone Numbers in the SIP" >=20 >=20 > I agree with Richard. My recollection of the discussion was=20 > that it leaned towards there not being a dependency between=20 > the two drafts - the two can proceed at their own rates. >=20 > John >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Richard Shockey > > Sent: 19 July 2010 16:40 > > To: bruno.chatras@orange-ftgroup.com; > > bernard_aboba@hotmail.com; martini@ietf.org > > Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call on=20 > > "Registration for Multiple Phone Numbers in the SIP" > > > > My memory of the conversation was quite clear. The two=20 > approaches are=20 > > orthogonal. Gin is NOT dependant on FRIENDS or the other=20 > way around.=20 > > Each approach should have its own option tag. There is NOT=20 > a one size=20 > > fits all solution. > > > > > > > > The friends solution can certainly propose a option tag on=20 > its own in=20 > > the usual way IETG WG way but the two are NOT part of a=20 > single draft. > > > > > > > > As far as I'm concerned the WGLC should proceed as normal. > > > > > > > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > > bruno.chatras@orange-ftgroup.com > > Sent: Monday, July 19, 2010 9:01 AM > > To: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: Re: [martini] REMINDER: Ongoing MARTINI WG last Call on=20 > > "Registration for Multiple Phone Numbers in the SIP" > > > > > > > > Looking to the minutes of the MARTINI Interim V virtual meeting, it=20 > > seems that the discussion about=20 > "draft-vanelburg-martini-friends-00"=20 > > was inconclusive as to whether a change was required to the "gin"=20 > > draft. I don't think the WGLC can be completed before we have=20 > > clarified the interactions between "gin" and "friends". > > > > Bruno > > > > > > > > ________________________________ > > > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Bernard=20 > Aboba Envoy=E9 :=20 > > jeudi 15 juillet 2010 19:57 =C0 : martini@ietf.org Objet : [martini] = > > REMINDER: Ongoing MARTINI WG last Call on "Registration for=20 > Multiple=20 > > Phone Numbers in the SIP" > > > > This is a reminder of an ongoing MARTINI WG last call on=20 > "Registration=20 > > for Multiple Phone Numbers in the SIP" prior to requesting that the=20 > > IESG publish the document as a Proposed Standard. > > > > The document is available for inspection here: > > > > http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt > > > > MARTINI WG last call will conclude on Thursday, July 22, 2010. > > > > Please respond to this WG last call, whether you have=20 > comments or not. > > > > If you have no comments, please reply to this message and=20 > indicate in=20 > > the body of your message whether you > > > > think the document is ready for consideration by the IESG or not. > > > > If you have comments, please provide them to the WG in one of the=20 > > following ways: > > > > 1. If you have an account on the IETF Tools server, or can=20 > open one,=20 > > please login and enter your issue(s) in the > > > > MARTINI Issue tracking database (TRAC), which is available here: > > > > http://trac.tools.ietf.org/wg/martini/trac/newticket > > > > Note that if you submit an issue in TRAC, it will=20 > automatically also=20 > > be posted to the MARTINI WG mailing list. > > > > 2. If you don't have an account on the IETF Tools server,=20 > please post=20 > > your > > > > Issue to the MARTINI WG mailing list (martini at > > ietf.org) in the following format: > > > > To: martini at ietf.org > > > > Subject: Requirements-Issue: <title of your issue> > > > > Priority: blocker, critical, major, minor or trivial > > > > <Explanation of your issue, including a proposal for specific text=20 > > changes to resolve the issue> > > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini=20 >=20 >=20 From adam@nostrum.com Tue Jul 20 08:38:53 2010 Return-Path: <adam@nostrum.com> 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 5D7D33A6B1F for <martini@core3.amsl.com>; Tue, 20 Jul 2010 08:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 avP2XWMvoBT3 for <martini@core3.amsl.com>; Tue, 20 Jul 2010 08:38:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3A2913A68B5 for <martini@ietf.org>; Tue, 20 Jul 2010 08:38:52 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6KFd2c5009083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 10:39:02 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C45C316.1090702@nostrum.com> Date: Tue, 20 Jul 2010 10:39:02 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us> <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> <B011440129B84B30978779D2BCA75D18@china.huawei.com> <9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 15:38:53 -0000 On 7/20/10 10:24, Jul 20, bruno.chatras@orange-ftgroup.com wrote: > I think the applicability of the 'friends' solution is wider than just 3GPP IMS networks. This solution is required when non-E.164 numbers or email-style URI have to be supported... You are following the OLIVE work, I assume? /a From bruno.chatras@orange-ftgroup.com Tue Jul 20 09:02:47 2010 Return-Path: <bruno.chatras@orange-ftgroup.com> 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 B67663A68FA for <martini@core3.amsl.com>; Tue, 20 Jul 2010 09:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 v6E0WyPTd4iA for <martini@core3.amsl.com>; Tue, 20 Jul 2010 09:02:46 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id D7EFC3A6909 for <martini@ietf.org>; Tue, 20 Jul 2010 09:02:45 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DC2D08B8014; Tue, 20 Jul 2010 18:01:14 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id A04D78B801A; Tue, 20 Jul 2010 17:59:45 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 17:58:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 17:58:44 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214101B1EC01@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4C45C316.1090702@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsoIcTgTg+jMHVnTxyi6qCUI4QITgAAfBaw References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us> <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> <B011440129B84B30978779D2BCA75D18@china.huawei.com> <9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr> <4C45C316.1090702@nostrum.com> From: <bruno.chatras@orange-ftgroup.com> To: <adam@nostrum.com> X-OriginalArrivalTime: 20 Jul 2010 15:58:46.0541 (UTC) FILETIME=[6F898BD0:01CB2824] Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 16:02:48 -0000 Yes of course and all other things that one can mix with a Martini as = well. However I don't understand how Olive can support the case where = bob@sales.entreprise.com and bob@helpdesk.entreprise.com are two = different persons, both of them being connected to the same PBX (or at = least to what is seen by the SSP as a single PBX) and this PBX has a = single contact address registered with the SSP. > -----Message d'origine----- > De : Adam Roach [mailto:adam@nostrum.com]=20 > Envoy=E9 : mardi 20 juillet 2010 17:39 > =C0 : CHATRAS Bruno RD-CORE-ISS > Cc : spencer@wonderhamster.org;=20 > john.elwell@siemens-enterprise.com; richard@shockey.us;=20 > bernard_aboba@hotmail.com; martini@ietf.org > Objet : Re: [martini] REMINDER: Ongoing MARTINI WG lastCall=20 > on "Registration for Multiple Phone Numbers in the SIP" >=20 >=20 > On 7/20/10 10:24, Jul 20, bruno.chatras@orange-ftgroup.com wrote: > > I think the applicability of the 'friends' solution is=20 > wider than just 3GPP IMS networks. This solution is required=20 > when non-E.164 numbers or email-style URI have to be supported... >=20 > You are following the OLIVE work, I assume? >=20 > /a >=20 From spencer@wonderhamster.org Tue Jul 20 09:14:49 2010 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 A5C023A6878 for <martini@core3.amsl.com>; Tue, 20 Jul 2010 09:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 q7uTD0PcEOzX for <martini@core3.amsl.com>; Tue, 20 Jul 2010 09:14:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id C14613A6B0B for <martini@ietf.org>; Tue, 20 Jul 2010 09:14:44 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LtqXN-1P06TE3nsb-0111dp; Tue, 20 Jul 2010 12:14:59 -0400 Message-ID: <C035C8BB231F4F9CB77B6FC02B5688CF@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: <bruno.chatras@orange-ftgroup.com>, <adam@nostrum.com> References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us> <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> <B011440129B84B30978779D2BCA75D18@china.huawei.com> <9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr> <4C45C316.1090702@nostrum.com> <9ECCF01B52E7AB408A7EB8535264214101B1EC01@ftrdmel0.rd.francetelecom.fr> Date: Tue, 20 Jul 2010 11:14:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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.5931 X-Provags-ID: V02:K0:urgi+woW3pHuhtZB9aMSrWzj18fURIn+YArfCWeLvNx +QXGHuAf3BGL/MtR638eB7wmEgfAdhq+hK1DR/yIo9sKe2Npx8 4vGtqMnm6s4P42DNbsePIohB7eF15QKlEX1Hf5WLPYxMDXcwH3 A7SPzBOFiv/oitTawV75iTCcJAJGT3FguD+z9Z3/vCuSNlppCu ehpIFe/0qN3qDIgwJ0asbkO0uJN7iYw3acpkDT+WMg= Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 16:14:49 -0000 Bruno, Speaking as co-chair ... The issue isn't about the value of the work, it's about where it is done. My understanding, which my co-chair shares, is that what's required to be done in the IETF, is approval for an IANA registration, and that's all. I thought that was the point of the request to add an additional allocation to the IANA section of the GIN draft, discussed at Interim V, and that's what I told our ADs. Are we now talking about doing additional specification work IN THE IETF, so that some IETF working group would have change control over it? If so, you guys really need to be talking to the ADs (and probably to the DISPATCH co-chairs as well). Thanks, Spencer ----- Original Message ----- From: <bruno.chatras@orange-ftgroup.com> To: <adam@nostrum.com> Cc: <spencer@wonderhamster.org>; <john.elwell@siemens-enterprise.com>; <richard@shockey.us>; <bernard_aboba@hotmail.com>; <martini@ietf.org> Sent: Tuesday, July 20, 2010 10:58 AM Subject: RE: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" Yes of course and all other things that one can mix with a Martini as well. However I don't understand how Olive can support the case where bob@sales.entreprise.com and bob@helpdesk.entreprise.com are two different persons, both of them being connected to the same PBX (or at least to what is seen by the SSP as a single PBX) and this PBX has a single contact address registered with the SSP. > -----Message d'origine----- > De : Adam Roach [mailto:adam@nostrum.com] > Envoyé : mardi 20 juillet 2010 17:39 > À : CHATRAS Bruno RD-CORE-ISS > Cc : spencer@wonderhamster.org; > john.elwell@siemens-enterprise.com; richard@shockey.us; > bernard_aboba@hotmail.com; martini@ietf.org > Objet : Re: [martini] REMINDER: Ongoing MARTINI WG lastCall > on "Registration for Multiple Phone Numbers in the SIP" > > > On 7/20/10 10:24, Jul 20, bruno.chatras@orange-ftgroup.com wrote: > > I think the applicability of the 'friends' solution is > wider than just 3GPP IMS networks. This solution is required > when non-E.164 numbers or email-style URI have to be supported... > > You are following the OLIVE work, I assume? > > /a > From trac@tools.ietf.org Tue Jul 20 11:45:17 2010 Return-Path: <trac@tools.ietf.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 C8C2E3A67E7 for <martini@core3.amsl.com>; Tue, 20 Jul 2010 11:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-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 2eP5XMq0LwSn for <martini@core3.amsl.com>; Tue, 20 Jul 2010 11:45:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D7EB43A67DB for <martini@ietf.org>; Tue, 20 Jul 2010 11:45:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1ObHoo-0002PT-M4; Tue, 20 Jul 2010 11:45:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, alan.b.johnston@gmail.com X-Trac-Project: martini Date: Tue, 20 Jul 2010 18:45:30 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/58 Message-ID: <067.ce0d2e0c8b0d30f079641219871d3516@tools.ietf.org> X-Trac-Ticket-ID: 58 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, alan.b.johnston@gmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #58: WGLC comments X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jul 2010 18:45:17 -0000 #58: WGLC comments ---------------------------------------+------------------------------------ Reporter: alan.b.johnston@… | Owner: adam@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ I have reviewed the document and believe it is ready to progress with no technical issues. A few minor issues are noted below that could be addressed to improve the document, but aren't worth entering into the tracker. - Alan - Section 5.1: The first time the bnc parameter is introduced, it might be worth explaining it stands for Bulk Number Contact - the first time I read it I thought it stood for Bayonet Neill-Concelman... Section 5.1: There are a couple of "must"s that probably are "MUST"s. Section 5.2: There is some justification why the SIP-PBX MUST support Path, but none is given here why the Registrar MUST support it. Is it for the same reason? Section 5.2: While the SIP-PBX MUST include Proxy-Require:gin, it is possible a registration might arrive at a Registrar with a bnc but no Proxy-Require:gin. Should we define the correct behavior of the Registrar for this case? -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/58> martini <http://tools.ietf.org/martini/> From HKaplan@acmepacket.com Tue Jul 20 11:49:51 2010 Return-Path: <HKaplan@acmepacket.com> 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 763BF3A68E8 for <martini@core3.amsl.com>; Tue, 20 Jul 2010 11:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599] 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 8WPalPTzizyp for <martini@core3.amsl.com>; Tue, 20 Jul 2010 11:49:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A8AE13A67DB for <martini@ietf.org>; Tue, 20 Jul 2010 11:49:49 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Jul 2010 14:50:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Jul 2010 14:50:03 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: Adam Roach <adam@nostrum.com> Date: Tue, 20 Jul 2010 14:49:53 -0400 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsnmTMPvPkhKgOvROKEqLaNQP6zeAAoxBRg Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F3A53@mail> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <430FC6BDED356B4C8498F634416644A921187F7251@mail> <4C44DE51.2030305@nostrum.com> In-Reply-To: <4C44DE51.2030305@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 18:49:51 -0000 Hi Adam, Yes the changed text sounds good - thanks! -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Monday, July 19, 2010 7:23 PM > To: Hadriel Kaplan > Cc: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Announcement of MARTINI WG last Call on > "Registration for Multiple Phone Numbers in the SIP" >=20 > On 7/16/10 10:37 AM, Hadriel Kaplan wrote: > > 5) Section 7.2.1 says: > > In particular, the "bnc" parameter is forbidden from appearing in > the > > body of a reg-event notify. > > > > Something about that statement rings warning bells in my head. I don't > know what that something is, but it seems wrong to me. :) Are we > absolutely sure this is a normative statement we want, forever? >=20 > The logic here is that subscribers to the event package won't > necessarily know about the GIN extension. If you send them a "bnc" URI, > they're going to have no clue that it's not just a normal URI. >=20 > Now, I don't think this prohibition is a "forever" thing. There's > certainly nothing that says that another extension (say, VERMOUTH) is > prohibited from overriding this prohibition with another behavior -- so > long as the subscriber indicates that it would know what to do with a > "bnc" URI. >=20 > Would the following change address your concern? >=20 >=20 > In particular, the "bnc" parameter is forbidden from appearing in the > body of a reg-event notify unless the subscriber has indicated > knowledge of the semantics of the "bnc" parameter. The means > for indicating this support are out of scope of this document. >=20 >=20 > /a From HKaplan@acmepacket.com Tue Jul 20 11:55:30 2010 Return-Path: <HKaplan@acmepacket.com> 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 677453A6803 for <martini@core3.amsl.com>; Tue, 20 Jul 2010 11:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] 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 YEkZI2rcsHxX for <martini@core3.amsl.com>; Tue, 20 Jul 2010 11:55:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5A1933A67DB for <martini@ietf.org>; Tue, 20 Jul 2010 11:55:29 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Jul 2010 14:55:44 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Jul 2010 14:55:43 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "bruno.chatras@orange-ftgroup.com" <bruno.chatras@orange-ftgroup.com>, "adam@nostrum.com" <adam@nostrum.com> Date: Tue, 20 Jul 2010 14:55:34 -0400 Thread-Topic: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsoIcTgTg+jMHVnTxyi6qCUI4QITgAAfBawAAYwBTA= Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F3A57@mail> References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us> <A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net> <B011440129B84B30978779D2BCA75D18@china.huawei.com> <9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr> <4C45C316.1090702@nostrum.com> <9ECCF01B52E7AB408A7EB8535264214101B1EC01@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214101B1EC01@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bernard_aboba@hotmail.com" <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 18:55:30 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of bruno.chatras@orange-ftgroup.com > Sent: Tuesday, July 20, 2010 11:59 AM >=20 > Yes of course and all other things that one can mix with a Martini as wel= l. > However I don't understand how Olive can support the case where > bob@sales.entreprise.com and bob@helpdesk.entreprise.com are two differen= t > persons, both of them being connected to the same PBX (or at least to wha= t > is seen by the SSP as a single PBX) and this PBX has a single contact > address registered with the SSP. If the PBX only registered a single contact, then the SSP wouldn't be able = to indicate two different target AoR domains - but that's actually a GOOD t= hing, I think. Either the PBX knows about the two AoR domains, in which ca= se it should have registered for them separately; or else it doesn't, in wh= ich case we shouldn't be sending two different domains to it. That was one= of the main points of GIN, imo: don't send something to the PBX it doesn't= expect to receive. -hadriel=20 From john.elwell@siemens-enterprise.com Tue Jul 20 15:11:46 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 9B22E3A680F for <martini@core3.amsl.com>; Tue, 20 Jul 2010 15:11:46 -0700 (PDT) X-Quarantine-ID: <quzsB0lZRkej> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=4.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 quzsB0lZRkej for <martini@core3.amsl.com>; Tue, 20 Jul 2010 15:11:44 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279663906-5906-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C0CBF3A67D9 for <martini@ietf.org>; Tue, 20 Jul 2010 15:11:44 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 22:12:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KMBQI9000466; Tue, 20 Jul 2010 22:12:00 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:28:02 -0700 Received: from xbh-bgl-411.cisco.com ([72.163.129.201]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 05:04:01 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:10:55 +0530 Received: from xbh-hkg-411.apac.cisco.com ([64.104.123.72]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 06:21:19 -0500 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 14:31:28 +0800 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 01:28:09 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 06:27:59 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6RuJZ008836; Tue, 20 Jul 2010 06:27:58 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-e.cisco.com with ESMTP; 20 Jul 2010 06:27:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227863A6BD9; Mon, 19 Jul 2010 23:27:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D483A6BD9 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 23:27:41 -0700 (PDT) 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 ek43u17JG+Yy for <martini@core3.amsl.com>; Mon, 19 Jul 2010 23:27:41 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AADFA3A6BB4 for <martini@ietf.org>; Mon, 19 Jul 2010 23:27:40 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-904084; Tue, 20 Jul 2010 08:27:54 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4B02523F0278; Tue, 20 Jul 2010 08:27:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Jul 2010 08:27:54 +0200 Date: Tue, 20 Jul 2010 01:27:52 -0500 Message-ID: <A444A0F8084434499206E78C106220CAECBA4BBF@MCHP058A.global-ad.net> In-Reply-To: <4C44B492.7060000@nostrum.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl><A444A0F8084434499206E78C106220CAECA8AAE4@MCHP058A.global-ad.net><4C44B492.7060000@nostrum.com> From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "Adam Roach" <adam@nostrum.com> Cc: Bernard Aboba <bernard_aboba@hotmail.com>, martini@ietf.org Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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, 20 Jul 2010 22:11:46 -0000 This is a multi-part message in MIME format... ------------=_1279663906-5906-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279663906-5906-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C0CBF3A67D9 for <martini@ietf.org>; Tue, 20 Jul 2010 15:11:44 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 3167 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANO7RUyrR7Ht/2dsb2JhbACfdnGmUpsMhTIEhACHDgw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 22:12:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KMBQI9000466; Tue, 20 Jul 2010 22:12:00 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:28:02 -0700 Received: from xbh-bgl-411.cisco.com ([72.163.129.201]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 05:04:01 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:10:55 +0530 Received: from xbh-hkg-411.apac.cisco.com ([64.104.123.72]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 06:21:19 -0500 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 14:31:28 +0800 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 01:28:09 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27D4.B85F6280" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 06:27:59 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6RuJZ008836; Tue, 20 Jul 2010 06:27:58 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-e.cisco.com with ESMTP; 20 Jul 2010 06:27:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227863A6BD9; Mon, 19 Jul 2010 23:27:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D483A6BD9 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 23:27:41 -0700 (PDT) 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 ek43u17JG+Yy for <martini@core3.amsl.com>; Mon, 19 Jul 2010 23:27:41 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AADFA3A6BB4 for <martini@ietf.org>; Mon, 19 Jul 2010 23:27:40 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-904084; Tue, 20 Jul 2010 08:27:54 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4B02523F0278; Tue, 20 Jul 2010 08:27:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Jul 2010 08:27:54 +0200 Content-class: urn:content-classes:message Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Date: Tue, 20 Jul 2010 01:27:52 -0500 Message-ID: <A444A0F8084434499206E78C106220CAECBA4BBF@MCHP058A.global-ad.net> In-Reply-To: <4C44B492.7060000@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: <A444A0F8084434499206E78C106220CAECBA4BBF@MCHP058A.global-ad.net> Thread-Topic: [martini] Announcement of MARTINI WG last Call on"Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsngFDsac2Jv5glSeOzY4ZRF8R4ygAVCIMQ References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl><A444A0F8084434499206E78C106220CAECA8AAE4@MCHP058A.global-ad.net><4C44B492.7060000@nostrum.com> 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> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>,<mailto:martini-request@ietf.org?subject=unsubscribe> From: "Elwell, John" <john.elwell@siemens-enterprise.com> Sender: <martini-bounces@ietf.org> To: "Adam Roach" <adam@nostrum.com> Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>, <martini@ietf.org> X-OriginalArrivalTime: 20 Jul 2010 06:31:28.0654 (UTC) FILETIME=[2F602AE0:01CB27D5] This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27D4.B85F6280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 >=20 > > 4. "The SSP registrar then maps I_i to the "bnc" AOR template and > > instance ID using the database, a persistent=20 > hash-map or similar > > technology." > > This is the first use of the expression "AOR template and=20 > instance ID". We could do with some clarification, but I=20 > don't have a proposal. We have something that could be=20 > described as a template, but I would have considered that to=20 > be a contact template rather than an AOR template. > > >=20 > I propose "...maps I_i to the contact and instance ID using the=20 > database...." [JRE] OK. Don't forget there are two more instances of "AOR template" = that need fixing. >=20 > > 5. "(1) The SIP-PBX registers with the SSP for a range of AORs. > > It includes the URI it expects to receive in the Request-URI > > in its "Contact" header field, and includes information that > > routes to the SIP-PBX in the "Path" header field." > > I think "the URI" should be changed to "the domain". Only=20 > the domain part of the REGISTER request's Contact header=20 > field will appear in the Request-URI of the inbound request. >=20 > But it's not really just the domain -- it can have=20 > parameters. Perhaps=20 > 'It indicates the form of the URI it expects to receive in the=20 > Request-URI in its "Contact" header field....' [JRE] That would be better. John >=20 > /a >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------_=_NextPart_001_01CB27D4.B85F6280 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhwGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAawAAAFJlOiBbbWFydGluaV0gQW5u b3VuY2VtZW50IG9mIE1BUlRJTkkgV0cgbGFzdCBDYWxsIG9uICJSZWdpc3RyYXRpb24gZm9yIE11 bHRpcGxlIFBob25lIE51bWJlcnMgaW4gdGhlIFNJUCIAyCQBBYADAA4AAADaBwcAFAABABsANAAC AE4BASCAAwAOAAAA2gcHABQAAQAcAAkAAgAkAQEJgAEAIQAAAEVGMjlBQURGNDI5N0E5NDFCMzUz MjIyREI4RUEzMEQxAEYHAQOQBgAoCwAAKAAAAAMANgAAAAAAQAA5AABkPa7UJ8sBHgA9AAEAAAAF AAAAUmU6IAAAAAAeAHAAAQAAAGYAAABbbWFydGluaV0gQW5ub3VuY2VtZW50IG9mIE1BUlRJTkkg V0cgbGFzdCBDYWxsIG9uIlJlZ2lzdHJhdGlvbiBmb3IgTXVsdGlwbGUgUGhvbmUgTnVtYmVycyBp biB0aGUgU0lQIgAAAAIBcQABAAAAGwAAAAHLJ4BQ7GnNib+YJUnjs2OGURfEeMoAFQiDEAAeABoM AQAAABkAAABtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcAAAAAHgAdDgEAAABnAAAAW21hcnRpbmld IEFubm91bmNlbWVudCBvZiBNQVJUSU5JIFdHIGxhc3QgQ2FsbCBvbiAiUmVnaXN0cmF0aW9uIGZv ciBNdWx0aXBsZSBQaG9uZSBOdW1iZXJzIGluIHRoZSBTSVAiAAACAQkQAQAAACwEAAAoBAAAqgcA AExaRnWjdoXSAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshEl DlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFCzCwkBZDM2 FlALpiAK4zsKhAqAPhz1HcAdwDQuICAiVGhlBgBTUEogGCBnBAB0cgrBdBce0AOgAMBwBCBJX2kN H9BvH9IeoGJuYyLJEMBPUh/QZW0LUQ6w/iAAcAsxHgYjJQuAH4AAcEJjHuBJRCB1AJBuWmcg42Qi IAGgYRQQLPkiUCBwBJAAkB+ACfAFQaMddRPgc2gtIDEgBbF9AJBtAxAKwCKfDrAT0G7hF6FneS4i HegewAQA5yOQBCAg8mZpFAAFQCRg2R7gb2Yg4w7AcBggBBC+aQIgHqAhnh3XI6kiHpCmVx7gBaB1 bC4QZCDQ/wPwH+AnoANwL6En8QaQDeCnIiAs0SWAYnUFQEkd19kwIG4nBUAT4HYiQSWw8QNgcG9z B0AvczMjMKLvH+AkhCIgL7ViHuAyRweQfwUBNgAuECVQJZEh1jHGd/8v0zMjBaAAgQSBNyE1UyDB 3x1mNgEloDlRAZBjOjEh5r8foB/hH8IDkQORIZouHefvHW4yIDOUIREuQGAgPjtWfy3yI68g4zJH JRVAYSnWW4BKUkVdIE9LHpDmRDLTAhByZxQgH9IYIPsiUEcBdDigICAFsB7gQlbfBCAr8S0bIXA1 U24J4C4QnStQeCSBPhUdbyA1HpEYKDEpKoEe4UlQLfhQQlgfNSXRMEQg8h8Cv0ZhJZEfoCSQK9Mh kXM+GN8jJiBwBUALgDDwdTaxIOO8VVIyIDBgLFIFkHQq8Xcg0BggJABpM0ELgCDjUuxlcQpQH4At UmFQT1PyezBgBCAiCFA7cyFwHtBh+wSBK0FlL/AlgUIjUbULgP9GYQDAMYI1Q1UvHzAIYA6wz1Mz ToNNJVQFIlA8cVc89ynaMiA08mseoFIlIXAnEP81thPRT4E54SDQX2MwIADAwwuAL2FPbmx5Hddh aB8lsArABUAr9UWAR0lT3FRFIbAYIFSTJwQgVsXvV0ZLNlfDMEFsAyAgQCXAvwrBVA8yICv1C4AG 4HUuAfdlBT4XSzZCMfEwYGVxKXDvBUAYIAdAYlFqJGBGs2M2/C0tUpIxYAOgMyNLNgqx7mE00SXR HpBQBJAT4CBR9Us2J1FjZDFSUfVZIivmf1JvU35LNmiqVk9da0BhJ/9FCh7ANXE4pDYBNgACQASQ OUrLSm8pYErfHZMvYf1LPF9+D38ff+p7pADAACD3C4AgoGHBbCSCggAfgID7tkAIkAAwLkZxe6Ro AkChIFA6Ly93hNAug3b2L4HSA4EvglJZAoWRgXMFe6R9h5AeADUQAQAAAEIAAAA8QTQ0NEEwRjgw ODQ0MzQ0OTkyMDZFNzhDMTA2MjIwQ0FFQ0JBNEJCRkBNQ0hQMDU4QS5nbG9iYWwtYWQubmV0PgAA AB4AORABAAAAjQAAADxCTFUxMzctVzEwNTUwQkEyMzIzNzdCRTc5MTNGRkU5M0IzMEBwaHguZ2Js PjxBNDQ0QTBGODA4NDQzNDQ5OTIwNkU3OEMxMDYyMjBDQUVDQThBQUU0QE1DSFAwNThBLmdsb2Jh bC1hZC5uZXQ+PDRDNDRCNDkyLjcwNjAwMDBAbm9zdHJ1bS5jb20+AAAAAB4AQhABAAAAHwAAADw0 QzQ0QjQ5Mi43MDYwMDAwQG5vc3RydW0uY29tPgAAHgBDEAEAAAAvAAAAPG1haWx0bzptYXJ0aW5p LXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1oZWxwPgAAHgBEEAEAAABkAAAAPGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFydGluaT4sPG1haWx0bzptYXJ0aW5pLXJlcXVl c3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+AB4ARRABAAAAZgAAADxodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmk+LDxtYWlsdG86bWFydGluaS1yZXF1ZXN0 QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmU+AAAACwDyEAAAQAAfAPMQAQAAAOoAAABSAGUA JQAzAEEAIABbAG0AYQByAHQAaQBuAGkAXQAgAEEAbgBuAG8AdQBuAGMAZQBtAGUAbgB0ACAAbwBm ACAATQBBAFIAVABJAE4ASQAgAFcARwAgAGwAYQBzAHQAIABDAGEAbABsACAAbwBuACAAJQAyADIA UgBlAGcAaQBzAHQAcgBhAHQAaQBvAG4AIABmAG8AcgAgAE0AdQBsAHQAaQBwAGwAZQAgAFAAaABv AG4AZQAgAE4AdQBtAGIAZQByAHMAIABpAG4AIAB0AGgAZQAgAFMASQBQACUAMgAyAC4ARQBNAEwA AAAAAEAABzClknO41CfLAUAACDDCuXq41CfLAQMA3j+vbwAAAwDfP/////8DAPE/AAAAAB4A+D8B AAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+T8BAAAAHgAAAAAAAADcp0DIwEIQGrS5 CAArL+GCAQAAAAAAAAAuAAAAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7 PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAEA AwAaQAAAAQAeADBAAQAAABkAAABtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcAAAAAHgAxQAEAAAAj AAAAam9obi5lbHdlbGxAc2llbWVucy1lbnRlcnByaXNlLmNvbQAAHgA4QAEAAAACAAAALgAAAB4A OUABAAAAAgAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGEOxd6qgDAAcQFwQAAAMAEBADAAAAAwAR EAAAAAAeAAgQAQAAAGUAAAA0IlRIRVNTUFJFR0lTVFJBUlRIRU5NQVBTSUlUT1RIRSJCTkMiQU9S VEVNUExBVEVBTkRJTlNUQU5DRUlEVVNJTkdUSEVEQVRBQkFTRSxBUEVSU0lTVEVOVEhBU0gtTUFQ T1JTAAAAAAIBfwABAAAAQgAAADxBNDQ0QTBGODA4NDQzNDQ5OTIwNkU3OEMxMDYyMjBDQUVDQkE0 QkJGQE1DSFAwNThBLmdsb2JhbC1hZC5uZXQ+AAAAjx4= ------_=_NextPart_001_01CB27D4.B85F6280-- ------------=_1279663906-5906-1-- From bruno.chatras@orange-ftgroup.com Wed Jul 21 00:35:51 2010 Return-Path: <bruno.chatras@orange-ftgroup.com> 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 9D7853A68B3 for <martini@core3.amsl.com>; Wed, 21 Jul 2010 00:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 mxoNfR7tNLze for <martini@core3.amsl.com>; Wed, 21 Jul 2010 00:35:50 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 768DD3A681F for <martini@ietf.org>; Wed, 21 Jul 2010 00:35:50 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 57AE16C000A; Wed, 21 Jul 2010 09:36:16 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4BEB16C0008; Wed, 21 Jul 2010 09:36:16 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jul 2010 09:35:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 09:35:50 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214101B1ECEF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F3A57@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] REMINDER: Ongoing MARTINI WG lastCall on"Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsoIcTgTg+jMHVnTxyi6qCUI4QITgAAfBawAAYwBTAAGpPdsA== References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us><A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net><B011440129B84B30978779D2BCA75D18@china.huawei.com><9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr><4C45C316.1090702@nostrum.com> <9ECCF01B52E7AB408A7EB8535264214101B1EC01@ftrdmel0.rd.francetelecom.fr> <430FC6BDED356B4C8498F634416644A9258D7F3A57@mail> From: <bruno.chatras@orange-ftgroup.com> To: <HKaplan@acmepacket.com>, <adam@nostrum.com> X-OriginalArrivalTime: 21 Jul 2010 07:35:52.0123 (UTC) FILETIME=[589880B0:01CB28A7] Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on"Registration for Multiple Phone Numbers in the SIP" 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: Wed, 21 Jul 2010 07:35:51 -0000 =20 > -----Message d'origine----- > De : Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Envoy=E9 : mardi 20 juillet 2010 20:56 > =C0 : CHATRAS Bruno RD-CORE-ISS; adam@nostrum.com > Cc : bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] REMINDER: Ongoing MARTINI WG lastCall=20 > on"Registration for Multiple Phone Numbers in the SIP" >=20 >=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of bruno.chatras@orange-ftgroup.com > > Sent: Tuesday, July 20, 2010 11:59 AM > >=20 > > Yes of course and all other things that one can mix with a=20 > Martini as well. > > However I don't understand how Olive can support the case where=20 > > bob@sales.entreprise.com and bob@helpdesk.entreprise.com are two=20 > > different persons, both of them being connected to the same=20 > PBX (or at=20 > > least to what is seen by the SSP as a single PBX) and this=20 > PBX has a=20 > > single contact address registered with the SSP. >=20 > If the PBX only registered a single contact, then the SSP=20 > wouldn't be able to indicate two different target AoR domains=20 > - but that's actually a GOOD thing, I think. Either the PBX=20 > knows about the two AoR domains, in which case it should have=20 > registered for them separately;=20 =3D=3D>BC: Of course it can register them separately (especially if = there are only two sub-domains) but why should we mandate this behavior = while there are other more flexible solutions that do not have this = constraint?=20 or else it doesn't, in which=20 > case we shouldn't be sending two different domains to it. =20 > That was one of the main points of GIN, imo: don't send=20 > something to the PBX it doesn't expect to receive. >=20 > -hadriel=20 >=20 From fluffy@cisco.com Wed Jul 21 13:43:56 2010 Return-Path: <fluffy@cisco.com> 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 5DFCC3A6893 for <martini@core3.amsl.com>; Wed, 21 Jul 2010 13:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.309 X-Spam-Level: X-Spam-Status: No, score=-110.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 zzyX2rwKf347 for <martini@core3.amsl.com>; Wed, 21 Jul 2010 13:43:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A9A5E3A67B1 for <martini@ietf.org>; Wed, 21 Jul 2010 13:43:55 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAHAO/4RkyrRN+K/2dsb2JhbAAekxmMPnGnXpsjhTIEhACEWQ Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2010 20:44:12 +0000 Received: from sjc-vpn5-1581.cisco.com (sjc-vpn5-1581.cisco.com [10.21.94.45]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6LKiC6L006040 for <martini@ietf.org>; Wed, 21 Jul 2010 20:44:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <BLU137-DS5FA9F257FE3EDF14F860593CA0@phx.gbl> Date: Wed, 21 Jul 2010 13:44:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9924A9F3-A504-41C7-B056-10AD6F5E09EF@cisco.com> References: <BLU137-DS5FA9F257FE3EDF14F860593CA0@phx.gbl> To: martini@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [martini] IETF 78 MARTINI WG Agenda - Take Two 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: Wed, 21 Jul 2010 20:43:56 -0000 The GIN + OLIVE + VERMOUTH agenda is the best agenda I have ever seen - = I've put the printed copy on my wall to explain IETF to my coworkers.=20 From D.Hancock@CableLabs.com Wed Jul 21 16:50:53 2010 Return-Path: <D.Hancock@CableLabs.com> 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 A7B9A3A68A4 for <martini@core3.amsl.com>; Wed, 21 Jul 2010 16:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 NokJrNsipNkR for <martini@core3.amsl.com>; Wed, 21 Jul 2010 16:50:51 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 4B8853A6824 for <martini@ietf.org>; Wed, 21 Jul 2010 16:50:51 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o6LNp5kB022952; Wed, 21 Jul 2010 17:51:05 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 21 Jul 2010 17:51:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 21 Jul 2010 17:51:07 -0600 From: David Hancock <D.Hancock@CableLabs.com> To: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Date: Wed, 21 Jul 2010 17:51:04 -0600 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsdmTvs9jjiZbQhTMWrM4rctI3xzwLi6oVg Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> In-Reply-To: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Wed, 21 Jul 2010 23:50:53 -0000 I've reviewed the document and think it is ready for consideration, pending= resolution of the issues described below. These issues all have to do with subscribing to reg-event. -------------------------------------------------------------- Issue-1: Section 7.7.2 says... If the SSP receives a SUBSCRIBE request for the registration event package with a Request-URI that indicates a contact registered via the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that is would proxy an INVITE bound for that AOR, unless the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (e.g., through an active back-end subscription). How does the SSP handle the SUBSCRIBE to reg-event for an enterprise user w= hen the SIP-PBX isn't registered? My understanding of RFC3680 is that if th= e target user of a reg-event SUBSCRIBE isn't registered, then the reg-event= subscriber receives a NOTIFY indicating "user not registered". The subscri= be dialog remains active, and if/when the target user subsequently register= s, the reg-event subscriber receives another NOTIFY containing the registra= tion data. Would this same process be followed when the reg-event subscript= ion is to an AOR owned by the SIP-PBX, and if yes, how does the SSP make th= at happen? -------------------------------------------------------------- Issue-2: How does a SIP-PBX that doesn't have SIP endpoints respond to a SU= BSCRIBE to reg-event (say, SIP-PBX supports only analog or H.323 lines)? I = assume it should create fake registration data is if the target AOR were re= gistered to a SIP endpoint. Does that need to be stated? -------------------------------------------------------------- Issue-3: Section 5.2 says... A further implication of this property is that an individual extension that is implicitly registered may also be explicitly registered using a normal, non-bulk registration (subject to SSP policy). If such a registration exists, it is refreshed independently of the bulk registration, and is not removed when the bulk registration is removed. I assume this means that an enterprise user AOR can be bound to two (multip= le) contact addresses; one bulk-registered by the PBX, and a second explici= tly registered by a SIP endpoint directly hosted by the SSP network.=20 Section 6 of the draft goes on to say that SUBSCRIBE requests to reg-event = are handled just like INVITE requests, which means that if the target AOR h= as multiple contacts, the SUBSCRIBE request is forked. This seems like a pr= oblem, since RFC3680 disallows forking (RFC3680 section 4.9). -------------------------------------------------------------- I didn't see these particular issues discussed in the MARTINI archive. I ap= ologize if they have in fact been discussed & resolved. Thanks David=20 ________________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: Tuesday, July 06, 2010 11:57 PM To: martini@ietf.org Subject: [martini] Announcement of MARTINI WG last Call on "Registration fo= r Multiple Phone Numbers in the SIP" This is an announcement of MARTINI WG last call on "Registration for Multip= le Phone Numbers in the SIP" prior to requesting that the IESG publish the = document as a Proposed Standard.=20 The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt MARTINI WG last call will conclude on Thursday, July 22, 2010.=20 =A0 Please respond to this WG last call, whether you have comments or not.=20 =A0 If you have no comments, please reply to this message and indicate in the b= ody of your message whether you think the document is ready for consideration by the IESG or not.=20 =A0 If you have comments, please provide them to the WG in one of the following= ways:=20 =A0 1. If you have an account on the IETF Tools server, or can open one, please= login and enter your issue(s) in the=20 MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket =A0 Note that if you submit an issue in TRAC, it will automatically also be pos= ted to the MARTINI WG mailing list.=20 =A0 2. If you don't have an account on the IETF Tools server, please post your Issue to the MARTINI WG mailing list (martini at ietf.org) in the following= format:=20 =A0 To:=A0 martini at ietf.org Subject: Requirements-Issue: <title of your issue> Priority: blocker, critical, major, minor or trivial =A0 <Explanation of your issue, including a proposal for specific text changes = to resolve the issue> From trac@tools.ietf.org Wed Jul 21 21:59:18 2010 Return-Path: <trac@tools.ietf.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 82B743A6838 for <martini@core3.amsl.com>; Wed, 21 Jul 2010 21:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-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 gAnGxozySH2l for <martini@core3.amsl.com>; Wed, 21 Jul 2010 21:59:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 66A823A67AE for <martini@ietf.org>; Wed, 21 Jul 2010 21:59:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1ObnsY-0007kA-GO; Wed, 21 Jul 2010 21:59:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, D.Hancock@CableLabs.com X-Trac-Project: martini Date: Thu, 22 Jul 2010 04:59:30 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/59 Message-ID: <065.89830ac389df38a6864ddc9101774de2@tools.ietf.org> X-Trac-Ticket-ID: 59 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, D.Hancock@CableLabs.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #59: Reg-Event Issues X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 22 Jul 2010 04:59:18 -0000 #59: Reg-Event Issues -------------------------------------+-------------------------------------- Reporter: D.Hancock@… | Owner: adam@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+-------------------------------------- These issues all have to do with subscribing to reg-event. -------------------------------------------------------------- Issue-1: Section 7.7.2 says... If the SSP receives a SUBSCRIBE request for the registration event package with a Request-URI that indicates a contact registered via the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that is would proxy an INVITE bound for that AOR, unless the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (e.g., through an active back-end subscription). How does the SSP handle the SUBSCRIBE to reg-event for an enterprise user when the SIP-PBX isn't registered? My understanding of RFC3680 is that if the target user of a reg-event SUBSCRIBE isn't registered, then the reg- event subscriber receives a NOTIFY indicating "user not registered". The subscribe dialog remains active, and if/when the target user subsequently registers, the reg-event subscriber receives another NOTIFY containing the registration data. Would this same process be followed when the reg-event subscription is to an AOR owned by the SIP-PBX, and if yes, how does the SSP make that happen? -------------------------------------------------------------- Issue-2: How does a SIP-PBX that doesn't have SIP endpoints respond to a SUBSCRIBE to reg-event (say, SIP-PBX supports only analog or H.323 lines)? I assume it should create fake registration data is if the target AOR were registered to a SIP endpoint. Does that need to be stated? -------------------------------------------------------------- Issue-3: Section 5.2 says... A further implication of this property is that an individual extension that is implicitly registered may also be explicitly registered using a normal, non-bulk registration (subject to SSP policy). If such a registration exists, it is refreshed independently of the bulk registration, and is not removed when the bulk registration is removed. I assume this means that an enterprise user AOR can be bound to two (multiple) contact addresses; one bulk-registered by the PBX, and a second explicitly registered by a SIP endpoint directly hosted by the SSP network. Section 6 of the draft goes on to say that SUBSCRIBE requests to reg-event are handled just like INVITE requests, which means that if the target AOR has multiple contacts, the SUBSCRIBE request is forked. This seems like a problem, since RFC3680 disallows forking (RFC3680 section 4.9). -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/59> martini <http://tools.ietf.org/martini/> From bernard_aboba@hotmail.com Wed Jul 21 22:07:45 2010 Return-Path: <bernard_aboba@hotmail.com> 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 10C8C3A698F for <martini@core3.amsl.com>; Wed, 21 Jul 2010 22:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_20=-0.74, HTML_MESSAGE=0.001] 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 LHI4asBHDcgF for <martini@core3.amsl.com>; Wed, 21 Jul 2010 22:07:41 -0700 (PDT) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by core3.amsl.com (Postfix) with ESMTP id B75CD3A68BF for <martini@ietf.org>; Wed, 21 Jul 2010 22:07:40 -0700 (PDT) Received: from BLU137-W25 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 22:07:55 -0700 Message-ID: <BLU137-W2595CEE66FACE65E4A841293A20@phx.gbl> Content-Type: multipart/alternative; boundary="_9afe9d84-9353-41d9-a982-ebe091bac1e9_" X-Originating-IP: [64.134.138.79] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <martini@ietf.org> Date: Wed, 21 Jul 2010 22:07:55 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jul 2010 05:07:55.0992 (UTC) FILETIME=[D86C2580:01CB295B] Subject: [martini] Final Reminder: MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Thu, 22 Jul 2010 05:07:45 -0000 --_9afe9d84-9353-41d9-a982-ebe091bac1e9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a final reminder of MARTINI WG last call on "Registration=20 for=20 Multiple Phone Numbers in the SIP" prior to requesting that the IESG=20 publish the document as a Proposed Standard.=20 The document is=20 available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt MARTINI WG last call will conclude on Thursday=2C July 22=2C 2010 (tomorrow). =20 Please respond to this WG last call=2C whether you=20 have comments or not.=20 =20 If you have no comments=2C please reply to this=20 message and indicate in the body of your message whether you think the document is ready for consideration by=20 the IESG or not.=20 =20 If you have comments=2C please provide them to the WG in one of the following ways:=20 =20 1. If you have an account on the IETF Tools server=2C or can open one=2C please login and enter your issue(s) in the=20 MARTINI Issue tracking database (TRAC)=2C which is=20 available here: http://trac.tools.ietf.org/wg/martini/trac/newticket =20 If you submit an issue in TRAC=2C it will automatically also be posted to the MARTINI WG mailing list.=20 Note: This mechanism is preferred=2C since it guarantees that your issue = will be tracked correctly=2C as well as being posted to the WG mailing list= .=20 2. If you don't have an account on the IETF Tools=20 server=2C please post your Issue to the MARTINI WG mailing list (martini at=20 ietf.org). You can do this by=20 responding to this message and explaining your issue in the body of the mes= sage=2C=20 including a proposal for specific text changes to resolve the issue.=20 = --_9afe9d84-9353-41d9-a982-ebe091bac1e9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> This is a final reminder of MARTINI WG last call on "Registration=20 for=20 Multiple Phone Numbers in the SIP" prior to requesting that the IESG=20 publish the document as a Proposed Standard. <br><br>The document is=20 available for inspection here:<br>http://www.ietf.org/internet-drafts/draft= -ietf-martini-gin-05.txt<br><br>MARTINI WG last call will conclude on Thursday=2C July 22=2C 2010 (tomorrow).<o:p>= </o:p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">Please respond to this WG last call=2C whether you=20 have comments or not. <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">If you have no comments=2C please reply to this=20 message and indicate in the body of your message whether you<o:p></o:p></p> <p class=3D"MsoNormal">think the document is ready for consideration by=20 the IESG or not. <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">If you have comments=2C please provide them to the W= G in one of the following ways: <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">1. If you have an account on the IETF Tools server= =2C or can open one=2C please login and enter your issue(s) in the <o:p></o:p></p> <p class=3D"MsoNormal">MARTINI Issue tracking database (TRAC)=2C which is=20 available here:<o:p></o:p></p> <p class=3D"MsoNormal">http://trac.tools.ietf.org/wg/martini/trac/newticket= <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> =3B</o:p></p> <p class=3D"MsoNormal">If you submit an issue in TRAC=2C it will automatically also be posted to the MARTINI WG mailing list. <o:p></o:p></p= > <p class=3D"MsoNormal"><o:p> =3B</o:p></p><p class=3D"MsoNormal"><o:p>N= ote: =3B This mechanism is preferred=2C since it guarantees that your i= ssue will be tracked correctly=2C as well as being posted to the WG mailing= list. <br></o:p></p><p class=3D"MsoNormal"><o:p><br></o:p></p> <p class=3D"MsoNormal">2. If you don't have an account on the IETF Tools=20 server=2C please post your<o:p></o:p></p> <p class=3D"MsoNormal">Issue to the MARTINI WG mailing list (martini at=20 ietf.org). =3B You can do this by <br></p><p class=3D"MsoNormal">respon= ding to this message and explaining your issue in the body of the message= =2C <br></p><p class=3D"MsoNormal">including a proposal for specific text changes to resolve the issue. =3B</p><br> </bo= dy> </html>= --_9afe9d84-9353-41d9-a982-ebe091bac1e9_-- From john.elwell@siemens-enterprise.com Thu Jul 22 00:26:57 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 BD4683A67B4 for <martini@core3.amsl.com>; Thu, 22 Jul 2010 00:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599] 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 8bTddco8GLg8 for <martini@core3.amsl.com>; Thu, 22 Jul 2010 00:26:56 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 963133A63C9 for <martini@ietf.org>; Thu, 22 Jul 2010 00:26:56 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-932073; Thu, 22 Jul 2010 09:27:12 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id D457B1EB82AB; Thu, 22 Jul 2010 09:27:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 22 Jul 2010 09:27:12 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: David Hancock <D.Hancock@CableLabs.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Date: Thu, 22 Jul 2010 09:27:10 +0200 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsdmTvs9jjiZbQhTMWrM4rctI3xzwLi6oVgABKABLA= Message-ID: <A444A0F8084434499206E78C106220CAECCCC458@MCHP058A.global-ad.net> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Thu, 22 Jul 2010 07:26:57 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of David Hancock > Sent: 22 July 2010 00:51 > To: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Announcement of MARTINI WG last Call=20 > on "Registration for Multiple Phone Numbers in the SIP" >=20 > I've reviewed the document and think it is ready for=20 > consideration, pending resolution of the issues described below. >=20 > These issues all have to do with subscribing to reg-event. >=20 > -------------------------------------------------------------- > Issue-1: > Section 7.7.2 says... > If the SSP receives a SUBSCRIBE request for the registration event > package with a Request-URI that indicates a contact registered via > the "Bulk Number Contact" mechanism defined in this document, then > the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the=20 > same way that > is would proxy an INVITE bound for that AOR, unless the SSP has and > can maintain a copy of complete, accurate, and up-to-date=20 > information > from the SIP-PBX (e.g., through an active back-end subscription). >=20 > How does the SSP handle the SUBSCRIBE to reg-event for an=20 > enterprise user when the SIP-PBX isn't registered? My=20 > understanding of RFC3680 is that if the target user of a=20 > reg-event SUBSCRIBE isn't registered, then the reg-event=20 > subscriber receives a NOTIFY indicating "user not=20 > registered". The subscribe dialog remains active, and if/when=20 > the target user subsequently registers, the reg-event=20 > subscriber receives another NOTIFY containing the=20 > registration data. Would this same process be followed when=20 > the reg-event subscription is to an AOR owned by the SIP-PBX,=20 > and if yes, how does the SSP make that happen? [JRE] Wouldn't the SSP return a 480 response to the SUBSCRIBE request if it= can't deliver it? John From dwsauder@dsauder.com Thu Jul 22 06:33:02 2010 Return-Path: <dwsauder@dsauder.com> 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 26DBD3A67B8 for <martini@core3.amsl.com>; Thu, 22 Jul 2010 06:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 uVmsQWT9f-Ve for <martini@core3.amsl.com>; Thu, 22 Jul 2010 06:33:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 03F033A682F for <martini@ietf.org>; Thu, 22 Jul 2010 06:33:01 -0700 (PDT) Received: from [10.16.5.31] ([206.132.246.2]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MBW50-1OmQID1h6E-00A5Ht; Thu, 22 Jul 2010 09:33:16 -0400 Message-ID: <4C484895.5010007@dsauder.com> Date: Thu, 22 Jul 2010 08:33:09 -0500 From: Doug Sauder <dwsauder@dsauder.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Bernard Aboba <bernard_aboba@hotmail.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> In-Reply-To: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> Content-Type: multipart/alternative; boundary="------------020702040707090907090205" X-Provags-ID: V02:K0:oBe/RDEk1xI35WVp2LxQwEqqubEPy08l5W3uPnuVZIa iSpysz0dPasOqvw2cVvD6X7D9BciNcLYDEB4+PqwVwYdcicgF2 V7mJtSsCIvHwyoiO5q0j2dnUzZSU4tuoe0p1jjeTaZngMkv4Vn C7nLqimBpmLtMnusPNGRZGzzMxpiSXteMRXSrTxQiOIVLANV4J dpOqgB6i0hAIA4eENZwwwY9Z1uWWiQm+Adih4PccZ0= Cc: martini@ietf.org Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Thu, 22 Jul 2010 13:33:02 -0000 This is a multi-part message in MIME format. --------------020702040707090907090205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I read the document and I want to voice my opinion that the document should be submitted to the IESG. -- Doug Sauder Bernard Aboba wrote: > This is an announcement of MARTINI WG last call on "Registration for > Multiple Phone Numbers in the SIP" prior to requesting that the IESG > publish the document as a Proposed Standard. > > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt > > MARTINI WG last call will conclude on Thursday, July 22, 2010. > > > > Please respond to this WG last call, whether you have comments or not. > > > > If you have no comments, please reply to this message and indicate in > the body of your message whether you > > think the document is ready for consideration by the IESG or not. > > > > If you have comments, please provide them to the WG in one of the > following ways: > > > > 1. If you have an account on the IETF Tools server, or can open one, > please login and enter your issue(s) in the > > MARTINI Issue tracking database (TRAC), which is available here: > > http://trac.tools.ietf.org/wg/martini/trac/newticket > > > > Note that if you submit an issue in TRAC, it will automatically also > be posted to the MARTINI WG mailing list. > > > > 2. If you don't have an account on the IETF Tools server, please post your > > Issue to the MARTINI WG mailing list (martini at ietf.org) in the > following format: > > > > To: martini at ietf.org > > Subject: Requirements-Issue: <title of your issue> > > Priority: blocker, critical, major, minor or trivial > > > > <Explanation of your issue, including a proposal for specific text > changes to resolve the issue> > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --------------020702040707090907090205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I read the document and I want to voice my opinion that the document should be submitted to the IESG.<br> <br> --<br> Doug Sauder<br> <br> Bernard Aboba wrote: <blockquote cite="mid:BLU137-W10550BA232377BE7913FFE93B30@phx.gbl" type="cite"> <style><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Verdana } --></style>This is an announcement of MARTINI WG last call on "Registration for Multiple Phone Numbers in the SIP" prior to requesting that the IESG publish the document as a Proposed Standard. <br> <br> The document is available for inspection here:<br> <a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt">http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt</a><br> <br> MARTINI WG last call will conclude on Thursday, July 22, 2010. <o:p></o:p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Please respond to this WG last call, whether you have comments or not. <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">If you have no comments, please reply to this message and indicate in the body of your message whether you<o:p></o:p></p> <p class="MsoNormal">think the document is ready for consideration by the IESG or not. <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">If you have comments, please provide them to the WG in one of the following ways: <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">1. If you have an account on the IETF Tools server, or can open one, please login and enter your issue(s) in the <o:p></o:p></p> <p class="MsoNormal">MARTINI Issue tracking database (TRAC), which is available here:<o:p></o:p></p> <p class="MsoNormal"><a class="moz-txt-link-freetext" href="http://trac.tools.ietf.org/wg/martini/trac/newticket">http://trac.tools.ietf.org/wg/martini/trac/newticket</a><o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">2. If you don't have an account on the IETF Tools server, please post your<o:p></o:p></p> <p class="MsoNormal">Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format: <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">To:  martini at ietf.org<o:p></o:p></p> <p class="MsoNormal">Subject: Requirements-Issue: <title of your issue><o:p></o:p></p> <p class="MsoNormal">Priority: blocker, critical, major, minor or trivial<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <Explanation of your issue, including a proposal for specific text changes to resolve the issue><br> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ martini mailing list <a class="moz-txt-link-abbreviated" href="mailto:martini@ietf.org">martini@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/martini">https://www.ietf.org/mailman/listinfo/martini</a> </pre> </blockquote> </body> </html> --------------020702040707090907090205-- From D.Hancock@CableLabs.com Thu Jul 22 07:02:19 2010 Return-Path: <D.Hancock@CableLabs.com> 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 23FBF3A67B8 for <martini@core3.amsl.com>; Thu, 22 Jul 2010 07:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 9AOK2nTigPGV for <martini@core3.amsl.com>; Thu, 22 Jul 2010 07:02:18 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 2CF233A676A for <martini@ietf.org>; Thu, 22 Jul 2010 07:02:18 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o6ME2Yv7015364; Thu, 22 Jul 2010 08:02:34 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 22 Jul 2010 08:02:33 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 22 Jul 2010 08:02:34 -0600 From: David Hancock <D.Hancock@CableLabs.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Date: Thu, 22 Jul 2010 08:02:33 -0600 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsdmTvs9jjiZbQhTMWrM4rctI3xzwLi6oVgABKABLAADUQkPQ== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF4B0488F@srvxchg> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg>, <A444A0F8084434499206E78C106220CAECCCC458@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAECCCC458@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Thu, 22 Jul 2010 14:02:19 -0000 ________________________________________ From: Elwell, John [john.elwell@siemens-enterprise.com] Sent: Thursday, July 22, 2010 1:27 AM To: David Hancock; Bernard Aboba; martini@ietf.org Subject: RE: [martini] Announcement of MARTINI WG last Call on "Registratio= n for Multiple Phone Numbers in the SIP" > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of David Hancock > Sent: 22 July 2010 00:51 > To: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Announcement of MARTINI WG last Call > on "Registration for Multiple Phone Numbers in the SIP" > > I've reviewed the document and think it is ready for > consideration, pending resolution of the issues described below. > > These issues all have to do with subscribing to reg-event. > > -------------------------------------------------------------- > Issue-1: > Section 7.7.2 says... > If the SSP receives a SUBSCRIBE request for the registration event > package with a Request-URI that indicates a contact registered via > the "Bulk Number Contact" mechanism defined in this document, then > the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the > same way that > is would proxy an INVITE bound for that AOR, unless the SSP has and > can maintain a copy of complete, accurate, and up-to-date > information > from the SIP-PBX (e.g., through an active back-end subscription). > > How does the SSP handle the SUBSCRIBE to reg-event for an > enterprise user when the SIP-PBX isn't registered? My > understanding of RFC3680 is that if the target user of a > reg-event SUBSCRIBE isn't registered, then the reg-event > subscriber receives a NOTIFY indicating "user not > registered". The subscribe dialog remains active, and if/when > the target user subsequently registers, the reg-event > subscriber receives another NOTIFY containing the > registration data. Would this same process be followed when > the reg-event subscription is to an AOR owned by the SIP-PBX, > and if yes, how does the SSP make that happen? [JRE] Wouldn't the SSP return a 480 response to the SUBSCRIBE request if it= can't deliver it? [dch] Yes, that would be one way to handle it, although not so friendly to = the reg-event subscriber. Since for "normal" registrations the SSP registra= r/proxy doesn't send a 480 response when the target user isn't registered, = it might be useful if the draft covered this case.=20 If we take this approach where the SSP treats these SUBSCRIBEs like any req= uest to be delivered to the SIP-PBX, then what happens to reg-event subscri= ptions to the SIP-PBX when the PBX transitions from registered to not-regis= tered? Would they simply expire? Thanks David John From ernst.horvath@siemens-enterprise.com Thu Jul 22 08:35:14 2010 Return-Path: <ernst.horvath@siemens-enterprise.com> 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 4699F3A6826 for <martini@core3.amsl.com>; Thu, 22 Jul 2010 08:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 laziZeQbwkCQ for <martini@core3.amsl.com>; Thu, 22 Jul 2010 08:35:13 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1CAE83A6813 for <martini@ietf.org>; Thu, 22 Jul 2010 08:35:12 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-941099; Thu, 22 Jul 2010 17:35:29 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 84A111EB82AB; Thu, 22 Jul 2010 17:35:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 22 Jul 2010 17:35:29 +0200 From: "Horvath, Ernst" <ernst.horvath@siemens-enterprise.com> To: Adam Roach <adam@nostrum.com> Date: Thu, 22 Jul 2010 17:35:27 +0200 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsnmT5NBHgKmz4dTiq6YnIrDkX6VwCGCIuA Message-ID: <7889A6C3D41A49439DAECC7B4C998F0106E39CBFAB@MCHP058A.global-ad.net> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <430FC6BDED356B4C8498F634416644A921187F7251@mail> <4C44DE51.2030305@nostrum.com> In-Reply-To: <4C44DE51.2030305@nostrum.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Thu, 22 Jul 2010 15:35:14 -0000 Adam, I don't understand the public GRUU example in 7.1.1. The GRUU returned to a= UA by the SIP-PBX looks like this: <allOneLine> Contact: <sip:line-1@10.20.1.17>; pub-gruu=3D"sip:+12145550102@ssp.example.com;bnc;gr=3Durn: uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=3D00:05:03:5e:70:a6"; +sip.instance=3D"<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>" ;expires=3D3600 </allOneLine> And may result in e.g. an INVITE request arriving at the SSP with the follo= wing Request-URI: <allOneLine> INVITE sip:+12145550102@ssp.example.com;bnc;gr=3Durn: uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=3D00:05:03:5e:70:a6 SIP/2.0 </allOneLine> I always thought a bnc parameter will only appear in REGISTER messages? Bes= ides that, this would be the only case where both a user part and a bnc par= ameter appear together. Thanks, Ernst From trac@tools.ietf.org Thu Jul 22 09:26:03 2010 Return-Path: <trac@tools.ietf.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 8DB423A6873 for <martini@core3.amsl.com>; Thu, 22 Jul 2010 09:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-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 GEGYVf533C7k for <martini@core3.amsl.com>; Thu, 22 Jul 2010 09:26:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BEF1C3A6814 for <martini@ietf.org>; Thu, 22 Jul 2010 09:26:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1ObybD-0005gN-Hz; Thu, 22 Jul 2010 09:26:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Thu, 22 Jul 2010 16:26:19 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/60 Message-ID: <076.524bbc875a26b8aaf4f993ab6860e933@tools.ietf.org> X-Trac-Ticket-ID: 60 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #60: Optionality of Service-Route etc. X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 22 Jul 2010 16:26:03 -0000 #60: Optionality of Service-Route etc. ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: gin | Version: Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- In section 7: "The following sections describe the means by which this mechanism interacts with relevant REGISTER-related extensions currently defined by the IETF." Perhaps there should be clarification as to whether or not this document requires support of any of these mechanisms. For example, I don't think there is any intention to mandate support of the Service-Route header field - section 7.4 just gives information on the impact if the mechanism is used. Similarly Path is optional, beyond the specific bits mandated elsewhere. I don't think there is any intention to mandate support for the registration event package (7.2) or SIP-Outbound (7.3). Concerning support for public and temporary GRUUs (7.1), I think this is the subject of a separate discussion. Depending on what is decided for each of these, either a blanket statement in 7 or individual statements in 7.1/2/3/4 should be added. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/60> martini <http://tools.ietf.org/martini/> From adam@nostrum.com Thu Jul 22 13:56:42 2010 Return-Path: <adam@nostrum.com> 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 AFF763A68CD for <martini@core3.amsl.com>; Thu, 22 Jul 2010 13:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 r18yhOygtDdA for <martini@core3.amsl.com>; Thu, 22 Jul 2010 13:56:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6609D3A67B1 for <martini@ietf.org>; Thu, 22 Jul 2010 13:56:41 -0700 (PDT) Received: from 200.98.240.10.in-addr.arpa (mb90736d0.tmodns.net [208.54.7.185]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6MKurc5088754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jul 2010 15:56:55 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C48B090.3040206@nostrum.com> Date: Thu, 22 Jul 2010 15:56:48 -0500 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: David Hancock <D.Hancock@CableLabs.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg>, <A444A0F8084434499206E78C106220CAECCCC458@MCHP058A.global-ad.net> <76AC5FEF83F1E64491446437EA81A61F7CF4B0488F@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF4B0488F@srvxchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 208.54.7.185 is authenticated by a trusted mechanism) Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Thu, 22 Jul 2010 20:56:42 -0000 On 7/22/10 9:02 AM, David Hancock wrote: > ________________________________________ > From: Elwell, John [john.elwell@siemens-enterprise.com] > Sent: Thursday, July 22, 2010 1:27 AM > To: David Hancock; Bernard Aboba; martini@ietf.org > Subject: RE: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of David Hancock >> Sent: 22 July 2010 00:51 >> To: Bernard Aboba; martini@ietf.org >> Subject: Re: [martini] Announcement of MARTINI WG last Call >> on "Registration for Multiple Phone Numbers in the SIP" >> >> I've reviewed the document and think it is ready for >> consideration, pending resolution of the issues described below. >> >> These issues all have to do with subscribing to reg-event. >> >> -------------------------------------------------------------- >> Issue-1: >> Section 7.7.2 says... >> If the SSP receives a SUBSCRIBE request for the registration event >> package with a Request-URI that indicates a contact registered via >> the "Bulk Number Contact" mechanism defined in this document, then >> the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the >> same way that >> is would proxy an INVITE bound for that AOR, unless the SSP has and >> can maintain a copy of complete, accurate, and up-to-date >> information >> from the SIP-PBX (e.g., through an active back-end subscription). >> >> How does the SSP handle the SUBSCRIBE to reg-event for an >> enterprise user when the SIP-PBX isn't registered? My >> understanding of RFC3680 is that if the target user of a >> reg-event SUBSCRIBE isn't registered, then the reg-event >> subscriber receives a NOTIFY indicating "user not >> registered". The subscribe dialog remains active, and if/when >> the target user subsequently registers, the reg-event >> subscriber receives another NOTIFY containing the >> registration data. Would this same process be followed when >> the reg-event subscription is to an AOR owned by the SIP-PBX, >> and if yes, how does the SSP make that happen? > [JRE] Wouldn't the SSP return a 480 response to the SUBSCRIBE request if it can't deliver it? > > [dch] Yes, that would be one way to handle it, although not so friendly to the reg-event subscriber. Since for "normal" registrations the SSP registrar/proxy doesn't send a 480 response when the target user isn't registered, it might be useful if the draft covered this case. Well, we don't mandate reg event at the moment (although John has opened a ticket on this subject), so mandating that the SSP support it would be something quite new. Now, it probably has value to say that the SSP can answer the subscription as long as the PBX isn't registered. But I don't think we need to mandate any particular behavior. Remember, we're defining protocols here, not architectures. We want to enable certain behaviors without limiting them or mandating them -- unless doing so is require for interoperability. > If we take this approach where the SSP treats these SUBSCRIBEs like any request to be delivered to the SIP-PBX, then what happens to reg-event subscriptions to the SIP-PBX when the PBX transitions from registered to not-registered? Would they simply expire? See RFC 3265, section 3.3.5 (or, for more clarity, rfc3265bis, section 4.4.2). /a From pkyzivat@cisco.com Fri Jul 23 06:04:11 2010 Return-Path: <pkyzivat@cisco.com> 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 212673A696C for <martini@core3.amsl.com>; Fri, 23 Jul 2010 06:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 fmR3ziAWb+Zm for <martini@core3.amsl.com>; Fri, 23 Jul 2010 06:04:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DE1E63A68DC for <martini@ietf.org>; Fri, 23 Jul 2010 06:04:09 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOUvSUxAZnwM/2dsb2JhbACfaHGmGJsKhTYEiGA Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2010 13:04:27 +0000 Received: from [10.86.253.215] ([10.86.253.215]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6ND4RH2016041; Fri, 23 Jul 2010 13:04:27 GMT Message-ID: <4C49935B.3080201@cisco.com> Date: Fri, 23 Jul 2010 09:04:27 -0400 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach <adam@nostrum.com>, "martini@ietf.org" <martini@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [martini] draft-ietf-martini-gin-05 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: Fri, 23 Jul 2010 13:04:11 -0000 [resend - I erroneously sent to sipcore previously] (Still catching up on my reading) This draft is hanging together very well now. I have a few comments: Section 7.1.2.2: According to RFC5627 (gruu) section 3.2, every registration refresh generates a new temp gruu, with special rules for expiration. Does that apply here too? Or is that changed for bnc registrations? Either way, I think the implications need to be discussed. Section 7.2.1: I think there may be an issue here. Normally RFC5628 (gruu reg event) would apply here, reporting the gruus assigned. (The most recent for the temp gruu.) That could work for the pub-gruu of each implicitly registered number. But it won't work for the temp gruus - the SSP doesn't even know what those are. If there was a record for the "base" AOR, that could contain the temp-gruu template. But that is currently forbidden. Again, I think something needs to be said about this, whatever way it should work. One thing to keep in mind is that management of temp gruus can be touchy relative to registration refreshes. If the registration ever expires, even momentarily, then the previously assigned temp gruus become invalid. Only new ones obtained after reregistration are then valid. In the case of the pbx with devices registered to it, that have have been issued "derived" temp gruus, those also become invalid. The only way to be certain this hasn't happened is to subscribe to the reg event package and get gruu reg event info about the temp gruu. But that will only work if the pbx can get temp gruu info from a reg event subscription to the SSP. Sorry to be so tardy in getting this info out. I think I alluded to it earlier, but I don't think I ever provided specifics. Thanks, Paul 7.2.2 There is an out for the SSP to handle the subscriptions if it can keep a complete, accurate and up to date copy of the data, e.g. through a backend subscription.) Its even harder than that, since the pbx could apply an authorization policy to each of those AORs, restricting who can see the info, and how much of it. The SSP couldn't learn that through backend subscriptions unless it maintains a distinct backend subscription for each potential subscriber. In this section gruus again rear their ugly heads. If the pbx supports gruu, then it probably SHOULD support the gruu reg event package and return the appropriate information. From brian.lindsay@genband.com Fri Jul 23 06:26:44 2010 Return-Path: <brian.lindsay@genband.com> 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 F3C793A685E for <martini@core3.amsl.com>; Fri, 23 Jul 2010 06:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ouDCYefXvaYm for <martini@core3.amsl.com>; Fri, 23 Jul 2010 06:26:42 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id C28CC3A68AF for <martini@ietf.org>; Fri, 23 Jul 2010 06:26:39 -0700 (PDT) Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTEmYobH8OUEfgJIOmZ9zFt46QJ4+PpFO@postini.com; Fri, 23 Jul 2010 06:26:59 PDT Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 08:26:51 -0500 Received: from GBPLMAIL01.genband.com ([fe80::5527:203:6352:79a0]) by GBEX01.genband.com ([fe80::8063:55ef:b7ab:3543%14]) with mapi; Fri, 23 Jul 2010 08:26:51 -0500 From: Brian Lindsay <brian.lindsay@genband.com> To: "john.elwell@siemens-enterprise.com" <john.elwell@siemens-enterprise.com>, "martini@ietf.org" <martini@ietf.org> Thread-Topic: [martini] #60: Optionality of Service-Route etc. Thread-Index: AQHLKbqgbM+XT7wPA0aVUZkUDyb9d5K9c1eA Date: Fri, 23 Jul 2010 13:26:48 +0000 Message-ID: <F1A0ED6425368141998E077AC43334E4038800@gbplmail01.genband.com> References: <076.524bbc875a26b8aaf4f993ab6860e933@tools.ietf.org> In-Reply-To: <076.524bbc875a26b8aaf4f993ab6860e933@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2010 13:26:51.0614 (UTC) FILETIME=[B5DB4FE0:01CB2A6A] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.000.1038-17522.007 X-TM-AS-Result: No--11.831700-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [martini] #60: Optionality of Service-Route etc. 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: Fri, 23 Jul 2010 13:26:44 -0000 Hi,=20 Similar to my comment on GRUU earlier in the week, I would like to see th= ese remain optional as far as the draft is concerned.=20 I had interpreted the existing intent of Section 7 as describing how the m= echanisms work with gin registration (and extending the mechanisms if need = be), but not coupling/requiring that a gin registration implementation also= implement these mechanisms. If that intent needs to be strengthened in the= text that's fine. Thanks Brian ------------- Brian Lindsay Sr. Architect, System Architecture GENBAND Office: +1.613.763.3459 =20 www.genband.com -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of martini issue tracker Sent: Thursday, July 22, 2010 12:26 PM To: john.elwell@siemens-enterprise.com Cc: martini@ietf.org Subject: [martini] #60: Optionality of Service-Route etc. #60: Optionality of Service-Route etc. ------------------------------------------------+----------------------- ------------------------------------------------+---- Reporter: john.elwell@... | Owner: =20 Type: defect | Status: new Priority: minor | Milestone: =20 Component: gin | Version: =20 Severity: In WG Last Call | Keywords: =20 ------------------------------------------------+----------------------- ------------------------------------------------+---- In section 7: "The following sections describe the means by which this mechanism interacts with relevant REGISTER-related extensions currently defined by the IETF." Perhaps there should be clarification as to whether or not this document = requires support of any of these mechanisms. For example, I don't think th= ere is any intention to mandate support of the Service-Route header field = - section 7.4 just gives information on the impact if the mechanism is use= d. Similarly Path is optional, beyond the specific bits mandated elsewhere= . I don't think there is any intention to mandate support for the registra= tion event package (7.2) or SIP-Outbound (7.3). Concerning support for pub= lic and temporary GRUUs (7.1), I think this is the subject of a separate d= iscussion. Depending on what is decided for each of these, either a blanke= t statement in 7 or individual statements in 7.1/2/3/4 should be added. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/60> martini <http://tools.ietf.org/martini/> _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Fri Jul 23 07:00:32 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 486813A682F for <martini@core3.amsl.com>; Fri, 23 Jul 2010 07:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599] 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 C+WmbaBQD7n2 for <martini@core3.amsl.com>; Fri, 23 Jul 2010 07:00:31 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A4B113A67EA for <martini@ietf.org>; Fri, 23 Jul 2010 07:00:30 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-952679; Fri, 23 Jul 2010 16:00:47 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id AFB3C1EB82AB; Fri, 23 Jul 2010 16:00:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 23 Jul 2010 16:00:47 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Brian Lindsay <brian.lindsay@genband.com>, "martini@ietf.org" <martini@ietf.org> Date: Fri, 23 Jul 2010 16:00:46 +0200 Thread-Topic: [martini] #60: Optionality of Service-Route etc. Thread-Index: AQHLKbqgbM+XT7wPA0aVUZkUDyb9d5K9c1eAgAEWB2A= Message-ID: <A444A0F8084434499206E78C106220CAECCCCBDF@MCHP058A.global-ad.net> References: <076.524bbc875a26b8aaf4f993ab6860e933@tools.ietf.org> <F1A0ED6425368141998E077AC43334E4038800@gbplmail01.genband.com> In-Reply-To: <F1A0ED6425368141998E077AC43334E4038800@gbplmail01.genband.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] #60: Optionality of Service-Route etc. 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: Fri, 23 Jul 2010 14:00:32 -0000 Right, so in that case I would propose the addition of the following senten= ce to the end of the first paragraph of section 7: "With the exception of requirements in section 5.1 relating to the Path hea= der field (RFC 3327), this document does not mandate support for any of the= mechanisms discussed in this section. Any requirements in the sub-sections= below apply only if the mechanism concerned is supported." John=20 > -----Original Message----- > From: Brian Lindsay [mailto:brian.lindsay@genband.com]=20 > Sent: 23 July 2010 14:27 > To: Elwell, John; martini@ietf.org > Subject: RE: [martini] #60: Optionality of Service-Route etc. >=20 > Hi,=20 >=20 > Similar to my comment on GRUU earlier in the week, I would=20 > like to see these remain optional as far as the draft is concerned.=20 >=20 > I had interpreted the existing intent of Section 7 as=20 > describing how the mechanisms work with gin registration (and=20 > extending the mechanisms if need be), but not=20 > coupling/requiring that a gin registration implementation=20 > also implement these mechanisms. If that intent needs to be=20 > strengthened in the text that's fine. >=20 >=20 > Thanks > Brian >=20 > ------------- > Brian Lindsay > Sr. Architect, System Architecture > GENBAND > Office: +1.613.763.3459 =20 > www.genband.com >=20 >=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of martini issue tracker > Sent: Thursday, July 22, 2010 12:26 PM > To: john.elwell@siemens-enterprise.com > Cc: martini@ietf.org > Subject: [martini] #60: Optionality of Service-Route etc. >=20 > #60: Optionality of Service-Route etc. > ------------------------------------------------+------------- > ---------- > ------------------------------------------------+---- > Reporter: john.elwell@... | Owner: =20 > Type: defect | Status: new > Priority: minor | Milestone: =20 > Component: gin | Version: =20 > Severity: In WG Last Call | Keywords: =20 > ------------------------------------------------+------------- > ---------- > ------------------------------------------------+---- > In section 7: > "The following sections describe the means by which this mechanism > interacts with relevant REGISTER-related extensions=20 > currently defined > by the IETF." >=20 > Perhaps there should be clarification as to whether or not=20 > this document requires support of any of these mechanisms.=20 > For example, I don't think there is any intention to mandate=20 > support of the Service-Route header field - section 7.4 just=20 > gives information on the impact if the mechanism is used.=20 > Similarly Path is optional, beyond the specific bits mandated=20 > elsewhere. I don't think there is any intention to mandate=20 > support for the registration event package (7.2) or=20 > SIP-Outbound (7.3). Concerning support for public and=20 > temporary GRUUs (7.1), I think this is the subject of a =20 > separate discussion. Depending on what is decided for each of=20 > these, either a blanket statement in 7 or individual=20 > statements in 7.1/2/3/4 should be added. >=20 > -- > Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/60> > martini <http://tools.ietf.org/martini/> >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From brian.lindsay@genband.com Fri Jul 23 07:57:55 2010 Return-Path: <brian.lindsay@genband.com> 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 7D1CE3A692B for <martini@core3.amsl.com>; Fri, 23 Jul 2010 07:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 KvfaIkAd7qg0 for <martini@core3.amsl.com>; Fri, 23 Jul 2010 07:57:54 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id BFCF63A6894 for <martini@ietf.org>; Fri, 23 Jul 2010 07:57:52 -0700 (PDT) Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTEmuAoy6yYVXSoIS2sEnvfUS3qPZPrFN@postini.com; Fri, 23 Jul 2010 07:58:12 PDT Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 09:57:13 -0500 Received: from GBPLMAIL01.genband.com ([fe80::5527:203:6352:79a0]) by GBEX01.genband.com ([fe80::8063:55ef:b7ab:3543%14]) with mapi; Fri, 23 Jul 2010 09:57:12 -0500 From: Brian Lindsay <brian.lindsay@genband.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "martini@ietf.org" <martini@ietf.org> Thread-Topic: [martini] #60: Optionality of Service-Route etc. Thread-Index: AQHLKbqgbM+XT7wPA0aVUZkUDyb9d5K9c1eAgAEWB2CAABGugA== Date: Fri, 23 Jul 2010 14:57:08 +0000 Message-ID: <F1A0ED6425368141998E077AC43334E403890E@gbplmail01.genband.com> References: <076.524bbc875a26b8aaf4f993ab6860e933@tools.ietf.org> <F1A0ED6425368141998E077AC43334E4038800@gbplmail01.genband.com> <A444A0F8084434499206E78C106220CAECCCCBDF@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAECCCCBDF@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2010 14:57:13.0051 (UTC) FILETIME=[5548F2B0:01CB2A77] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.000.1038-17522.007 X-TM-AS-Result: No--19.409600-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [martini] #60: Optionality of Service-Route etc. 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: Fri, 23 Jul 2010 14:57:55 -0000 Hi John, That looks pretty good. Thanks Brian -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Friday, July 23, 2010 10:01 AM To: Brian Lindsay; martini@ietf.org Subject: RE: [martini] #60: Optionality of Service-Route etc. Right, so in that case I would propose the addition of the following senten= ce to the end of the first paragraph of section 7: "With the exception of requirements in section 5.1 relating to the Path hea= der field (RFC 3327), this document does not mandate support for any of the= mechanisms discussed in this section. Any requirements in the sub-sections= below apply only if the mechanism concerned is supported." John=20 > -----Original Message----- > From: Brian Lindsay [mailto:brian.lindsay@genband.com] > Sent: 23 July 2010 14:27 > To: Elwell, John; martini@ietf.org > Subject: RE: [martini] #60: Optionality of Service-Route etc. >=20 > Hi, >=20 > Similar to my comment on GRUU earlier in the week, I would like to=20 > see these remain optional as far as the draft is concerned. >=20 > I had interpreted the existing intent of Section 7 as describing how=20 > the mechanisms work with gin registration (and extending the=20 > mechanisms if need be), but not coupling/requiring that a gin=20 > registration implementation also implement these mechanisms. If that=20 > intent needs to be strengthened in the text that's fine. >=20 >=20 > Thanks > Brian >=20 > ------------- > Brian Lindsay > Sr. Architect, System Architecture > GENBAND > Office: +1.613.763.3459 =20 > www.genband.com >=20 >=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of martini issue tracker > Sent: Thursday, July 22, 2010 12:26 PM > To: john.elwell@siemens-enterprise.com > Cc: martini@ietf.org > Subject: [martini] #60: Optionality of Service-Route etc. >=20 > #60: Optionality of Service-Route etc. > ------------------------------------------------+------------- > ---------- > ------------------------------------------------+---- > Reporter: john.elwell@... | Owner: =20 > Type: defect | Status: new > Priority: minor | Milestone: =20 > Component: gin | Version: =20 > Severity: In WG Last Call | Keywords: =20 > ------------------------------------------------+------------- > ---------- > ------------------------------------------------+---- > In section 7: > "The following sections describe the means by which this mechanism > interacts with relevant REGISTER-related extensions=20 > currently defined > by the IETF." >=20 > Perhaps there should be clarification as to whether or not=20 > this document requires support of any of these mechanisms.=20 > For example, I don't think there is any intention to mandate=20 > support of the Service-Route header field - section 7.4 just=20 > gives information on the impact if the mechanism is used.=20 > Similarly Path is optional, beyond the specific bits mandated=20 > elsewhere. I don't think there is any intention to mandate=20 > support for the registration event package (7.2) or=20 > SIP-Outbound (7.3). Concerning support for public and=20 > temporary GRUUs (7.1), I think this is the subject of a =20 > separate discussion. Depending on what is decided for each of=20 > these, either a blanket statement in 7 or individual=20 > statements in 7.1/2/3/4 should be added. >=20 > -- > Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/60> > martini <http://tools.ietf.org/martini/> >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From HKaplan@acmepacket.com Fri Jul 23 08:16:21 2010 Return-Path: <HKaplan@acmepacket.com> 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 35C103A68CF for <martini@core3.amsl.com>; Fri, 23 Jul 2010 08:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599] 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 9UHdVt+iEGSR for <martini@core3.amsl.com>; Fri, 23 Jul 2010 08:16:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A04023A67E6 for <martini@ietf.org>; Fri, 23 Jul 2010 08:16:16 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Jul 2010 11:16:31 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Jul 2010 11:16:31 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, Brian Lindsay <brian.lindsay@genband.com>, "martini@ietf.org" <martini@ietf.org> Date: Fri, 23 Jul 2010 11:16:31 -0400 Thread-Topic: [martini] #60: Optionality of Service-Route etc. Thread-Index: AQHLKbqgbM+XT7wPA0aVUZkUDyb9d5K9c1eAgAEWB2CAABYXQA== Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F4086@mail> References: <076.524bbc875a26b8aaf4f993ab6860e933@tools.ietf.org> <F1A0ED6425368141998E077AC43334E4038800@gbplmail01.genband.com> <A444A0F8084434499206E78C106220CAECCCCBDF@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAECCCCBDF@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] #60: Optionality of Service-Route etc. 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: Fri, 23 Jul 2010 15:16:21 -0000 Sounds good. (though as an aside, unlike gruu and outbound, Service-Route support is not= indicated in the REGISTER request and thus not really useful if it's not m= andatory and tied to gin, but that's a more generic problem anyway) -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Elwell, John > Sent: Friday, July 23, 2010 10:01 AM > To: Brian Lindsay; martini@ietf.org > Subject: Re: [martini] #60: Optionality of Service-Route etc. >=20 > Right, so in that case I would propose the addition of the following > sentence to the end of the first paragraph of section 7: > "With the exception of requirements in section 5.1 relating to the Path > header field (RFC 3327), this document does not mandate support for any o= f > the mechanisms discussed in this section. Any requirements in the sub- > sections below apply only if the mechanism concerned is supported." >=20 > John >=20 > > -----Original Message----- > > From: Brian Lindsay [mailto:brian.lindsay@genband.com] > > Sent: 23 July 2010 14:27 > > To: Elwell, John; martini@ietf.org > > Subject: RE: [martini] #60: Optionality of Service-Route etc. > > > > Hi, > > > > Similar to my comment on GRUU earlier in the week, I would > > like to see these remain optional as far as the draft is concerned. > > > > I had interpreted the existing intent of Section 7 as > > describing how the mechanisms work with gin registration (and > > extending the mechanisms if need be), but not > > coupling/requiring that a gin registration implementation > > also implement these mechanisms. If that intent needs to be > > strengthened in the text that's fine. > > > > > > Thanks > > Brian > > > > ------------- > > Brian Lindsay > > Sr. Architect, System Architecture > > GENBAND > > Office: +1.613.763.3459 > > www.genband.com > > > > > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of martini issue tracker > > Sent: Thursday, July 22, 2010 12:26 PM > > To: john.elwell@siemens-enterprise.com > > Cc: martini@ietf.org > > Subject: [martini] #60: Optionality of Service-Route etc. > > > > #60: Optionality of Service-Route etc. > > ------------------------------------------------+------------- > > ---------- > > ------------------------------------------------+---- > > Reporter: john.elwell@... | Owner: > > Type: defect | Status: new > > Priority: minor | Milestone: > > Component: gin | Version: > > Severity: In WG Last Call | Keywords: > > ------------------------------------------------+------------- > > ---------- > > ------------------------------------------------+---- > > In section 7: > > "The following sections describe the means by which this mechanism > > interacts with relevant REGISTER-related extensions > > currently defined > > by the IETF." > > > > Perhaps there should be clarification as to whether or not > > this document requires support of any of these mechanisms. > > For example, I don't think there is any intention to mandate > > support of the Service-Route header field - section 7.4 just > > gives information on the impact if the mechanism is used. > > Similarly Path is optional, beyond the specific bits mandated > > elsewhere. I don't think there is any intention to mandate > > support for the registration event package (7.2) or > > SIP-Outbound (7.3). Concerning support for public and > > temporary GRUUs (7.1), I think this is the subject of a > > separate discussion. Depending on what is decided for each of > > these, either a blanket statement in 7 or individual > > statements in 7.1/2/3/4 should be added. > > > > -- > > Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/60> > > martini <http://tools.ietf.org/martini/> > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From HKaplan@acmepacket.com Fri Jul 23 08:30:19 2010 Return-Path: <HKaplan@acmepacket.com> 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 0F4E43A69CD for <martini@core3.amsl.com>; Fri, 23 Jul 2010 08:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599] 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 LaEOKmD76gTM for <martini@core3.amsl.com>; Fri, 23 Jul 2010 08:30:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E81CF3A692B for <martini@ietf.org>; Fri, 23 Jul 2010 08:30:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Jul 2010 11:30:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Jul 2010 11:30:24 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "bruno.chatras@orange-ftgroup.com" <bruno.chatras@orange-ftgroup.com>, "adam@nostrum.com" <adam@nostrum.com> Date: Fri, 23 Jul 2010 11:30:24 -0400 Thread-Topic: [martini] REMINDER: Ongoing MARTINI WG lastCall on"Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsoIcTgTg+jMHVnTxyi6qCUI4QITgAAfBawAAYwBTAAGpPdsAB09bMw Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F4093@mail> References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us><A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net><B011440129B84B30978779D2BCA75D18@china.huawei.com><9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr><4C45C316.1090702@nostrum.com> <9ECCF01B52E7AB408A7EB8535264214101B1EC01@ftrdmel0.rd.francetelecom.fr> <430FC6BDED356B4C8498F634416644A9258D7F3A57@mail> <9ECCF01B52E7AB408A7EB8535264214101B1ECEF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214101B1ECEF@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bernard_aboba@hotmail.com" <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on"Registration for Multiple Phone Numbers in the SIP" 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: Fri, 23 Jul 2010 15:30:19 -0000 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange- > ftgroup.com] > Sent: Wednesday, July 21, 2010 3:36 AM >=20 > > -----Message d'origine----- > > De : Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Envoy=E9 : mardi 20 juillet 2010 20:56 > > If the PBX only registered a single contact, then the SSP > > wouldn't be able to indicate two different target AoR domains > > - but that's actually a GOOD thing, I think. Either the PBX > > knows about the two AoR domains, in which case it should have > > registered for them separately; >=20 > =3D=3D>BC: Of course it can register them separately (especially if there= are > only two sub-domains) but why should we mandate this behavior while there > are other more flexible solutions that do not have this constraint? Because it follows 3261? Because it keeps the request-uri as the identity = and the address of the target, as opposed to just the identity but not the = address? Also, it's arguable which is more "flexible". Having a separate REGISTER f= or each AoR domain allows the service provider to have separate registrars = responsible for each domain, and invoke separate service-route and paths. -hadriel From D.Hancock@CableLabs.com Fri Jul 23 13:56:09 2010 Return-Path: <D.Hancock@CableLabs.com> 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 172183A67E1 for <martini@core3.amsl.com>; Fri, 23 Jul 2010 13:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 pHupDbx5gGWw for <martini@core3.amsl.com>; Fri, 23 Jul 2010 13:56:08 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 14D2A3A66B4 for <martini@ietf.org>; Fri, 23 Jul 2010 13:56:08 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o6NKuNAj006138; Fri, 23 Jul 2010 14:56:24 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 23 Jul 2010 14:56:24 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 23 Jul 2010 14:56:25 -0600 From: David Hancock <D.Hancock@CableLabs.com> To: Adam Roach <adam@nostrum.com> Date: Fri, 23 Jul 2010 14:56:23 -0600 Thread-Topic: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" Thread-Index: Acsp4GyLiIriHCtqRpewFUgrJXYWjQAxvYYg Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF4F166B4@srvxchg> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg>, <A444A0F8084434499206E78C106220CAECCCC458@MCHP058A.global-ad.net> <76AC5FEF83F1E64491446437EA81A61F7CF4B0488F@srvxchg> <4C48B090.3040206@nostrum.com> In-Reply-To: <4C48B090.3040206@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Fri, 23 Jul 2010 20:56:09 -0000 Comments at the end... > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, July 22, 2010 2:57 PM > To: David Hancock > Cc: Elwell, John; Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Announcement of MARTINI WG last Call on > "Registration for Multiple Phone Numbers in the SIP" >=20 > On 7/22/10 9:02 AM, David Hancock wrote: > > ________________________________________ > > From: Elwell, John [john.elwell@siemens-enterprise.com] > > Sent: Thursday, July 22, 2010 1:27 AM > > To: David Hancock; Bernard Aboba; martini@ietf.org > > Subject: RE: [martini] Announcement of MARTINI WG last Call on > "Registration for Multiple Phone Numbers in the SIP" > > > >> -----Original Message----- > >> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of David Hancock > >> Sent: 22 July 2010 00:51 > >> To: Bernard Aboba; martini@ietf.org > >> Subject: Re: [martini] Announcement of MARTINI WG last Call > >> on "Registration for Multiple Phone Numbers in the SIP" > >> > >> I've reviewed the document and think it is ready for > >> consideration, pending resolution of the issues described below. > >> > >> These issues all have to do with subscribing to reg-event. > >> > >> -------------------------------------------------------------- > >> Issue-1: > >> Section 7.7.2 says... > >> If the SSP receives a SUBSCRIBE request for the registration event > >> package with a Request-URI that indicates a contact registered via > >> the "Bulk Number Contact" mechanism defined in this document, then > >> the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the > >> same way that > >> is would proxy an INVITE bound for that AOR, unless the SSP has an= d > >> can maintain a copy of complete, accurate, and up-to-date > >> information > >> from the SIP-PBX (e.g., through an active back-end subscription). > >> > >> How does the SSP handle the SUBSCRIBE to reg-event for an > >> enterprise user when the SIP-PBX isn't registered? My > >> understanding of RFC3680 is that if the target user of a > >> reg-event SUBSCRIBE isn't registered, then the reg-event > >> subscriber receives a NOTIFY indicating "user not > >> registered". The subscribe dialog remains active, and if/when > >> the target user subsequently registers, the reg-event > >> subscriber receives another NOTIFY containing the > >> registration data. Would this same process be followed when > >> the reg-event subscription is to an AOR owned by the SIP-PBX, > >> and if yes, how does the SSP make that happen? > > [JRE] Wouldn't the SSP return a 480 response to the SUBSCRIBE request i= f > it can't deliver it? > > > > [dch] Yes, that would be one way to handle it, although not so friendly > to the reg-event subscriber. Since for "normal" registrations the SSP > registrar/proxy doesn't send a 480 response when the target user isn't > registered, it might be useful if the draft covered this case. >=20 > Well, we don't mandate reg event at the moment (although John has opened > a ticket on this subject), so mandating that the SSP support it would be > something quite new. Now, it probably has value to say that the SSP can > answer the subscription as long as the PBX isn't registered. But I don't > think we need to mandate any particular behavior. >=20 > Remember, we're defining protocols here, not architectures. We want to > enable certain behaviors without limiting them or mandating them -- > unless doing so is require for interoperability. >=20 > > If we take this approach where the SSP treats these SUBSCRIBEs like any > request to be delivered to the SIP-PBX, then what happens to reg-event > subscriptions to the SIP-PBX when the PBX transitions from registered to > not-registered? Would they simply expire? >=20 > See RFC 3265, section 3.3.5 (or, for more clarity, rfc3265bis, section > 4.4.2). >=20 [dch] Interesting. Your idea being (I assume) that that this mechanism cou= ld be used to pass the reg-event subscription back and forth between the SS= P network and the SIP-PBX, based on whether the PBX itself is registered or= not. I'm sensitive to your concern about not over-mandating what can be l= eft to implementation. But I think an informative sentence or two on this w= ould be very useful.=20 Thanks David > /a From adam@nostrum.com Sat Jul 24 02:55:59 2010 Return-Path: <adam@nostrum.com> 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 3F1333A6816 for <martini@core3.amsl.com>; Sat, 24 Jul 2010 02:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 Rlx4CXpn7+aq for <martini@core3.amsl.com>; Sat, 24 Jul 2010 02:55:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C9CDF3A681E for <martini@ietf.org>; Sat, 24 Jul 2010 02:55:57 -0700 (PDT) Received: from dhcp-23f3.meeting.ietf.org (dhcp-23f3.meeting.ietf.org [130.129.35.243]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6O9uBPd071519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2010 04:56:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4AB8BA.6090707@nostrum.com> Date: Sat, 24 Jul 2010 11:56:10 +0200 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: David Hancock <D.Hancock@CableLabs.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.35.243 is authenticated by a trusted mechanism) Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Sat, 24 Jul 2010 09:55:59 -0000 > -------------------------------------------------------------- > > Issue-2: How does a SIP-PBX that doesn't have SIP endpoints respond to a SUBSCRIBE to reg-event (say, SIP-PBX supports only analog or H.323 lines)? I assume it should create fake registration data is if the target AOR were registered to a SIP endpoint. Does that need to be stated? You've described pretty much the correct behavior. I'm not certain we need to have a lot of discussion about this, although a one-sentence summary (similar to what you've put above) probably has some value. > -------------------------------------------------------------- > > Issue-3: > Section 5.2 says... > A further implication of this property is that an individual extension > that is implicitly registered may also be explicitly registered using > a normal, non-bulk registration (subject to SSP policy). If such a > registration exists, it is refreshed independently of the bulk > registration, and is not removed when the bulk registration is > removed. > > I assume this means that an enterprise user AOR can be bound to two (multiple) contact addresses; one bulk-registered by the PBX, and a second explicitly registered by a SIP endpoint directly hosted by the SSP network. > > Section 6 of the draft goes on to say that SUBSCRIBE requests to reg-event are handled just like INVITE requests, which means that if the target AOR has multiple contacts, the SUBSCRIBE request is forked. This seems like a problem, since RFC3680 disallows forking (RFC3680 section 4.9). Yeah, I've always considered event packages that forbid multiple subscriptions in the case of a forked SUBSCRIBE to indicate a lack of imagination on behalf of the event package designer. :) Basically, the only way to make this work properly would be to require the SSP to maintain back-end subscriptions to the PBX(es), and to compose all the relevant data into a single record. This isn't a difficult problem, but it requires significant new code in the SSP. The only way we could guarantee this working would be to mandate such behavior. I don't think that'll make people particularly happy. I'll add a slide to the deck for discussion at the face-to-face meeting to see what people want to do here. /a From adam@nostrum.com Sat Jul 24 02:57:58 2010 Return-Path: <adam@nostrum.com> 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 967C93A681E for <martini@core3.amsl.com>; Sat, 24 Jul 2010 02:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 BFNvNo1NYr2e for <martini@core3.amsl.com>; Sat, 24 Jul 2010 02:57:57 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5E56D3A68B3 for <martini@ietf.org>; Sat, 24 Jul 2010 02:57:57 -0700 (PDT) Received: from dhcp-23f3.meeting.ietf.org (dhcp-23f3.meeting.ietf.org [130.129.35.243]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6O9wBG7071660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2010 04:58:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4AB933.2080609@nostrum.com> Date: Sat, 24 Jul 2010 11:58:11 +0200 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: David Hancock <D.Hancock@CableLabs.com> References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg>, <A444A0F8084434499206E78C106220CAECCCC458@MCHP058A.global-ad.net> <76AC5FEF83F1E64491446437EA81A61F7CF4B0488F@srvxchg> <4C48B090.3040206@nostrum.com> <76AC5FEF83F1E64491446437EA81A61F7CF4F166B4@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF4F166B4@srvxchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.35.243 is authenticated by a trusted mechanism) Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Sat, 24 Jul 2010 09:57:58 -0000 On 7/23/10 10:56 PM, David Hancock wrote: > Comments at the end... > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> >> ... >>> If we take this approach where the SSP treats these SUBSCRIBEs like any >> request to be delivered to the SIP-PBX, then what happens to reg-event >> subscriptions to the SIP-PBX when the PBX transitions from registered to >> not-registered? Would they simply expire? >> >> See RFC 3265, section 3.3.5 (or, for more clarity, rfc3265bis, section >> 4.4.2). >> > [dch] Interesting. Your idea being (I assume) that that this mechanism could be used to pass the reg-event subscription back and forth between the SSP network and the SIP-PBX, based on whether the PBX itself is registered or not. I'm sensitive to your concern about not over-mandating what can be left to implementation. But I think an informative sentence or two on this would be very useful. That seems reasonable. /a From trac@tools.ietf.org Sat Jul 24 07:13:08 2010 Return-Path: <trac@tools.ietf.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 16BB53A69A8 for <martini@core3.amsl.com>; Sat, 24 Jul 2010 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-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 VlN3dlLanUuZ for <martini@core3.amsl.com>; Sat, 24 Jul 2010 07:13:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 044E13A69A9 for <martini@ietf.org>; Sat, 24 Jul 2010 07:13:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OcfTI-0000su-91; Sat, 24 Jul 2010 07:13:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, pkyzivat@cisco.com X-Trac-Project: martini Date: Sat, 24 Jul 2010 14:13:00 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/martini/trac/ticket/61 Message-ID: <060.5b4526d4c22b62aadd6b6d04a6998d50@tools.ietf.org> X-Trac-Ticket-ID: 61 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, pkyzivat@cisco.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #61: Review X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 24 Jul 2010 14:13:08 -0000 #61: Review --------------------------------+------------------------------------------- Reporter: pkyzivat@… | Owner: adam@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: --------------------------------+------------------------------------------- This draft is hanging together very well now. I have a few comments: Section 7.1.2.2: According to RFC5627 (gruu) section 3.2, every registration refresh generates a new temp gruu, with special rules for expiration. Does that apply here too? Or is that changed for bnc registrations? Either way, I think the implications need to be discussed. Section 7.2.1: I think there may be an issue here. Normally RFC5628 (gruu reg event) would apply here, reporting the gruus assigned. (The most recent for the temp gruu.) That could work for the pub-gruu of each implicitly registered number. But it won't work for the temp gruus - the SSP doesn't even know what those are. If there was a record for the "base" AOR, that could contain the temp-gruu template. But that is currently forbidden. Again, I think something needs to be said about this, whatever way it should work. One thing to keep in mind is that management of temp gruus can be touchy relative to registration refreshes. If the registration ever expires, even momentarily, then the previously assigned temp gruus become invalid. Only new ones obtained after reregistration are then valid. In the case of the pbx with devices registered to it, that have have been issued "derived" temp gruus, those also become invalid. The only way to be certain this hasn't happened is to subscribe to the reg event package and get gruu reg event info about the temp gruu. But that will only work if the pbx can get temp gruu info from a reg event subscription to the SSP. Sorry to be so tardy in getting this info out. I think I alluded to it earlier, but I don't think I ever provided specifics. Thanks, Paul 7.2.2 There is an out for the SSP to handle the subscriptions if it can keep a complete, accurate and up to date copy of the data, e.g. through a backend subscription.) Its even harder than that, since the pbx could apply an authorization policy to each of those AORs, restricting who can see the info, and how much of it. The SSP couldn't learn that through backend subscriptions unless it maintains a distinct backend subscription for each potential subscriber. In this section gruus again rear their ugly heads. If the pbx supports gruu, then it probably SHOULD support the gruu reg event package and return the appropriate information. -- Ticket URL: <http://tools.ietf.org/wg/martini/trac/ticket/61> martini <http://tools.ietf.org/martini/> From trac@tools.ietf.org Sat Jul 24 07:21:05 2010 Return-Path: <trac@tools.ietf.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 A80AB3A694C for <martini@core3.amsl.com>; Sat, 24 Jul 2010 07:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-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 WD97kPoTJJ9M for <martini@core3.amsl.com>; Sat, 24 Jul 2010 07:21:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BD83F3A67FC for <martini@ietf.org>; Sat, 24 Jul 2010 07:21:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OcfbN-0002HJ-Uc; Sat, 24 Jul 2010 07:21:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, ernst.horvath@siemens-enterprise.com X-Trac-Project: martini Date: Sat, 24 Jul 2010 14:21:21 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/martini/trac/ticket/62 Message-ID: <078.951de67fe3f3dbf4c2a7a2cb77c7bff0@tools.ietf.org> X-Trac-Ticket-ID: 62 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, ernst.horvath@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #62: Public GRUU Example X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 24 Jul 2010 14:21:05 -0000 #62: Public GRUU Example --------------------------------------------------+------------------------- Reporter: ernst.horvath@… | Owner: adam@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Keywords: --------------------------------------------------+------------------------- I don't understand the public GRUU example in 7.1.1. The GRUU returned to a UA by the SIP-PBX looks like this: <allOneLine> Contact: <sip:line-1 at 10.20.1.17>; pub-gruu="sip:+12145550102 at ssp.example.com;bnc;gr=urn: uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6"; +sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>" ;expires=3600 </allOneLine> And may result in e.g. an INVITE request arriving at the SSP with the following Request-URI: <allOneLine> INVITE sip:+12145550102 at ssp.example.com;bnc;gr=urn: uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6 SIP/2.0 </allOneLine> I always thought a bnc parameter will only appear in REGISTER messages? Besides that, this would be the only case where both a user part and a bnc parameter appear together. -- Ticket URL: <http://tools.ietf.org/wg/martini/trac/ticket/62> martini <http://tools.ietf.org/martini/> From bernard_aboba@hotmail.com Sat Jul 24 07:45:19 2010 Return-Path: <bernard_aboba@hotmail.com> 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 74E773A6A41 for <martini@core3.amsl.com>; Sat, 24 Jul 2010 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 Pdc3Pg1QrmUW for <martini@core3.amsl.com>; Sat, 24 Jul 2010 07:45:18 -0700 (PDT) Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by core3.amsl.com (Postfix) with ESMTP id B8DD53A6A47 for <martini@ietf.org>; Sat, 24 Jul 2010 07:45:17 -0700 (PDT) Received: from BLU137-W34 ([65.55.111.71]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 07:45:36 -0700 Message-ID: <BLU137-W3432C29462C0AA4C769DF193A40@phx.gbl> Content-Type: multipart/alternative; boundary="_60e5c78d-05af-4e8a-b228-b85ae65a99a8_" X-Originating-IP: [130.129.54.251] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <martini@ietf.org> Date: Sat, 24 Jul 2010 07:45:36 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jul 2010 14:45:36.0246 (UTC) FILETIME=[E05EB160:01CB2B3E] Subject: [martini] Summary of MARTINI WG Last Call on "Registration for Multiple Phone Numbers in the SIP" 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: Sat, 24 Jul 2010 14:45:19 -0000 --_60e5c78d-05af-4e8a-b228-b85ae65a99a8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MARTINI WG last call on "Registration for Multiple Phone Numbers in the SIP= " completed on July 22=2C 2010.=20 WG consensus as expressed on the mailing list was overwhelmingly in favor o= f publication of the document=2C once the issues raised in WG last call hav= e been addressed.=20 15 Issues were submitted (#48 - 62) during WG last call. The issues are av= ailable for inspection here: http://tools.ietf.org/wg/martini/trac/report/1 = --_60e5c78d-05af-4e8a-b228-b85ae65a99a8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> MARTINI WG last call on "Registration for Multiple Phone Numbers in the SIP= " completed on July 22=2C 2010. <br><br>WG consensus as expressed on the ma= iling list was overwhelmingly in favor of publication of the document=2C on= ce the issues raised in WG last call have been addressed. <br><br>15 Issues= were submitted (#48 - 62) during WG last call. =3B The issues are avai= lable for inspection here:<br>http://tools.ietf.org/wg/martini/trac/report/= 1<br> </body> </html>= --_60e5c78d-05af-4e8a-b228-b85ae65a99a8_-- From bruno.chatras@orange-ftgroup.com Mon Jul 26 00:17:11 2010 Return-Path: <bruno.chatras@orange-ftgroup.com> 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 1596D3A69FA for <martini@core3.amsl.com>; Mon, 26 Jul 2010 00:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 cwITGF5mgxrf for <martini@core3.amsl.com>; Mon, 26 Jul 2010 00:17:01 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 67ACD3A69E8 for <martini@ietf.org>; Mon, 26 Jul 2010 00:16:54 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D1987FC400D; Mon, 26 Jul 2010 09:17:04 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B3B4FFC4001; Mon, 26 Jul 2010 09:16:59 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 09:16:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jul 2010 09:16:34 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214101B50E4E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F4093@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] REMINDER: Ongoing MARTINI WG lastCall on"Registration for Multiple Phone Numbers in the SIP" Thread-Index: AcsoIcTgTg+jMHVnTxyi6qCUI4QITgAAfBawAAYwBTAAGpPdsAB09bMwAIXfCRA= References: <BLU137-W168F37C34E4BA034704B8893BB0@phx.gbl><9ECCF01B52E7AB408A7EB8535264214101AEE888@ftrdmel0.rd.francetelecom.fr><000001cb2758$9c977cd0$d5c67670$@us><A444A0F8084434499206E78C106220CAECBA4A08@MCHP058A.global-ad.net><B011440129B84B30978779D2BCA75D18@china.huawei.com><9ECCF01B52E7AB408A7EB8535264214101B1EBC5@ftrdmel0.rd.francetelecom.fr><4C45C316.1090702@nostrum.com> <9ECCF01B52E7AB408A7EB8535264214101B1EC01@ftrdmel0.rd.francetelecom.fr> <430FC6BDED356B4C8498F634416644A9258D7F3A57@mail> <9ECCF01B52E7AB408A7EB8535264214101B1ECEF@ftrdmel0.rd.francetelecom.fr> <430FC6BDED356B4C8498F634416644A9258D7F4093@mail> From: <bruno.chatras@orange-ftgroup.com> To: <HKaplan@acmepacket.com>, <adam@nostrum.com> X-OriginalArrivalTime: 26 Jul 2010 07:16:35.0739 (UTC) FILETIME=[7B670EB0:01CB2C92] Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] REMINDER: Ongoing MARTINI WG lastCall on"Registration for Multiple Phone Numbers in the SIP" 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: Mon, 26 Jul 2010 07:17:11 -0000 =20 > -----Message d'origine----- > De : Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Envoy=E9 : vendredi 23 juillet 2010 17:30 > =C0 : CHATRAS Bruno RD-CORE-ISS; adam@nostrum.com > Cc : bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] REMINDER: Ongoing MARTINI WG lastCall=20 > on"Registration for Multiple Phone Numbers in the SIP" >=20 >=20 >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-=20 > > ftgroup.com] > > Sent: Wednesday, July 21, 2010 3:36 AM > >=20 > > > -----Message d'origine----- > > > De : Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Envoy=E9 : mardi=20 > > > 20 juillet 2010 20:56 If the PBX only registered a single=20 > contact,=20 > > > then the SSP wouldn't be able to indicate two different=20 > target AoR=20 > > > domains > > > - but that's actually a GOOD thing, I think. Either the=20 > PBX knows=20 > > > about the two AoR domains, in which case it should have=20 > registered=20 > > > for them separately; > >=20 > > =3D=3D>BC: Of course it can register them separately=20 > (especially if there=20 > > are only two sub-domains) but why should we mandate this behavior=20 > > while there are other more flexible solutions that do not=20 > have this constraint? >=20 > Because it follows 3261? Because it keeps the request-uri as=20 > the identity and the address of the target, as opposed to=20 > just the identity but not the address? >=20 > Also, it's arguable which is more "flexible". Having a=20 > separate REGISTER for each AoR domain allows the service=20 > provider to have separate registrars responsible for each=20 > domain, and invoke separate service-route and paths. Flexible in miy mind means that the solution should be flexible enough = to work in both cases: separate or single REGISTER for each AoR domain. = In other words a good solution should not place a constraint on this = point. >=20 > -hadriel >=20 From root@core3.amsl.com Mon Jul 26 02:00:01 2010 Return-Path: <root@core3.amsl.com> X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 861863A6AD1; Mon, 26 Jul 2010 02:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100726090001.861863A6AD1@core3.amsl.com> Date: Mon, 26 Jul 2010 02:00:01 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-reqs-09.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: Mon, 26 Jul 2010 09:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF. Title : Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) Author(s) : J. Elwell, H. Kaplan Filename : draft-ietf-martini-reqs-09.txt Pages : 13 Date : 2010-07-26 This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-martini-reqs-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-26015055.I-D@ietf.org> --NextPart-- From john.elwell@siemens-enterprise.com Mon Jul 26 05:36:04 2010 Return-Path: <john.elwell@siemens-enterprise.com> 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 D579F3A6802; Mon, 26 Jul 2010 05:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 nMl2QBsG3hsr; Mon, 26 Jul 2010 05:36:00 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id ED3B23A6BF4; Mon, 26 Jul 2010 05:35:52 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-967020; Mon, 26 Jul 2010 14:36:04 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id EDA921EB82AE; Mon, 26 Jul 2010 14:36:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 26 Jul 2010 14:36:03 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "Internet-Drafts@ietf.org" <Internet-Drafts@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org> Date: Mon, 26 Jul 2010 14:36:02 +0200 Thread-Topic: [martini] I-D Action:draft-ietf-martini-reqs-09.txt Thread-Index: AcssoQMFSNImzFpNQWWzYNbJNwDdbgAHXxAw Message-ID: <A444A0F8084434499206E78C106220CA01BE6F5CB6@MCHP058A.global-ad.net> References: <20100726090001.861863A6AD1@core3.amsl.com> In-Reply-To: <20100726090001.861863A6AD1@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] I-D Action:draft-ietf-martini-reqs-09.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: Mon, 26 Jul 2010 12:36:04 -0000 The only changes were: - removal of reference to martini mailing list; - addition of figure near start of section 3; - revised title of 3.3.1; - added reference to RFC 3966 from section 3.1.3. These were as requested during IETF last call / IESG review. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 26 July 2010 10:00 > To: i-d-announce@ietf.org > Cc: martini@ietf.org > Subject: [martini] I-D Action:draft-ietf-martini-reqs-09.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Multiple AoR reachabiliTy=20 > InformatioN Indication Working Group of the IETF. >=20 >=20 > Title : Requirements for multiple address of=20 > record (AOR) reachability information in the Session=20 > Initiation Protocol (SIP) > Author(s) : J. Elwell, H. Kaplan > Filename : draft-ietf-martini-reqs-09.txt > Pages : 13 > Date : 2010-07-26 >=20 > This document states requirements for a standardized SIP registration > mechanism for multiple addresses of record, the mechanism being > suitable for deployment by SIP service providers on a large scale in > support of small to medium sized Private Branch Exchanges (PBXs). > The requirements are for a solution that can, as a minimum, support > AORs based on E.164 numbers. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-09.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = From wwwrun@core3.amsl.com Mon Jul 26 06:29:00 2010 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CA41F3A695E; Mon, 26 Jul 2010 06:29:00 -0700 (PDT) X-idtracker: yes From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Message-Id: <20100726132900.CA41F3A695E@core3.amsl.com> Date: Mon, 26 Jul 2010 06:29:00 -0700 (PDT) Cc: martini chair <martini-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, martini mailing list <martini@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [martini] Document Action: 'Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP)' to Informational RFC 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: Mon, 26 Jul 2010 13:29:01 -0000 The IESG has approved the following document: - 'Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) ' <draft-ietf-martini-reqs-09.txt> as an Informational RFC This document is the product of the Multiple AoR reachabiliTy InformatioN Indication Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-09.txt Technical Summary This document summarizes the requirements for a mechanism to enable registration of multiple addresses of record within SIP. The goal is to produce a mechanism suitable for deployment by SIP service providers on a large scale in support of small to medium sized PBXs. Working Group Summary The WG discussed the issue of E.164/non-E.164 AORs in considerable depth, and concluded that extensibility to handle non-E.164 AORs (such as private numbers and email-style addresses) was important. Document Quality The document has been reviewed by participants within the IETF MARTINI WG, including SIP service providers as well as representatives from the PBX vendor community. It has gone through MARTINI WG last call, with only modest changes resulting. Personnel Bernard Aboba is the document shepherd for this document. Gonzalo Camarillo is the responsible AD. From fluffy@cisco.com Thu Jul 29 09:38:04 2010 Return-Path: <fluffy@cisco.com> 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 70D293A698E for <martini@core3.amsl.com>; Thu, 29 Jul 2010 09:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.781 X-Spam-Level: X-Spam-Status: No, score=-109.781 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, 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 vYOH-yLwicUa for <martini@core3.amsl.com>; Thu, 29 Jul 2010 09:38:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6B6833A68B7 for <martini@ietf.org>; Thu, 29 Jul 2010 09:38:03 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAEdLUUxAZnwN/2dsb2JhbACTMoxVcaVemxWFOASIeQ X-IronPort-AV: E=Sophos;i="4.55,281,1278288000"; d="scan'208";a="140888228" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2010 16:38:27 +0000 Received: from dhcp-10-61-110-127.cisco.com (dhcp-10-61-110-127.cisco.com [10.61.110.127]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6TGcQrA002585 for <martini@ietf.org>; Thu, 29 Jul 2010 16:38:27 GMT From: Cullen Jennings <fluffy@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jul 2010 18:38:26 +0200 Message-Id: <4B22E796-2E6F-4382-96E3-0CF35F7868CA@cisco.com> To: martini@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [martini] Notes from Martini 78 meeting 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: Thu, 29 Jul 2010 16:38:04 -0000 Here are the notes I took from the meeting. Might help with the minutes. = These notes refer to the text in Adam's slides and make no sense without = the slides. Where I say "Ticket X", I am referring to Adam's slides not = the tracker.=20 Cullen Agreed to change the text in Appendix A so that it matches the text in = requirements specification.=20 No objection to Issue 4 and Issue 5. Ticket #51. Decided that incorrect URI will cause rejection Ticket #54.=20 Everywhere we have BNC before another term, it needs to be defined. On = this issue in #54 reword to be "URI without a BNC" Ticket #55 Agreement in principal, but like to add "some future extenuation" to the = crazy sentence Adam proposed in the slide.=20 Ticket #56.=20 Agreed on Proposal #1 and #2. Will return an existing 500 class = response.=20 Ticket #57. If the PBX asks for a GRUU, and it supports GIN, then the SSP MUST = return one.=20 Olive ------------------------------------------ About 10 people thought that it was worth working on a solution to alpha = names like "bob@example.com" Suggestion to split into two documents. One for "bob" and one for "1234"=20= Vermouth ------------------------------------------ Normal subscription get routed to the PBX.=20 Seemed to be general support for a new event package.=20 Afternoon Session on Temp GRUU in GIN ----------------------- Agreed to add text Adam had on slide. =20