From ietf.hanserik@gmail.com Mon May 3 06:21:37 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 7EBB728C1E0 for ; Mon, 3 May 2010 06:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_05=-1.11, J_CHICKENPOX_57=0.6] 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 jAnJwzwNZlb0 for ; Mon, 3 May 2010 06:21:36 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 3441628C1A1 for ; Mon, 3 May 2010 06:19:42 -0700 (PDT) Received: by ewy24 with SMTP id 24so610572ewy.33 for ; Mon, 03 May 2010 06:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=D3jMDIUZRGcHKQUyM7t2tuYpzbPPt8XFUxWUnO0TrCo=; b=jBmLMYZAp+mjf5tl8pym7T27SvNiWukEBIrmwaOHzrwrmf5HUp/8v4+Xndv3XYAcTh VnjcPAm0r9K8L2KsrbDLoMOwxW8+5+bIJRURRC+tYe2ZZR5sDzAf230rT/PKjFF1tD4L PlT4ytPZDPr45OCLcEu7b+EjfPOkhzAWysLnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oMY957mxcPOvj3E/1ymGOsmJwvU50pxKPB6mgEBxDVzz6UheA6FSJfVLT44WGv6ZWo cxkZvpwJQAXCG45Uhb0kGAy+TCxHrge3lF0IBo1kw+YlRbp6NfKzdPwfwuLZunIQa3sh 8dAqNCSzvGH50HdO6+2eoO45e3k5+mxSbSjHo= MIME-Version: 1.0 Received: by 10.213.65.74 with SMTP id h10mr1326869ebi.60.1272892759752; Mon, 03 May 2010 06:19:19 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 06:19:19 -0700 (PDT) In-Reply-To: References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> Date: Mon, 3 May 2010 15:19:19 +0200 Message-ID: From: Hans Erik van Elburg To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 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 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, 03 May 2010 13:21:37 -0000 It is not clear what you are referring to as a shared understanding, so it is hard to answer that question. I am not sure there exists such shared understanding yet. /Hans Erik van Elburg On Tue, Apr 27, 2010 at 2:23 AM, Bernard Aboba wrote: > Spencer said: > > "Speaking as co-chair... > > Should that shared understanding go in the (various) solution drafts?" > > [BA] I would think that it should go somewhere, certainly. From ietf.hanserik@gmail.com Mon May 3 06:32:53 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 DA1D43A6CC5 for ; Mon, 3 May 2010 06:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 FxUwCjj9pDQV for ; Mon, 3 May 2010 06:32:53 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 7414628C197 for ; Mon, 3 May 2010 06:32:46 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so103976eyf.51 for ; Mon, 03 May 2010 06:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lGK5yGMpnPkUQzDbR1UYeOnvi4oKitv609kou54cqPQ=; b=my7DfEaesI9pHOPar1nRAuIrGeW2ZTMU20iVea0LEUiJs64I0faXwiA583yGcCPNVU x1ibeyixAtzg5VrLC9o+eQXh34vi9EoOC8bjxgygPDOyucTa+7FRJutwZ084qkVHtkHt zQAThmvX8CXyW0pfhTOdp9D+9j2APyg+vwxyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Sou+rajtSPs9VMJuPm2XPRILKleMOI0kZ1cHQI5uDWn7PUJf6Cyk4vr5+3XT2c3HMm fScqLKg6ObzdyDKlNJBkhucJQvWJYtn2rmYcDbeQ8q2AKlwwsVfQRte0eZdEiIqcD0eJ kPDd7nSIJ73kxizlycw8t0bje9kXLZjYJy4/w= MIME-Version: 1.0 Received: by 10.213.47.195 with SMTP id o3mr1285366ebf.48.1272893548859; Mon, 03 May 2010 06:32:28 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 06:32:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 15:32:28 +0200 Message-ID: From: Hans Erik van Elburg To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: martini@ietf.org Subject: Re: [martini] FW: Notes from Martini Virtual Interim IV 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, 03 May 2010 13:32:54 -0000 On Sat, May 1, 2010 at 12:30 AM, Bernard Aboba wrote: > > 1. Requirements discussion led by John Elwell ... > Keith - there is also a desire that these requirements can be supported by > MARTINI GIN extension, and not a whole new solution. Bernard - such a change > would require a MARTINI charter change. Someone - (who?) doesn't agree this > is a charter change. s/"Someone"/"Hans Erik" /Hans Erik From spencer@wonderhamster.org Mon May 3 07:14:27 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 8290C3A6CE0 for ; Mon, 3 May 2010 07:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_50=0.001, J_CHICKENPOX_57=0.6, 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 PbbMKpx3QtDx for ; Mon, 3 May 2010 07:14:26 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 8E4003A682E for ; Mon, 3 May 2010 07:14:26 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MUHYA-1NzYVA2Yew-00R4Pc; Mon, 03 May 2010 10:13:56 -0400 Message-ID: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> From: "Spencer Dawkins" To: "Hans Erik van Elburg" , "Bernard Aboba" References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> Date: Mon, 3 May 2010 09:13:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/W0VbWHN4uH5er6nMxRpp38Ne9wdHuQ/wgLru 9f+3GeJpAdNfYDBChoULazSoYMbFBthwEPXW1fKPofeV4Kb03e S91BrBWL43C2Q2zWRMMIwnwOsFSheyyLWpJHzbxGG4= 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 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, 03 May 2010 14:14:27 -0000 Hi, Hans Erik, This pointed back to http://www.ietf.org/mail-archive/web/martini/current/msg01418.html, which referenced http://www.ietf.org/mail-archive/web/martini/current/msg01410.html - either a bulk registration "acts exactly like" a whole bunch of individual registrations, or it doesn't. We've spent a fair amount of time cycling on this as a working group - that's what I'd like to close on and document. Spencer > It is not clear what you are referring to as a shared understanding, > so it is hard to answer that question. I am not sure there exists such > shared understanding yet. > > /Hans Erik van Elburg > > On Tue, Apr 27, 2010 at 2:23 AM, Bernard Aboba > wrote: >> Spencer said: >> >> "Speaking as co-chair... >> >> Should that shared understanding go in the (various) solution drafts?" >> >> [BA] I would think that it should go somewhere, certainly. From ietf.hanserik@gmail.com Mon May 3 07:30:27 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 97C3D28C1DC for ; Mon, 3 May 2010 07:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_05=-1.11, J_CHICKENPOX_57=0.6] 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 VM2AZviCzZ1v for ; Mon, 3 May 2010 07:30:25 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 858DC28C1D6 for ; Mon, 3 May 2010 07:30:25 -0700 (PDT) Received: by ewy24 with SMTP id 24so632100ewy.33 for ; Mon, 03 May 2010 07:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=iuVBGIdOFGc7rVjb3bDg2hNM430XHTlqNzpQ/tTePAc=; b=EVUsnaBkUffZnl1oGT4cP1GzV2qe2eFo9z4bRh1YczYCApIbdp8Hzg3smSlATQW/CH isBfIZsUVglgc4IbqLO2bDWt2UjeVs6sRKgvc1BGLbMgc5l9LD0cqSuWYHu4yTVzh4Fr O6q8eUrw+2tZvQRgj/iPHt2CyUGuh1e3vbc/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GCGlpF7bQ6NDtOqKA++OpgTsHu77xlZzGIllO+W7CT2+RQFp/i4bMm8AHiq4K2olhK Baez0gHYibay+iibBox1B9q3w4X6Q8mb7oVup1zQclnfmSEnBWvB9eSZFRcy3yWw90kW UWTVDjWT/zE15dOvB3iPHQmfh/3OXmufYMYok= MIME-Version: 1.0 Received: by 10.213.46.133 with SMTP id j5mr1470491ebf.66.1272897007545; Mon, 03 May 2010 07:30:07 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 07:30:07 -0700 (PDT) In-Reply-To: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> Date: Mon, 3 May 2010 16:30:07 +0200 Message-ID: From: Hans Erik van Elburg To: Spencer Dawkins Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernard Aboba , 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 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, 03 May 2010 14:30:27 -0000 It doesn't. The question is, if it is a relevant criterion at all. Sure a particular solution can document that it has that property, fine. /Hans Erik van Elburg On Mon, May 3, 2010 at 4:13 PM, Spencer Dawkins wrote: > Hi, Hans Erik, > > This pointed back to > http://www.ietf.org/mail-archive/web/martini/current/msg01418.html, which > referenced > http://www.ietf.org/mail-archive/web/martini/current/msg01410.html - either > a bulk registration "acts exactly like" a whole bunch of individual > registrations, or it doesn't. We've spent a fair amount of time cycling on > this as a working group - that's what I'd like to close on and document. > > Spencer > > >> It is not clear what you are referring to as a shared understanding, >> so it is hard to answer that question. I am not sure there exists such >> shared understanding yet. >> >> /Hans Erik van Elburg >> >> On Tue, Apr 27, 2010 at 2:23 AM, Bernard Aboba >> wrote: >>> >>> Spencer said: >>> >>> "Speaking as co-chair... >>> >>> Should that shared understanding go in the (various) solution drafts?" >>> >>> [BA] I would think that it should go somewhere, certainly. > > From HKaplan@acmepacket.com Mon May 3 07:52:39 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 4EDE428C20A for ; Mon, 3 May 2010 07:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 tK9Zirah5Hn1 for ; Mon, 3 May 2010 07:52:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6D8B628C205 for ; Mon, 3 May 2010 07:52:38 -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; Mon, 3 May 2010 10:52:23 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 3 May 2010 10:52:23 -0400 From: Hadriel Kaplan To: "martini@ietf.org" Date: Mon, 3 May 2010 10:52:19 -0400 Thread-Topic: draft-kaplan-martini-with-olive-01 posted Thread-Index: Acrq0DrNfnqIt2G7S6qruTIq7V4pzg== Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1AD9@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: [martini] draft-kaplan-martini-with-olive-01 posted 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, 03 May 2010 14:52:39 -0000 Howdy, An updated olive-draft has been posted. -hadriel A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP MARTINI with Other Logical Identifier Values which a= re not E.164 (OLIVE) Author(s) : H. Kaplan, et al. Filename : draft-kaplan-martini-with-olive-01.txt Pages : 18 Date : 2010-05-03 The Martini Working Group is defining a mechanism for SIP IP-PBX type devic= es to REGISTER and obtain SIP service for E.164-based Address of Records. = This document defines a means for other, non- E.164 AoRs of the Registered-to SSP's domain to be used with Martini-based = IP-PBXs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-martini-with-olive-01.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 implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From ietf.hanserik@gmail.com Mon May 3 08:36: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 90F9A3A6CAE for ; Mon, 3 May 2010 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=-0.771, 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 JHMrgTXKF4VG for ; Mon, 3 May 2010 08:36:22 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id DF9D23A6D27 for ; Mon, 3 May 2010 08:36:17 -0700 (PDT) Received: by ewy24 with SMTP id 24so653391ewy.33 for ; Mon, 03 May 2010 08:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BDP1z+Hyh/nba1nQuyYoheALmC48WuKxN0x1e5k2WRM=; b=O5bsfvyvborTY8+nY8rdeEQiBaII9WoQA8PIWKEclxAdCLVbPF4EheGI5zmFJ9mNnp 9HShb6NteMB17uujgVtmUk3+dax5+kLJfUxspuJDv7VU95jipRGRietMDmS8Jm/Th/gP Hlp+Q+7EzclK9In8mTX613bDsaauUMXcKZdwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ClAMhOfUQ+vvbPUtpG2rSFBBkNvmyjkUE+QmqDLjWv+7ubWifs09H7WJOaMgmX4mAy NQELJ4Bd5Pya6l2GubSD1+5BIsYLbrvDcG3m/kdElQ1wEj3aSJnwcxFgOuDyvFOPRjP/ SlhtV9IMeNc+NxgRtG1HYsbOTq3D01A3GcRKY= MIME-Version: 1.0 Received: by 10.213.1.215 with SMTP id 23mr1273313ebg.88.1272900960052; Mon, 03 May 2010 08:36:00 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 08:36:00 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06BE19@mail> References: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> <085.ceee3770ac403db1e4a00bf5702eaea8@tools.ietf.org> <430FC6BDED356B4C8498F634416644A91A7A06BE19@mail> Date: Mon, 3 May 2010 17:36:00 +0200 Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 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, 03 May 2010 15:36:23 -0000 Typical use of this reg-event package seems to be that the UA (PBX) can be notified that it is being deregistered by the SSP. For example for reauthentication purposes. So I do think you have a point but for other reasons then you give ;-) /Hans Erik van Elburg On Fri, Apr 23, 2010 at 5:16 PM, Hadriel Kaplan wr= ote: > > Huh. =A0This is an interesting issue, because I think it means the bulk r= egistration is not just a short-hand for multiple unique registrations. > > What I mean is that I was assuming the bulk REGISTER was just a collapsed= /compressed form of separate Registrations, and that it really does registe= r contacts for separate AoRs, which really are the SSP's AoRs, as in "sip:+= 12345@ssp.com". =A0And the SSP Registrar really does have registration stat= e for that AoR: one that has the expanded contact of the PBX, an expires of= the bnc REGISTER, etc. > > If that's true, I don't see why a SUBSCRIBE to "sip:+12345@ssp.com" for r= eg-event should be automatically contact-routed to the PBX. =A0It wouldn't = have been if the registered AoR was "sip:bob@ssp.com", for example. > > If the subscriber is asking for the reg-event state of "sip:+12345@ssp.co= m", then that's what it should get. =A0It may, upon learning the registered= contact, send another SUBSCRIBE to the contact itself, which would go to t= he PBX, but that's a different target. > > -hadriel > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Beha= lf >> Of martini issue tracker >> Sent: Monday, April 19, 2010 6:13 PM >> To: adam@nostrum.com >> Cc: martini@ietf.org >> Subject: Re: [martini] #36: Reg-event package and individual extension >> state (section 7.2.2) >> >> #36: Reg-event package and individual extension state (section 7.2.2) >> ------------------------------------------------+-----------------------= -- >> -- >> =A0Reporter: =A0john.elwell@... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 | =A0 =A0 =A0 =A0Owner: >> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 Status: =A0closed >> =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 =A0Milestone: >> milestone1 >> Component: =A0gin =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 =A0 =A0Version: >> =A0Severity: =A0Active WG Document =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 Resolution: =A0fixed >> =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0| >> ------------------------------------------------+-----------------------= -- >> -- >> Changes (by adam@...): >> >> =A0 * status: =A0new =3D> closed >> =A0 * resolution: =A0=3D> fixed >> >> >> Comment: >> >> =A0This is mostly correct. There's nothing that says that the SSP can't,= for >> =A0example, act as a presence server for the users behind the PBX. That >> would >> =A0be something that the SSP and PBX owners would need to agree on, of >> =A0course. However, you are correct in pointing out that the behavior in >> =A07.2.2 is a reiteration of the generally expected behavior described i= n >> =A0section 6. This will be clarified as follows: >> >> =A0 =A0 =A0 =A0 =A0 =A0As described in section 6, the >> =A0 =A0 =A0 =A0 =A0 =A0SSP will generally retarget all requests addresse= d to >> =A0 =A0 =A0 =A0 =A0 =A0a phone number owned by a PBX to that PBX accordi= ng >> =A0 =A0 =A0 =A0 =A0 =A0to the mapping established at registration time. >> =A0 =A0 =A0 =A0 =A0 =A0Although policy at the SSP may override this gene= rally >> =A0 =A0 =A0 =A0 =A0 =A0expected behavior, proper behavior of the registr= ation >> =A0 =A0 =A0 =A0 =A0 =A0event package requires that all "reg" event SUBSC= RIBE >> =A0 =A0 =A0 =A0 =A0 =A0requests are processed by the PBX. As a consequen= ce, >> =A0 =A0 =A0 =A0 =A0 =A0the requirements on an SSP for processing registr= ation >> =A0 =A0 =A0 =A0 =A0 =A0event package SUBSCRIBE requests are not left to = policy. >> >> =A0This also highlights the fact that there are no normative requirement= s to >> =A0handle INVITE in this way -- I've added some text to section 6 to bot= h >> =A0clarify that the processing generally applies to any method, and that= it >> =A0is mandatory for INVITE. >> >> -- >> Ticket URL: >> >> 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 spencer@wonderhamster.org Mon May 3 09:44:36 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 B17B828C22C for ; Mon, 3 May 2010 09:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_50=0.001, J_CHICKENPOX_57=0.6, 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 mdvceP8rGJH7 for ; Mon, 3 May 2010 09:44:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id B9E423A6A3B for ; Mon, 3 May 2010 09:44:35 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mgsiu-1NmtUM0spU-00M4IC; Mon, 03 May 2010 12:44:11 -0400 Message-ID: <480951BB4EC045799A62BA2973A0AF31@china.huawei.com> From: "Spencer Dawkins" To: "Hans Erik van Elburg" References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> Date: Mon, 3 May 2010 11:44:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18CHBJN/+WQTyV0i1tvQ2aB2fYfYlki4IDdIpG jXnmyq9WZFskUdzyqhshMhZIHu6yUKKuR3yARQE7K9C9EQbLZB 6A594rRULEMUXQSP/1NdB2MIudnWB9jnP9B8PTNTQk= Cc: Bernard Aboba , 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 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, 03 May 2010 16:44:36 -0000 Hi, Hans Erik, Speaking as a participant, I agree, and speaking as co-chair, I think that's where the working group is on this topic. Again, speaking as co-chair, my concern (and I BELIEVE that Bernard shares this concern, although he can school me about this if I got it wrong), is that as long as we haven't documented that consensus, we'll continue to cycle on this question, probably at the most inconvenient time (like, for example, IETF Last Call time for a specific solution draft). That's the reason for my question, which I think is starting to turn into a co-chair suggestion to the editor for the requirements document, unless the working group disagrees - but I want to ask the working group, before telling the editor anything. Spencer > It doesn't. > > The question is, if it is a relevant criterion at all. Sure a > particular solution can document that it has that property, fine. > > /Hans Erik van Elburg > > On Mon, May 3, 2010 at 4:13 PM, Spencer Dawkins > wrote: >> Hi, Hans Erik, >> >> This pointed back to >> http://www.ietf.org/mail-archive/web/martini/current/msg01418.html, which >> referenced >> http://www.ietf.org/mail-archive/web/martini/current/msg01410.html - >> either >> a bulk registration "acts exactly like" a whole bunch of individual >> registrations, or it doesn't. We've spent a fair amount of time cycling >> on >> this as a working group - that's what I'd like to close on and document. >> >> Spencer >> >> >>> It is not clear what you are referring to as a shared understanding, >>> so it is hard to answer that question. I am not sure there exists such >>> shared understanding yet. >>> >>> /Hans Erik van Elburg >>> >>> On Tue, Apr 27, 2010 at 2:23 AM, Bernard Aboba >>> wrote: >>>> >>>> Spencer said: >>>> >>>> "Speaking as co-chair... >>>> >>>> Should that shared understanding go in the (various) solution drafts?" >>>> >>>> [BA] I would think that it should go somewhere, certainly. >> >> From HKaplan@acmepacket.com Mon May 3 12:07:40 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 D76703A6928 for ; Mon, 3 May 2010 12:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] 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 VtqaYhtPn3XQ for ; Mon, 3 May 2010 12:07:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 05AF33A694A for ; Mon, 3 May 2010 12:07:39 -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; Mon, 3 May 2010 15:07:23 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 3 May 2010 15:07:23 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , Spencer Dawkins Date: Mon, 3 May 2010 15:07:22 -0400 Thread-Topic: [martini] #36: Reg-event package and individual extension state(section 7.2.2) Thread-Index: AcrqzTtDdtHJEwWxQFuyXjbCT/jQqgAJpY4w Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> 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 Cc: Bernard Aboba , "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 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, 03 May 2010 19:07:41 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Hans Erik van Elburg > Sent: Monday, May 03, 2010 10:30 AM >=20 > It doesn't. In what way doesn't it? -hadriel From HKaplan@acmepacket.com Mon May 3 12:27:36 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 55B433A6AD5 for ; Mon, 3 May 2010 12:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 oZ+0Kmu6LFsa for ; Mon, 3 May 2010 12:27:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6EE603A6A29 for ; Mon, 3 May 2010 12:27:35 -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; Mon, 3 May 2010 15:27:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 3 May 2010 15:27:20 -0400 From: Hadriel Kaplan To: "martini@ietf.org" Date: Mon, 3 May 2010 15:27:18 -0400 Thread-Topic: draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive Thread-Index: Acrq9qUxG4fe2zfZQimHUHvKYklVcQ== Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@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: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive 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, 03 May 2010 19:27:36 -0000 Howdy, I have submitted a new draft strawman proposal for reg-event which tries to= accomplish the following: 1) Gives reg-event for open-numbering-plans 2) Subscribes for AoRs *in* the PBX, vs. just SSP's 3) Subscribes for all implicitly registered AoRs (e.g., so PBX can check it= ) 4) Creates an acronym for Vermouth Any comments/flames welcomed. -hadriel A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP MARTINI Variant of 'Event-package for Registrations'= for Managed Open-ended Username Target Handling (VERMOUTH) Author(s) : H. Kaplan, et al. Filename : draft-kaplan-martini-vermouth-00.txt Pages : 19 Date : 2010-05-03 The Martini Working Group is defining a mechanism for SIP IP-PBX type devic= es to REGISTER and obtain SIP service for E.164-based Address of Records, i= n [draft-gin]. Another draft [draft-olive] proposes the same for non-E.164= -based AoRs. This document defines a variant of the Registration Event-pac= kage [reg-event] for open-ended AoRs for either mechanisms, using a wildcar= d syntax and specific target handling rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-martini-vermouth-00.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 implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From ietf.hanserik@gmail.com Mon May 3 12:33:42 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 2874D3A6AD5 for ; Mon, 3 May 2010 12:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] 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 NtGUgjKtm72v for ; Mon, 3 May 2010 12:33:41 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id D4EF53A6ADC for ; Mon, 3 May 2010 12:33:40 -0700 (PDT) Received: by ewy24 with SMTP id 24so768930ewy.33 for ; Mon, 03 May 2010 12:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zyYawt4WfOpG4sv2u744Ah+7NalnfA4xOt2a+4ln2ak=; b=QGCsgXI0JZPQ0GmjFo5jCBg5fxXhNNtBaZOh8Vx01o7/KVvWvWRe2YFMPmZfOuRklV 8U9+mL0M1M+NmxA4QS8frI5t9ttDwSAm34Wa5NNDDkGFC+Jgst0yYaIpzStg6j4YD+hd j5gWI2tbV3wuMTlm2dkCLaxfwx3XfJSt4yIEA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bBN/YBxMy9hp+T4LABAoVQg2yzTbASQKBEjLrUHh2P+IpVnnz9hDRfU4LJCbMqbo28 evbZuAUqvCjlsEyTLQ+rxjVB1ofVLjLcEKk/FQgx3R46hH2iTzSLuc0ukAbvRyTBRSRv /k7zjUFxhOSh/U8nFl9i0jCMuB+2sLKIOgbUw= MIME-Version: 1.0 Received: by 10.213.54.205 with SMTP id r13mr5879343ebg.79.1272915202496; Mon, 03 May 2010 12:33:22 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 12:33:22 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> Date: Mon, 3 May 2010 21:33:22 +0200 Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernard Aboba , "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 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, 03 May 2010 19:33:42 -0000 On Mon, May 3, 2010 at 9:07 PM, Hadriel Kaplan wrote: >> >> It doesn't. > > In what way doesn't it? > In the way that a bulk registration does not have to "act exactly like" a whole bunch of individual registrations and most probably won't. /Hans Erik van Elburg From HKaplan@acmepacket.com Mon May 3 13:24:08 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 E7EF928C2CE for ; Mon, 3 May 2010 13:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] 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 Zl5mhMC+9YGn for ; Mon, 3 May 2010 13:24:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 623E028C2CC for ; Mon, 3 May 2010 13:22:41 -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; Mon, 3 May 2010 16:22:26 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 3 May 2010 16:22:26 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , Spencer Dawkins Date: Mon, 3 May 2010 16:22:25 -0400 Thread-Topic: [martini] #36: Reg-event package and individual extension state(section 7.2.2) Thread-Index: AcrqzTtDdtHJEwWxQFuyXjbCT/jQqgAJswyw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1C0B@mail> References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> 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 Cc: Bernard Aboba , "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 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, 03 May 2010 20:24:08 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Hans Erik van Elburg > Sent: Monday, May 03, 2010 10:30 AM >=20 > The question is, if it is a relevant criterion at all. Sure a > particular solution can document that it has that property, fine. I think it's pretty important to know what the bulk REGISTER does from a lo= gical perspective. A case in point is the reg-event handling. =20 We either say "it is exactly a compressed form of multiple distinct REGISTE= Rs for each AoR", or else we have to define exactly what it does mean, so t= hat any and all uses of it can be discerned - if any future work done in DI= SPATCH/whatever deals with registered UA's explicitly, then it would have t= o take this "Registration of AoRs which is sort-of but not really a Registr= ation of AoRs" into account as well. =20 There're pro's/con's for dealing with it as a compressed form vs. some hybr= id, but we do need to decide what it really is and document it. -hadriel From trac@tools.ietf.org Mon May 3 13:33:14 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 5CBA33A68F5 for ; Mon, 3 May 2010 13:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, 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 bz27+WWCH+uj for ; Mon, 3 May 2010 13:33:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 164353A6807 for ; Mon, 3 May 2010 13:33:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O92K2-0005Il-HL; Mon, 03 May 2010 13:32:58 -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.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Mon, 03 May 2010 20:32:57 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/41 Message-ID: <064.c7f9b407eec269da298fd711cd7baeaa@tools.ietf.org> X-Trac-Ticket-ID: 41 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] #41: What happens to a "presence" Subscription for an E.164 AoR? 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, 03 May 2010 20:33:14 -0000 #41: What happens to a "presence" Subscription for an E.164 AoR? ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Does a SUBSCRIBE for the "presence" package targeted to "sip:+1234567@ssp.com" get contact-routed to the IP-PBX, or processed by the SSP's presence servers? -- Ticket URL: martini From trac@tools.ietf.org Mon May 3 13:37: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 DDCCC3A688E for ; Mon, 3 May 2010 13:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, 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 GkQm0pdaYNwp for ; Mon, 3 May 2010 13:37:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3EF0F3A6B04 for ; Mon, 3 May 2010 13:37:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O92Nq-0005XR-Jk; Mon, 03 May 2010 13:36:54 -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.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Mon, 03 May 2010 20:36:54 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/42 Message-ID: <064.cc4bd224fb47783459292c826cf7630f@tools.ietf.org> X-Trac-Ticket-ID: 42 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] #42: Do Contact feature-tags apply to all expanded contacts? 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, 03 May 2010 20:37:13 -0000 #42: Do Contact feature-tags apply to all expanded contacts? ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Do feature-tags (RFC 3840) in the Contact of a bulk REGISTER apply to all the expanded Contacts, or just to the IP-PBX? I think it applies to all, but whatever the answer is it should be covered in draft-gin text, just to be clear. -- Ticket URL: martini From trac@tools.ietf.org Mon May 3 13:42:03 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 E15913A6A39 for ; Mon, 3 May 2010 13:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, 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 id14TrYBmYKJ for ; Mon, 3 May 2010 13:42:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 042FC3A69C2 for ; Mon, 3 May 2010 13:42:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O92Sb-0006GF-3F; Mon, 03 May 2010 13:41: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.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Mon, 03 May 2010 20:41:49 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/43 Message-ID: <064.dc530b9ba5e66b0cf7f07120a5680d5d@tools.ietf.org> X-Trac-Ticket-ID: 43 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] #43: Do option-tags in REGISTER apply for all expanded Contacts? 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, 03 May 2010 20:42:04 -0000 #43: Do option-tags in REGISTER apply for all expanded Contacts? ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- If the REGISTER request has option-tag "foo", does "foo" apply to all expanded Registered contacts? For example "ice", or any future option- tag. Need to document the answer to this in draft-gin. -- Ticket URL: martini From adam@nostrum.com Mon May 3 14:25:51 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 919623A68BB for ; Mon, 3 May 2010 14:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.126, 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 3edsbQBLir4q for ; Mon, 3 May 2010 14:25:50 -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 ACA033A6A9A for ; Mon, 3 May 2010 14:25: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 o43LPQKr051519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 16:25:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BDF3F45.4050005@nostrum.com> Date: Mon, 03 May 2010 16:25:25 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: hkaplan@acmepacket.com References: <064.c7f9b407eec269da298fd711cd7baeaa@tools.ietf.org> In-Reply-To: <064.c7f9b407eec269da298fd711cd7baeaa@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] #41: What happens to a "presence" Subscription for an E.164 AoR? 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, 03 May 2010 21:25:51 -0000 On 5/3/10 3:32 PM, martini issue tracker wrote: > #41: What happens to a "presence" Subscription for an E.164 AoR? > ------------------------------------+--------------------------------------- > Reporter: hkaplan@… | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: milestone1 > Component: gin | Version: 1.0 > Severity: Active WG Document | Keywords: > ------------------------------------+--------------------------------------- > Does a SUBSCRIBE for the "presence" package targeted to > "sip:+1234567@ssp.com" get contact-routed to the IP-PBX, or processed by > the SSP's presence servers? > Given that non-gin implementations have alternately chosen to handle presence in servers or at the endpoint, I would argue that this question verges on metaphysical. SIP presence in general leaves this open to network policy. I think that's still the correct answer here. /a From adam@nostrum.com Mon May 3 14:37:10 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 37F443A693F for ; Mon, 3 May 2010 14:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, 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 VNDlD-xjftWU for ; Mon, 3 May 2010 14:37:09 -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 1AFC03A6922 for ; Mon, 3 May 2010 14:37:08 -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 o43LaqdT052492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 16:36:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BDF41F4.7000802@nostrum.com> Date: Mon, 03 May 2010 16:36:52 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: hkaplan@acmepacket.com References: <064.cc4bd224fb47783459292c826cf7630f@tools.ietf.org> In-Reply-To: <064.cc4bd224fb47783459292c826cf7630f@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] #42: Do Contact feature-tags apply to all expanded contacts? 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, 03 May 2010 21:37:10 -0000 On 5/3/10 3:36 PM, martini issue tracker wrote: > #42: Do Contact feature-tags apply to all expanded contacts? > ------------------------------------+--------------------------------------- > Reporter: hkaplan@… | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: milestone1 > Component: gin | Version: 1.0 > Severity: Active WG Document | Keywords: > ------------------------------------+--------------------------------------- > Do feature-tags (RFC 3840) in the Contact of a bulk REGISTER apply to all > the expanded Contacts, or just to the IP-PBX? I think it applies to all, > but whatever the answer is it should be covered in draft-gin text, just to > be clear. > I agree on both points. /a From adam@nostrum.com Mon May 3 14:38:26 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 AE0A13A6861 for ; Mon, 3 May 2010 14:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.119, 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 5wb7ktSQaeoh for ; Mon, 3 May 2010 14:38:26 -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 636AE28C2D4 for ; Mon, 3 May 2010 14:38:25 -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 o43Lc8wY052558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 16:38:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BDF4240.2040405@nostrum.com> Date: Mon, 03 May 2010 16:38:08 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: martini issue tracker References: <064.dc530b9ba5e66b0cf7f07120a5680d5d@tools.ietf.org> In-Reply-To: <064.dc530b9ba5e66b0cf7f07120a5680d5d@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] #43: Do option-tags in REGISTER apply for all expanded Contacts? 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, 03 May 2010 21:38:26 -0000 On 5/3/10 3:41 PM, martini issue tracker wrote: > #43: Do option-tags in REGISTER apply for all expanded Contacts? > ------------------------------------+--------------------------------------- > Reporter: hkaplan@… | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: milestone1 > Component: gin | Version: 1.0 > Severity: Active WG Document | Keywords: > ------------------------------------+--------------------------------------- > If the REGISTER request has option-tag "foo", does "foo" apply to all > expanded Registered contacts? For example "ice", or any future option- > tag. Need to document the answer to this in draft-gin. > Considering, say, "path" and "service-route", I think the answer is pretty clearly "yes." I agree this should be explicit. /a From ietf.hanserik@gmail.com Mon May 3 14:43:29 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 BFC8D28C2FC for ; Mon, 3 May 2010 14:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 uUL+pnr2NiIr for ; Mon, 3 May 2010 14:43:28 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id AE57128C2F5 for ; Mon, 3 May 2010 14:43:24 -0700 (PDT) Received: by ewy24 with SMTP id 24so827344ewy.33 for ; Mon, 03 May 2010 14:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OVQ+yDEe/oh8muoghGsXGPOQQvRPxLNuxG49TvzHer4=; b=MRPXrFT93TSvpaA615JIPj2AEs58jZCH02TH2pLtnonaHqp/D0vD8QI3aj4urHRyXu h136QcyRm47hXjVIZ3mTdQU+NZWflsTAGimduC3737Cd3QJUyM6zS4M4YfPa6UXICoEN yK9vZ1/WQQQtOxzn+xRhzGkBYxD5jhKd40egQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GoGGw9C5V+AG7QBXjp7YAe4w18vn1gE7OduMhppmDjX3g3QradYOZrLfOnn4J3/9UU FXhRNF7tmCWAG2PEVEgA/Uw9+os0VvAnAnHblAtL12NCPadzKBvlrt3333IZ2/bwCDOA lk/y7Gzz7d9w7KfmBr2VZ7cO8NUzDuUYfL9X4= MIME-Version: 1.0 Received: by 10.213.78.140 with SMTP id l12mr1439264ebk.15.1272922986555; Mon, 03 May 2010 14:43:06 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 14:43:06 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@mail> References: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@mail> Date: Mon, 3 May 2010 23:43:06 +0200 Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive 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, 03 May 2010 21:43:29 -0000 There is some valid ideas in this and with some work it could be made to work with several different mechanisms. This does not have to be gin specific. Some issues/questions: - the use of the bnc tag to address the AOR behind the PBX seems counterintuitive, as one is in fact in this case addressing a normal registration... - the use of a special tag to mint subscription requests to address the AOR behind the PBX assumes knowledge at the subscriber about the AOR's terminating arrangement. This is in general problematic. As such arrangement should be possible to be freely changed by the receiving company, without notifying potential originators. Not to mention the security issues with revealing the connection topology. - can there be more range parameters? - can the range parameter be injected at any place in a string or only at the end of the user part? - regarding 5.4 open issue, yes bulk AOR's are only short hand representation of ranges registered. They themselves are not registered and should not be used as AOR's themselves and therefore section 5.4 should be removed. And some statement should be made somewhere that bulk AOR's can not be used as normal AOR's. In IMS we call this wildcarded PUI and those can only be used to match distinct PUI's with, same here maybe it is better to talk about wildcarded AOR's as it expresses this property better. - statements (for ex. 5.1) like "Any internal optimization performed by the SSP location-service database for handling Bulk-AoRs MUST NOT change this external behavior. " Are not referring to the SUBSCRIBE mechanism and therefore inappropriate repetition of an opinion in this draft ;-) - Appendix A: While I have no problem with simplifying the pattern, to enable less configuration errors and complaince with RFC3261. You bring back here the issue of automatically detecting provisioning mismatches by the PBX. Is this based on something you have seen in practice? Why would this be an issue at all? Even in the simplified case I don not think that an IP-PBX can conclude anything when it has knowledge about the full generated set of AOR's. It suffices to match each configured AOR with the patterns returned. /Hans Erik van Elburg On Mon, May 3, 2010 at 9:27 PM, Hadriel Kaplan wro= te: > > Howdy, > I have submitted a new draft strawman proposal for reg-event which tries = to accomplish the following: > 1) Gives reg-event for open-numbering-plans > 2) Subscribes for AoRs *in* the PBX, vs. just SSP's > 3) Subscribes for all implicitly registered AoRs (e.g., so PBX can check = it) > 4) Creates an acronym for Vermouth > > Any comments/flames welcomed. > > -hadriel > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SIP MARTINI Variant of 'Event-= package for Registrations' for Managed Open-ended Username Target Handling = (VERMOUTH) > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-martini-vermouth-00= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-03 > > The Martini Working Group is defining a mechanism for SIP IP-PBX type dev= ices to REGISTER and obtain SIP service for E.164-based Address of Records,= in [draft-gin]. =A0Another draft [draft-olive] proposes the same for non-E= .164-based AoRs. =A0This document defines a variant of the Registration Eve= nt-package [reg-event] for open-ended AoRs for either mechanisms, using a w= ildcard syntax and specific target handling rules. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-martini-vermouth-00.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 implemen= tation to automatically retrieve the ASCII version of the Internet-Draft. > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From adam@nostrum.com Mon May 3 14:43:31 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 8F72728C2F7 for ; Mon, 3 May 2010 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 0i0l+xYxqY6S for ; Mon, 3 May 2010 14:43:31 -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 DC60B28C2FB for ; Mon, 3 May 2010 14:43:26 -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 o43Lh8j9052937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 16:43:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BDF436C.7010803@nostrum.com> Date: Mon, 03 May 2010 16:43:08 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hans Erik van Elburg References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> 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: Bernard Aboba , "martini@ietf.org" , Hadriel Kaplan 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 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, 03 May 2010 21:43:31 -0000 On 5/3/10 2:33 PM, Hans Erik van Elburg wrote: > On Mon, May 3, 2010 at 9:07 PM, Hadriel Kaplan wrote: > >>> It doesn't. >>> >> In what way doesn't it? >> >> > In the way that a bulk registration does not have to "act exactly > like" a whole bunch of individual registrations and most probably > won't. > This is becoming as clear as mud. What property are you proposing the solution should exhibit? Can you propose some text? /a From ietf.hanserik@gmail.com Mon May 3 14:48:25 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 B3FBF28C2F1 for ; Mon, 3 May 2010 14:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] 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 O8dEeMQ-HaOP for ; Mon, 3 May 2010 14:48:25 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id BECA83A6988 for ; Mon, 3 May 2010 14:48:24 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so138743eyf.51 for ; Mon, 03 May 2010 14:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y92Vri82UKhq4yfH2jWR+AuQPbfplZJKqa3FGoyRZqc=; b=MqmjTyMMV9//TJjB4wOZKY49pBv8WHSj5bX9T9AOmXLWFsC+W4wqSm5MSbMbyEPMmf fmN7oqi1KLd/RB7N2qG4rqvrGzTY9Jsatd+h/E3Sp/zgHP5bcj1i99YGmiyOv80ygMQ9 7PG+iTKumMpAjuOfXwPsSMlhOQFxs79Juenps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G1I5v2OvLkZLwaGbnyV1ybeVxgfs1BqZvx6lyk1rW/kAZ4Zf9jqdYgSwKBGeDZoXRF AOnwcLf+xLIxT12luwwF7QbyQc49uyE4gjvUAqga987dzQWqkwCnWmVfRdHIfODcAyFs cshn1qcj0qD4pjbJQLFKiB2zD6HgcTB15xalo= MIME-Version: 1.0 Received: by 10.213.65.202 with SMTP id k10mr1757700ebi.63.1272923287263; Mon, 03 May 2010 14:48:07 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 14:48:07 -0700 (PDT) In-Reply-To: <4BDF436C.7010803@nostrum.com> References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> Date: Mon, 3 May 2010 23:48:07 +0200 Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , "martini@ietf.org" , Hadriel Kaplan 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 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, 03 May 2010 21:48:25 -0000 On Mon, May 3, 2010 at 11:43 PM, Adam Roach wrote: > On 5/3/10 2:33 PM, Hans Erik van Elburg wrote: >> >> On Mon, May 3, 2010 at 9:07 PM, Hadriel Kaplan >> =A0wrote: >> >>>> >>>> It doesn't. >>>> >>> >>> In what way doesn't it? >>> >>> >> >> In the way that a bulk registration does not have to "act exactly >> like" a whole bunch of individual registrations and most probably >> won't. >> > > This is becoming as clear as mud. What property are you proposing the > solution should exhibit? Can you propose some text? > I was responding to Spencer's call for common understanding. I was not proposing any specific change for gin. I agree that this is maybe not the right thread. From adam@nostrum.com Mon May 3 14:56:02 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 9D8D33A6A81 for ; Mon, 3 May 2010 14:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_05=-1.11, J_CHICKENPOX_57=0.6, 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 2Td4o+vnTPaC for ; Mon, 3 May 2010 14:56:02 -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 981B53A6984 for ; Mon, 3 May 2010 14:56:01 -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 o43Lthlv053961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 16:55:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BDF465F.3040104@nostrum.com> Date: Mon, 03 May 2010 16:55:43 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hans Erik van Elburg References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.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: Bernard Aboba , "martini@ietf.org" , Hadriel Kaplan Subject: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) 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, 03 May 2010 21:56:02 -0000 On 5/3/10 4:48 PM, Hans Erik van Elburg wrote: > On Mon, May 3, 2010 at 11:43 PM, Adam Roach wrote: > >> On 5/3/10 2:33 PM, Hans Erik van Elburg wrote: >> >>> On Mon, May 3, 2010 at 9:07 PM, Hadriel Kaplan >>> wrote: >>> >>> >>>>> It doesn't. >>>>> >>>>> >>>> In what way doesn't it? >>>> >>>> >>>> >>> In the way that a bulk registration does not have to "act exactly >>> like" a whole bunch of individual registrations and most probably >>> won't. >>> >>> >> This is becoming as clear as mud. What property are you proposing the >> solution should exhibit? Can you propose some text? >> >> > I was responding to Spencer's call for common understanding. I was not > proposing any specific change for gin. I agree that this is maybe not > the right thread. > Okay, so, in a different thread now: do you have any actionable comments regarding Spencer's call for consensus, or are you simply being contrarian? I believe that the relevant text in GIN is: After the PBX is authenticated, the registrar updates its location service with a unique AOR to Contact mapping for each of the phone numbers associated with the PBX. Semantically, each of these mappings will be treated as a unique row in the location service. The actual implementation may, of course, perform internal optimizations to reduce the amount of memory used to store such information. If you think this is incorrect, please propose a concrete change. /a From ietf.hanserik@gmail.com Mon May 3 15:34: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 6E11D28C265 for ; Mon, 3 May 2010 15:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=-1.511, BAYES_50=0.001, J_CHICKENPOX_57=0.6] 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 XZyRgh19B+DC for ; Mon, 3 May 2010 15:34:29 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 6E2293A698D for ; Mon, 3 May 2010 15:34:29 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so140309eyf.51 for ; Mon, 03 May 2010 15:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MT6USKgxj56n+UBZzt41mgHP5umlNHIKScRSaI5xDLs=; b=d3pbPL7GxMNZhWX6JTvcXa8duztO6RMfI45r/JE6Cic1EkfZopgsvkuF0fQ3tVa0De 3a6isL0SQF82LG6VE14jGQKgdubDdD1VBRB+yVoY7wGzX5Mil4ZidWwRokROEIrS+bUB JOf7VbmJCgNb9oQQIVFBFRfnSEVVv8vjO7b9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QWEVkZVu570G3uhZTEtDxQIBog4UvFu68O8fJOXWoBvrSQasHKrr9eEaor+tzlogMV NpCiyq1xLSNjbJbIz0bEUOnGQpE6iQTAtW1w0f/eGUtDCxd8gqJyWB+9BXbrgLaeBXJw c4TD3kjWZN6pze5utmEa/tbEYcY1JrNe0sO6Y= MIME-Version: 1.0 Received: by 10.213.47.202 with SMTP id o10mr1770319ebf.33.1272926051920; Mon, 03 May 2010 15:34:11 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 15:34:11 -0700 (PDT) In-Reply-To: <4BDF465F.3040104@nostrum.com> References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.com> Date: Tue, 4 May 2010 00:34:11 +0200 Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) 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, 03 May 2010 22:34:30 -0000 I was reacting to Spencers question if martini should agree on a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations criterion that every solution should fulfill. I was saying no it is not a relevant criterion. (If that makes me a contrarian in your world, then so be it.) I also said: "Sure a particular solution can document that it has that property, fine." So if GIN is claiming to have this property then I am fine with that. (Not sure it is true though.) So why do you want me to propose a change to gin in this respect?? /Hans Erik On Mon, May 3, 2010 at 11:55 PM, Adam Roach wrote: >> I was responding to Spencer's call for common understanding. I was not >> proposing any specific change for gin. I agree that this is maybe not >> the right thread. >> > > Okay, so, in a different thread now: do you have any actionable comments > regarding Spencer's call for consensus, or are you simply being contraria= n? > > I believe that the relevant text in GIN is: > > =A0 After the PBX is authenticated, the > =A0 registrar updates its location service with a unique AOR to Contact > =A0 mapping for each of the phone numbers associated with the PBX. > =A0 Semantically, each of these mappings will be treated as a unique row > =A0 in the location service. =A0The actual implementation may, of course, > =A0 perform internal optimizations to reduce the amount of memory used to > =A0 store such information. > > If you think this is incorrect, please propose a concrete change. > > /a > From adam@nostrum.com Mon May 3 16:20:33 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 E40C63A6B81 for ; Mon, 3 May 2010 16:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 dHMtUchx5YRw for ; Mon, 3 May 2010 16:20:32 -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 752FF3A6B54 for ; Mon, 3 May 2010 16:20: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 o43NK59Z060110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 18:20:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BDF5A25.2030208@nostrum.com> Date: Mon, 03 May 2010 18:20:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hans Erik van Elburg References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.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: Bernard Aboba , "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) 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, 03 May 2010 23:20:33 -0000 On 5/3/10 5:34 PM, Hans Erik van Elburg wrote: > I was reacting to Spencers question if martini should agree on > a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations > criterion that every solution should fulfill. > I was saying no it is not a relevant criterion. (If that makes me a > contrarian in your world, then so be it.) > > I also said: "Sure a particular solution can document that it has that > property, fine." > So if GIN is claiming to have this property then I am fine with that. > (Not sure it is true though.) > > So why do you want me to propose a change to gin in this respect?? > The actual question he asked ("Should that shared understanding go in the (various) solution drafts?") was specifically asking about what should or should not go into the solution drafts. GIN is a solutions draft. It sounded to me like you were trying to raise a point on this call for consensus, which I would expect to either take the form of either "yes, we need to add X to the solutions draft" or "no, I don't think we need to make any changes to the solutions draft on this topic." At this point, I think you read Spencer's question as meaning something very different than I did. /a From spencer@wonderhamster.org Mon May 3 18:23:45 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 CA1713A6D51 for ; Mon, 3 May 2010 18:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.164 X-Spam-Level: X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_50=0.001, J_CHICKENPOX_57=0.6] 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 i4jGfQLIKaqg for ; Mon, 3 May 2010 18:23:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id A106128C1B2 for ; Mon, 3 May 2010 18:23:30 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MCt7j-1OH34C3bVb-009g06; Mon, 03 May 2010 21:22:26 -0400 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" , "Hans Erik van Elburg" References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.com> <4BDF5A25.2030208@nostrum.com> Date: Mon, 3 May 2010 20:22:14 -0500 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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+zQ9XiQof42Kkxbs74wU8vN7d8N8ch3fySJtN KOR7TM9Zi6WzAYGd7mOdOVXZ0KfONSAgDv4qd6vE5avOZ+wby/ mx+pvHkQi8nngebDSGXFgupQZygQC8kE6c/mWoRup4= Cc: Bernard Aboba , Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) 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, 04 May 2010 01:23:46 -0000 So, a few points, speaking as co-chair... - I apologize for not asking a well-formed question clearly. - We've had a couple of terse exchanges on the mailing list, that I had to go back and re-read before I understood the point being made (to me), and I can imagine that others were losing context as well. - I'm thinking that my biggest contribution to confusion was not starting a new thread for my question (thank you, Adam, for forking), and making it more clear that I was asking in a REQUIREMENTS context, and not in a GIN/FRIENDS/OLIVE/VERMOUTH/etc. context. If I'm reading today's threads clearly, that clearly threw Adam off - I wasn't asking about a change to GIN, and I don't think Hans Erik (the non-contrarian) was talking about a change to GIN, either, but I don't seem to have made that point clearly. - (the reason why I'm posting this note as chair is) What I'm concerned about is us (and not just MARTINI, but the entire SIP community) getting into a metaphysical debate about whether a solution that is NOT just the moral equivalent of a compressed string of REGISTERs is acceptable. Earlier today, I mentioned that I would expect any such debate to arise at the worst possible time, and I'd like to document working group consensus - if we can arrive at that consensus, so that we can quickly respond "yeah, we thought about that". - (again, posting this specific point as chair) It seems to me that having this text in a solutions draft is the wrong place, because solutions would either have this attribute, or they wouldn't, so we couldn't declare consensus on this point while we're still chatting up the solution draft itself. It's possible that all this is misplaced concern, and that we'll never need to document that it's important that a solutions draft does have the "compression-equivalent" property, or not (as in, "if GIN has this property and another solutions draft does not, is that a meaningful advantage for GIN?"). So, for instance, is it an advantage for a specific solution that a SIP-PBX can remove a single AOR/contact mapping that was registered as part of a bulk registration? If MARTINI=compress(individual REGISTERs), you could do that to an individually-REGISTERed mapping, couldn't you? Thanks for any enlightenment that you guys can pass along, of course. Spencer ----- Original Message ----- From: "Adam Roach" To: "Hans Erik van Elburg" Cc: "Bernard Aboba" ; ; "Hadriel Kaplan" Sent: Monday, May 03, 2010 6:20 PM Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) > On 5/3/10 5:34 PM, Hans Erik van Elburg wrote: >> I was reacting to Spencers question if martini should agree on >> a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations >> criterion that every solution should fulfill. >> I was saying no it is not a relevant criterion. (If that makes me a >> contrarian in your world, then so be it.) >> >> I also said: "Sure a particular solution can document that it has that >> property, fine." >> So if GIN is claiming to have this property then I am fine with that. >> (Not sure it is true though.) >> >> So why do you want me to propose a change to gin in this respect?? >> > > The actual question he asked ("Should that shared understanding go in the > (various) solution drafts?") was specifically asking about what should or > should not go into the solution drafts. GIN is a solutions draft. It > sounded to me like you were trying to raise a point on this call for > consensus, which I would expect to either take the form of either "yes, we > need to add X to the solutions draft" or "no, I don't think we need to > make any changes to the solutions draft on this topic." > > At this point, I think you read Spencer's question as meaning something > very different than I did. From adam@nostrum.com Mon May 3 19:24:45 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 0D94A3A6B70 for ; Mon, 3 May 2010 19:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_40=-0.185, J_CHICKENPOX_57=0.6, 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 sCxNa9TqoJhg for ; Mon, 3 May 2010 19:24:44 -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 BFF643A6D53 for ; Mon, 3 May 2010 19:24:42 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o442ONhn073404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 21:24:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BDF8557.4050408@nostrum.com> Date: Mon, 03 May 2010 21:24:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Spencer Dawkins References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.com> <4BDF5A25.2030208@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: Bernard Aboba , Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) 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, 04 May 2010 02:24:45 -0000 I'm composing a longer response to some of the other points in Spencer's email, but wanted to chime in on the easy one before it slips my attention. On 5/3/10 20:22, May 3, Spencer Dawkins wrote: > So, for instance, is it an advantage for a specific solution that a > SIP-PBX can remove a single AOR/contact mapping that was registered as > part of a bulk registration? If MARTINI=compress(individual > REGISTERs), you could do that to an individually-REGISTERed mapping, > couldn't you? Not sensibly. The problem is that the extension would be re-registered whenever you refreshed the bulk registration. This isn't unique to GIN -- it's pretty much a property of any system like the one you describe. So, the best you could do is de-register it every time you refresh the registration on the range. Even then, you'll have a race if, for example, an INVITE for the excluded extension arrives between the two REGISTER messages. That's why we added text to GIN in the most recent revision that explicitly disallows this behavior (or, really, makes it a no-op). It's not a requirement to be able to de-register a single number out of a range, and the complications that arise if you try to do so are more work than they are worth. /a From BLINDSAY@nortel.com Mon May 3 19:26:32 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 DA0CA28C312 for ; Mon, 3 May 2010 19:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.691 X-Spam-Level: X-Spam-Status: No, score=-4.691 tagged_above=-999 required=5 tests=[AWL=-1.292, BAYES_50=0.001, J_CHICKENPOX_57=0.6, 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 O5FtyG7wZHcQ for ; Mon, 3 May 2010 19:26:30 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 666C628C35A for ; Mon, 3 May 2010 19:26:30 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o442PfG27668; Tue, 4 May 2010 02:25:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 May 2010 22:24:49 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) Thread-Index: AcrrKHUsIl1l9p5oT/eD5zOsPTKMvgABu4iQ References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.com><4BDF5A25.2030208@nostrum.com> From: "Brian Lindsay" To: "Spencer Dawkins" , "Adam Roach" , "Hans Erik van Elburg" Cc: Bernard Aboba , martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 04 May 2010 02:26:32 -0000 Hi Spencer, To chime in (and agree with Hans I think), I don't believe that the requirements document should include this constraint and hence restrict the set of solutions. Also, I don't agree with necessarily treating the gin bnc solution as 100% equivalent to a set of individual registrations, to the extent of your "for instance" below. I much prefer the existing text in the gin draft on this particular topic for example: "Although the SSP treats this registration as a number of discrete rows for the purpose of retargeting incoming requests, the renewal, expiration, and removal of these rows is bound to the registered "bnc" contact. In particular, this means that REGISTER requests that attempt to de-register a single phone number that has been implicitly registered MUST NOT remove that phone number from the bulk registration." Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Monday, May 03, 2010 9:22 PM To: Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) So, a few points, speaking as co-chair... - I apologize for not asking a well-formed question clearly. - We've had a couple of terse exchanges on the mailing list, that I had to go back and re-read before I understood the point being made (to me), and I can imagine that others were losing context as well. - I'm thinking that my biggest contribution to confusion was not starting a new thread for my question (thank you, Adam, for forking), and making it more clear that I was asking in a REQUIREMENTS context, and not in a GIN/FRIENDS/OLIVE/VERMOUTH/etc. context. If I'm reading today's threads clearly, that clearly threw Adam off - I wasn't asking about a change to GIN, and I don't think Hans Erik (the non-contrarian) was talking about a change to GIN, either, but I don't seem to have made that point clearly. - (the reason why I'm posting this note as chair is) What I'm concerned about is us (and not just MARTINI, but the entire SIP community) getting into a metaphysical debate about whether a solution that is NOT just the moral equivalent of a compressed string of REGISTERs is acceptable. Earlier today, I mentioned that I would expect any such debate to arise at the worst possible time, and I'd like to document working group consensus - if we can arrive at that consensus, so that we can quickly respond "yeah, we thought about that". - (again, posting this specific point as chair) It seems to me that having this text in a solutions draft is the wrong place, because solutions would either have this attribute, or they wouldn't, so we couldn't declare consensus on this point while we're still chatting up the solution draft itself. It's possible that all this is misplaced concern, and that we'll never need to document that it's important that a solutions draft does have the "compression-equivalent" property, or not (as in, "if GIN has this property and another solutions draft does not, is that a meaningful advantage for GIN?"). So, for instance, is it an advantage for a specific solution that a SIP-PBX can remove a single AOR/contact mapping that was registered as part of a bulk registration? If MARTINI=3Dcompress(individual = REGISTERs), you could do that to an individually-REGISTERed mapping, couldn't you? Thanks for any enlightenment that you guys can pass along, of course. Spencer ----- Original Message ----- From: "Adam Roach" To: "Hans Erik van Elburg" Cc: "Bernard Aboba" ; ; "Hadriel Kaplan" Sent: Monday, May 03, 2010 6:20 PM Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) > On 5/3/10 5:34 PM, Hans Erik van Elburg wrote: >> I was reacting to Spencers question if martini should agree on=20 >> a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations >> criterion that every solution should fulfill. >> I was saying no it is not a relevant criterion. (If that makes me a=20 >> contrarian in your world, then so be it.) >> >> I also said: "Sure a particular solution can document that it has=20 >> that property, fine." >> So if GIN is claiming to have this property then I am fine with that. >> (Not sure it is true though.) >> >> So why do you want me to propose a change to gin in this respect?? >> > > The actual question he asked ("Should that shared understanding go in=20 > the > (various) solution drafts?") was specifically asking about what should > or should not go into the solution drafts. GIN is a solutions draft.=20 > It sounded to me like you were trying to raise a point on this call=20 > for consensus, which I would expect to either take the form of either=20 > "yes, we need to add X to the solutions draft" or "no, I don't think=20 > we need to make any changes to the solutions draft on this topic." > > At this point, I think you read Spencer's question as meaning=20 > something very different than I did. _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Mon May 3 20:59:04 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 043473A6BB5 for ; Mon, 3 May 2010 20:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_05=-1.11, J_CHICKENPOX_57=0.6, 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 wHOiYH+ofjP2 for ; Mon, 3 May 2010 20:59:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id E70513A6816 for ; Mon, 3 May 2010 20:59:02 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M8NJq-1NDJYo03us-00vLsM; Mon, 03 May 2010 23:58:47 -0400 Message-ID: From: "Spencer Dawkins" To: "Brian Lindsay" , "Adam Roach" , "Hans Erik van Elburg" References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.com><4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> Date: Mon, 3 May 2010 22:58:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19WmqOppMx88gj9xQxGql4RXa7/v+ggObalHT2 mH2nwOJc+SjE7/lHRZMn3Vt+UW3VZsuRNvcOc77MM9pOAkjaaT COCG4EG88l4f1oJo5bpGPZT1kFjv8aNbNVIyZPWmEk= Cc: Bernard Aboba , martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 04 May 2010 03:59:04 -0000 As co-chair, I'm replying to Brian's note, but have seen Adam's note as well... Thanks for the feedback here. My concern has been thrashing around since Bernard's "violates the principle of least astonishment" note (http://www.ietf.org/mail-archive/web/martini/current/msg01406.html). I'm doing better now. Thanks, Spencer ----- Original Message ----- From: "Brian Lindsay" To: "Spencer Dawkins" ; "Adam Roach" ; "Hans Erik van Elburg" Cc: "Bernard Aboba" ; "Hadriel Kaplan" ; Sent: Monday, May 03, 2010 9:24 PM Subject: RE: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) Hi Spencer, To chime in (and agree with Hans I think), I don't believe that the requirements document should include this constraint and hence restrict the set of solutions. Also, I don't agree with necessarily treating the gin bnc solution as 100% equivalent to a set of individual registrations, to the extent of your "for instance" below. I much prefer the existing text in the gin draft on this particular topic for example: "Although the SSP treats this registration as a number of discrete rows for the purpose of retargeting incoming requests, the renewal, expiration, and removal of these rows is bound to the registered "bnc" contact. In particular, this means that REGISTER requests that attempt to de-register a single phone number that has been implicitly registered MUST NOT remove that phone number from the bulk registration." Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Monday, May 03, 2010 9:22 PM To: Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) So, a few points, speaking as co-chair... - I apologize for not asking a well-formed question clearly. - We've had a couple of terse exchanges on the mailing list, that I had to go back and re-read before I understood the point being made (to me), and I can imagine that others were losing context as well. - I'm thinking that my biggest contribution to confusion was not starting a new thread for my question (thank you, Adam, for forking), and making it more clear that I was asking in a REQUIREMENTS context, and not in a GIN/FRIENDS/OLIVE/VERMOUTH/etc. context. If I'm reading today's threads clearly, that clearly threw Adam off - I wasn't asking about a change to GIN, and I don't think Hans Erik (the non-contrarian) was talking about a change to GIN, either, but I don't seem to have made that point clearly. - (the reason why I'm posting this note as chair is) What I'm concerned about is us (and not just MARTINI, but the entire SIP community) getting into a metaphysical debate about whether a solution that is NOT just the moral equivalent of a compressed string of REGISTERs is acceptable. Earlier today, I mentioned that I would expect any such debate to arise at the worst possible time, and I'd like to document working group consensus - if we can arrive at that consensus, so that we can quickly respond "yeah, we thought about that". - (again, posting this specific point as chair) It seems to me that having this text in a solutions draft is the wrong place, because solutions would either have this attribute, or they wouldn't, so we couldn't declare consensus on this point while we're still chatting up the solution draft itself. It's possible that all this is misplaced concern, and that we'll never need to document that it's important that a solutions draft does have the "compression-equivalent" property, or not (as in, "if GIN has this property and another solutions draft does not, is that a meaningful advantage for GIN?"). So, for instance, is it an advantage for a specific solution that a SIP-PBX can remove a single AOR/contact mapping that was registered as part of a bulk registration? If MARTINI=compress(individual REGISTERs), you could do that to an individually-REGISTERed mapping, couldn't you? Thanks for any enlightenment that you guys can pass along, of course. Spencer ----- Original Message ----- From: "Adam Roach" To: "Hans Erik van Elburg" Cc: "Bernard Aboba" ; ; "Hadriel Kaplan" Sent: Monday, May 03, 2010 6:20 PM Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) > On 5/3/10 5:34 PM, Hans Erik van Elburg wrote: >> I was reacting to Spencers question if martini should agree on >> a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations >> criterion that every solution should fulfill. >> I was saying no it is not a relevant criterion. (If that makes me a >> contrarian in your world, then so be it.) >> >> I also said: "Sure a particular solution can document that it has >> that property, fine." >> So if GIN is claiming to have this property then I am fine with that. >> (Not sure it is true though.) >> >> So why do you want me to propose a change to gin in this respect?? >> > > The actual question he asked ("Should that shared understanding go in > the > (various) solution drafts?") was specifically asking about what should > or should not go into the solution drafts. GIN is a solutions draft. > It sounded to me like you were trying to raise a point on this call > for consensus, which I would expect to either take the form of either > "yes, we need to add X to the solutions draft" or "no, I don't think > we need to make any changes to the solutions draft on this topic." > > At this point, I think you read Spencer's question as meaning > something very different than I did. _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From ietf.hanserik@gmail.com Mon May 3 22:04:41 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 2142D3A6BE4 for ; Mon, 3 May 2010 22:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 T3HTy440whke for ; Mon, 3 May 2010 22:04:37 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 60C9E3A6D60 for ; Mon, 3 May 2010 22:04:28 -0700 (PDT) Received: by ewy24 with SMTP id 24so882351ewy.33 for ; Mon, 03 May 2010 22:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WOOTH4Bi3Q3Obzn9ONSZOdgWH1JYx/yXrcUK4J0xsUE=; b=gar4gb9KkH6RcxhtDcEf8SfMkYcERMlJ6YfX0AMDzaLFHZK39L/S+HFQASCkQIJwkL C1FSMKFKV51e7kXGldE0ZxNpUwT3GO2witj8E6qYOmRXQPyR+U0y38AERLXQj/n0jpQr NI9hxnQ5vmvcZERVzNTCQlOFtxDFA+5eek9gE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZokW5UJYly7k9q0yrvcqxETHn/9Uqom1oXqi6Ao/UHQvEG8O/cnUKYKNZ9OprfFvcL bgOfW8R7xMbzdrrSGil1XeNOuX/rHAP8YBk9/AIIDWkzzgaNrummMSWRS55nSCn2nZOp z1XglMEaouEFK9vU/RVEO/PUDUYd3OIvGc4Fk= MIME-Version: 1.0 Received: by 10.213.48.132 with SMTP id r4mr1823160ebf.55.1272949451054; Mon, 03 May 2010 22:04:11 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Mon, 3 May 2010 22:04:11 -0700 (PDT) In-Reply-To: References: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@mail> Date: Tue, 4 May 2010 07:04:11 +0200 Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive 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, 04 May 2010 05:04:41 -0000 Hi Hadriel, Having thought about this a bit more, I do think that the what would suffice is having the following usages: 5. Subscribing for Registration State Resources 5.1. Subscribing to AoRs Where it is in fact "Subscribing to state in the IP-PBX". 5.2. Subscribing for all implicitly registered AoRs..........8 As is. As 5.1 is usefull for other UA's the result will not surprise them and it will be usefull information. 5.2 is useful for the PBX to monitor its own registration state. Then there is no need for SUBSCRIBES with awkward bnc parameters. I know this violates the principle that this is a normal registration, but that is because it is not a normal registration. Curious if you think this could be a way forward. /Hans Erik van Elburg On Mon, May 3, 2010 at 11:43 PM, Hans Erik van Elburg wrote: > There is some valid ideas in this and with some work it could be made > to work with several different mechanisms. This does not have to be > gin specific. > > Some issues/questions: > - the use of the bnc tag to address the AOR behind the PBX seems > counterintuitive, as one is in fact in this case addressing a normal > registration... > - the use of a special tag to mint subscription requests to address > the AOR behind the PBX assumes knowledge at the subscriber about the > AOR's terminating arrangement. This is in general problematic. As such > arrangement should be possible to be freely changed by the receiving > company, without notifying potential originators. Not to mention the > security issues with revealing the connection topology. > - can there be more range parameters? > - can the range parameter be injected at any place in a string or only > at the end of the user part? > - regarding 5.4 open issue, yes bulk AOR's are only short hand > representation of ranges registered. They themselves are not > registered and should not be used as AOR's themselves and therefore > section 5.4 should be removed. And some statement should be made > somewhere that bulk AOR's can not be used as normal AOR's. In IMS we > call this wildcarded PUI and those can only be used to match distinct > PUI's with, same here maybe it is better to talk about wildcarded > AOR's as it expresses this property better. > - statements (for ex. 5.1) like "Any internal optimization performed > by the SSP location-service database for handling Bulk-AoRs MUST NOT > change this external behavior. " Are not referring to the SUBSCRIBE > mechanism and therefore inappropriate repetition of an opinion in this > draft ;-) > - Appendix A: While I have no problem with simplifying the pattern, to > enable less configuration errors and complaince with RFC3261. You > bring back here the issue of automatically detecting provisioning > mismatches by the PBX. Is this based on something you have seen in > practice? Why would this be an issue at all? Even in the simplified > case I don not think that an IP-PBX can conclude anything when it has > knowledge about the full generated set of AOR's. It suffices to match > each configured AOR with the patterns returned. > > /Hans Erik van Elburg > > On Mon, May 3, 2010 at 9:27 PM, Hadriel Kaplan w= rote: >> >> Howdy, >> I have submitted a new draft strawman proposal for reg-event which tries= to accomplish the following: >> 1) Gives reg-event for open-numbering-plans >> 2) Subscribes for AoRs *in* the PBX, vs. just SSP's >> 3) Subscribes for all implicitly registered AoRs (e.g., so PBX can check= it) >> 4) Creates an acronym for Vermouth >> >> Any comments/flames welcomed. >> >> -hadriel >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SIP MARTINI Variant of 'Event= -package for Registrations' for Managed Open-ended Username Target Handling= (VERMOUTH) >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan, et al. >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-martini-vermouth-0= 0.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-03 >> >> The Martini Working Group is defining a mechanism for SIP IP-PBX type de= vices to REGISTER and obtain SIP service for E.164-based Address of Records= , in [draft-gin]. =A0Another draft [draft-olive] proposes the same for non-= E.164-based AoRs. =A0This document defines a variant of the Registration Ev= ent-package [reg-event] for open-ended AoRs for either mechanisms, using a = wildcard syntax and specific target handling rules. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kaplan-martini-vermouth-00.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 impleme= ntation to automatically retrieve the ASCII version of the Internet-Draft. >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > From martien.huysmans@ericsson.com Tue May 4 01:23:04 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 8D33C3A6959 for ; Tue, 4 May 2010 01:23:04 -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 JNlR4ulT48MU for ; Tue, 4 May 2010 01:23:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5756D3A695F for ; Tue, 4 May 2010 01:22:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-29-4bdfd93e5bb1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 90.85.08537.E39DFDB4; Tue, 4 May 2010 10:22:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 4 May 2010 10:22:22 +0200 From: Martien Huysmans To: "adam@nostrum.com" , "hkaplan@acmepacket.com" Date: Tue, 4 May 2010 10:22:20 +0200 Thread-Topic: [martini] #41: What happens to a "presence" Subscription for an E.164 AoR? Thread-Index: AcrrBy6Ui4Sm+Bq5RPGF/DH2LMjQqwAW1erA Message-ID: References: <064.c7f9b407eec269da298fd711cd7baeaa@tools.ietf.org> <4BDF3F45.4050005@nostrum.com> In-Reply-To: <4BDF3F45.4050005@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-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] #41: What happens to a "presence" Subscription for an E.164 AoR? 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, 04 May 2010 08:23:04 -0000 Adam Are you saying that the current martini-gin draft supports an architecture where for sip:+1234567@ssp.com the presence server resides at the SSP and=20 where the IPPBX would provide voice services? /Martien -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Monday, May 03, 2010 11:25 PM To: hkaplan@acmepacket.com Cc: martini@ietf.org Subject: Re: [martini] #41: What happens to a "presence" Subscription for a= n E.164 AoR? On 5/3/10 3:32 PM, martini issue tracker wrote: > #41: What happens to a "presence" Subscription for an E.164 AoR? > ------------------------------------+--------------------------------- > ------------------------------------+------ > Reporter: hkaplan@... | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: milestone1 > Component: gin | Version: 1.0 > Severity: Active WG Document | Keywords: > ------------------------------------+--------------------------------- > ------------------------------------+------ > Does a SUBSCRIBE for the "presence" package targeted to > "sip:+1234567@ssp.com" get contact-routed to the IP-PBX, or processed b= y > the SSP's presence servers? > =20 Given that non-gin implementations have alternately chosen to handle presen= ce in servers or at the endpoint, I would argue that this question verges o= n metaphysical. SIP presence in general leaves this open to network policy. I think that's = still the correct answer here. /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From martien.huysmans@ericsson.com Tue May 4 02:57:20 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 4849B3A69C7 for ; Tue, 4 May 2010 02:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 cxa3zaCkSryL for ; Tue, 4 May 2010 02:57:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1199A3A67F9 for ; Tue, 4 May 2010 02:57:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-62-4bdfef6e6da8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B5.73.08537.E6FEFDB4; Tue, 4 May 2010 11:57:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 4 May 2010 11:57:02 +0200 From: Martien Huysmans To: Spencer Dawkins , Brian Lindsay , Adam Roach , Hans Erik van Elburg Date: Tue, 4 May 2010 11:57:01 +0200 Thread-Topic: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) Thread-Index: AcrrPh1ZmhImaMGfSbCmbtQdWYmCmQAKPUQg Message-ID: References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.com><4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 04 May 2010 09:57:20 -0000 Spencer I am trying to follow and understand the discussion around "bulk registrati= on"=20 and "single AoR registration" and the RFC3621 principles that people refer = to.=20 The "principle of least astonishment" that Spencers mentions,=20 has resulted in describing my astonishment in this email. I hope that people forgive me if my astonishment is due to lack of understa= nding=20 of the ongoing discussion. - An PBX user registers with it's PBX. Standard RFC3261, so no astonishment= . - An PBX registers with the SSP, to be able to send and receive calls. No a= stonishment - Having a second "single AoR registration" for that PBX user at the SSP fe= els strange. It seems to be independant of the registration of the PBX user in the PBX= domain. In the SSP domain an "AOR -> Contact" mapping exists, even when the PBX user is not registered at the PBX. - A call can be made towards an service in the PBX domain.=20 That service would not have a registration in the PBX domain, but would have a "single AoR registration" at the SSP domain.=20 - Why mandate that an SSP needs to know the individual users behind an PBX? This may be valid for certain cases, but why have it as a general rule?=20 Thanks Martien=20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Spencer Dawkins Sent: Tuesday, May 04, 2010 5:59 AM To: Brian Lindsay; Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packagea= nd individual extension state(section 7.2.2)) As co-chair, I'm replying to Brian's note, but have seen Adam's note as well... Thanks for the feedback here. My concern has been thrashing around since Bernard's "violates the principl= e of least astonishment" note (http://www.ietf.org/mail-archive/web/martini= /current/msg01406.html). I'm doing better now. Thanks, Spencer ----- Original Message ----- From: "Brian Lindsay" To: "Spencer Dawkins" ; "Adam Roach"=20 ; "Hans Erik van Elburg" Cc: "Bernard Aboba" ; "Hadriel Kaplan"=20 ; Sent: Monday, May 03, 2010 9:24 PM Subject: RE: [martini] Not the same thread (was Re: #36: Reg-event packagea= nd individual extension state(section 7.2.2)) Hi Spencer, To chime in (and agree with Hans I think), I don't believe that the requi= rements document should include this constraint and hence restrict the set = of solutions. Also, I don't agree with necessarily treating the gin bnc solution as 100= % equivalent to a set of individual registrations, to the extent of your "f= or instance" below. I much prefer the existing text in the gin draft on thi= s particular topic for example: "Although the SSP treats this registration as a number of discrete rows for the purpose of retargeting incoming requests, the renewal, expiration, and removal of these rows is bound to the registered "bnc" contact. In particular, this means that REGISTER requests that attempt to de-register a single phone number that has been implicitly registered MUST NOT remove that phone number from the bulk registration." Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Spencer Dawkins Sent: Monday, May 03, 2010 9:22 PM To: Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packagea= nd individual extension state(section 7.2.2)) So, a few points, speaking as co-chair... - I apologize for not asking a well-formed question clearly. - We've had a couple of terse exchanges on the mailing list, that I had to = go back and re-read before I understood the point being made (to me), and I= can imagine that others were losing context as well. - I'm thinking that my biggest contribution to confusion was not starting a= new thread for my question (thank you, Adam, for forking), and making it m= ore clear that I was asking in a REQUIREMENTS context, and not in a GIN/FRI= ENDS/OLIVE/VERMOUTH/etc. context. If I'm reading today's threads clearly, t= hat clearly threw Adam off - I wasn't asking about a change to GIN, and I d= on't think Hans Erik (the non-contrarian) was talking about a change to GIN= , either, but I don't seem to have made that point clearly. - (the reason why I'm posting this note as chair is) What I'm concerned abo= ut is us (and not just MARTINI, but the entire SIP community) getting into = a metaphysical debate about whether a solution that is NOT just the moral e= quivalent of a compressed string of REGISTERs is acceptable. Earlier today, I mentioned that I would expect any such debate to arise at = the worst possible time, and I'd like to document working group consensus -= if we can arrive at that consensus, so that we can quickly respond "yeah, = we thought about that". - (again, posting this specific point as chair) It seems to me that having = this text in a solutions draft is the wrong place, because solutions would = either have this attribute, or they wouldn't, so we couldn't declare consen= sus on this point while we're still chatting up the solution draft itself. It's possible that all this is misplaced concern, and that we'll never need= to document that it's important that a solutions draft does have the "comp= ression-equivalent" property, or not (as in, "if GIN has this property and = another solutions draft does not, is that a meaningful advantage for GIN?")= . So, for instance, is it an advantage for a specific solution that a SIP-PBX= can remove a single AOR/contact mapping that was registered as part of a b= ulk registration? If MARTINI=3Dcompress(individual REGISTERs), you could do= that to an individually-REGISTERed mapping, couldn't you? Thanks for any enlightenment that you guys can pass along, of course. Spencer ----- Original Message ----- From: "Adam Roach" To: "Hans Erik van Elburg" Cc: "Bernard Aboba" ; ; "Hadri= el Kaplan" Sent: Monday, May 03, 2010 6:20 PM Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package = and individual extension state(section 7.2.2)) > On 5/3/10 5:34 PM, Hans Erik van Elburg wrote: >> I was reacting to Spencers question if martini should agree on=20 >> a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations >> criterion that every solution should fulfill. >> I was saying no it is not a relevant criterion. (If that makes me a=20 >> contrarian in your world, then so be it.) >> >> I also said: "Sure a particular solution can document that it has=20 >> that property, fine." >> So if GIN is claiming to have this property then I am fine with that. >> (Not sure it is true though.) >> >> So why do you want me to propose a change to gin in this respect?? >> > > The actual question he asked ("Should that shared understanding go in=20 > the > (various) solution drafts?") was specifically asking about what should > or should not go into the solution drafts. GIN is a solutions draft. > It sounded to me like you were trying to raise a point on this call=20 > for consensus, which I would expect to either take the form of either=20 > "yes, we need to add X to the solutions draft" or "no, I don't think=20 > we need to make any changes to the solutions draft on this topic." > > At this point, I think you read Spencer's question as meaning=20 > something very different than I did. _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Tue May 4 05:57:01 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 A10DC3A6BDA for ; Tue, 4 May 2010 05:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 KSz52+x0EU7Q for ; Tue, 4 May 2010 05:57:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 50B113A6842 for ; Tue, 4 May 2010 05:57:00 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Mexyj-1NybLb0mVN-00P80l; Tue, 04 May 2010 08:56:15 -0400 Message-ID: From: "Spencer Dawkins" To: "Martien Huysmans" , "Brian Lindsay" , "Adam Roach" , "Hans Erik van Elburg" References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com><430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail><4BDF436C.7010803@nostrum.com><4BDF465F.3040104@nostrum.com><4BDF5A25.2030208@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> Date: Tue, 4 May 2010 07:56:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+szyeRYMPoRDcbG2EBhZSqUUlcKK72KuJtBha ZN+34GsHTHL3y1uYIRDm3SZPhIWRMrKs9f/5RcAsswiy5HkRqo 9D4wEwMG4YywJ6mo3bwEWgmmucvTdwOzOOzftYCYzs= Cc: Bernard Aboba , Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-eventpackageand individual extension state(section 7.2.2)) 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, 04 May 2010 12:57:01 -0000 Hi, Martien, You might get a different (and smarter) answer from other working group participants, but if I'm understanding your question, here's my answer. What we're talking about is the case where the SP knows every AOR that it will forward INVITEs for, to the SIP-PBX. If the SP is going to forward INVITEs for AORs that it knows nothing about (and by "AOR", I probably mean "left hand/userpart"), it's going to have to base that forwarding decision on the AOR domain name. We talked about doing dynamic registration for domains (the IETF 76 DISPATCH ad hoc was called "DREGS", which stood for "Domain Registration"), and decided (these are my words) that maintaining a parallel forwarding mechanism for strings that looked like domain names was not helpful (it generated concerns about "alt.root", among other concerns), and that anyone who really wanted to do this could use DYN-DNS to create the DNS entries needed, and then use RFC 3263 call routing for these INVITEs. Does this answer make sense? Spencer ----- Original Message ----- From: "Martien Huysmans" To: "Spencer Dawkins" ; "Brian Lindsay" ; "Adam Roach" ; "Hans Erik van Elburg" Cc: "Bernard Aboba" ; ; "Hadriel Kaplan" Sent: Tuesday, May 04, 2010 4:57 AM Subject: RE: [martini] Not the same thread (was Re: #36: Reg-eventpackageand individual extension state(section 7.2.2)) Spencer I am trying to follow and understand the discussion around "bulk registration" and "single AoR registration" and the RFC3621 principles that people refer to. The "principle of least astonishment" that Spencers mentions, has resulted in describing my astonishment in this email. I hope that people forgive me if my astonishment is due to lack of understanding of the ongoing discussion. - An PBX user registers with it's PBX. Standard RFC3261, so no astonishment. - An PBX registers with the SSP, to be able to send and receive calls. No astonishment - Having a second "single AoR registration" for that PBX user at the SSP feels strange. It seems to be independant of the registration of the PBX user in the PBX domain. In the SSP domain an "AOR -> Contact" mapping exists, even when the PBX user is not registered at the PBX. - A call can be made towards an service in the PBX domain. That service would not have a registration in the PBX domain, but would have a "single AoR registration" at the SSP domain. - Why mandate that an SSP needs to know the individual users behind an PBX? This may be valid for certain cases, but why have it as a general rule? Thanks Martien -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Tuesday, May 04, 2010 5:59 AM To: Brian Lindsay; Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) As co-chair, I'm replying to Brian's note, but have seen Adam's note as well... Thanks for the feedback here. My concern has been thrashing around since Bernard's "violates the principle of least astonishment" note (http://www.ietf.org/mail-archive/web/martini/current/msg01406.html). I'm doing better now. Thanks, Spencer ----- Original Message ----- From: "Brian Lindsay" To: "Spencer Dawkins" ; "Adam Roach" ; "Hans Erik van Elburg" Cc: "Bernard Aboba" ; "Hadriel Kaplan" ; Sent: Monday, May 03, 2010 9:24 PM Subject: RE: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) Hi Spencer, To chime in (and agree with Hans I think), I don't believe that the requirements document should include this constraint and hence restrict the set of solutions. Also, I don't agree with necessarily treating the gin bnc solution as 100% equivalent to a set of individual registrations, to the extent of your "for instance" below. I much prefer the existing text in the gin draft on this particular topic for example: "Although the SSP treats this registration as a number of discrete rows for the purpose of retargeting incoming requests, the renewal, expiration, and removal of these rows is bound to the registered "bnc" contact. In particular, this means that REGISTER requests that attempt to de-register a single phone number that has been implicitly registered MUST NOT remove that phone number from the bulk registration." Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Monday, May 03, 2010 9:22 PM To: Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) So, a few points, speaking as co-chair... - I apologize for not asking a well-formed question clearly. - We've had a couple of terse exchanges on the mailing list, that I had to go back and re-read before I understood the point being made (to me), and I can imagine that others were losing context as well. - I'm thinking that my biggest contribution to confusion was not starting a new thread for my question (thank you, Adam, for forking), and making it more clear that I was asking in a REQUIREMENTS context, and not in a GIN/FRIENDS/OLIVE/VERMOUTH/etc. context. If I'm reading today's threads clearly, that clearly threw Adam off - I wasn't asking about a change to GIN, and I don't think Hans Erik (the non-contrarian) was talking about a change to GIN, either, but I don't seem to have made that point clearly. - (the reason why I'm posting this note as chair is) What I'm concerned about is us (and not just MARTINI, but the entire SIP community) getting into a metaphysical debate about whether a solution that is NOT just the moral equivalent of a compressed string of REGISTERs is acceptable. Earlier today, I mentioned that I would expect any such debate to arise at the worst possible time, and I'd like to document working group consensus - if we can arrive at that consensus, so that we can quickly respond "yeah, we thought about that". - (again, posting this specific point as chair) It seems to me that having this text in a solutions draft is the wrong place, because solutions would either have this attribute, or they wouldn't, so we couldn't declare consensus on this point while we're still chatting up the solution draft itself. It's possible that all this is misplaced concern, and that we'll never need to document that it's important that a solutions draft does have the "compression-equivalent" property, or not (as in, "if GIN has this property and another solutions draft does not, is that a meaningful advantage for GIN?"). So, for instance, is it an advantage for a specific solution that a SIP-PBX can remove a single AOR/contact mapping that was registered as part of a bulk registration? If MARTINI=compress(individual REGISTERs), you could do that to an individually-REGISTERed mapping, couldn't you? Thanks for any enlightenment that you guys can pass along, of course. Spencer ----- Original Message ----- From: "Adam Roach" To: "Hans Erik van Elburg" Cc: "Bernard Aboba" ; ; "Hadriel Kaplan" Sent: Monday, May 03, 2010 6:20 PM Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) > On 5/3/10 5:34 PM, Hans Erik van Elburg wrote: >> I was reacting to Spencers question if martini should agree on >> a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations >> criterion that every solution should fulfill. >> I was saying no it is not a relevant criterion. (If that makes me a >> contrarian in your world, then so be it.) >> >> I also said: "Sure a particular solution can document that it has >> that property, fine." >> So if GIN is claiming to have this property then I am fine with that. >> (Not sure it is true though.) >> >> So why do you want me to propose a change to gin in this respect?? >> > > The actual question he asked ("Should that shared understanding go in > the > (various) solution drafts?") was specifically asking about what should > or should not go into the solution drafts. GIN is a solutions draft. > It sounded to me like you were trying to raise a point on this call > for consensus, which I would expect to either take the form of either > "yes, we need to add X to the solutions draft" or "no, I don't think > we need to make any changes to the solutions draft on this topic." > > At this point, I think you read Spencer's question as meaning > something very different than I did. _______________________________________________ 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 Tue May 4 06:12: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 A2CE63A6B3C for ; Tue, 4 May 2010 06:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.220, 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 XW02AMyfHA5H for ; Tue, 4 May 2010 06:12:37 -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 D36353A6C17 for ; Tue, 4 May 2010 06:10:33 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o44DADLj027330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 08:10:13 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BE01CB5.50103@nostrum.com> Date: Tue, 04 May 2010 08:10:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martien Huysmans References: <064.c7f9b407eec269da298fd711cd7baeaa@tools.ietf.org> <4BDF3F45.4050005@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] #41: What happens to a "presence" Subscription for an E.164 AoR? 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, 04 May 2010 13:12:38 -0000 On 5/4/10 03:22, May 4, Martien Huysmans wrote: > Adam > > Are you saying that the current martini-gin draft supports an architecture > where for sip:+1234567@ssp.com the presence server resides at the SSP and > where the IPPBX would provide voice services? > It certainly does. It also supports one in which the presence server resides at the PBX. This also true for voicemail, and pretty much any other service typically provided in the network. To be clear, GIN is agnostic on these topics, just like normal registrations are. It is doing nothing additional to facilitate this functionality. /a > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Monday, May 03, 2010 11:25 PM > To: hkaplan@acmepacket.com > Cc: martini@ietf.org > Subject: Re: [martini] #41: What happens to a "presence" Subscription for an E.164 AoR? > > On 5/3/10 3:32 PM, martini issue tracker wrote: > >> #41: What happens to a "presence" Subscription for an E.164 AoR? >> ------------------------------------+--------------------------------- >> ------------------------------------+------ >> Reporter: hkaplan@... | Owner: >> Type: enhancement | Status: new >> Priority: minor | Milestone: milestone1 >> Component: gin | Version: 1.0 >> Severity: Active WG Document | Keywords: >> ------------------------------------+--------------------------------- >> ------------------------------------+------ >> Does a SUBSCRIBE for the "presence" package targeted to >> "sip:+1234567@ssp.com" get contact-routed to the IP-PBX, or processed by >> the SSP's presence servers? >> >> > Given that non-gin implementations have alternately chosen to handle presence in servers or at the endpoint, I would argue that this question verges on metaphysical. > > SIP presence in general leaves this open to network policy. I think that's still the correct answer here. > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From HKaplan@acmepacket.com Tue May 4 06:39:48 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 01BFB3A692D for ; Tue, 4 May 2010 06:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_05=-1.11, J_CHICKENPOX_57=0.6] 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 xk2OeelYrYKi for ; Tue, 4 May 2010 06:39:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9C5C03A69A2 for ; Tue, 4 May 2010 06:39:41 -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, 4 May 2010 09:39:27 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 4 May 2010 09:39:26 -0400 From: Hadriel Kaplan To: Adam Roach , Spencer Dawkins Date: Tue, 4 May 2010 09:39:26 -0400 Thread-Topic: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) Thread-Index: AcrrMOrC9/TYqbglS1+Q/gphzGxBGQAFfmcA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1D36@mail> References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.com> <4BDF5A25.2030208@nostrum.com> <4BDF8557.4050408@nostrum.com> In-Reply-To: <4BDF8557.4050408@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 , "martini@ietf.org" Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package and individual extension state(section 7.2.2)) 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, 04 May 2010 13:39:48 -0000 It's not even just E.164 *ranges* - it's ANY AoR of the set, and the set ma= y not even be a range. =20 I had assumed you could not de-register a "number in the middle" or *any* s= ingle AoR of the set, because it's illogical - by *definition* a bulk REGIS= TER expands to its AoR set by the provisioning. So if the provisioning say= s "expand pbx123's REGISTER to foo@ssp.com and bar@ssp.com", then de-Regist= ering "foo@ssp.com" will de-register it only until the next re-Register of = pbx123. So basically what the PBX would be doing by de-registering one member of th= e set is conflicting with the provisioning - it's like there's a mis-provis= ioning error going on. Clearly a de-REGISTER will not, and is not intended= to, "fix" this provisioning error. What *should* happen is the SSP should change it's provisioning to no longe= r include the specific AoR in the "expansion set". If we had a reg-event m= odel, for example, the SSP systems could even Notify the PBX of the change = - but it still wouldn't need or expect or be right for the PBX to send a de= -REGISTER. -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Monday, May 03, 2010 10:24 PM > To: Spencer Dawkins >=20 > On 5/3/10 20:22, May 3, Spencer Dawkins wrote: > > So, for instance, is it an advantage for a specific solution that a > > SIP-PBX can remove a single AOR/contact mapping that was registered as > > part of a bulk registration? If MARTINI=3Dcompress(individual > > REGISTERs), you could do that to an individually-REGISTERed mapping, > > couldn't you? >=20 > Not sensibly. The problem is that the extension would be re-registered > whenever you refreshed the bulk registration. This isn't unique to GIN > -- it's pretty much a property of any system like the one you describe. > So, the best you could do is de-register it every time you refresh the > registration on the range. Even then, you'll have a race if, for > example, an INVITE for the excluded extension arrives between the two > REGISTER messages. >=20 > That's why we added text to GIN in the most recent revision that > explicitly disallows this behavior (or, really, makes it a no-op). It's > not a requirement to be able to de-register a single number out of a > range, and the complications that arise if you try to do so are more > work than they are worth. >=20 > /a From martien.huysmans@ericsson.com Tue May 4 07:38:39 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 955633A6C4C for ; Tue, 4 May 2010 07:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=-2.150, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] 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 d0CnFzJ3FjNQ for ; Tue, 4 May 2010 07:38:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F2A743A6C59 for ; Tue, 4 May 2010 07:38:06 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-99-4be0313fae4d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2F.AC.21861.F3130EB4; Tue, 4 May 2010 16:37:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 4 May 2010 16:37:50 +0200 From: Martien Huysmans To: Spencer Dawkins , Brian Lindsay , Adam Roach , Hans Erik van Elburg Date: Tue, 4 May 2010 16:37:50 +0200 Thread-Topic: [martini] Not the same thread (was Re: #36: Reg-eventpackageand individual extension state(section 7.2.2)) Thread-Index: Acrric927YmeZrNETKOfGB8HkV5+dwAC8fjg Message-ID: References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com><430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail><4BDF436C.7010803@nostrum.com><4BDF465F.3040104@nostrum.com><4BDF5A25.2030208@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Not the same thread (was Re: #36: Reg-eventpackageand individual extension state(section 7.2.2)) 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, 04 May 2010 14:38:39 -0000 Spencer Txs for replying to the email. Unfortunately it doesn't take away my astoni= shment. The 2nd paragraph has more depth. I will have a look at DRGS to digest that= . /Martien=20 -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 Sent: Tuesday, May 04, 2010 2:56 PM To: Martien Huysmans; Brian Lindsay; Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-eventpackagean= d individual extension state(section 7.2.2)) Hi, Martien, You might get a different (and smarter) answer from other working group par= ticipants, but if I'm understanding your question, here's my answer. What we're talking about is the case where the SP knows every AOR that it w= ill forward INVITEs for, to the SIP-PBX. If the SP is going to forward INVI= TEs for AORs that it knows nothing about (and by "AOR", I probably mean "le= ft hand/userpart"), it's going to have to base that forwarding decision on = the AOR domain name. We talked about doing dynamic registration for domains (the IETF 76 DISPATC= H ad hoc was called "DREGS", which stood for "Domain Registration"), and de= cided (these are my words) that maintaining a parallel forwarding mechanism= for strings that looked like domain names was not helpful (it generated co= ncerns about "alt.root", among other concerns), and that anyone who really = wanted to do this could use DYN-DNS to create the DNS entries needed, and t= hen use RFC 3263 call routing for these INVITEs. Does this answer make sense? Spencer ----- Original Message ----- From: "Martien Huysmans" To: "Spencer Dawkins" ; "Brian Lindsay"=20 ; "Adam Roach" ; "Hans Erik van Elbu= rg" Cc: "Bernard Aboba" ; ; "Hadri= el Kaplan" Sent: Tuesday, May 04, 2010 4:57 AM Subject: RE: [martini] Not the same thread (was Re: #36: Reg-eventpackagean= d individual extension state(section 7.2.2)) Spencer I am trying to follow and understand the discussion around "bulk registrati= on" and "single AoR registration" and the RFC3621 principles that people refer = to. The "principle of least astonishment" that Spencers mentions, has resulted = in describing my astonishment in this email. I hope that people forgive me if my astonishment is due to lack of understa= nding of the ongoing discussion. - An PBX user registers with it's PBX. Standard RFC3261, so no astonishment= . - An PBX registers with the SSP, to be able to send and receive calls. No a= stonishment - Having a second "single AoR registration" for that PBX user at the SSP fe= els strange. It seems to be independant of the registration of the PBX user in the PBX= domain. In the SSP domain an "AOR -> Contact" mapping exists, even when the PBX user is not registered at the PBX. - A call can be made towards an service in the PBX domain. That service would not have a registration in the PBX domain, but would have a "single AoR registration" at the SSP domain. - Why mandate that an SSP needs to know the individual users behind an PBX? This may be valid for certain cases, but why have it as a general rule? Thanks Martien -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Spencer Dawkins Sent: Tuesday, May 04, 2010 5:59 AM To: Brian Lindsay; Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packagea= nd individual extension state(section 7.2.2)) As co-chair, I'm replying to Brian's note, but have seen Adam's note as well... Thanks for the feedback here. My concern has been thrashing around since Bernard's "violates the principl= e of least astonishment" note (http://www.ietf.org/mail-archive/web/martini= /current/msg01406.html). I'm doing better now. Thanks, Spencer ----- Original Message ----- From: "Brian Lindsay" To: "Spencer Dawkins" ; "Adam Roach" ; "Hans Erik van Elburg" Cc: "Bernard Aboba" ; "Hadriel Kaplan" ; Sent: Monday, May 03, 2010 9:24 PM Subject: RE: [martini] Not the same thread (was Re: #36: Reg-event packagea= nd individual extension state(section 7.2.2)) Hi Spencer, To chime in (and agree with Hans I think), I don't believe that the=20 requirements document should include this constraint and hence restrict the= =20 set of solutions. Also, I don't agree with necessarily treating the gin bnc solution as 100= %=20 equivalent to a set of individual registrations, to the extent of your "for= =20 instance" below. I much prefer the existing text in the gin draft on this=20 particular topic for example: "Although the SSP treats this registration as a number of discrete rows for the purpose of retargeting incoming requests, the renewal, expiration, and removal of these rows is bound to the registered "bnc" contact. In particular, this means that REGISTER requests that attempt to de-register a single phone number that has been implicitly registered MUST NOT remove that phone number from the bulk registration." Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf= =20 Of Spencer Dawkins Sent: Monday, May 03, 2010 9:22 PM To: Adam Roach; Hans Erik van Elburg Cc: Bernard Aboba; Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event=20 packageand individual extension state(section 7.2.2)) So, a few points, speaking as co-chair... - I apologize for not asking a well-formed question clearly. - We've had a couple of terse exchanges on the mailing list, that I had to= =20 go back and re-read before I understood the point being made (to me), and I= =20 can imagine that others were losing context as well. - I'm thinking that my biggest contribution to confusion was not starting a= =20 new thread for my question (thank you, Adam, for forking), and making it=20 more clear that I was asking in a REQUIREMENTS context, and not in a=20 GIN/FRIENDS/OLIVE/VERMOUTH/etc. context. If I'm reading today's threads=20 clearly, that clearly threw Adam off - I wasn't asking about a change to=20 GIN, and I don't think Hans Erik (the non-contrarian) was talking about a=20 change to GIN, either, but I don't seem to have made that point clearly. - (the reason why I'm posting this note as chair is) What I'm concerned=20 about is us (and not just MARTINI, but the entire SIP community) getting=20 into a metaphysical debate about whether a solution that is NOT just the=20 moral equivalent of a compressed string of REGISTERs is acceptable. Earlier today, I mentioned that I would expect any such debate to arise at= =20 the worst possible time, and I'd like to document working group consensus -= =20 if we can arrive at that consensus, so that we can quickly respond "yeah, w= e=20 thought about that". - (again, posting this specific point as chair) It seems to me that having= =20 this text in a solutions draft is the wrong place, because solutions would= =20 either have this attribute, or they wouldn't, so we couldn't declare=20 consensus on this point while we're still chatting up the solution draft=20 itself. It's possible that all this is misplaced concern, and that we'll never need= =20 to document that it's important that a solutions draft does have the=20 "compression-equivalent" property, or not (as in, "if GIN has this property= =20 and another solutions draft does not, is that a meaningful advantage for=20 GIN?"). So, for instance, is it an advantage for a specific solution that a SIP-PBX= =20 can remove a single AOR/contact mapping that was registered as part of a=20 bulk registration? If MARTINI=3Dcompress(individual REGISTERs), you could d= o=20 that to an individually-REGISTERed mapping, couldn't you? Thanks for any enlightenment that you guys can pass along, of course. Spencer ----- Original Message ----- From: "Adam Roach" To: "Hans Erik van Elburg" Cc: "Bernard Aboba" ; ;=20 "Hadriel Kaplan" Sent: Monday, May 03, 2010 6:20 PM Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event package= =20 and individual extension state(section 7.2.2)) > On 5/3/10 5:34 PM, Hans Erik van Elburg wrote: >> I was reacting to Spencers question if martini should agree on >> a-bulk-registratiuon-is-the-same-as-a-bunch-of-single-registrations >> criterion that every solution should fulfill. >> I was saying no it is not a relevant criterion. (If that makes me a >> contrarian in your world, then so be it.) >> >> I also said: "Sure a particular solution can document that it has >> that property, fine." >> So if GIN is claiming to have this property then I am fine with that. >> (Not sure it is true though.) >> >> So why do you want me to propose a change to gin in this respect?? >> > > The actual question he asked ("Should that shared understanding go in > the > (various) solution drafts?") was specifically asking about what should > or should not go into the solution drafts. GIN is a solutions draft. > It sounded to me like you were trying to raise a point on this call > for consensus, which I would expect to either take the form of either > "yes, we need to add X to the solutions draft" or "no, I don't think > we need to make any changes to the solutions draft on this topic." > > At this point, I think you read Spencer's question as meaning > something very different than I did. _______________________________________________ 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 HKaplan@acmepacket.com Tue May 4 07:43: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 C276B3A6C44 for ; Tue, 4 May 2010 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 4rnPLt7Ul3VH for ; Tue, 4 May 2010 07:43:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7CCEC3A6B84 for ; Tue, 4 May 2010 07:43:08 -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, 4 May 2010 10:42:51 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 4 May 2010 10:42:51 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Tue, 4 May 2010 10:42:50 -0400 Thread-Topic: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive Thread-Index: AcrrRz02QWY0FEueTdW77yal+c+ydQASBSSA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1D7B@mail> References: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@mail> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive 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, 04 May 2010 14:43:12 -0000 Hi Hans Erik, I _think_ what you're saying is: for the case where a SUBSCRIBE is targeted= to an AoR the PBX implicitly registered for, it should be routed to the PB= X; and for the case where we want the SSP to process it itself, we should d= efine a new target syntax, such as the "bnc" param I use in the draft. In = other words, swap those two cases in the draft from a target URI perspectiv= e. Correct? Obviously that's also a reasonable way to go, but I'd like to make that an = open issue/decision for WG consensus. Personally I prefer it the way in the current vermouth draft: a SUBSCRIBE t= argeted to the AoR gets processed by the SSP just like any other, while a S= UBSCRIBE to the AoR with a URI param of "bnc" gets routed to the PBX. My reasoning is as follows: Currently, for any "normal" Registration model, a SUBSCRIBE targeted to the= AoR gets processed by the SSP. In effect, the combination of that target = URI and the "reg" event package indicator are used as a resource identifier= for getting the SSP's registration state of that AoR. So... 1) Currently, since the SUBSCRIBE's target URI looks like any other AoR of = the SSP, *any* proxy in the SSP can make a simple routing decision to send = all SUBSCRIBEs for reg-event to a specific app server which handles reg-eve= nt, without knowing what "type" of AoR the target URI refers to. If we mak= e SUBSCRIBEs for implicitly registered AoRs route differently, without some= specific indication in the SUBSCRIBE, then that's no longer as simple a th= ing to do. 2) It really is possible for the SSP to support multiple contacts for any A= oR in the set of implicitly registered AoRs. It's not common of course, bu= t I could see an SSP wanting to offer their customers to Register one or mo= re of those same numbers for home-office or traveling users. Those users r= eally will be Registered in the SSP, not the PBX. And the SSP really will = have legitimate, "normal" registration state for that same AoR which is als= o Registered implicitly by the PBX. So for that case the SUBSCRIBE being r= outed differently than normal is really screwed up. 3) Personally, I think in hindsight it was a mistake to have SUBSCRIBEs for= a target URI route differently than any other request for that same target= URI, and route differently for different event packages. That ship has sa= iled, obviously, and all kinds of method-specific and header-specific routi= ng occurs in the real world - but it would be nice not to add yet more comp= lexity by having different routing for a combination of {method + event + A= oR-type}. It's not a huge deal, since we're already down that rabbit hole,= but still it would be nice. -hadriel > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Tuesday, May 04, 2010 1:04 AM > To: Hadriel Kaplan > Cc: martini@ietf.org > Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event > handling for draft-gin and draft-olive >=20 > Hi Hadriel, >=20 > Having thought about this a bit more, I do think that the what would > suffice is having the following usages: >=20 > 5. Subscribing for Registration State Resources > 5.1. Subscribing to AoRs > Where it is in fact "Subscribing to state in the IP-PBX". >=20 > 5.2. Subscribing for all implicitly registered AoRs..........8 > As is. >=20 > As 5.1 is usefull for other UA's the result will not surprise them and > it will be usefull information. > 5.2 is useful for the PBX to monitor its own registration state. >=20 > Then there is no need for SUBSCRIBES with awkward bnc parameters. > I know this violates the principle that this is a normal registration, > but that is because it is not a normal registration. >=20 > Curious if you think this could be a way forward. >=20 > /Hans Erik van Elburg >=20 > On Mon, May 3, 2010 at 11:43 PM, Hans Erik van Elburg > wrote: > > There is some valid ideas in this and with some work it could be made > > to work with several different mechanisms. This does not have to be > > gin specific. > > > > Some issues/questions: > > - the use of the bnc tag to address the AOR behind the PBX seems > > counterintuitive, as one is in fact in this case addressing a normal > > registration... > > - the use of a special tag to mint subscription requests to address > > the AOR behind the PBX assumes knowledge at the subscriber about the > > AOR's terminating arrangement. This is in general problematic. As such > > arrangement should be possible to be freely changed by the receiving > > company, without notifying potential originators. Not to mention the > > security issues with revealing the connection topology. > > - can there be more range parameters? > > - can the range parameter be injected at any place in a string or only > > at the end of the user part? > > - regarding 5.4 open issue, yes bulk AOR's are only short hand > > representation of ranges registered. They themselves are not > > registered and should not be used as AOR's themselves and therefore > > section 5.4 should be removed. And some statement should be made > > somewhere that bulk AOR's can not be used as normal AOR's. In IMS we > > call this wildcarded PUI and those can only be used to match distinct > > PUI's with, same here maybe it is better to talk about wildcarded > > AOR's as it expresses this property better. > > - statements (for ex. 5.1) like "Any internal optimization performed > > by the SSP location-service database for handling Bulk-AoRs MUST NOT > > change this external behavior. " Are not referring to the SUBSCRIBE > > mechanism and therefore inappropriate repetition of an opinion in this > > draft ;-) > > - Appendix A: While I have no problem with simplifying the pattern, to > > enable less configuration errors and complaince with RFC3261. You > > bring back here the issue of automatically detecting provisioning > > mismatches by the PBX. Is this based on something you have seen in > > practice? Why would this be an issue at all? Even in the simplified > > case I don not think that an IP-PBX can conclude anything when it has > > knowledge about the full generated set of AOR's. It suffices to match > > each configured AOR with the patterns returned. > > > > /Hans Erik van Elburg > > > > On Mon, May 3, 2010 at 9:27 PM, Hadriel Kaplan > wrote: > >> > >> Howdy, > >> I have submitted a new draft strawman proposal for reg-event which > tries to accomplish the following: > >> 1) Gives reg-event for open-numbering-plans > >> 2) Subscribes for AoRs *in* the PBX, vs. just SSP's > >> 3) Subscribes for all implicitly registered AoRs (e.g., so PBX can > check it) > >> 4) Creates an acronym for Vermouth > >> > >> Any comments/flames welcomed. > >> > >> -hadriel > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> > >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SIP MARTINI Variant of 'Eve= nt-package for > Registrations' for Managed Open-ended Username Target Handling (VERMOUTH) > >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan, et al. > >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-martini-vermouth= -00.txt > >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19 > >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-03 > >> > >> The Martini Working Group is defining a mechanism for SIP IP-PBX type > devices to REGISTER and obtain SIP service for E.164-based Address of > Records, in [draft-gin]. =A0Another draft [draft-olive] proposes the same > for non-E.164-based AoRs. =A0This document defines a variant of the > Registration Event-package [reg-event] for open-ended AoRs for either > mechanisms, using a wildcard syntax and specific target handling rules. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-kaplan-martini-vermouth- > 00.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. > >> > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > From HKaplan@acmepacket.com Tue May 4 08:03:35 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 338A13A6C75 for ; Tue, 4 May 2010 08:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] 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 eoGEfkGFBrSF for ; Tue, 4 May 2010 08:03:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4FD9A3A6C4C for ; Tue, 4 May 2010 08:03:33 -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, 4 May 2010 11:03:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 4 May 2010 11:03:18 -0400 From: Hadriel Kaplan To: Martien Huysmans , Spencer Dawkins , Brian Lindsay , Adam Roach , Hans Erik van Elburg Date: Tue, 4 May 2010 11:03:17 -0400 Thread-Topic: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) Thread-Index: AcrrPh1ZmhImaMGfSbCmbtQdWYmCmQAKPUQgAAxXTKA= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail> References: <73590937730D49A282BEFFF23EB0E4AC@china.huawei.com> <430FC6BDED356B4C8498F634416644A91A8A5F1BB6@mail> <4BDF436C.7010803@nostrum.com> <4BDF465F.3040104@nostrum.com><4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> 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 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 04 May 2010 15:03:35 -0000 Hi Martien, Just to be clear - what we're talking about is whether the bulk REGISTER sh= ould be logically equivalent to multiple individual/single REGISTERs for ea= ch AoR in the set. But we don't actually mean multiple individual REGISTER= s would be sent to the SSP. No "real" user behind the PBX would ever send = a REGISTER to the SSP - we're only talking about the REGISTER from the PBX,= and whether the rules we define for that should be exactly the same as for= some other world where the PBX sends each REGISTER separately for each AoR= - but still the PBX would be the one sending those REGISTERs by itself, no= t the users behind the PBX. In other words, imagine a multi-line UA/MTA/ga= teway which sends individual REGISTERs - is the bulk REGISTER just a compre= ssed form of that, or something different? (I think you were on the same page already, but I couldn't tell from some o= f your questions) Other comments inline... > -----Original Message----- > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com] > Sent: Tuesday, May 04, 2010 5:57 AM > To: Spencer Dawkins; Brian Lindsay; Adam Roach; Hans Erik van Elburg >=20 > - An PBX user registers with it's PBX. Standard RFC3261, so no > astonishment. Sure, but what AoR is that PBX user actually Registering for? I.e., does t= he PBX user's REGISTER To-URI have something like "sip:+12345@ssp.com" in i= t? Or is it an AoR of the actual PBX, like "sip:12345@192.1.2.3" or "sip:1= 2345@local.pbx.com"? That makes a big difference. =20 > - An PBX registers with the SSP, to be able to send and receive calls. No > astonishment Right, but it's Registering for an AoR *belonging to the SSP*. I.e., "sip:= +12345@ssp.com". =20 > - Having a second "single AoR registration" for that PBX user at the SSP > feels strange. > It seems to be independant of the registration of the PBX user in the > PBX domain. > In the SSP domain an "AOR -> Contact" mapping exists, > even when the PBX user is not registered at the PBX. Yup, and it *should*. The PBX *is* the user, from the SSP's perspective. = It knows nothing about any possible UA's behind the PBX, and it doesn't car= e. The SSP's E.164 was allocated to the PBX, effectively on a static basis= . If a call comes into the SSP for that AoR, it needs to route it to the P= BX no matter what - for example if the "real" UA for that number isn't Regi= stered in the PBX, the PBX might have voicemail, or might forward it to a r= eceptionist or whatever. =20 > - Why mandate that an SSP needs to know the individual users behind an > PBX? > This may be valid for certain cases, but why have it as a general rule? It doesn't know about "individual users behind the PBX" - it knows about Ao= Rs.=20 -hadriel From trac@tools.ietf.org Tue May 4 09:28: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 0CBF828C15D for ; Tue, 4 May 2010 09:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, 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 HEqjGkokw9XJ for ; Tue, 4 May 2010 09:28:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B14D53A69F5 for ; Tue, 4 May 2010 09:26:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O9KwT-0007Ep-2O; Tue, 04 May 2010 09:25:53 -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.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Tue, 04 May 2010 16:25:53 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/15#comment:3 Message-ID: <074.3983acf5f303a8c5ebc3dd4ffbfafb90@tools.ietf.org> References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> 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: Re: [martini] #15: support for non E.164 numbers 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, 04 May 2010 16:28:07 -0000 #15: support for non E.164 numbers -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Changes (by john.elwell@…): * status: reopened => closed * resolution: => fixed -- Ticket URL: martini From trac@tools.ietf.org Tue May 4 09:33:50 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 8E1103A6CB5 for ; Tue, 4 May 2010 09:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, 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 7a5FfhZdc1-a for ; Tue, 4 May 2010 09:33:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0FB463A69B8 for ; Tue, 4 May 2010 09:32:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O9L2B-0006Zk-W2; Tue, 04 May 2010 09:31:48 -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.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: bernard_aboba@hotmail.com, john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Tue, 04 May 2010 16:31:47 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/16#comment:5 Message-ID: <074.cb9159e9197c0e6dc99d2e1b74b5e1a3@tools.ietf.org> References: <065.111f925a59a8643c429a6e1e5e86d2da@tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <065.111f925a59a8643c429a6e1e5e86d2da@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, 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: Re: [martini] #16: Extensibility to support any AOR 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, 04 May 2010 16:33:50 -0000 #16: Extensibility to support any AOR -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: Type: enhancement | Status: closed Priority: critical | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Changes (by john.elwell@…): * status: reopened => closed * resolution: => fixed -- Ticket URL: martini From trac@tools.ietf.org Tue May 4 09:49:57 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 1E6993A6C7D for ; Tue, 4 May 2010 09:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, 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 Ie82Q5PikVjf for ; Tue, 4 May 2010 09:49:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C06F23A6CA9 for ; Tue, 4 May 2010 09:48:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O9LIa-0002Cj-4F; Tue, 04 May 2010 09:48:44 -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.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Tue, 04 May 2010 16:48:44 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/39#comment:3 Message-ID: <076.3d7104764e501a2c94d830a685203bdf@tools.ietf.org> References: <067.f3a7b7aa7fd51ebcf25b5734dc877c4d@tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <067.f3a7b7aa7fd51ebcf25b5734dc877c4d@tools.ietf.org> 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: Re: [martini] #39: Section 1 Explanatory Text 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, 04 May 2010 16:49:57 -0000 #39: Section 1 Explanatory Text ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: john.elwell@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Changes (by john.elwell@…): * status: new => closed * resolution: => fixed -- Ticket URL: martini From john.elwell@siemens-enterprise.com Tue May 4 09:51: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 32A073A69B8 for ; Tue, 4 May 2010 09:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.190, 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 Xokl1dHftXoh for ; Tue, 4 May 2010 09:51:03 -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 C39A73A6C6A for ; Tue, 4 May 2010 09:50:53 -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-56222 for martini@ietf.org; Tue, 4 May 2010 18:50:37 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 053C61EB82AB for ; Tue, 4 May 2010 18:50:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 4 May 2010 18:50:36 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Tue, 4 May 2010 18:50:35 +0200 Thread-Topic: Reqs-05 Thread-Index: AcrrqeqFGCRq8PfQQhKHph5VO/QzRg== Message-ID: 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: [martini] Reqs-05 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, 04 May 2010 16:51:05 -0000 Reqs-05 is now available: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-05.txt Changes from 04: - Resolution of issues #15, #16 and #39 as agreed at interim meeting and co= nfirmed by consensus call on list. All issues are closed at this point in time. John= From root@core3.amsl.com Tue May 4 10:00:01 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 8CD1C3A6A30; Tue, 4 May 2010 10: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: <20100504170001.8CD1C3A6A30@core3.amsl.com> Date: Tue, 4 May 2010 10:00:01 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-reqs-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, 04 May 2010 17: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-05.txt Pages : 13 Date : 2010-05-04 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 PBXs. The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This work is being discussed on the martini@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-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-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-04094908.I-D@ietf.org> --NextPart-- From bernard_aboba@hotmail.com Tue May 4 12:50: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 218D228C5FC for ; Tue, 4 May 2010 12:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[AWL=0.347, 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 N950+kJzFypx for ; Tue, 4 May 2010 12:50:23 -0700 (PDT) Received: from blu0-omc2-s5.blu0.hotmail.com (blu0-omc2-s5.blu0.hotmail.com [65.55.111.80]) by core3.amsl.com (Postfix) with ESMTP id 3DC9528C4A4 for ; Tue, 4 May 2010 12:13:40 -0700 (PDT) Received: from BLU137-DS1 ([65.55.111.73]) by blu0-omc2-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 May 2010 12:13:26 -0700 X-Originating-IP: [131.107.0.117] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 4 May 2010 12:13:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0428_01CAEB83.31B99710" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcrrvaKxbDWoul6pSgqETCs+ydNLPw== Content-Language: en-us X-OriginalArrivalTime: 04 May 2010 19:13:26.0403 (UTC) FILETIME=[DF784D30:01CAEBBD] Subject: [martini] Draft PROTO writeup for MARTINI Requirements Document 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, 04 May 2010 19:50:30 -0000 ------=_NextPart_000_0428_01CAEB83.31B99710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit PROTO Writeup for draft-ietf-martini-reqs ================================================= http://tools.ietf.org/html/draft-ietf-martini-reqs (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Bernard Aboba is the document shepherd. I have personally reviewed the document, and believe it is ready for publication as an Informational RFC. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been extensively discussed on the MARTINI WG mailing list. The discussion has included representatives from both the PBX and service-provider communities as well as participants in 3GPP and SIPForum. As a result, the reviews appear to have been reasonably thorough and representative. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There has been vigorous discussion in a number of the requirements included in the document, but those issues have been resolved. As a result, there appears to be strong consensus behind the document, and the working group is using the requirements in evaluating proposed protocol solutions. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? IDNits are clean: idnits 2.12.02 tmp/draft-ietf-martini-reqs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. No nits found. ---------------------------------------------------------------------------- ---- (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references in the document have been split into normative and informative. Normative references are all stable documents published as RFCs. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA Considerations section exists (section 7). It requires no action by IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 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. ------=_NextPart_000_0428_01CAEB83.31B99710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

PROTO = Writeup for draft-ietf-martini-reqs

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

= http://tools.ietf.org/html/draft-ietf-martini-reqs

 

   = (1.a)  Who is the Document Shepherd for this document?  Has = the

      = Document Shepherd personally reviewed this version of the = document

      and, in particular, = does he or she believe this version is ready

      for forwarding to the = IESG for publication?

 

Bernard = Aboba is the document shepherd.  I have personally = reviewed

the document, and believe it = is ready for publication as an Informational RFC.

 

   = (1.b)  Has the document had adequate review both from key members = of

      the = interested community and others?  Does the Document = Shepherd

      have any concerns about = the depth or breadth of the reviews that

      have been = performed?

 

The document has been extensively discussed on the = MARTINI WG mailing list.  The discussion has

included representatives from both the PBX and = service-provider communities as well as

participants in 3GPP and SIPForum.  As a result, = the reviews appear to have been

reasonably thorough and representative. =

 

   (1.c)  Does the Document Shepherd = have concerns that the document

      needs more review from = a particular or broader perspective, e.g.,

      security, operational = complexity, someone familiar with AAA,

      internationalization or = XML?

 

No concerns.

 

   = (1.d)  Does the Document Shepherd have any specific concerns = or

      = issues with this document that the Responsible Area = Director

      and/or the IESG should = be aware of?  For example, perhaps he or

      she is uncomfortable = with certain parts of the document, or has

      concerns whether there = really is a need for it.  In any event, if

      the interested = community has discussed those issues and has

      indicated that it still = wishes to advance the document, detail

      those concerns = here.

 

No concerns.

 

   = (1.e)  How solid is the consensus of the interested community = behind

      = this document?  Does it represent the strong concurrence of a = few

      = individuals, with others being silent, or does the = interested

      community as a whole = understand and agree with it?

 

There has = been vigorous discussion in a number of the requirements included in the = document,

but those issues have been = resolved.  As a result, there appears to be strong consensus = behind

the document, and the working = group is using the requirements in evaluating proposed

protocol solutions.

 

   = (1.f)  Has anyone threatened an appeal or otherwise indicated = extreme

      discontent?  If = so, please summarise the areas of conflict in

      separate email messages = to the Responsible Area Director.  (It

      should be in a separate = email because this questionnaire is

      entered into the ID = Tracker.)

 

No.

 

   = (1.g)  Has the Document Shepherd personally verified that = the

      = document satisfies all ID nits?  (See

      = http://www.ietf.org/ID-Checklist.html and

      = http://tools.ietf.org/tools/idnits/).  Boilerplate checks are = not

      = enough; this check needs to be thorough.  Has the document met = all

      = formal review criteria it needs to, such as the MIB Doctor, = media

      = type and URI type reviews?

 

IDNits are = clean:

 

idnits 2.12.02

 

tmp/draft-ietf-martini-reqs-05.txt:

 

  = Checking boilerplate required by RFC 5378 and the IETF Trust = (see

  = http://trustee.ietf.org/license-info):

  = -------------------------------------------------------------------------= ---

 

     No issues found = here.

 

  Checking nits according to = http://www.ietf.org/id-info/1id-guidelines.txt:

  = -------------------------------------------------------------------------= ---

 

     No issues found = here.

 

  Checking nits according to = http://www.ietf.org/id-info/checklist :

  = -------------------------------------------------------------------------= ---

 

     No issues found = here.

 

  Miscellaneous warnings:

  = -------------------------------------------------------------------------= ---

 

     No issues found = here.

 

  Checking references for intended status: = Informational

  = -------------------------------------------------------------------------= ---

 

     No issues found = here.

 

     No nits = found.

-------------------------------------------------------= -------------------------

 

   = (1.h)  Has the document split its references into normative = and

      = informative?  Are there normative references to documents that = are

      = not ready for advancement or are otherwise in an unclear = state?

      = If such normative references exist, what is the strategy for = their

      = completion?  Are there normative references that are = downward

      references, as = described in [RFC3967]?  If so, list these = downward

      references to support = the Area Director in the Last Call procedure

      for them = [RFC3967].

 

The references in the document have been split into = normative and informative.

 

Normative = references are all stable documents published as RFCs.

 

   = (1.i)  Has the Document Shepherd verified that the document = IANA

      = consideration section exists and is consistent with the body = of

      the = document?  If the document specifies protocol extensions, = are

      = reservations requested in appropriate IANA registries?  Are = the

      = IANA registries clearly identified?  If the document creates a = new

      = registry, does it define the proposed initial contents of = the

      = registry and an allocation procedure for future = registrations?

      Does it suggested a = reasonable name for the new registry?  See

      = [I-D.narten-iana-considerations-rfc2434bis].  If the = document

      describes an Expert = Review process has Shepherd conferred with the

     Responsible Area = Director so that the IESG can appoint the needed

      Expert during the IESG = Evaluation?

 

The IANA Considerations section exists (section = 7).  It requires no action by IANA.

 

   = (1.j)  Has the Document Shepherd verified that sections of = the

      = document that are written in a formal language, such as XML = code,

      = BNF rules, MIB definitions, etc., validate correctly in = an

      = automated checker?

 

Not = applicable.

 

   (1.k)  The IESG approval = announcement includes a Document

      Announcement = Write-Up.  Please provide such a Document

      Announcement = Writeup?  Recent examples can be found in the

      "Action" = announcements for approved documents.  The = approval

      announcement contains = the following sections:

=

      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.

------=_NextPart_000_0428_01CAEB83.31B99710-- From spencer@wonderhamster.org Wed May 5 02:09:01 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 D218B3A6BB7 for ; Wed, 5 May 2010 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.945, 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 OpFF9bRwf5wo for ; Wed, 5 May 2010 02:08:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 48B5F3A6BBD for ; Wed, 5 May 2010 02:08:58 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MMkL9-1OHYHH30HP-0080tn; Wed, 05 May 2010 05:08:36 -0400 Message-ID: <2F00EA045C064CB78BA74D23D29D57F8@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , References: Date: Wed, 5 May 2010 04:08:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/E2D53FzlABpLIew1hLRRwaQbYdV8y137ezTM 0CCiCIIm7PnREdKmA2NyHM3//3Romu6AgfXGoZuGjbs0bY+BxD iOmj2jkkgbHqW91KCllEHx8ylSkWvz1dPILGZt9UKM= Subject: Re: [martini] Draft PROTO writeup for MARTINI Requirements Document 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, 05 May 2010 09:09:02 -0000 Just to provide context... we're at zero open issues on the requirements draft after working group last call, and we've decided not to put anything in the requirements draft about bulk registration working the same way as multiple individual registrations, which was the last relevant mailing list topic, so we're planning to request publication of this draft Real Soon Now. We are planning to do the same thing with solutions drafts as they hit zero open issues after working group last call, so please be prepared to move pretty quickly. Not that "move pretty quickly" is new... Thanks, Spencer, as co-chair ----- Original Message ----- From: Bernard Aboba To: martini@ietf.org Sent: Tuesday, May 04, 2010 2:13 PM Subject: [martini] Draft PROTO writeup for MARTINI Requirements Document PROTO Writeup for draft-ietf-martini-reqs ================================================= http://tools.ietf.org/html/draft-ietf-martini-reqs (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Bernard Aboba is the document shepherd. I have personally reviewed the document, and believe it is ready for publication as an Informational RFC. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been extensively discussed on the MARTINI WG mailing list. The discussion has included representatives from both the PBX and service-provider communities as well as participants in 3GPP and SIPForum. As a result, the reviews appear to have been reasonably thorough and representative. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There has been vigorous discussion in a number of the requirements included in the document, but those issues have been resolved. As a result, there appears to be strong consensus behind the document, and the working group is using the requirements in evaluating proposed protocol solutions. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? IDNits are clean: idnits 2.12.02 tmp/draft-ietf-martini-reqs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. No nits found. -------------------------------------------------------------------------------- (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references in the document have been split into normative and informative. Normative references are all stable documents published as RFCs. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA Considerations section exists (section 7). It requires no action by IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 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. _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Wed May 5 02:15:26 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 BCE193A6BBA for ; Wed, 5 May 2010 02:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=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 XxSJxMv5in9p for ; Wed, 5 May 2010 02:15: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 D8C363A69CC for ; Wed, 5 May 2010 02:14:39 -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-63274; Wed, 5 May 2010 11:14:25 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 6777C1EB82AB; Wed, 5 May 2010 11:14:25 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 5 May 2010 11:14:25 +0200 From: "Elwell, John" To: Hadriel Kaplan , Hans Erik van Elburg Date: Wed, 5 May 2010 11:14:23 +0200 Thread-Topic: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive Thread-Index: AcrrRz02QWY0FEueTdW77yal+c+ydQASBSSAACi7dzA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@mail> <430FC6BDED356B4C8498F634416644A91A8A5F1D7B@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1D7B@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive 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, 05 May 2010 09:15:26 -0000 Hadriel, I am concerned that it is somewhat counter-intuitive from a subscriber poin= t of view to have to put in a special parameter to get to the PBX. I am not= sure how the reg-event package is used in practice, but suppose some prese= nce-like application is using reg-event to see whether any device is curren= tly registered for a user. It is not aware that +12345 is behind a PBX, so = it subscribes to reg-event at +12345, without any special parameter, gets b= ack the contact sip:+12345@192.168.0.8, and concludes yes, there is a devic= e present. Yet behind the PBX, there may be no device registered against +1= 2345. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 04 May 2010 15:43 > To: Hans Erik van Elburg > Cc: martini@ietf.org > Subject: Re: [martini] draft-kaplan-martini-vermouth-00:=20 > reg-event handling for draft-gin and draft-olive >=20 >=20 > Hi Hans Erik, > I _think_ what you're saying is: for the case where a=20 > SUBSCRIBE is targeted to an AoR the PBX implicitly registered=20 > for, it should be routed to the PBX; and for the case where=20 > we want the SSP to process it itself, we should define a new=20 > target syntax, such as the "bnc" param I use in the draft. =20 > In other words, swap those two cases in the draft from a=20 > target URI perspective. >=20 > Correct? >=20 > Obviously that's also a reasonable way to go, but I'd like to=20 > make that an open issue/decision for WG consensus. >=20 > Personally I prefer it the way in the current vermouth draft:=20 > a SUBSCRIBE targeted to the AoR gets processed by the SSP=20 > just like any other, while a SUBSCRIBE to the AoR with a URI=20 > param of "bnc" gets routed to the PBX. >=20 > My reasoning is as follows: > Currently, for any "normal" Registration model, a SUBSCRIBE=20 > targeted to the AoR gets processed by the SSP. In effect,=20 > the combination of that target URI and the "reg" event=20 > package indicator are used as a resource identifier for=20 > getting the SSP's registration state of that AoR. So... >=20 > 1) Currently, since the SUBSCRIBE's target URI looks like any=20 > other AoR of the SSP, *any* proxy in the SSP can make a=20 > simple routing decision to send all SUBSCRIBEs for reg-event=20 > to a specific app server which handles reg-event, without=20 > knowing what "type" of AoR the target URI refers to. If we=20 > make SUBSCRIBEs for implicitly registered AoRs route=20 > differently, without some specific indication in the=20 > SUBSCRIBE, then that's no longer as simple a thing to do. >=20 > 2) It really is possible for the SSP to support multiple=20 > contacts for any AoR in the set of implicitly registered=20 > AoRs. It's not common of course, but I could see an SSP=20 > wanting to offer their customers to Register one or more of=20 > those same numbers for home-office or traveling users. Those=20 > users really will be Registered in the SSP, not the PBX. And=20 > the SSP really will have legitimate, "normal" registration=20 > state for that same AoR which is also Registered implicitly=20 > by the PBX. So for that case the SUBSCRIBE being routed=20 > differently than normal is really screwed up. >=20 > 3) Personally, I think in hindsight it was a mistake to have=20 > SUBSCRIBEs for a target URI route differently than any other=20 > request for that same target URI, and route differently for=20 > different event packages. That ship has sailed, obviously,=20 > and all kinds of method-specific and header-specific routing=20 > occurs in the real world - but it would be nice not to add=20 > yet more complexity by having different routing for a=20 > combination of {method + event + AoR-type}. It's not a huge=20 > deal, since we're already down that rabbit hole, but still it=20 > would be nice. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: Tuesday, May 04, 2010 1:04 AM > > To: Hadriel Kaplan > > Cc: martini@ietf.org > > Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event > > handling for draft-gin and draft-olive > >=20 > > Hi Hadriel, > >=20 > > Having thought about this a bit more, I do think that the what would > > suffice is having the following usages: > >=20 > > 5. Subscribing for Registration State Resources > > 5.1. Subscribing to AoRs > > Where it is in fact "Subscribing to state in the IP-PBX". > >=20 > > 5.2. Subscribing for all implicitly registered=20 > AoRs..........8 > > As is. > >=20 > > As 5.1 is usefull for other UA's the result will not=20 > surprise them and > > it will be usefull information. > > 5.2 is useful for the PBX to monitor its own registration state. > >=20 > > Then there is no need for SUBSCRIBES with awkward bnc parameters. > > I know this violates the principle that this is a normal=20 > registration, > > but that is because it is not a normal registration. > >=20 > > Curious if you think this could be a way forward. > >=20 > > /Hans Erik van Elburg > >=20 > > On Mon, May 3, 2010 at 11:43 PM, Hans Erik van Elburg > > wrote: > > > There is some valid ideas in this and with some work it=20 > could be made > > > to work with several different mechanisms. This does not=20 > have to be > > > gin specific. > > > > > > Some issues/questions: > > > - the use of the bnc tag to address the AOR behind the PBX seems > > > counterintuitive, as one is in fact in this case=20 > addressing a normal > > > registration... > > > - the use of a special tag to mint subscription requests=20 > to address > > > the AOR behind the PBX assumes knowledge at the=20 > subscriber about the > > > AOR's terminating arrangement. This is in general=20 > problematic. As such > > > arrangement should be possible to be freely changed by=20 > the receiving > > > company, without notifying potential originators. Not to=20 > mention the > > > security issues with revealing the connection topology. > > > - can there be more range parameters? > > > - can the range parameter be injected at any place in a=20 > string or only > > > at the end of the user part? > > > - regarding 5.4 open issue, yes bulk AOR's are only short hand > > > representation of ranges registered. They themselves are not > > > registered and should not be used as AOR's themselves and=20 > therefore > > > section 5.4 should be removed. And some statement should be made > > > somewhere that bulk AOR's can not be used as normal=20 > AOR's. In IMS we > > > call this wildcarded PUI and those can only be used to=20 > match distinct > > > PUI's with, same here maybe it is better to talk about wildcarded > > > AOR's as it expresses this property better. > > > - statements (for ex. 5.1) like "Any internal=20 > optimization performed > > > by the SSP location-service database for handling=20 > Bulk-AoRs MUST NOT > > > change this external behavior. " Are not referring to the=20 > SUBSCRIBE > > > mechanism and therefore inappropriate repetition of an=20 > opinion in this > > > draft ;-) > > > - Appendix A: While I have no problem with simplifying=20 > the pattern, to > > > enable less configuration errors and complaince with RFC3261. You > > > bring back here the issue of automatically detecting provisioning > > > mismatches by the PBX. Is this based on something you have seen in > > > practice? Why would this be an issue at all? Even in the=20 > simplified > > > case I don not think that an IP-PBX can conclude anything=20 > when it has > > > knowledge about the full generated set of AOR's. It=20 > suffices to match > > > each configured AOR with the patterns returned. > > > > > > /Hans Erik van Elburg > > > > > > On Mon, May 3, 2010 at 9:27 PM, Hadriel Kaplan=20 > > > wrote: > > >> > > >> Howdy, > > >> I have submitted a new draft strawman proposal for=20 > reg-event which > > tries to accomplish the following: > > >> 1) Gives reg-event for open-numbering-plans > > >> 2) Subscribes for AoRs *in* the PBX, vs. just SSP's > > >> 3) Subscribes for all implicitly registered AoRs (e.g.,=20 > so PBX can > > check it) > > >> 4) Creates an acronym for Vermouth > > >> > > >> Any comments/flames welcomed. > > >> > > >> -hadriel > > >> > > >> > > >> A New Internet-Draft is available from the on-line=20 > Internet-Drafts > > directories. > > >> > > >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SIP MARTINI Variant of=20 > 'Event-package for > > Registrations' for Managed Open-ended Username Target=20 > Handling (VERMOUTH) > > >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan, et al. > > >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-martini-vermou= th-00.txt > > >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19 > > >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-03 > > >> > > >> The Martini Working Group is defining a mechanism for=20 > SIP IP-PBX type > > devices to REGISTER and obtain SIP service for E.164-based=20 > Address of > > Records, in [draft-gin]. =A0Another draft [draft-olive]=20 > proposes the same > > for non-E.164-based AoRs. =A0This document defines a variant of the > > Registration Event-package [reg-event] for open-ended AoRs=20 > for either > > mechanisms, using a wildcard syntax and specific target=20 > handling rules. > > >> > > >> A URL for this Internet-Draft is: > > >>=20 > http://www.ietf.org/internet-drafts/draft-kaplan-martini-vermouth- > > 00.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. > > >> > > >> > > >> _______________________________________________ > > >> 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 ietf.hanserik@gmail.com Wed May 5 07:13: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 488963A6D39 for ; Wed, 5 May 2010 07:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.223 X-Spam-Level: X-Spam-Status: No, score=-1.223 tagged_above=-999 required=5 tests=[AWL=-1.038, 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 Cx34q3K8K6K7 for ; Wed, 5 May 2010 07:12:59 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id DC4ED3A6C23 for ; Wed, 5 May 2010 07:08:05 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so223470eyf.51 for ; Wed, 05 May 2010 07:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MT5bBmbGEiWSX+EpcHmjQBrSXeHRwImBT8jgQHx51fc=; b=gSGRJEcDb5v5Oz6A17wIn7CZM46GAHbuAEmmcRJs0p3TR8AvlQtUsjn3DXYV/AGMpE QqKJbBOFnkqJq4HlamfK1h1Nr8zxe2OhrWzN5BcNDIr4GGl34gDlZZ4gYeGMneq0binK R7wnvtPsPic6+wQf9uG+7bnM0mw3leCN//rYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OgaEL9QlKUp7rxLsQ2Z77aBhv+PS2IkB1SUOe0bIKbit3k0DgP18YQgvIrq7nvxmh0 8bhW9udCRZ0LW9Wu+4+b8ljGFxp7qEOha+KHzml4qBNBEI1s5lFv0ACculM6vO41lT7S HIXTzgLBAGzU8Ku09Wqz5WIgk/vUCAsmfzR8Y= MIME-Version: 1.0 Received: by 10.213.76.12 with SMTP id a12mr7100901ebk.55.1273068469160; Wed, 05 May 2010 07:07:49 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Wed, 5 May 2010 07:07:49 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1D7B@mail> References: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@mail> <430FC6BDED356B4C8498F634416644A91A8A5F1D7B@mail> Date: Wed, 5 May 2010 16:07:49 +0200 Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive 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, 05 May 2010 14:13:00 -0000 On Tue, May 4, 2010 at 4:42 PM, Hadriel Kaplan wro= te: > > Hi Hans Erik, > I _think_ what you're saying is: for the case where a SUBSCRIBE is target= ed to an AoR the PBX implicitly registered for, it should be routed to the = PBX; and for the case where we want the SSP to process it itself, we should= define a new target syntax, such as the "bnc" param I use in the draft. = =A0In other words, swap those two cases in the draft from a target URI pers= pective. > > Correct? > [HE] Yes you could interpret it like that. But I also think there is no need for the case where the SSP returns the result, so I would just suggest to remove that unless there is a use case for which this information is usefull. > Obviously that's also a reasonable way to go, but I'd like to make that a= n open issue/decision for WG consensus. > > Personally I prefer it the way in the current vermouth draft: a SUBSCRIBE= targeted to the AoR gets processed by the SSP just like any other, while a= SUBSCRIBE to the AoR with a URI param of "bnc" gets routed to the PBX. > > My reasoning is as follows: > Currently, for any "normal" Registration model, a SUBSCRIBE targeted to t= he AoR gets processed by the SSP. =A0In effect, the combination of that tar= get URI and the "reg" event package indicator are used as a resource identi= fier for getting the SSP's registration state of that AoR. =A0So... > Yes for normal registrations you may view it like that. > 1) Currently, since the SUBSCRIBE's target URI looks like any other AoR o= f the SSP, *any* proxy in the SSP can make a simple routing decision to sen= d all SUBSCRIBEs for reg-event to a specific app server which handles reg-e= vent, without knowing what "type" of AoR the target URI refers to. =A0If we= make SUBSCRIBEs for implicitly registered AoRs route differently, without = some specific indication in the SUBSCRIBE, then that's no longer as simple = a thing to do. > I do not agree, the location server can together with the location where the AOR can be reached return information that this is a bulk contact. That information can be used by the SSP's proxy to apply proper handling. > 2) It really is possible for the SSP to support multiple contacts for any= AoR in the set of implicitly registered AoRs. =A0It's not common of course= , but I could see an SSP wanting to offer their customers to Register one o= r more of those same numbers for home-office or traveling users. =A0Those u= sers really will be Registered in the SSP, not the PBX. =A0And the SSP real= ly will have legitimate, "normal" registration state for that same AoR whic= h is also Registered implicitly by the PBX. =A0So for that case the SUBSCRI= BE being routed differently than normal is really screwed up. > This is a very strange use case, normally you either receive service from the SSP (centrex scenario) or from the PBX. Mixing those two is asking for problems. Conflicting service configurations etc. In such a case the user would rather have two different AOR's. > 3) Personally, I think in hindsight it was a mistake to have SUBSCRIBEs f= or a target URI route differently than any other request for that same targ= et URI, and route differently for different event packages. =A0That ship ha= s sailed, obviously, and all kinds of method-specific and header-specific r= outing occurs in the real world - but it would be nice not to add yet more = complexity by having different routing for a combination of {method + event= + AoR-type}. =A0It's not a huge deal, since we're already down that rabbit= hole, but still it would be nice. > The more impportant criterion is if the result that the subscriber expects is usefull and meaningful. That there will be slight differences certain behaviours for bulk registrations is completely OK. And the complexity added is minor really. /Hans Erik From ietf.hanserik@gmail.com Wed May 5 07:37:54 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 F359E28C222 for ; Wed, 5 May 2010 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_20=-0.74, J_CHICKENPOX_57=0.6] 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 lALqRPp3N-fd for ; Wed, 5 May 2010 07:37:53 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 352E828C2BC for ; Wed, 5 May 2010 07:31:38 -0700 (PDT) Received: by ewy24 with SMTP id 24so1362835ewy.33 for ; Wed, 05 May 2010 07:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l1zJ9BPoUp3/u0zNWJSIV9DWMdelsgBUJkAFi6teMaw=; b=mdK79jr38wZbXvTy1sPj2PjLo/bqelrSCTS3OcH8QcYQ31y+yUnjgXnxzydfnddGjB FUGBQcLGbKNrVjJQJkmBhBSA6QSvFLXZGO2923Wr8UAnA7B/fMO/QnSxjNsce/ymj1vQ 2Bf6tPNO9Gp28Bpx3io3KJRdxqpdMlf76s7OM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jPWgjyK5Os8GftTNjVbML5Qo/HEt8S2AH+pRsKBmgTdr60AHNw74S/Y8tKw2BozMf/ tJKQ4ACG5hsyNxNhGyADow96DRV5nlLj1IGTArxKelCDCaT7u2ktBfj+Blp/wUGcxs7J xPcZktxKgSOCRw4/cYQIBdlcbRTGVM0/y96EY= MIME-Version: 1.0 Received: by 10.213.52.201 with SMTP id j9mr7075992ebg.87.1273069881412; Wed, 05 May 2010 07:31:21 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Wed, 5 May 2010 07:31:21 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail> References: <4BDF465F.3040104@nostrum.com> <4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail> Date: Wed, 5 May 2010 16:31:21 +0200 Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" , Bernard Aboba Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 05 May 2010 14:37:54 -0000 On Tue, May 4, 2010 at 5:03 PM, Hadriel Kaplan wro= te: >> - An PBX registers with the SSP, to be able to send and receive calls. N= o >> astonishment > > Right, but it's Registering for an AoR *belonging to the SSP*. =A0I.e., "= sip:+12345@ssp.com". > [HE] Think it is more correct to say that it is registering reachability information for a bulk contact, which is then bound by the SSP to a bunch of implicitly registered AOR's. These AOR's dop not have to belong to the SSP, but they can. The SSP's proxy is responsible for handling them and forwarding them applying rules that apply to bulk contacts. > >> - Having a second "single AoR registration" for that PBX user at the SSP >> feels strange. >> =A0 It seems to be independant of the registration of the PBX user in th= e >> PBX domain. >> =A0 In the SSP domain an "AOR -> Contact" mapping exists, >> =A0 even when the PBX user is not registered at the PBX. > > Yup, and it *should*. =A0The PBX *is* the user, from the SSP's perspectiv= e. =A0It knows nothing about any possible UA's behind the PBX, and it doesn= 't care. =A0The SSP's E.164 was allocated to the PBX, effectively on a stat= ic basis. =A0If a call comes into the SSP for that AoR, it needs to route i= t to the PBX no matter what - for example if the "real" UA for that number = isn't Registered in the PBX, the PBX might have voicemail, or might forward= it to a receptionist or whatever. > [HE] The SSP's proxy knows that this is a bulkcontact and hence that it is not the last responsible entity for the AOR. In fact this is not a normal "single AoR registration" it is really a special one. The description that describes the semantics in terns of single location service entries, is just a way of expressing it. We should not confuse this to mean that the bulkregistration created entry is just like a normal registration. Therefore the current semantics description might be misleading, but I always thought that it wasn't as it explicitly says that you do not have to implement it like that. > >> - Why mandate that an SSP needs to know the individual users behind an >> PBX? >> =A0 This may be valid for certain cases, but why have it as a general ru= le? > > It doesn't know about "individual users behind the PBX" - it knows about = AoRs. > [HE] Yes, for once I agree. This is no different then the IMS solution where Wildcarded PUI's or Distinct PUI's are implicitly registered. Those have to be provisioned in the HSS of the SSP. How you do that and if you give companies a means to provision this themsleves using some portal or so, is outside the scope of the martini discussion. But it can be done. From ietf.hanserik@gmail.com Wed May 5 10:06:29 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 297593A6B91 for ; Wed, 5 May 2010 10:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 8xGdgjw59dEM for ; Wed, 5 May 2010 10:06:27 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 4B7E13A6A10 for ; Wed, 5 May 2010 10:06:24 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so6975eyf.51 for ; Wed, 05 May 2010 10:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/T1rwCOGvuCFoLwByB6xNbma2DM+EJ0kTrniMM4oX0I=; b=RsV/HOc6AuoOb1ejbVLNgk8LUqgC1+BVaVTlUceJwfYgUxSoUzMvif+mHTXOp+unKK MVirGZLUO3bAg3iXTAwmENHHhXRJt1OaCpTNIRmZ3UyXVcgT5Z+AFz14jJq1qUfRKGhA bYbGYPmqpJf37WyvHN9eVoHefWZW9tesJeiM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=luVzsQB/HotTYAxA3ODDjnGkHuZZunYm4PKdO5bsTmF0Fjos1mRNv+V/WcfT4bUNwU Og+ykv7GIGpwFAC2c5eeOUUaVq+KYNwK7WEAHI+Uv0hOJ5wGyBv8F7PLXvKIWowxewqV DV9fZd5V7rNtijCZvIV3kTVsJ7Yq5sQ8HnOX4= MIME-Version: 1.0 Received: by 10.213.50.195 with SMTP id a3mr4985693ebg.13.1273079167683; Wed, 05 May 2010 10:06:07 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Wed, 5 May 2010 10:06:07 -0700 (PDT) In-Reply-To: <2F00EA045C064CB78BA74D23D29D57F8@china.huawei.com> References: <2F00EA045C064CB78BA74D23D29D57F8@china.huawei.com> Date: Wed, 5 May 2010 19:06:07 +0200 Message-ID: From: Hans Erik van Elburg To: Spencer Dawkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] Draft PROTO writeup for MARTINI Requirements Document 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, 05 May 2010 17:06:29 -0000 Hi Bernard, Spencer, How much time do people get to do a full reread of the latest requirements draft, for which a new version was just been submitted yesterday. After the main issues are resolved people may want to propose less major improvements to text, to make it really ready for publication. What is the process? When does WGLC end? /Hans Erik van Elburg On Wed, May 5, 2010 at 11:08 AM, Spencer Dawkins wrote: > Just to provide context... we're at zero open issues on the requirements > draft after working group last call, and we've decided not to put anythin= g > in the requirements draft about bulk registration working the same way as > multiple individual registrations, which was the last relevant mailing li= st > topic, so we're planning to request publication of this draft Real Soon N= ow. > > We are planning to do the same thing with solutions drafts as they hit ze= ro > open issues after working group last call, so please be prepared to move > pretty quickly. Not that "move pretty quickly" is new... > > Thanks, > > Spencer, as co-chair > > ----- Original Message ----- From: Bernard Aboba > To: martini@ietf.org > Sent: Tuesday, May 04, 2010 2:13 PM > Subject: [martini] Draft PROTO writeup for MARTINI Requirements Document > > > > PROTO Writeup for draft-ietf-martini-reqs > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > http://tools.ietf.org/html/draft-ietf-martini-reqs > > =A0(1.a) =A0Who is the Document Shepherd for this document? =A0Has the > =A0 =A0 Document Shepherd personally reviewed this version of the documen= t > =A0 =A0 and, in particular, does he or she believe this version is ready > =A0 =A0 for forwarding to the IESG for publication? > > Bernard Aboba is the document shepherd. =A0I have personally reviewed > the document, and believe it is ready for publication as an Informational > RFC. > > =A0(1.b) =A0Has the document had adequate review both from key members of > =A0 =A0 the interested community and others? =A0Does the Document Shepher= d > =A0 =A0 have any concerns about the depth or breadth of the reviews that > =A0 =A0 have been performed? > > The document has been extensively discussed on the MARTINI WG mailing lis= t. > The discussion has > included representatives from both the PBX and service-provider communiti= es > as well as > participants in 3GPP and SIPForum. =A0As a result, the reviews appear to = have > been > reasonably thorough and representative. > > =A0(1.c) =A0Does the Document Shepherd have concerns that the document > =A0 =A0 needs more review from a particular or broader perspective, e.g., > =A0 =A0 security, operational complexity, someone familiar with AAA, > =A0 =A0 internationalization or XML? > > No concerns. > > =A0(1.d) =A0Does the Document Shepherd have any specific concerns or > =A0 =A0 issues with this document that the Responsible Area Director > =A0 =A0 and/or the IESG should be aware of? =A0For example, perhaps he or > =A0 =A0 she is uncomfortable with certain parts of the document, or has > =A0 =A0 concerns whether there really is a need for it. =A0In any event, = if > =A0 =A0 the interested community has discussed those issues and has > =A0 =A0 indicated that it still wishes to advance the document, detail > =A0 =A0 those concerns here. > > No concerns. > > =A0(1.e) =A0How solid is the consensus of the interested community behind > =A0 =A0 this document? =A0Does it represent the strong concurrence of a f= ew > =A0 =A0 individuals, with others being silent, or does the interested > =A0 =A0 community as a whole understand and agree with it? > > There has been vigorous discussion in a number of the requirements includ= ed > in the document, > but those issues have been resolved. =A0As a result, there appears to be > strong consensus behind > the document, and the working group is using the requirements in evaluati= ng > proposed > protocol solutions. > > =A0(1.f) =A0Has anyone threatened an appeal or otherwise indicated extrem= e > =A0 =A0 discontent? =A0If so, please summarise the areas of conflict in > =A0 =A0 separate email messages to the Responsible Area Director. =A0(It > =A0 =A0 should be in a separate email because this questionnaire is > =A0 =A0 entered into the ID Tracker.) > > No. > > =A0(1.g) =A0Has the Document Shepherd personally verified that the > =A0 =A0 document satisfies all ID nits? =A0(See > =A0 =A0 http://www.ietf.org/ID-Checklist.html and > =A0 =A0 http://tools.ietf.org/tools/idnits/). =A0Boilerplate checks are n= ot > =A0 =A0 enough; this check needs to be thorough. =A0Has the document met = all > =A0 =A0 formal review criteria it needs to, such as the MIB Doctor, media > =A0 =A0 type and URI type reviews? > > IDNits are clean: > > idnits 2.12.02 > > tmp/draft-ietf-martini-reqs-05.txt: > > =A0Checking boilerplate required by RFC 5378 and the IETF Trust (see > =A0http://trustee.ietf.org/license-info): > =A0----------------------------------------------------------------------= ------ > > =A0 =A0No issues found here. > > =A0Checking nits according to http://www.ietf.org/id-info/1id-guidelines.= txt: > =A0----------------------------------------------------------------------= ------ > > =A0 =A0No issues found here. > > =A0Checking nits according to http://www.ietf.org/id-info/checklist : > =A0----------------------------------------------------------------------= ------ > > =A0 =A0No issues found here. > > =A0Miscellaneous warnings: > =A0----------------------------------------------------------------------= ------ > > =A0 =A0No issues found here. > > =A0Checking references for intended status: Informational > =A0----------------------------------------------------------------------= ------ > > =A0 =A0No issues found here. > > =A0 =A0No nits found. > -------------------------------------------------------------------------= ------- > > =A0(1.h) =A0Has the document split its references into normative and > =A0 =A0 informative? =A0Are there normative references to documents that = are > =A0 =A0 not ready for advancement or are otherwise in an unclear state? > =A0 =A0 If such normative references exist, what is the strategy for thei= r > =A0 =A0 completion? =A0Are there normative references that are downward > =A0 =A0 references, as described in [RFC3967]? =A0If so, list these downw= ard > =A0 =A0 references to support the Area Director in the Last Call procedur= e > =A0 =A0 for them [RFC3967]. > > The references in the document have been split into normative and > informative. > > Normative references are all stable documents published as RFCs. > > =A0(1.i) =A0Has the Document Shepherd verified that the document IANA > =A0 =A0 consideration section exists and is consistent with the body of > =A0 =A0 the document? =A0If the document specifies protocol extensions, a= re > =A0 =A0 reservations requested in appropriate IANA registries? =A0Are the > =A0 =A0 IANA registries clearly identified? =A0If the document creates a = new > =A0 =A0 registry, does it define the proposed initial contents of the > =A0 =A0 registry and an allocation procedure for future registrations? > =A0 =A0 Does it suggested a reasonable name for the new registry? =A0See > =A0 =A0 [I-D.narten-iana-considerations-rfc2434bis]. =A0If the document > =A0 =A0 describes an Expert Review process has Shepherd conferred with th= e > =A0 =A0Responsible Area Director so that the IESG can appoint the needed > =A0 =A0 Expert during the IESG Evaluation? > > The IANA Considerations section exists (section 7). =A0It requires no act= ion > by IANA. > > =A0(1.j) =A0Has the Document Shepherd verified that sections of the > =A0 =A0 document that are written in a formal language, such as XML code, > =A0 =A0 BNF rules, MIB definitions, etc., validate correctly in an > =A0 =A0 automated checker? > > Not applicable. > > =A0(1.k) =A0The IESG approval announcement includes a Document > =A0 =A0 Announcement Write-Up. =A0Please provide such a Document > =A0 =A0 Announcement Writeup? =A0Recent examples can be found in the > =A0 =A0 "Action" announcements for approved documents. =A0The approval > =A0 =A0 announcement contains the following sections: > =A0 =A0 Technical Summary > > This document summarizes the requirements for a mechanism to enable > registration of multiple addresses of record within SIP. =A0 The goal > is to produce a mechanism =A0suitable for deployment by SIP service > providers on a large scale in support of small to medium sized PBXs. > > =A0 =A0 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. > > =A0 =A0 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 communit= y. > It has gone > through MARTINI WG last call, with only modest changes resulting. > > =A0 =A0 Personnel > > Bernard Aboba is the document shepherd for this document. > Gonzalo Camarillo is the responsible AD. > > > > _______________________________________________ > 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 ietf.hanserik@gmail.com Wed May 5 10:28:42 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 0BC5B3A6934 for ; Wed, 5 May 2010 10:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.078, 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 GinSlH5x80cH for ; Wed, 5 May 2010 10:28:41 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 6F4EE3A69D8 for ; Wed, 5 May 2010 10:26:59 -0700 (PDT) Received: by ewy24 with SMTP id 24so1418915ewy.33 for ; Wed, 05 May 2010 10:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=M7CHKBWXnJo2sRK/z/ITZo16PSnHzmhdOXTVNX3kt+c=; b=vib3BTMDNGdOGUFpYWKa9LAu+897l+74lW1o6CtqS0fjmBzOp1dTvU/0EshPYHMfee suiDBFNF2MY8gzzLmqYnVjo6+FMaAF/nornUHjon6hC67ZAKjyWOzlKNG/14VyMr4h9U SMrOPOgY3ScrvP4FbxCgUi+j2ESQtyiyqG9nU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xXbMqfi3yEeD6CfR12ea/gqijmifDmo0bh3OEDBfGOX6XgBjTeKTVM9R+NPbS6xhvr KTeqyQqxh8EHtrRsjJpSu5UHzlkZ4CMzvlQ2pQufycjMBldjFULq+07bS178/8UpbJQW rpPRbscHqb9zUtJBAno3Q4b7SzfB385CLIC2A= MIME-Version: 1.0 Received: by 10.213.75.204 with SMTP id z12mr7201194ebj.16.1273080402341; Wed, 05 May 2010 10:26:42 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Wed, 5 May 2010 10:26:42 -0700 (PDT) Date: Wed, 5 May 2010 19:26:42 +0200 Message-ID: From: Hans Erik van Elburg To: "Elwell, John" , Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: martini@ietf.org Subject: [martini] Nits Re: I-D Action:draft-ietf-martini-reqs-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: Wed, 05 May 2010 17:28:42 -0000 Hi John, Hadriel, As people seem to want to put lots of speed on this now, i did a very quick reread. Found the following nits: Section 1: - Please remove the follwoing text from the end of the last paragraph: "The ability to handle other forms of AOR is outside the scope of this document, although a solution that can handle other forms of AOR is not precluded if it does not lead to significant additional complexity or a delay in producing the standard. AORs based on E.164 numbers represent an overwhelming proportion of the current market for small/medium SIP- PBXs, and it is for this sector that an urgent solution is required. This does not preclude future work on solutions for AORs that are not based on numbers or are based on non-E.164 numbers (private numbers)." It is not consistent with the new requirements 21 & 21. And further it contains an opinion about the state of the market "overwhelming proportion of the current market". Please remove this. Section 3: - 3rd paragraph, replace "almost always" with "often". That makes it more factual and less opinionated. Best Regards, /Hans Erik van Elburg On Tue, May 4, 2010 at 7:00 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiple AoR reachabiliTy InformatioN In= dication Working Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Requirements for multiple addr= ess of record (AOR) reachability information in the Session Initiation Prot= ocol (SIP) > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Elwell, H. Kaplan > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-martini-reqs-05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-04 > > 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 PBXs. =A0The requirements are for a > solution that can, as a minimum, support AORs based on E.164 numbers. > > This work is being discussed on the martini@ietf.org mailing list. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-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. > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > > From pkyzivat@cisco.com Wed May 5 16:04:03 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 6481628C16E for ; Wed, 5 May 2010 16:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.986 X-Spam-Level: X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 u01NefXo3Ckl for ; Wed, 5 May 2010 16:04:02 -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 2248428C141 for ; Wed, 5 May 2010 16:04:02 -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: AvsEAD+W4UtAZnwM/2dsb2JhbACdV3GkSZlahRME X-IronPort-AV: E=Sophos;i="4.52,337,1270425600"; d="scan'208";a="108490428" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 May 2010 23:03:48 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o45N3mbQ023478; Wed, 5 May 2010 23:03:48 GMT Message-ID: <4BE1F958.9090604@cisco.com> Date: Wed, 05 May 2010 19:03:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hans Erik van Elburg References: <4BDF465F.3040104@nostrum.com> <4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 05 May 2010 23:04:03 -0000 Hans Erik van Elburg wrote: > On Tue, May 4, 2010 at 5:03 PM, Hadriel Kaplan wrote: > >>> - An PBX registers with the SSP, to be able to send and receive calls. No >>> astonishment >> Right, but it's Registering for an AoR *belonging to the SSP*. I.e., "sip:+12345@ssp.com". >> > [HE] Think it is more correct to say that it is registering > reachability information for a bulk contact, which is then bound by > the SSP to a bunch of implicitly registered AOR's. These AOR's dop not > have to belong to the SSP, but they can. The SSP's proxy is > responsible for handling them and forwarding them applying rules that > apply to bulk contacts. We've been through this before :-( If the domain of the request, when it arrives at the SSP, is not a domain it is responsible for, then it is bound to deliver it using 3261/3263 rules. SSP.com has no business making side agreements on where to route requests for other domains. Otherwise, I'm going to sign up my pbx with your SSP and ask to have sip:barack_obama@whitehouse.gov be one of my implicitly registered AORs. This kind of routing *must* be restricted to domains the SSP is responsible for. Thanks, Paul From ietf.hanserik@gmail.com Wed May 5 23:08: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 C36973A6AA5 for ; Wed, 5 May 2010 23:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] 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 Mvn+zt5MhhPn for ; Wed, 5 May 2010 23:08:55 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 47D1D3A6A2D for ; Wed, 5 May 2010 23:08:55 -0700 (PDT) Received: by ewy24 with SMTP id 24so2018690ewy.13 for ; Wed, 05 May 2010 23:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=04Dd1zwADc6G74Unzjg+HUQ/wszKe6lTMjt7IqwYZ78=; b=rmlk1EFenfHzL7dQxnDggvBnCPrJtLahVRXzpR3dpf9xdrjXQreDjeycbQScEdHyXI eB27Rnxw1s86T6rXmGqo+4Dzg0INLd1UBSpRcBT+gvJTw0LiPZ921h2ga0BCWRe4dIAx 24eGqDvH38Yp42dJYBL/7uNlo5ziXv+Xx4BcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KuMwob+IgOYkMn5azX9RHlBzlZazN7PmXl0DkFVnX45lXATcMS98eq9aU20odusSFg WfomInEvEhs+paq4ePxavUS9I4maYMfNezBIfiCfE/Pg6WqUA5eyEbxktT+8yNIX+B64 xVJCmhij5GlZuKLOGtCXQsGbioUbSRP5U58KU= MIME-Version: 1.0 Received: by 10.213.72.129 with SMTP id m1mr3057751ebj.86.1273126118526; Wed, 05 May 2010 23:08:38 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Wed, 5 May 2010 23:08:38 -0700 (PDT) In-Reply-To: <4BE1F958.9090604@cisco.com> References: <4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail> <4BE1F958.9090604@cisco.com> Date: Thu, 6 May 2010 08:08:38 +0200 Message-ID: From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 06 May 2010 06:08:56 -0000 On Thu, May 6, 2010 at 1:03 AM, Paul Kyzivat wrote: > > > Hans Erik van Elburg wrote: >> >> On Tue, May 4, 2010 at 5:03 PM, Hadriel Kaplan >> wrote: >> >>>> - An PBX registers with the SSP, to be able to send and receive calls. >>>> No >>>> astonishment >>> >>> Right, but it's Registering for an AoR *belonging to the SSP*. =A0I.e., >>> "sip:+12345@ssp.com". >>> >> [HE] Think it is more correct to say that it is registering >> reachability information for a bulk contact, which is then bound by >> the SSP to a bunch of implicitly registered AOR's. These AOR's dop not >> have to belong to the SSP, but they can. The SSP's proxy is >> responsible for handling them and forwarding them applying rules that >> apply to bulk contacts. > > We've been through this before :-( > People still seem to misunderstand the implications though. Looking at the conclusions that people draw from this. > If the domain of the request, when it arrives at the SSP, is not a domain= it > is responsible for, then it is bound to deliver it using 3261/3263 rules. > SSP.com has no business making side agreements on where to route requests > for other domains. > Correct. The key phrasing is here "responsible for". If the SSP has an agreement with the owner of the domain "company.com" that it will handle incoming traffic for that company, then the SSP's proxy is configured to be "responsible" for that domain. And it would also need to make this known into DNS so that traffic for that domain will be delivered to the SSP. > Otherwise, I'm going to sign up my pbx with your SSP and ask to have > sip:barack_obama@whitehouse.gov be one of my implicitly registered AORs. > You can ask watever you want, but your SSP is not going to configure that for you unless you own the domain whitehgouse.gov and are the person that is allowed to make such requests under the agreement between the SSP and company.com. > This kind of routing *must* be restricted to domains the SSP is responsib= le > for. > Yes, I agree. But if it is responsible for a domain it does not mean that it owns the domain. From john.elwell@siemens-enterprise.com Wed May 5 23:31: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 888003A6A48 for ; Wed, 5 May 2010 23:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.210, 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 MDdZzR4eTp+B for ; Wed, 5 May 2010 23:30:59 -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 17F733A68E1 for ; Wed, 5 May 2010 23:30:54 -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-76345; Thu, 6 May 2010 08:30:41 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 1E7B91EB82AB; Thu, 6 May 2010 08:30:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 6 May 2010 08:30:41 +0200 From: "Elwell, John" To: Hans Erik van Elburg , Hadriel Kaplan Date: Thu, 6 May 2010 08:30:39 +0200 Thread-Topic: Nits Re: [martini] I-D Action:draft-ietf-martini-reqs-05.txt Thread-Index: AcrseCEYWQialfykQdeOD6g2ICG/EwAa+wuA 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Nits Re: I-D Action:draft-ietf-martini-reqs-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: Thu, 06 May 2010 06:31:00 -0000 Hans Erik, See below. In addition, I need to check with the chairs whether the documen= t has already left the WG. > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 05 May 2010 18:27 > To: Elwell, John; Hadriel Kaplan > Cc: martini@ietf.org > Subject: Nits Re: [martini] I-D Action:draft-ietf-martini-reqs-05.txt >=20 > Hi John, Hadriel, >=20 > As people seem to want to put lots of speed on this now, i did a very > quick reread. Found the following nits: >=20 > Section 1: > - Please remove the follwoing text from the end of the last paragraph: > "The ability to handle > other forms of AOR is outside the scope of this document,=20 > although a > solution that can handle other forms of AOR is not precluded if it > does not lead to significant additional complexity or a delay in > producing the standard. AORs based on E.164 numbers represent an > overwhelming proportion of the current market for small/medium SIP- > PBXs, and it is for this sector that an urgent solution is=20 > required. > This does not preclude future work on solutions for AORs=20 > that are not > based on numbers or are based on non-E.164 numbers=20 > (private numbers)." >=20 > It is not consistent with the new requirements 21 & 21. And further it > contains an opinion about the state of the market "overwhelming > proportion of the current market". Please remove this. [JRE] I agree that this text needs some attention. We can either delete it = or repair it. In my working copy I have deleted it, but I would like to hea= r other views, since we would lose some of the rationale for focusing on E.= 164-based initially. >=20 > Section 3: > - 3rd paragraph, replace "almost always" with "often". >=20 > That makes it more factual and less opinionated. [JRE] I don't mind making that change. John >=20 > Best Regards, > /Hans Erik van Elburg >=20 > On Tue, May 4, 2010 at 7:00 PM, wrote: > > 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. > > > > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Requirements for multiple ad= dress=20 > of record (AOR) reachability information in the Session=20 > Initiation Protocol (SIP) > > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Elwell, H. Kaplan > > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-martini-reqs-05.txt > > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 > > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-04 > > > > This document states requirements for a standardized SIP=20 > 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 PBXs. =A0The requirements are for a > > solution that can, as a minimum, support AORs based on=20 > E.164 numbers. > > > > This work is being discussed on the martini@ietf.org mailing list. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-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. > > > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > > > = From john.elwell@siemens-enterprise.com Wed May 5 23:42:21 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 B71A528C0D6 for ; Wed, 5 May 2010 23:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 L-S2jeUO26UE for ; Wed, 5 May 2010 23:42:20 -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 D64283A6A75 for ; Wed, 5 May 2010 23:42:19 -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-76271; Thu, 6 May 2010 08:42:06 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 1DAA823F0278; Thu, 6 May 2010 08:42:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 6 May 2010 08:42:06 +0200 From: "Elwell, John" To: Hans Erik van Elburg , Spencer Dawkins Date: Thu, 6 May 2010 08:42:04 +0200 Thread-Topic: [martini] Draft PROTO writeup for MARTINI Requirements Document Thread-Index: AcrsdUgFbHTNvyXaRfmalMhz0WWCCwAcY4Qw Message-ID: References: <2F00EA045C064CB78BA74D23D29D57F8@china.huawei.com> Keywords: MARTINI 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Draft PROTO writeup for MARTINI Requirements Document 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, 06 May 2010 06:42:21 -0000 Hans Erik, The chairs can correct me if I am wrong, but WGLC finished back in March, a= nd since then we have just been fixing the outstanding issues. There seemed= to be consensus on the call last week that there were no further issues an= d that it was ready to go. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: 05 May 2010 18:06 > To: Spencer Dawkins > Cc: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Draft PROTO writeup for MARTINI=20 > Requirements Document >=20 > Hi Bernard, Spencer, >=20 > How much time do people get to do a full reread of the latest > requirements draft, for which a new version was just been submitted > yesterday. >=20 > After the main issues are resolved people may want to propose less > major improvements to text, to make it really ready for publication. >=20 > What is the process? When does WGLC end? >=20 > /Hans Erik van Elburg >=20 > On Wed, May 5, 2010 at 11:08 AM, Spencer Dawkins > wrote: > > Just to provide context... we're at zero open issues on the=20 > requirements > > draft after working group last call, and we've decided not=20 > to put anything > > in the requirements draft about bulk registration working=20 > the same way as > > multiple individual registrations, which was the last=20 > relevant mailing list > > topic, so we're planning to request publication of this=20 > draft Real Soon Now. > > > > We are planning to do the same thing with solutions drafts=20 > as they hit zero > > open issues after working group last call, so please be=20 > prepared to move > > pretty quickly. Not that "move pretty quickly" is new... > > > > Thanks, > > > > Spencer, as co-chair > > > > ----- Original Message ----- From: Bernard Aboba > > To: martini@ietf.org > > Sent: Tuesday, May 04, 2010 2:13 PM > > Subject: [martini] Draft PROTO writeup for MARTINI=20 > Requirements Document > > > > > > > > PROTO Writeup for draft-ietf-martini-reqs > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > http://tools.ietf.org/html/draft-ietf-martini-reqs > > > > =A0(1.a) =A0Who is the Document Shepherd for this document? =A0Has the > > =A0 =A0 Document Shepherd personally reviewed this version of=20 > the document > > =A0 =A0 and, in particular, does he or she believe this version is read= y > > =A0 =A0 for forwarding to the IESG for publication? > > > > Bernard Aboba is the document shepherd. =A0I have personally reviewed > > the document, and believe it is ready for publication as an=20 > Informational > > RFC. > > > > =A0(1.b) =A0Has the document had adequate review both from key=20 > members of > > =A0 =A0 the interested community and others? =A0Does the Document Sheph= erd > > =A0 =A0 have any concerns about the depth or breadth of the reviews tha= t > > =A0 =A0 have been performed? > > > > The document has been extensively discussed on the MARTINI=20 > WG mailing list. > > The discussion has > > included representatives from both the PBX and=20 > service-provider communities > > as well as > > participants in 3GPP and SIPForum. =A0As a result, the=20 > reviews appear to have > > been > > reasonably thorough and representative. > > > > =A0(1.c) =A0Does the Document Shepherd have concerns that the document > > =A0 =A0 needs more review from a particular or broader=20 > perspective, e.g., > > =A0 =A0 security, operational complexity, someone familiar with AAA, > > =A0 =A0 internationalization or XML? > > > > No concerns. > > > > =A0(1.d) =A0Does the Document Shepherd have any specific concerns or > > =A0 =A0 issues with this document that the Responsible Area Director > > =A0 =A0 and/or the IESG should be aware of? =A0For example, perhaps he = or > > =A0 =A0 she is uncomfortable with certain parts of the document, or has > > =A0 =A0 concerns whether there really is a need for it. =A0In any=20 > event, if > > =A0 =A0 the interested community has discussed those issues and has > > =A0 =A0 indicated that it still wishes to advance the document, detail > > =A0 =A0 those concerns here. > > > > No concerns. > > > > =A0(1.e) =A0How solid is the consensus of the interested=20 > community behind > > =A0 =A0 this document? =A0Does it represent the strong=20 > concurrence of a few > > =A0 =A0 individuals, with others being silent, or does the interested > > =A0 =A0 community as a whole understand and agree with it? > > > > There has been vigorous discussion in a number of the=20 > requirements included > > in the document, > > but those issues have been resolved. =A0As a result, there=20 > appears to be > > strong consensus behind > > the document, and the working group is using the=20 > requirements in evaluating > > proposed > > protocol solutions. > > > > =A0(1.f) =A0Has anyone threatened an appeal or otherwise=20 > indicated extreme > > =A0 =A0 discontent? =A0If so, please summarise the areas of conflict in > > =A0 =A0 separate email messages to the Responsible Area Director. =A0(I= t > > =A0 =A0 should be in a separate email because this questionnaire is > > =A0 =A0 entered into the ID Tracker.) > > > > No. > > > > =A0(1.g) =A0Has the Document Shepherd personally verified that the > > =A0 =A0 document satisfies all ID nits? =A0(See > > =A0 =A0 http://www.ietf.org/ID-Checklist.html and > > =A0 =A0 http://tools.ietf.org/tools/idnits/). =A0Boilerplate=20 > checks are not > > =A0 =A0 enough; this check needs to be thorough. =A0Has the=20 > document met all > > =A0 =A0 formal review criteria it needs to, such as the MIB=20 > Doctor, media > > =A0 =A0 type and URI type reviews? > > > > IDNits are clean: > > > > idnits 2.12.02 > > > > tmp/draft-ietf-martini-reqs-05.txt: > > > > =A0Checking boilerplate required by RFC 5378 and the IETF Trust (see > > =A0http://trustee.ietf.org/license-info): > > =A0 > -------------------------------------------------------------- > -------------- > > > > =A0 =A0No issues found here. > > > > =A0Checking nits according to=20 > http://www.ietf.org/id-info/1id-guidelines.txt: > > =A0 > -------------------------------------------------------------- > -------------- > > > > =A0 =A0No issues found here. > > > > =A0Checking nits according to http://www.ietf.org/id-info/checklist : > > =A0 > -------------------------------------------------------------- > -------------- > > > > =A0 =A0No issues found here. > > > > =A0Miscellaneous warnings: > > =A0 > -------------------------------------------------------------- > -------------- > > > > =A0 =A0No issues found here. > > > > =A0Checking references for intended status: Informational > > =A0 > -------------------------------------------------------------- > -------------- > > > > =A0 =A0No issues found here. > > > > =A0 =A0No nits found. > >=20 > -------------------------------------------------------------- > ------------------ > > > > =A0(1.h) =A0Has the document split its references into normative and > > =A0 =A0 informative? =A0Are there normative references to=20 > documents that are > > =A0 =A0 not ready for advancement or are otherwise in an unclear state? > > =A0 =A0 If such normative references exist, what is the=20 > strategy for their > > =A0 =A0 completion? =A0Are there normative references that are downward > > =A0 =A0 references, as described in [RFC3967]? =A0If so, list=20 > these downward > > =A0 =A0 references to support the Area Director in the Last=20 > Call procedure > > =A0 =A0 for them [RFC3967]. > > > > The references in the document have been split into normative and > > informative. > > > > Normative references are all stable documents published as RFCs. > > > > =A0(1.i) =A0Has the Document Shepherd verified that the document IANA > > =A0 =A0 consideration section exists and is consistent with the body of > > =A0 =A0 the document? =A0If the document specifies protocol=20 > extensions, are > > =A0 =A0 reservations requested in appropriate IANA registries? =A0Are t= he > > =A0 =A0 IANA registries clearly identified? =A0If the document=20 > creates a new > > =A0 =A0 registry, does it define the proposed initial contents of the > > =A0 =A0 registry and an allocation procedure for future registrations? > > =A0 =A0 Does it suggested a reasonable name for the new registry? =A0Se= e > > =A0 =A0 [I-D.narten-iana-considerations-rfc2434bis]. =A0If the document > > =A0 =A0 describes an Expert Review process has Shepherd=20 > conferred with the > > =A0 =A0Responsible Area Director so that the IESG can appoint the neede= d > > =A0 =A0 Expert during the IESG Evaluation? > > > > The IANA Considerations section exists (section 7). =A0It=20 > requires no action > > by IANA. > > > > =A0(1.j) =A0Has the Document Shepherd verified that sections of the > > =A0 =A0 document that are written in a formal language, such as=20 > XML code, > > =A0 =A0 BNF rules, MIB definitions, etc., validate correctly in an > > =A0 =A0 automated checker? > > > > Not applicable. > > > > =A0(1.k) =A0The IESG approval announcement includes a Document > > =A0 =A0 Announcement Write-Up. =A0Please provide such a Document > > =A0 =A0 Announcement Writeup? =A0Recent examples can be found in the > > =A0 =A0 "Action" announcements for approved documents. =A0The approval > > =A0 =A0 announcement contains the following sections: > > =A0 =A0 Technical Summary > > > > This document summarizes the requirements for a mechanism to enable > > registration of multiple addresses of record within SIP. =A0 The goal > > is to produce a mechanism =A0suitable for deployment by SIP service > > providers on a large scale in support of small to medium sized PBXs. > > > > =A0 =A0 Working Group Summary > > > > The WG discussed the issue of E.164/non-E.164 AORs in=20 > considerable depth, > > and concluded that > > extensibility to handle non-E.164 AORs (such as private numbers and > > email-style addresses) > > was important. > > > > =A0 =A0 Document Quality > > > > The document has been reviewed by participants within the=20 > IETF MARTINI WG, > > including SIP > > service providers as well as representatives from the PBX=20 > vendor community. > > It has gone > > through MARTINI WG last call, with only modest changes resulting. > > > > =A0 =A0 Personnel > > > > Bernard Aboba is the document shepherd for this document. > > Gonzalo Camarillo is the responsible AD. > > > > > > > > _______________________________________________ > > 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 bruno.chatras@orange-ftgroup.com Thu May 6 00:06:11 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 725A03A63D3 for ; Thu, 6 May 2010 00:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_20=-0.74, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 NqFJt7VIqFmV for ; Thu, 6 May 2010 00:06:07 -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 09F723A6915 for ; Thu, 6 May 2010 00:06:07 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 696706FCC47; Thu, 6 May 2010 09:04:31 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 64BC86FCC05; Thu, 6 May 2010 09:03:18 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 09:02:31 +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: Thu, 6 May 2010 09:02:30 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214101696F60@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Nits Re: I-D Action:draft-ietf-martini-reqs-05.txt Thread-Index: AcrseCEYWQialfykQdeOD6g2ICG/EwAa+wuAAAF3yVA= References: From: To: , , X-OriginalArrivalTime: 06 May 2010 07:02:31.0884 (UTC) FILETIME=[18F740C0:01CAECEA] Cc: martini@ietf.org Subject: Re: [martini] Nits Re: I-D Action:draft-ietf-martini-reqs-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: Thu, 06 May 2010 07:06:11 -0000 I think we should remove this text. It is indeed not consistent with Req = 21 as it starts with "The ability to handle other forms of AOR is = outside the scope of this document." > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > Envoy=E9 : jeudi 6 mai 2010 08:31 > =C0 : Hans Erik van Elburg; Hadriel Kaplan > Cc : martini@ietf.org > Objet : Re: [martini] Nits Re: I-D=20 > Action:draft-ietf-martini-reqs-05.txt >=20 > Hans Erik, >=20 > See below. In addition, I need to check with the chairs=20 > whether the document has already left the WG. >=20 > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 05 May 2010 18:27 > > To: Elwell, John; Hadriel Kaplan > > Cc: martini@ietf.org > > Subject: Nits Re: [martini] I-D=20 > Action:draft-ietf-martini-reqs-05.txt > >=20 > > Hi John, Hadriel, > >=20 > > As people seem to want to put lots of speed on this now, i=20 > did a very=20 > > quick reread. Found the following nits: > >=20 > > Section 1: > > - Please remove the follwoing text from the end of the last=20 > paragraph: > > "The ability to handle > > other forms of AOR is outside the scope of this=20 > document, although=20 > > a > > solution that can handle other forms of AOR is not=20 > precluded if it > > does not lead to significant additional complexity or a delay in > > producing the standard. AORs based on E.164 numbers represent an > > overwhelming proportion of the current market for=20 > small/medium SIP- > > PBXs, and it is for this sector that an urgent solution is=20 > > required. > > This does not preclude future work on solutions for AORs=20 > that are=20 > > not > > based on numbers or are based on non-E.164 numbers (private=20 > > numbers)." > >=20 > > It is not consistent with the new requirements 21 & 21. And=20 > further it=20 > > contains an opinion about the state of the market "overwhelming=20 > > proportion of the current market". Please remove this. > [JRE] I agree that this text needs some attention. We can=20 > either delete it or repair it. In my working copy I have=20 > deleted it, but I would like to hear other views, since we=20 > would lose some of the rationale for focusing on E.164-based=20 > initially. >=20 > >=20 > > Section 3: > > - 3rd paragraph, replace "almost always" with "often". > >=20 > > That makes it more factual and less opinionated. > [JRE] I don't mind making that change. >=20 > John >=20 >=20 > >=20 > > Best Regards, > > /Hans Erik van Elburg > >=20 > > On Tue, May 4, 2010 at 7:00 PM, wrote: > > > 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. > > > > > > > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Requirements for = multiple address > > of record (AOR) reachability information in the Session Initiation=20 > > Protocol (SIP) > > > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Elwell, H. Kaplan > > > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: = draft-ietf-martini-reqs-05.txt > > > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 > > > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-04 > > > > > > This document states requirements for a standardized SIP > > registration > > > mechanism for multiple addresses of record, the mechanism being=20 > > > suitable for deployment by SIP service providers on a=20 > large scale in=20 > > > support of small to medium sized PBXs. =A0The requirements=20 > are for a=20 > > > solution that can, as a minimum, support AORs based on > > E.164 numbers. > > > > > > This work is being discussed on the martini@ietf.org mailing list. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-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=20 > > > implementation to automatically retrieve the ASCII version of the=20 > > > Internet-Draft. > > > > > > > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > > > > > > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From ietf.hanserik@gmail.com Thu May 6 01:15:59 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 7EE023A680D for ; Thu, 6 May 2010 01:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 Bsqi0BYuSKRc for ; Thu, 6 May 2010 01:15:57 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 694C43A67FE for ; Thu, 6 May 2010 01:15:57 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so32517eyf.51 for ; Thu, 06 May 2010 01:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jwCvxd2JSYMtXVaUQ0awSbw5RnR63A0GLm1FTpZYR5U=; b=QZWW2Rsm+NyxI7lbmq+GX9oD3rjUek2v7SZtwTXyeQF/akOgJqikqvMWw0D8yXJ+eH 2lctNtp6kIiXM1gR9ug4cs8I0TfvrSuUDHRcNe7oLXECHg33w9NDohePT6onPpUd2tf6 U+xK3H1KYnDb9rOSvLvSNpNspHG5yAq2v6E2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZntZNIcLDoSkCm2hHup0vFLVR2HGSQustZAv7IcJE9pAaV/hlw90AgeNMlXq4A3sAY DtzvJ6JBHcRc/ITH8h6G7Jl9ZDcDIMm0wLhL6uzgn7qBOmfdCwxfQsMVrzH62fNXpxDx 4Mz2dpB5kPMnN+r3+ku1CE5kOjmGfufg7mn80= MIME-Version: 1.0 Received: by 10.213.78.140 with SMTP id l12mr3048052ebk.15.1273133740411; Thu, 06 May 2010 01:15:40 -0700 (PDT) Received: by 10.213.108.142 with HTTP; Thu, 6 May 2010 01:15:40 -0700 (PDT) In-Reply-To: References: <2F00EA045C064CB78BA74D23D29D57F8@china.huawei.com> Date: Thu, 6 May 2010 10:15:40 +0200 Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Draft PROTO writeup for MARTINI Requirements Document 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, 06 May 2010 08:15:59 -0000 Yes in principle, but the version that is now being forwarded was not available at that time. It is hard to do a consistency read on a draft that is not available. /Hans Erik van Elburg On Thu, May 6, 2010 at 8:42 AM, Elwell, John wrote: > Hans Erik, > > The chairs can correct me if I am wrong, but WGLC finished back in March,= and since then we have just been fixing the outstanding issues. There seem= ed to be consensus on the call last week that there were no further issues = and that it was ready to go. > > John > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg >> Sent: 05 May 2010 18:06 >> To: Spencer Dawkins >> Cc: Bernard Aboba; martini@ietf.org >> Subject: Re: [martini] Draft PROTO writeup for MARTINI >> Requirements Document >> >> Hi Bernard, Spencer, >> >> How much time do people get to do a full reread of the latest >> requirements draft, for which a new version was just been submitted >> yesterday. >> >> After the main issues are resolved people may want to propose less >> major improvements to text, to make it really ready for publication. >> >> What is the process? When does WGLC end? >> >> /Hans Erik van Elburg >> >> On Wed, May 5, 2010 at 11:08 AM, Spencer Dawkins >> wrote: >> > Just to provide context... we're at zero open issues on the >> requirements >> > draft after working group last call, and we've decided not >> to put anything >> > in the requirements draft about bulk registration working >> the same way as >> > multiple individual registrations, which was the last >> relevant mailing list >> > topic, so we're planning to request publication of this >> draft Real Soon Now. >> > >> > We are planning to do the same thing with solutions drafts >> as they hit zero >> > open issues after working group last call, so please be >> prepared to move >> > pretty quickly. Not that "move pretty quickly" is new... >> > >> > Thanks, >> > >> > Spencer, as co-chair >> > >> > ----- Original Message ----- From: Bernard Aboba >> > To: martini@ietf.org >> > Sent: Tuesday, May 04, 2010 2:13 PM >> > Subject: [martini] Draft PROTO writeup for MARTINI >> Requirements Document >> > >> > >> > >> > PROTO Writeup for draft-ietf-martini-reqs >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> > >> > http://tools.ietf.org/html/draft-ietf-martini-reqs >> > >> > =A0(1.a) =A0Who is the Document Shepherd for this document? =A0Has the >> > =A0 =A0 Document Shepherd personally reviewed this version of >> the document >> > =A0 =A0 and, in particular, does he or she believe this version is rea= dy >> > =A0 =A0 for forwarding to the IESG for publication? >> > >> > Bernard Aboba is the document shepherd. =A0I have personally reviewed >> > the document, and believe it is ready for publication as an >> Informational >> > RFC. >> > >> > =A0(1.b) =A0Has the document had adequate review both from key >> members of >> > =A0 =A0 the interested community and others? =A0Does the Document Shep= herd >> > =A0 =A0 have any concerns about the depth or breadth of the reviews th= at >> > =A0 =A0 have been performed? >> > >> > The document has been extensively discussed on the MARTINI >> WG mailing list. >> > The discussion has >> > included representatives from both the PBX and >> service-provider communities >> > as well as >> > participants in 3GPP and SIPForum. =A0As a result, the >> reviews appear to have >> > been >> > reasonably thorough and representative. >> > >> > =A0(1.c) =A0Does the Document Shepherd have concerns that the document >> > =A0 =A0 needs more review from a particular or broader >> perspective, e.g., >> > =A0 =A0 security, operational complexity, someone familiar with AAA, >> > =A0 =A0 internationalization or XML? >> > >> > No concerns. >> > >> > =A0(1.d) =A0Does the Document Shepherd have any specific concerns or >> > =A0 =A0 issues with this document that the Responsible Area Director >> > =A0 =A0 and/or the IESG should be aware of? =A0For example, perhaps he= or >> > =A0 =A0 she is uncomfortable with certain parts of the document, or ha= s >> > =A0 =A0 concerns whether there really is a need for it. =A0In any >> event, if >> > =A0 =A0 the interested community has discussed those issues and has >> > =A0 =A0 indicated that it still wishes to advance the document, detail >> > =A0 =A0 those concerns here. >> > >> > No concerns. >> > >> > =A0(1.e) =A0How solid is the consensus of the interested >> community behind >> > =A0 =A0 this document? =A0Does it represent the strong >> concurrence of a few >> > =A0 =A0 individuals, with others being silent, or does the interested >> > =A0 =A0 community as a whole understand and agree with it? >> > >> > There has been vigorous discussion in a number of the >> requirements included >> > in the document, >> > but those issues have been resolved. =A0As a result, there >> appears to be >> > strong consensus behind >> > the document, and the working group is using the >> requirements in evaluating >> > proposed >> > protocol solutions. >> > >> > =A0(1.f) =A0Has anyone threatened an appeal or otherwise >> indicated extreme >> > =A0 =A0 discontent? =A0If so, please summarise the areas of conflict i= n >> > =A0 =A0 separate email messages to the Responsible Area Director. =A0(= It >> > =A0 =A0 should be in a separate email because this questionnaire is >> > =A0 =A0 entered into the ID Tracker.) >> > >> > No. >> > >> > =A0(1.g) =A0Has the Document Shepherd personally verified that the >> > =A0 =A0 document satisfies all ID nits? =A0(See >> > =A0 =A0 http://www.ietf.org/ID-Checklist.html and >> > =A0 =A0 http://tools.ietf.org/tools/idnits/). =A0Boilerplate >> checks are not >> > =A0 =A0 enough; this check needs to be thorough. =A0Has the >> document met all >> > =A0 =A0 formal review criteria it needs to, such as the MIB >> Doctor, media >> > =A0 =A0 type and URI type reviews? >> > >> > IDNits are clean: >> > >> > idnits 2.12.02 >> > >> > tmp/draft-ietf-martini-reqs-05.txt: >> > >> > =A0Checking boilerplate required by RFC 5378 and the IETF Trust (see >> > =A0http://trustee.ietf.org/license-info): >> > >> -------------------------------------------------------------- >> -------------- >> > >> > =A0 =A0No issues found here. >> > >> > =A0Checking nits according to >> http://www.ietf.org/id-info/1id-guidelines.txt: >> > >> -------------------------------------------------------------- >> -------------- >> > >> > =A0 =A0No issues found here. >> > >> > =A0Checking nits according to http://www.ietf.org/id-info/checklist : >> > >> -------------------------------------------------------------- >> -------------- >> > >> > =A0 =A0No issues found here. >> > >> > =A0Miscellaneous warnings: >> > >> -------------------------------------------------------------- >> -------------- >> > >> > =A0 =A0No issues found here. >> > >> > =A0Checking references for intended status: Informational >> > >> -------------------------------------------------------------- >> -------------- >> > >> > =A0 =A0No issues found here. >> > >> > =A0 =A0No nits found. >> > >> -------------------------------------------------------------- >> ------------------ >> > >> > =A0(1.h) =A0Has the document split its references into normative and >> > =A0 =A0 informative? =A0Are there normative references to >> documents that are >> > =A0 =A0 not ready for advancement or are otherwise in an unclear state= ? >> > =A0 =A0 If such normative references exist, what is the >> strategy for their >> > =A0 =A0 completion? =A0Are there normative references that are downwar= d >> > =A0 =A0 references, as described in [RFC3967]? =A0If so, list >> these downward >> > =A0 =A0 references to support the Area Director in the Last >> Call procedure >> > =A0 =A0 for them [RFC3967]. >> > >> > The references in the document have been split into normative and >> > informative. >> > >> > Normative references are all stable documents published as RFCs. >> > >> > =A0(1.i) =A0Has the Document Shepherd verified that the document IANA >> > =A0 =A0 consideration section exists and is consistent with the body o= f >> > =A0 =A0 the document? =A0If the document specifies protocol >> extensions, are >> > =A0 =A0 reservations requested in appropriate IANA registries? =A0Are = the >> > =A0 =A0 IANA registries clearly identified? =A0If the document >> creates a new >> > =A0 =A0 registry, does it define the proposed initial contents of the >> > =A0 =A0 registry and an allocation procedure for future registrations? >> > =A0 =A0 Does it suggested a reasonable name for the new registry? =A0S= ee >> > =A0 =A0 [I-D.narten-iana-considerations-rfc2434bis]. =A0If the documen= t >> > =A0 =A0 describes an Expert Review process has Shepherd >> conferred with the >> > =A0 =A0Responsible Area Director so that the IESG can appoint the need= ed >> > =A0 =A0 Expert during the IESG Evaluation? >> > >> > The IANA Considerations section exists (section 7). =A0It >> requires no action >> > by IANA. >> > >> > =A0(1.j) =A0Has the Document Shepherd verified that sections of the >> > =A0 =A0 document that are written in a formal language, such as >> XML code, >> > =A0 =A0 BNF rules, MIB definitions, etc., validate correctly in an >> > =A0 =A0 automated checker? >> > >> > Not applicable. >> > >> > =A0(1.k) =A0The IESG approval announcement includes a Document >> > =A0 =A0 Announcement Write-Up. =A0Please provide such a Document >> > =A0 =A0 Announcement Writeup? =A0Recent examples can be found in the >> > =A0 =A0 "Action" announcements for approved documents. =A0The approval >> > =A0 =A0 announcement contains the following sections: >> > =A0 =A0 Technical Summary >> > >> > This document summarizes the requirements for a mechanism to enable >> > registration of multiple addresses of record within SIP. =A0 The goal >> > is to produce a mechanism =A0suitable for deployment by SIP service >> > providers on a large scale in support of small to medium sized PBXs. >> > >> > =A0 =A0 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. >> > >> > =A0 =A0 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. >> > >> > =A0 =A0 Personnel >> > >> > Bernard Aboba is the document shepherd for this document. >> > Gonzalo Camarillo is the responsible AD. >> > >> > >> > >> > _______________________________________________ >> > 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 keith.drage@alcatel-lucent.com Thu May 6 03:41:27 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 087163A6B33 for ; Thu, 6 May 2010 03:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.272 X-Spam-Level: X-Spam-Status: No, score=-5.272 tagged_above=-999 required=5 tests=[AWL=0.977, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 j9OFVz7DmsED for ; Thu, 6 May 2010 03:41:25 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CB2EC3A6A8B for ; Thu, 6 May 2010 03:41:24 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o46AePiF020157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 May 2010 12:41:03 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 6 May 2010 12:40:44 +0200 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , Hans Erik van Elburg , Spencer Dawkins Date: Thu, 6 May 2010 12:40:43 +0200 Thread-Topic: [martini] Draft PROTO writeup for MARTINI Requirements Document Thread-Index: AcrsdUgFbHTNvyXaRfmalMhz0WWCCwAcY4QwAAfgJRA= Message-ID: References: <2F00EA045C064CB78BA74D23D29D57F8@china.huawei.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Draft PROTO writeup for MARTINI Requirements Document 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, 06 May 2010 10:41:27 -0000 For the record, I do not believe that question was asked or answered on the= call. Nor do I believe it has been asked on the list. Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, May 06, 2010 7:42 AM > To: Hans Erik van Elburg; Spencer Dawkins > Cc: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Draft PROTO writeup for MARTINI=20 > Requirements Document >=20 > Hans Erik, >=20 > The chairs can correct me if I am wrong, but WGLC finished=20 > back in March, and since then we have just been fixing the=20 > outstanding issues. There seemed to be consensus on the call=20 > last week that there were no further issues and that it was=20 > ready to go. >=20 > John=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > > Sent: 05 May 2010 18:06 > > To: Spencer Dawkins > > Cc: Bernard Aboba; martini@ietf.org > > Subject: Re: [martini] Draft PROTO writeup for MARTINI Requirements=20 > > Document > >=20 > > Hi Bernard, Spencer, > >=20 > > How much time do people get to do a full reread of the latest=20 > > requirements draft, for which a new version was just been submitted=20 > > yesterday. > >=20 > > After the main issues are resolved people may want to propose less=20 > > major improvements to text, to make it really ready for publication. > >=20 > > What is the process? When does WGLC end? > >=20 > > /Hans Erik van Elburg > >=20 > > On Wed, May 5, 2010 at 11:08 AM, Spencer Dawkins=20 > > wrote: > > > Just to provide context... we're at zero open issues on the > > requirements > > > draft after working group last call, and we've decided not > > to put anything > > > in the requirements draft about bulk registration working > > the same way as > > > multiple individual registrations, which was the last > > relevant mailing list > > > topic, so we're planning to request publication of this > > draft Real Soon Now. > > > > > > We are planning to do the same thing with solutions drafts > > as they hit zero > > > open issues after working group last call, so please be > > prepared to move > > > pretty quickly. Not that "move pretty quickly" is new... > > > > > > Thanks, > > > > > > Spencer, as co-chair > > > > > > ----- Original Message ----- From: Bernard Aboba > > > To: martini@ietf.org > > > Sent: Tuesday, May 04, 2010 2:13 PM > > > Subject: [martini] Draft PROTO writeup for MARTINI > > Requirements Document > > > > > > > > > > > > PROTO Writeup for draft-ietf-martini-reqs=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > > http://tools.ietf.org/html/draft-ietf-martini-reqs > > > > > > =A0(1.a) =A0Who is the Document Shepherd for this document? =A0Has th= e > > > =A0 =A0 Document Shepherd personally reviewed this version of > > the document > > > =A0 =A0 and, in particular, does he or she believe this=20 > version is ready > > > =A0 =A0 for forwarding to the IESG for publication? > > > > > > Bernard Aboba is the document shepherd. =A0I have=20 > personally reviewed=20 > > > the document, and believe it is ready for publication as an > > Informational > > > RFC. > > > > > > =A0(1.b) =A0Has the document had adequate review both from key > > members of > > > =A0 =A0 the interested community and others? =A0Does the=20 > Document Shepherd > > > =A0 =A0 have any concerns about the depth or breadth of the=20 > reviews that > > > =A0 =A0 have been performed? > > > > > > The document has been extensively discussed on the MARTINI > > WG mailing list. > > > The discussion has > > > included representatives from both the PBX and > > service-provider communities > > > as well as > > > participants in 3GPP and SIPForum. =A0As a result, the > > reviews appear to have > > > been > > > reasonably thorough and representative. > > > > > > =A0(1.c) =A0Does the Document Shepherd have concerns that the documen= t > > > =A0 =A0 needs more review from a particular or broader > > perspective, e.g., > > > =A0 =A0 security, operational complexity, someone familiar with AAA, > > > =A0 =A0 internationalization or XML? > > > > > > No concerns. > > > > > > =A0(1.d) =A0Does the Document Shepherd have any specific concerns or > > > =A0 =A0 issues with this document that the Responsible Area Director > > > =A0 =A0 and/or the IESG should be aware of? =A0For example,=20 > perhaps he or > > > =A0 =A0 she is uncomfortable with certain parts of the=20 > document, or has > > > =A0 =A0 concerns whether there really is a need for it. =A0In any > > event, if > > > =A0 =A0 the interested community has discussed those issues and has > > > =A0 =A0 indicated that it still wishes to advance the document, detai= l > > > =A0 =A0 those concerns here. > > > > > > No concerns. > > > > > > =A0(1.e) =A0How solid is the consensus of the interested > > community behind > > > =A0 =A0 this document? =A0Does it represent the strong > > concurrence of a few > > > =A0 =A0 individuals, with others being silent, or does the interested > > > =A0 =A0 community as a whole understand and agree with it? > > > > > > There has been vigorous discussion in a number of the > > requirements included > > > in the document, > > > but those issues have been resolved. =A0As a result, there > > appears to be > > > strong consensus behind > > > the document, and the working group is using the > > requirements in evaluating > > > proposed > > > protocol solutions. > > > > > > =A0(1.f) =A0Has anyone threatened an appeal or otherwise > > indicated extreme > > > =A0 =A0 discontent? =A0If so, please summarise the areas of conflict = in > > > =A0 =A0 separate email messages to the Responsible Area Director. =A0= (It > > > =A0 =A0 should be in a separate email because this questionnaire is > > > =A0 =A0 entered into the ID Tracker.) > > > > > > No. > > > > > > =A0(1.g) =A0Has the Document Shepherd personally verified that the > > > =A0 =A0 document satisfies all ID nits? =A0(See > > > =A0 =A0 http://www.ietf.org/ID-Checklist.html and > > > =A0 =A0 http://tools.ietf.org/tools/idnits/). =A0Boilerplate > > checks are not > > > =A0 =A0 enough; this check needs to be thorough. =A0Has the > > document met all > > > =A0 =A0 formal review criteria it needs to, such as the MIB > > Doctor, media > > > =A0 =A0 type and URI type reviews? > > > > > > IDNits are clean: > > > > > > idnits 2.12.02 > > > > > > tmp/draft-ietf-martini-reqs-05.txt: > > > > > > =A0Checking boilerplate required by RFC 5378 and the IETF Trust (see > > > =A0http://trustee.ietf.org/license-info): > > > =A0 > > -------------------------------------------------------------- > > -------------- > > > > > > =A0 =A0No issues found here. > > > > > > =A0Checking nits according to > > http://www.ietf.org/id-info/1id-guidelines.txt: > > > =A0 > > -------------------------------------------------------------- > > -------------- > > > > > > =A0 =A0No issues found here. > > > > > > =A0Checking nits according to=20 > http://www.ietf.org/id-info/checklist : > > > =A0 > > -------------------------------------------------------------- > > -------------- > > > > > > =A0 =A0No issues found here. > > > > > > =A0Miscellaneous warnings: > > > =A0 > > -------------------------------------------------------------- > > -------------- > > > > > > =A0 =A0No issues found here. > > > > > > =A0Checking references for intended status: Informational > > > =A0 > > -------------------------------------------------------------- > > -------------- > > > > > > =A0 =A0No issues found here. > > > > > > =A0 =A0No nits found. > > >=20 > > -------------------------------------------------------------- > > ------------------ > > > > > > =A0(1.h) =A0Has the document split its references into normative and > > > =A0 =A0 informative? =A0Are there normative references to > > documents that are > > > =A0 =A0 not ready for advancement or are otherwise in an=20 > unclear state? > > > =A0 =A0 If such normative references exist, what is the > > strategy for their > > > =A0 =A0 completion? =A0Are there normative references that are downwa= rd > > > =A0 =A0 references, as described in [RFC3967]? =A0If so, list > > these downward > > > =A0 =A0 references to support the Area Director in the Last > > Call procedure > > > =A0 =A0 for them [RFC3967]. > > > > > > The references in the document have been split into normative and=20 > > > informative. > > > > > > Normative references are all stable documents published as RFCs. > > > > > > =A0(1.i) =A0Has the Document Shepherd verified that the document IANA > > > =A0 =A0 consideration section exists and is consistent with=20 > the body of > > > =A0 =A0 the document? =A0If the document specifies protocol > > extensions, are > > > =A0 =A0 reservations requested in appropriate IANA=20 > registries? =A0Are the > > > =A0 =A0 IANA registries clearly identified? =A0If the document > > creates a new > > > =A0 =A0 registry, does it define the proposed initial contents of the > > > =A0 =A0 registry and an allocation procedure for future registrations= ? > > > =A0 =A0 Does it suggested a reasonable name for the new registry? =A0= See > > > =A0 =A0 [I-D.narten-iana-considerations-rfc2434bis]. =A0If the docume= nt > > > =A0 =A0 describes an Expert Review process has Shepherd > > conferred with the > > > =A0 =A0Responsible Area Director so that the IESG can appoint=20 > the needed > > > =A0 =A0 Expert during the IESG Evaluation? > > > > > > The IANA Considerations section exists (section 7). =A0It > > requires no action > > > by IANA. > > > > > > =A0(1.j) =A0Has the Document Shepherd verified that sections of the > > > =A0 =A0 document that are written in a formal language, such as > > XML code, > > > =A0 =A0 BNF rules, MIB definitions, etc., validate correctly in an > > > =A0 =A0 automated checker? > > > > > > Not applicable. > > > > > > =A0(1.k) =A0The IESG approval announcement includes a Document > > > =A0 =A0 Announcement Write-Up. =A0Please provide such a Document > > > =A0 =A0 Announcement Writeup? =A0Recent examples can be found in the > > > =A0 =A0 "Action" announcements for approved documents. =A0The approva= l > > > =A0 =A0 announcement contains the following sections: > > > =A0 =A0 Technical Summary > > > > > > This document summarizes the requirements for a mechanism=20 > to enable=20 > > > registration of multiple addresses of record within SIP. =A0 > The goal=20 > > > is to produce a mechanism =A0suitable for deployment by SIP service=20 > > > providers on a large scale in support of small to medium=20 > sized PBXs. > > > > > > =A0 =A0 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=20 > numbers and=20 > > > email-style addresses) was important. > > > > > > =A0 =A0 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. > > > > > > =A0 =A0 Personnel > > > > > > Bernard Aboba is the document shepherd for this document. > > > Gonzalo Camarillo is the responsible AD. > > > > > > > > > > > > _______________________________________________ > > > 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 > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From martien.huysmans@ericsson.com Thu May 6 08:25:44 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 1F7DC28C18B for ; Thu, 6 May 2010 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=-2.063, 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 9lM+T7lzJ636 for ; Thu, 6 May 2010 08:25:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9EC4328C183 for ; Thu, 6 May 2010 08:01:16 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-8f-4be2d9ae93a9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CA.0E.21861.EA9D2EB4; Thu, 6 May 2010 17:01:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 6 May 2010 17:01:02 +0200 From: Martien Huysmans To: Hans Erik van Elburg , Hadriel Kaplan Date: Thu, 6 May 2010 17:01:01 +0200 Thread-Topic: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive Thread-Index: AcrsXRH1iZLCZyajSiyFj9e4cyMOpAAzrH8g Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@mail> <430FC6BDED356B4C8498F634416644A91A8A5F1D7B@mail> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive 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, 06 May 2010 15:25:44 -0000 The email below contain the following statement: ---- This is a very strange use case, normally you either receive service from t= he SSP (centrex scenario) or from the PBX. Mixing those two is asking for p= roblems. Conflicting service configurations etc. In such a case the user wo= uld rather have two different AOR's. ---- I think that SIP Connect 1.1 mentions the combination of a user registered = at the PBX=20 could have a VoiceMail service from the SSP. I als remember a previous email from Adam where I asked Are you saying that the current martini-gin draft supports an=20 architecture where for sip:+1234567@ssp.com the presence server=20 resides at the SSP and where the IPPBX would provide voice services? and Adam replied: =20 It certainly does. It also supports one in which the presence server resi= des at the PBX.=20 This also true for voicemail, and pretty much any other service typically= =20 provided in the network. So I am left a little bit puzzled, what the architecture supports. /Martien =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Hans Erik van Elburg Sent: Wednesday, May 05, 2010 4:08 PM To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling= for draft-gin and draft-olive On Tue, May 4, 2010 at 4:42 PM, Hadriel Kaplan wro= te: > > Hi Hans Erik, > I _think_ what you're saying is: for the case where a SUBSCRIBE is target= ed to an AoR the PBX implicitly registered for, it should be routed to the = PBX; and for the case where we want the SSP to process it itself, we should= define a new target syntax, such as the "bnc" param I use in the draft. = =A0In other words, swap those two cases in the draft from a target URI pers= pective. > > Correct? > [HE] Yes you could interpret it like that. But I also think there is no nee= d for the case where the SSP returns the result, so I would just suggest to= remove that unless there is a use case for which this information is usefu= ll. > Obviously that's also a reasonable way to go, but I'd like to make that a= n open issue/decision for WG consensus. > > Personally I prefer it the way in the current vermouth draft: a SUBSCRIBE= targeted to the AoR gets processed by the SSP just like any other, while a= SUBSCRIBE to the AoR with a URI param of "bnc" gets routed to the PBX. > > My reasoning is as follows: > Currently, for any "normal" Registration model, a SUBSCRIBE targeted to t= he AoR gets processed by the SSP. =A0In effect, the combination of that tar= get URI and the "reg" event package indicator are used as a resource identi= fier for getting the SSP's registration state of that AoR. =A0So... > Yes for normal registrations you may view it like that. > 1) Currently, since the SUBSCRIBE's target URI looks like any other AoR o= f the SSP, *any* proxy in the SSP can make a simple routing decision to sen= d all SUBSCRIBEs for reg-event to a specific app server which handles reg-e= vent, without knowing what "type" of AoR the target URI refers to. =A0If we= make SUBSCRIBEs for implicitly registered AoRs route differently, without = some specific indication in the SUBSCRIBE, then that's no longer as simple = a thing to do. > I do not agree, the location server can together with the location where th= e AOR can be reached return information that this is a bulk contact. That i= nformation can be used by the SSP's proxy to apply proper handling. > 2) It really is possible for the SSP to support multiple contacts for any= AoR in the set of implicitly registered AoRs. =A0It's not common of course= , but I could see an SSP wanting to offer their customers to Register one o= r more of those same numbers for home-office or traveling users. =A0Those u= sers really will be Registered in the SSP, not the PBX. =A0And the SSP real= ly will have legitimate, "normal" registration state for that same AoR whic= h is also Registered implicitly by the PBX. =A0So for that case the SUBSCRI= BE being routed differently than normal is really screwed up. > This is a very strange use case, normally you either receive service from t= he SSP (centrex scenario) or from the PBX. Mixing those two is asking for p= roblems. Conflicting service configurations etc. In such a case the user wo= uld rather have two different AOR's. > 3) Personally, I think in hindsight it was a mistake to have SUBSCRIBEs f= or a target URI route differently than any other request for that same targ= et URI, and route differently for different event packages. =A0That ship ha= s sailed, obviously, and all kinds of method-specific and header-specific r= outing occurs in the real world - but it would be nice not to add yet more = complexity by having different routing for a combination of {method + event= + AoR-type}. =A0It's not a huge deal, since we're already down that rabbit= hole, but still it would be nice. > The more impportant criterion is if the result that the subscriber expects = is usefull and meaningful. That there will be slight differences certain be= haviours for bulk registrations is completely OK. And the complexity added = is minor really. /Hans Erik _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From trac@tools.ietf.org Thu May 6 09:21: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 3F5F83A6B63 for ; Thu, 6 May 2010 09:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.167, 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 aM7UAAgqEnJQ for ; Thu, 6 May 2010 09:21:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D54483A69D1 for ; Thu, 6 May 2010 09:18:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OA3mY-0001fi-Cf; Thu, 06 May 2010 09:18:38 -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.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Thu, 06 May 2010 16:18:38 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/44 Message-ID: <076.fa8b2577d9df47f0a9e152e92c961a8a@tools.ietf.org> X-Trac-Ticket-ID: 44 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] #44: Removal of text in section 1 to do with non-E.164-based AORs 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: Thu, 06 May 2010 16:21:38 -0000 #44: Removal of text in section 1 to do with non-E.164-based AORs ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: reqs | Version: Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- The text beginning "The ability to handle other forms of AOR..." onwards in the last paragraph of section 1 is inconsistent with the recently added REQ20 and REQ21. It is no longer relevant and can be deleted. -- Ticket URL: martini From trac@tools.ietf.org Thu May 6 09:22:33 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 0101A28C107 for ; Thu, 6 May 2010 09:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.167, 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 lRSFufrQDIup for ; Thu, 6 May 2010 09:22:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C87E528C104 for ; Thu, 6 May 2010 09:19:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OA3nD-0003uQ-0X; Thu, 06 May 2010 09:19: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.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Thu, 06 May 2010 16:19:18 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/44#comment:1 Message-ID: <085.877db24be427154a96107c5166f3658c@tools.ietf.org> References: <076.fa8b2577d9df47f0a9e152e92c961a8a@tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <076.fa8b2577d9df47f0a9e152e92c961a8a@tools.ietf.org> 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: Re: [martini] #44: Removal of text in section 1 to do with non-E.164-based AORs 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: Thu, 06 May 2010 16:22:33 -0000 #44: Removal of text in section 1 to do with non-E.164-based AORs ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: reqs | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Changes (by john.elwell@…): * status: new => closed * resolution: => fixed -- Ticket URL: martini From john.elwell@siemens-enterprise.com Thu May 6 09:28:10 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 EB1D13A6B83 for ; Thu, 6 May 2010 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, TVD_SPACE_RATIO=2.219] 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 mQLHWaZLCbbN for ; Thu, 6 May 2010 09:28:10 -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 AA1D53A68D0 for ; Thu, 6 May 2010 09:26:30 -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-86227 for martini@ietf.org; Thu, 6 May 2010 18:26:17 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 4918A1EB82AB for ; Thu, 6 May 2010 18:26:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 6 May 2010 18:26:17 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Thu, 6 May 2010 18:26:16 +0200 Thread-Topic: Reqs--06 submitted Thread-Index: AcrtONobOD05OJuDTHiO8xUoYUeLKw== Message-ID: 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: [martini] Reqs--06 submitted 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, 06 May 2010 16:28:11 -0000 This just fixes issue #44: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-06.txt John From root@core3.amsl.com Thu May 6 09:30: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 D11123A6C05; Thu, 6 May 2010 09:30: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: <20100506163001.D11123A6C05@core3.amsl.com> Date: Thu, 6 May 2010 09:30:01 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-reqs-06.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: Thu, 06 May 2010 16:30: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 : 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-06.txt Pages : 12 Date : 2010-05-06 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 PBXs. The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This work is being discussed on the martini@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-06092516.I-D@ietf.org> --NextPart-- From HKaplan@acmepacket.com Thu May 6 21:25:31 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 3242F3A6830 for ; Thu, 6 May 2010 21:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_50=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 LRJo9LpUOl2d for ; Thu, 6 May 2010 21:25:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CD3203A691C for ; Thu, 6 May 2010 21:25:23 -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, 7 May 2010 00:25:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 00:25:10 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Fri, 7 May 2010 00:25:09 -0400 Thread-Topic: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive Thread-Index: AcrrCaVH7jcOUgcZRF2tKcDmy53I9ACkAdQA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D74A6@mail> References: <430FC6BDED356B4C8498F634416644A91A8A5F1BD4@mail> 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 Cc: "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive 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: Fri, 07 May 2010 04:25:31 -0000 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Monday, May 03, 2010 5:43 PM > To: Hadriel Kaplan > > - Appendix A: While I have no problem with simplifying the pattern, to > enable less configuration errors and complaince with RFC3261. You > bring back here the issue of automatically detecting provisioning > mismatches by the PBX. Is this based on something you have seen in > practice? Why would this be an issue at all? Even in the simplified > case I don not think that an IP-PBX can conclude anything when it has > knowledge about the full generated set of AOR's. It suffices to match > each configured AOR with the patterns returned. Yes, unfortunately it's been a real issue. For example, there was a servic= e outage just a couple weeks ago in a big carrier which impacted service fo= r a bunch of Enterprise trunks. Several things were configured incorrectly= to make it become an actual outage of service for a bunch of Enterprise tr= unks, but the initial trigger which brought it down was the SSP thought the= PBX owned a number and the PBX did not. It caused an infinite loop, and d= ue to poor configuration (and no throttles) several systems went to max uti= lization until humans stopped it. So having a PBX just run a regex against the numbers it knows about is not = enough - because that doesn't tell it what *additional* numbers the SSP thi= nks the PBX has which the PBX doesn't. One could design a PBX to also use = the regex against SIP Requests themselves, and decide that if the regex mat= ches the Request's URI then it does own the username, and then return a 404= if it doesn't really have provisioning for that username. But even that w= ould get complicated fast. These regex's are provisioned by people, and in= my experience most people are really bad at creating _good_ regex patterns= . Unless we really need the complete flexibility of a regex pattern, I wou= ld recommend we avoid it. -hadriel From martien.huysmans@ericsson.com Thu May 6 23:41:25 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 64AC63A68B0 for ; Thu, 6 May 2010 23:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[AWL=1.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 COELn4pmJmjG for ; Thu, 6 May 2010 23:41:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DCA653A69EF for ; Thu, 6 May 2010 23:41:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-e2-4be3b6053e35 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B7.20.08537.506B3EB4; Fri, 7 May 2010 08:41:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 7 May 2010 08:41:09 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Fri, 7 May 2010 08:41:08 +0200 Thread-Topic: draft-ietf-martini-reqs-06.txt: req 1 "deemed to have been assigned" Thread-Index: AcrtsEZfuzxnVn5FTn2wTui1sZCD8g== 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_B5CE2B521539624E8364D395B6F76B5C1DCF16D673ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] draft-ietf-martini-reqs-06.txt: req 1 "deemed to have been assigned" 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: Fri, 07 May 2010 06:41:25 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D673ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question on req 1 in draft-ietf-martini-reqs-06.txt. The text talks about "telephone numbers deemed to have been assigned to the= SIP-PBX". Why does the text include "deemed to have been"? The term "deemed" isn't used elsewhere in this document. /Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D673ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Question on req 1 in draft-ietf-martini-reqs-06.txt.
 
The text talks about "telephone numbers deemed to have been assigned to the SIP-PBX".=
 
Why does the text inc= lude "deemed to have been"?
The term "deemed= " isn't used elsewhere in this document.
 
/Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D673ESESSCMS0356e_-- From martien.huysmans@ericsson.com Thu May 6 23:54:33 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 49DFB3A6B9E for ; Thu, 6 May 2010 23:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, 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 Z7GnhZxS2dy9 for ; Thu, 6 May 2010 23:54:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 428183A6BE1 for ; Thu, 6 May 2010 23:54:31 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-8f-4be3b9197fe0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BF.36.21861.919B3EB4; Fri, 7 May 2010 08:54:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 7 May 2010 08:54:17 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Fri, 7 May 2010 08:54:16 +0200 Thread-Topic: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Thread-Index: AcrtshwWqHqa9So2TYGa8e5DGI//gQ== 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_B5CE2B521539624E8364D395B6F76B5C1DCF16D6ACESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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: Fri, 07 May 2010 06:54:33 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D6ACESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question on draft-ietf-martini-reqs-06.txt. The text talks twice about "UAs register with the SIP-PBX on behalf of the = AORs concerned". What does this mean? How does an UA register with an SIP-PBX "on behalf of" an AOR? /Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D6ACESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Question on draft-ietf-martini-reqs-06.txt.
 
The text talks twice about "UAs register with the SIP-PBX on behalf of the AORs concerned&q= uot;.
What does this mean?<= /font>
How does an UA regist= er with an SIP-PBX "on behalf of" an AOR?
 
/Martien
 
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D6ACESESSCMS0356e_-- From martien.huysmans@ericsson.com Fri May 7 00:02:26 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 F233E3A6BB4 for ; Fri, 7 May 2010 00:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.192 X-Spam-Level: X-Spam-Status: No, score=-5.192 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 4dGEST0eou+m for ; Fri, 7 May 2010 00:02:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 052273A67D2 for ; Fri, 7 May 2010 00:02:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-04-4be3baf2e0c1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.83.08537.2FAB3EB4; Fri, 7 May 2010 09:02:11 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 7 May 2010 09:02:10 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Fri, 7 May 2010 09:02:09 +0200 Thread-Topic: draft-ietf-martini-reqs-06: textual comments Thread-Index: AcrtszYoAIBIFInCSg+Z+kBAkRnSyA== 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_B5CE2B521539624E8364D395B6F76B5C1DCF16D6C1ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] draft-ietf-martini-reqs-06: textual comments 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: Fri, 07 May 2010 07:02:26 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D6C1ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some minor textual comments - the document uses the terms client, subscriber and user. where I have the feeling that they may mean the same - ch 3 talks about "normal" first-party SIP REGISTER. I suggest to remove "first-party". - chapter 6 talks about "numbers", where it should say "telephone numbers" /Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D6C1ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Some minor textual comments
 
- the document uses the terms client, subscriber and user.
  where I have the feeling that they may mean the same
 
- ch 3 talks about "normal" first-party SIP REGISTER.
  I suggest to remove "first-party".
 
- chapter 6 talks about "numbers", where it should say "= ;telephone numbers"
 
/Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DCF16D6C1ESESSCMS0356e_-- From john.elwell@siemens-enterprise.com Fri May 7 06:02: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 668983A6851 for ; Fri, 7 May 2010 06:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.208, 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 T8umiPTEeRK9 for ; Fri, 7 May 2010 06:02:17 -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 BD87F3A6837 for ; Fri, 7 May 2010 06:02:16 -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-97473; Fri, 7 May 2010 15:01:59 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 91E091EB82AB; Fri, 7 May 2010 15:01:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 7 May 2010 15:01:59 +0200 From: "Elwell, John" To: Martien Huysmans , "martini@ietf.org" Date: Fri, 7 May 2010 15:01:58 +0200 Thread-Topic: [martini] draft-ietf-martini-reqs-06.txt: req 1 "deemed to have been assigned" Thread-Index: AcrtsEZfuzxnVn5FTn2wTui1sZCD8gANQa6g 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] draft-ietf-martini-reqs-06.txt: req 1 "deemed to have been assigned" 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: Fri, 07 May 2010 13:02:18 -0000 It can probably be deleted. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > Sent: 07 May 2010 07:41 > To: martini@ietf.org > Subject: [martini] draft-ietf-martini-reqs-06.txt: req 1=20 > "deemed to have been assigned" >=20 > Question on req 1 in draft-ietf-martini-reqs-06.txt. > =20 > The text talks about "telephone numbers deemed to have been=20 > assigned to the SIP-PBX". > =20 > Why does the text include "deemed to have been"? > The term "deemed" isn't used elsewhere in this document. > =20 > /Martien > = From john.elwell@siemens-enterprise.com Fri May 7 06:02: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 8A6183A6B28 for ; Fri, 7 May 2010 06:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.206, 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 4tzkVZqE7j8q for ; Fri, 7 May 2010 06:02:29 -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 826113A6851 for ; Fri, 7 May 2010 06:02:29 -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-97480; Fri, 7 May 2010 15:02:16 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 90AA91EB82AB; Fri, 7 May 2010 15:02:16 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 7 May 2010 15:02:16 +0200 From: "Elwell, John" To: Martien Huysmans , "martini@ietf.org" Date: Fri, 7 May 2010 15:02:14 +0200 Thread-Topic: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Thread-Index: AcrtshwWqHqa9So2TYGa8e5DGI//gQAMtdgA 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] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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: Fri, 07 May 2010 13:02:30 -0000 Each UA that has credentials for a particular AOR can register a contact UR= I on behalf of that AOR. What is the problem with that? What preposition wo= uld you prefer? John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > Sent: 07 May 2010 07:54 > To: martini@ietf.org > Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on=20 > behalf of AOR". >=20 > Question on draft-ietf-martini-reqs-06.txt.=20 > =20 > The text talks twice about "UAs register with the SIP-PBX on=20 > behalf of the AORs concerned". > What does this mean? > How does an UA register with an SIP-PBX "on behalf of" an AOR? > =20 > /Martien > =20 > = From john.elwell@siemens-enterprise.com Fri May 7 06:03:51 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 D423F3A6837 for ; Fri, 7 May 2010 06:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_20=-0.74, 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 Zv-+IJqZSZQX for ; Fri, 7 May 2010 06:03:51 -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 D3D653A6811 for ; Fri, 7 May 2010 06:03:50 -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-97450; Fri, 7 May 2010 15:03:35 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8F89B1EB82AE; Fri, 7 May 2010 15:03:35 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 7 May 2010 15:03:35 +0200 From: "Elwell, John" To: Martien Huysmans , "martini@ietf.org" Date: Fri, 7 May 2010 15:03:33 +0200 Thread-Topic: draft-ietf-martini-reqs-06: textual comments Thread-Index: AcrtszYoAIBIFInCSg+Z+kBAkRnSyAAMIpJw 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] draft-ietf-martini-reqs-06: textual comments 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: Fri, 07 May 2010 13:03:51 -0000 I have started to make changes in my working copy, but it is most disappoin= ting to receive comments right after I posted a new version on text that ha= s been around for weeks. I will let the chairs advise me what to do. See al= so below: > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > Sent: 07 May 2010 08:02 > To: martini@ietf.org > Subject: [martini] draft-ietf-martini-reqs-06: textual comments >=20 > Some minor textual comments > =20 > - the document uses the terms client, subscriber and user. > where I have the feeling that they may mean the same [JRE] The term "subscriber" is probably wrong and should probably be change= d to user, but it is used in various contexts such as "normal subscriber UA= " where it should perhaps just be deleted. Please provide text proposals fo= r all instances you want changed. As for "client", that should be "user". > =20 > - ch 3 talks about "normal" first-party SIP REGISTER. > I suggest to remove "first-party". [JRE] "first party" was added to distinguish from "third party" - what is t= he problem with that? > =20 > - chapter 6 talks about "numbers", where it should say=20 > "telephone numbers" [JRE] Thanks. John > =20 > /Martien > = From pkyzivat@cisco.com Fri May 7 11:29:22 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 6777E3A68E4 for ; Fri, 7 May 2010 11:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.232 X-Spam-Level: X-Spam-Status: No, score=-9.232 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_05=-1.11, J_CHICKENPOX_57=0.6, 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 lRGs6alk0q5p for ; Fri, 7 May 2010 11:29:21 -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 10B7B3A68C2 for ; Fri, 7 May 2010 11:29:20 -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: AvsEAAf540tAZnwM/2dsb2JhbACeGXGmPplPhRUE X-IronPort-AV: E=Sophos;i="4.52,349,1270425600"; d="scan'208";a="109159951" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 May 2010 18:29:05 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o47IT5ha003386; Fri, 7 May 2010 18:29:05 GMT Message-ID: <4BE45BEE.7000606@cisco.com> Date: Fri, 07 May 2010 14:29:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hans Erik van Elburg References: <4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail> <4BE1F958.9090604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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: Fri, 07 May 2010 18:29:22 -0000 Hans Erik van Elburg wrote: > On Thu, May 6, 2010 at 1:03 AM, Paul Kyzivat wrote: >> >> Hans Erik van Elburg wrote: >>> On Tue, May 4, 2010 at 5:03 PM, Hadriel Kaplan >>> wrote: >>> >>>>> - An PBX registers with the SSP, to be able to send and receive calls. >>>>> No >>>>> astonishment >>>> Right, but it's Registering for an AoR *belonging to the SSP*. I.e., >>>> "sip:+12345@ssp.com". >>>> >>> [HE] Think it is more correct to say that it is registering >>> reachability information for a bulk contact, which is then bound by >>> the SSP to a bunch of implicitly registered AOR's. These AOR's dop not >>> have to belong to the SSP, but they can. The SSP's proxy is >>> responsible for handling them and forwarding them applying rules that >>> apply to bulk contacts. >> We've been through this before :-( >> > People still seem to misunderstand the implications though. Looking at > the conclusions that people draw from this. > >> If the domain of the request, when it arrives at the SSP, is not a domain it >> is responsible for, then it is bound to deliver it using 3261/3263 rules. >> SSP.com has no business making side agreements on where to route requests >> for other domains. >> > Correct. The key phrasing is here "responsible for". If the SSP has > an agreement with the owner of the domain "company.com" that it will > handle incoming traffic for that company, then the SSP's proxy is > configured to be "responsible" for that domain. And it would also need > to make this known into DNS so that traffic for that domain will be > delivered to the SSP. I think this is not good enough. If I come to the SSP and sign it up to forward incoming traffic for whitehouse.gov to me, how is it supposed to determine if I am the rightful owner of that domain? And if I am, now does it determine if I continue to be? You might argue: what's the harm? If I'm not the owner of whitehouse.gov then I won't be able to update DNS to direct whitehouse.gov traffic to the SSP. But there is still harm, because even without that I can then snag any traffic for whitehouse.gov that is originated by another of the SSP's customers. Its a different situation if the SSP acquires a domain name of my choice on my behalf. Then it clearly is responsible for the domain. The fuzzy area is where I acquire rights to the domain name, and update DNS to direct sip traffic to the SSP. In that case, what you suggest should work, if there was a way to ensure that I own the rights to that domain, and thus have the right to delegate responsibility for it to the SSP. In principle that should be ok, but I don't know how the SSP learns this and also learns if/when the ownership changes. Thanks, Paul >> Otherwise, I'm going to sign up my pbx with your SSP and ask to have >> sip:barack_obama@whitehouse.gov be one of my implicitly registered AORs. >> > You can ask watever you want, but your SSP is not going to configure > that for you unless you own the domain whitehgouse.gov and are the > person that is allowed to make such requests under the agreement > between the SSP and company.com. > >> This kind of routing *must* be restricted to domains the SSP is responsible >> for. >> > Yes, I agree. But if it is responsible for a domain it does not mean > that it owns the domain. From martien.huysmans@ericsson.com Mon May 10 03:42:28 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 E797B3A6884 for ; Mon, 10 May 2010 03:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_50=0.001, J_CHICKENPOX_57=0.6, 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 GsQ-h0B60ojc for ; Mon, 10 May 2010 03:42:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8638D3A680A for ; Mon, 10 May 2010 03:42:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-bf-4be7e30675f5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CF.8A.08537.603E7EB4; Mon, 10 May 2010 12:42:14 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 10 May 2010 12:42:13 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 10 May 2010 12:41:14 +0200 From: Martien Huysmans To: Paul Kyzivat , Hans Erik van Elburg Date: Mon, 10 May 2010 12:41:13 +0200 Thread-Topic: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) Thread-Index: AcruEzIZumeoRdYOSUC8d+d+UeVwYACGWp2Q Message-ID: References: <4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail> <4BE1F958.9090604@cisco.com> <4BE45BEE.7000606@cisco.com> In-Reply-To: <4BE45BEE.7000606@cisco.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-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 10 May 2010 10:42:29 -0000 Paul The answer confuses me. You start by saying "I think this is not good enoug= h'. and then you email ends with "In principle that should be ok". And this for a first and last paragraph that include similar questions. Isn't the domain name ownership really a security related question? /Martien -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: Friday, May 07, 2010 8:29 PM To: Hans Erik van Elburg Cc: Bernard Aboba; martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packagea= nd individual extension state(section 7.2.2)) Hans Erik van Elburg wrote: > On Thu, May 6, 2010 at 1:03 AM, Paul Kyzivat wrote: >> >> Hans Erik van Elburg wrote: >>> On Tue, May 4, 2010 at 5:03 PM, Hadriel Kaplan=20 >>> >>> wrote: >>> >>>>> - An PBX registers with the SSP, to be able to send and receive calls= . >>>>> No >>>>> astonishment >>>> Right, but it's Registering for an AoR *belonging to the SSP*. =20 >>>> I.e., "sip:+12345@ssp.com". >>>> >>> [HE] Think it is more correct to say that it is registering=20 >>> reachability information for a bulk contact, which is then bound by=20 >>> the SSP to a bunch of implicitly registered AOR's. These AOR's dop=20 >>> not have to belong to the SSP, but they can. The SSP's proxy is=20 >>> responsible for handling them and forwarding them applying rules=20 >>> that apply to bulk contacts. >> We've been through this before :-( >> > People still seem to misunderstand the implications though. Looking at=20 > the conclusions that people draw from this. >=20 >> If the domain of the request, when it arrives at the SSP, is not a=20 >> domain it is responsible for, then it is bound to deliver it using 3261/= 3263 rules. >> SSP.com has no business making side agreements on where to route=20 >> requests for other domains. >> > Correct. The key phrasing is here "responsible for". If the SSP has=20 > an agreement with the owner of the domain "company.com" that it will=20 > handle incoming traffic for that company, then the SSP's proxy is=20 > configured to be "responsible" for that domain. And it would also need=20 > to make this known into DNS so that traffic for that domain will be=20 > delivered to the SSP. I think this is not good enough. If I come to the SSP and sign it up to forward incoming traffic for whiteho= use.gov to me, how is it supposed to determine if I am the rightful owner o= f that domain? And if I am, now does it determine if I continue to be? You might argue: what's the harm? If I'm not the owner of whitehouse.gov th= en I won't be able to update DNS to direct whitehouse.gov traffic to the SS= P. But there is still harm, because even without that I can then snag any t= raffic for whitehouse.gov that is originated by another of the SSP's custom= ers. Its a different situation if the SSP acquires a domain name of my choice on= my behalf. Then it clearly is responsible for the domain. The fuzzy area is where I acquire rights to the domain name, and update DNS= to direct sip traffic to the SSP. In that case, what you suggest should wo= rk, if there was a way to ensure that I own the rights to that domain, and = thus have the right to delegate responsibility for it to the SSP. In princi= ple that should be ok, but I don't know how the SSP learns this and also le= arns if/when the ownership changes. Thanks, Paul >> Otherwise, I'm going to sign up my pbx with your SSP and ask to have=20 >> sip:barack_obama@whitehouse.gov be one of my implicitly registered AORs. >> > You can ask watever you want, but your SSP is not going to configure=20 > that for you unless you own the domain whitehgouse.gov and are the=20 > person that is allowed to make such requests under the agreement=20 > between the SSP and company.com. >=20 >> This kind of routing *must* be restricted to domains the SSP is=20 >> responsible for. >> > Yes, I agree. But if it is responsible for a domain it does not mean=20 > that it owns the domain. _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From martien.huysmans@ericsson.com Mon May 10 04:44:42 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 BE48228C17B for ; Mon, 10 May 2010 04:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.372 X-Spam-Level: X-Spam-Status: No, score=-4.372 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, 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 Zy-N7CPMlhsI for ; Mon, 10 May 2010 04:44:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CD26328C15F for ; Mon, 10 May 2010 04:44:20 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-e1-4be7f187a4b5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6F.C3.08537.781F7EB4; Mon, 10 May 2010 13:44:08 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 10 May 2010 13:44:07 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 10 May 2010 13:44:07 +0200 From: Martien Huysmans To: "Elwell, John" , "martini@ietf.org" Date: Mon, 10 May 2010 13:44:05 +0200 Thread-Topic: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Thread-Index: AcrtshwWqHqa9So2TYGa8e5DGI//gQAMtdgAAJJtG7A= 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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, 10 May 2010 11:44:42 -0000 John The "problem" is trying to understand why the text includes "on behalf of". This document is input for the other martini document and it should make sense to me or anybody else.=20 I looked at RFC3261 on the usage of "on behalf of". Section 10.2:=20 Registration on behalf of a particular address-of-record can be performe= d=20 by a suitably authorized third party.=20 I have the impression that your text is not talking about "3rd party regist= ration". But I may be wrong. You asked for a proposition. Here is an attempt. 1) remove the sentence in section 1. Rationale: The information feels superluous compared to the=20 sentences before this sentence. 2) Update REQ4 to: The mechanism MUST allow an UA to register with a SIP-PBX=20 without needing to involve the SSP in the registration process, in order to receive requests targeted at assigned telephone numbers. Rationale: - it uses MUST instead of "MUST NOT". - 3rd party registration is a "basic mechanims" according RFC3261. So no need to repeat that. /Martien -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Friday, May 07, 2010 3:02 PM To: Martien Huysmans; martini@ietf.org Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Each UA that has credentials for a particular AOR can register a contact UR= I on behalf of that AOR. What is the problem with that? What preposition wo= uld you prefer? John=20 > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > Sent: 07 May 2010 07:54 > To: martini@ietf.org > Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf=20 > of AOR". >=20 > Question on draft-ietf-martini-reqs-06.txt.=20 > =20 > The text talks twice about "UAs register with the SIP-PBX on behalf of=20 > the AORs concerned". > What does this mean? > How does an UA register with an SIP-PBX "on behalf of" an AOR? > =20 > /Martien > =20 > = From martien.huysmans@ericsson.com Mon May 10 06:17: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 AD5FE28C133 for ; Mon, 10 May 2010 06:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_40=-0.185, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4, 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 o1L0RSf+reRv for ; Mon, 10 May 2010 06:17:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C07E028C195 for ; Mon, 10 May 2010 06:17:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-74-4be8075497d7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.41.08537.45708EB4; Mon, 10 May 2010 15:17:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 10 May 2010 15:17:08 +0200 From: Martien Huysmans To: "Elwell, John" , "martini@ietf.org" Date: Mon, 10 May 2010 15:17:07 +0200 Thread-Topic: draft-ietf-martini-reqs-06: textual comments Thread-Index: AcrtszYoAIBIFInCSg+Z+kBAkRnSyAAMIpJwAJSYuYA= 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] draft-ietf-martini-reqs-06: textual comments 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, 10 May 2010 13:17:56 -0000 John I appologize for any inconvience. I am new to IETF and rather late into the= MARTINI discussion. I saw the WGLC, which I thought is an invitation for (last0 comments. Other comments below.. /Martien -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Friday, May 07, 2010 3:04 PM To: Martien Huysmans; martini@ietf.org Subject: RE: draft-ietf-martini-reqs-06: textual comments I have started to make changes in my working copy, but it is most disappoin= ting to receive comments right after I posted a new version on text that ha= s been around for weeks. I will let the chairs advise me what to do. See al= so below: > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > Sent: 07 May 2010 08:02 > To: martini@ietf.org > Subject: [martini] draft-ietf-martini-reqs-06: textual comments >=20 > Some minor textual comments > =20 > - the document uses the terms client, subscriber and user. > where I have the feeling that they may mean the same [JRE] The term "subscriber" is probably wrong and should probably be change= d to user, but it is used in various contexts such as "normal subscriber UA= " where it should perhaps just be deleted. Please provide text proposals fo= r all instances you want changed. As for "client", that should be "user". [MAHU] Subscriber is used at number of places. Here is overview and propose= d changes: Section 3: "typical subscriber UA" -> "normal user" Section 3.1.1: "normal subscriber Uas" -> "normal user" "subscriber Uas" -> "user" Section 5, DES1: "ordinary subscribers" -> "normal users" > =20 > - ch 3 talks about "normal" first-party SIP REGISTER. > I suggest to remove "first-party". [JRE] "first party" was added to distinguish from "third party" - what is t= he problem with that? [MAHU] I understand the distinction. But the current text/document doesn't = talk about "third party". The current text is: In all respects, it appears on the wire as a "normal" first-party SIP RE= GISTER request,=20 as if from a typical subscriber UA. This sentence has some redundancy: "normal", "first-part" and "as if from a= typical subscriber UA" all seem to convey the same message. This is a minor thing. If you like the proposal, ok. If not, also ok. > =20 > - chapter 6 talks about "numbers", where it should say "telephone=20 > numbers" [JRE] Thanks. John > =20 > /Martien > = From john.elwell@siemens-enterprise.com Mon May 10 06:43:04 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 AFE863A694F for ; Mon, 10 May 2010 06:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_50=0.001, GB_I_INVITATION=-2, 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 RCNwlXNIWaeY for ; Mon, 10 May 2010 06:43:03 -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 79AE63A68E6 for ; Mon, 10 May 2010 06:43:03 -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-117189; Mon, 10 May 2010 15:42:50 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id AE10923F0278; Mon, 10 May 2010 15:42:50 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 10 May 2010 15:42:50 +0200 From: "Elwell, John" To: Martien Huysmans , "martini@ietf.org" Date: Mon, 10 May 2010 15:42:49 +0200 Thread-Topic: draft-ietf-martini-reqs-06: textual comments Thread-Index: AcrtszYoAIBIFInCSg+Z+kBAkRnSyAAMIpJwAJSYuYAAA54KsA== 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] draft-ietf-martini-reqs-06: textual comments 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, 10 May 2010 13:43:04 -0000 Martien, The WGLC finished several weeks ago, but nevertheless your comments are app= reciated. My expression of disappointment was not aimed at you personally, = but the continued delays in getting this document, which is only Informatio= nal, out of the door. I have taken on board your comments in my working cop= y (with some slight changes - see below), but I will hold back for a day or= so before publishing 07 to see if further comments arrive.=20 > -----Original Message----- > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com]=20 > Sent: 10 May 2010 14:17 > To: Elwell, John; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06: textual comments >=20 > John >=20 > I appologize for any inconvience. I am new to IETF and rather=20 > late into the MARTINI discussion. > I saw the WGLC, which I thought is an invitation for (last0 comments. >=20 > Other comments below.. >=20 > /Martien >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Friday, May 07, 2010 3:04 PM > To: Martien Huysmans; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06: textual comments >=20 > I have started to make changes in my working copy, but it is=20 > most disappointing to receive comments right after I posted a=20 > new version on text that has been around for weeks. I will=20 > let the chairs advise me what to do. See also below: >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > > Sent: 07 May 2010 08:02 > > To: martini@ietf.org > > Subject: [martini] draft-ietf-martini-reqs-06: textual comments > >=20 > > Some minor textual comments > > =20 > > - the document uses the terms client, subscriber and user. > > where I have the feeling that they may mean the same > [JRE] The term "subscriber" is probably wrong and should=20 > probably be changed to user, but it is used in various=20 > contexts such as "normal subscriber UA" where it should=20 > perhaps just be deleted. Please provide text proposals for=20 > all instances you want changed. As for "client", that should=20 > be "user". > [MAHU] Subscriber is used at number of places. Here is=20 > overview and proposed changes: > Section 3: "typical subscriber UA" -> "normal user" > Section 3.1.1: "normal subscriber Uas" -> "normal user" > "subscriber Uas" -> "user" > Section 5, DES1: "ordinary subscribers" -> "normal users" [JRE] I prefer to keep "UA" in place, so I have changed to "typical user's = UA" and "normal UAs". >=20 > > =20 > > - ch 3 talks about "normal" first-party SIP REGISTER. > > I suggest to remove "first-party". > [JRE] "first party" was added to distinguish from "third=20 > party" - what is the problem with that? > [MAHU] I understand the distinction. But the current=20 > text/document doesn't talk about "third party". > The current text is: > In all respects, it appears on the wire as a "normal"=20 > first-party SIP REGISTER request,=20 > as if from a typical subscriber UA. > This sentence has some redundancy: "normal", "first-part" and=20 > "as if from a typical subscriber UA" > all seem to convey the same message. >=20 > This is a minor thing. If you like the proposal, ok. If not, also ok. [JRE] I have done as you suggest. John >=20 > > =20 > > - chapter 6 talks about "numbers", where it should say "telephone=20 > > numbers" > [JRE] Thanks. >=20 > John >=20 > > =20 > > /Martien > > = From john.elwell@siemens-enterprise.com Mon May 10 06:57:47 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 EA99D3A6880 for ; Mon, 10 May 2010 06:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.239, 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 2iEdzt6z7UEn for ; Mon, 10 May 2010 06:57:47 -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 D0E123A683C for ; Mon, 10 May 2010 06:57:46 -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-117533; Mon, 10 May 2010 15:57:34 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D0A8A23F0278; Mon, 10 May 2010 15:57:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 10 May 2010 15:57:34 +0200 From: "Elwell, John" To: Martien Huysmans , "martini@ietf.org" Date: Mon, 10 May 2010 15:57:33 +0200 Thread-Topic: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Thread-Index: AcrtshwWqHqa9So2TYGa8e5DGI//gQAMtdgAAJJtG7AABly/EA== 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] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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, 10 May 2010 13:57:48 -0000 =20 > -----Original Message----- > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com]=20 > Sent: 10 May 2010 12:44 > To: Elwell, John; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on=20 > behalf of AOR". >=20 > John >=20 > The "problem" is trying to understand why the text includes=20 > "on behalf of". > This document is input for the other martini document and it=20 > should make > sense to me or anybody else.=20 >=20 > I looked at RFC3261 on the usage of "on behalf of". > Section 10.2:=20 > Registration on behalf of a particular address-of-record=20 > can be performed=20 > by a suitably authorized third party.=20 > I have the impression that your text is not talking about=20 > "3rd party registration". > But I may be wrong. >=20 > You asked for a proposition. Here is an attempt. >=20 > 1) remove the sentence in section 1. > Rationale: The information feels superluous compared to the=20 > sentences before this sentence. [JRE] I will do this. >=20 > 2) Update REQ4 to: > The mechanism MUST allow an UA to register with a SIP-PBX=20 > without needing to involve the SSP in the registration process, > in order to receive requests targeted at assigned=20 > telephone numbers. [JRE] I liked the existing "MUST NOT prevent" formulation, because clearly,= even without MARTINI, UAs behind a PBX can register with the PBX, so we ju= st want to make sure the MARTINI mechanism does not prevent this. I think w= e can change "on behalf of" to "for", if that helps. Again, changes are in my working copy - I will wait a day or two before pub= lishing reqs-07. John >=20 > Rationale: > - it uses MUST instead of "MUST NOT". > - 3rd party registration is a "basic mechanims" according=20 > RFC3261. So > no need to repeat that. >=20 > /Martien >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Friday, May 07, 2010 3:02 PM > To: Martien Huysmans; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on=20 > behalf of AOR". >=20 > Each UA that has credentials for a particular AOR can=20 > register a contact URI on behalf of that AOR. What is the=20 > problem with that? What preposition would you prefer? >=20 > John=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > > Sent: 07 May 2010 07:54 > > To: martini@ietf.org > > Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4:=20 > "on behalf=20 > > of AOR". > >=20 > > Question on draft-ietf-martini-reqs-06.txt.=20 > > =20 > > The text talks twice about "UAs register with the SIP-PBX=20 > on behalf of=20 > > the AORs concerned". > > What does this mean? > > How does an UA register with an SIP-PBX "on behalf of" an AOR? > > =20 > > /Martien > > =20 > > = From bernard_aboba@hotmail.com Mon May 10 07:29: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 AE93C3A6963 for ; Mon, 10 May 2010 07:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.542 X-Spam-Level: X-Spam-Status: No, score=0.542 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6] 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 Ee6ADTjARdDJ for ; Mon, 10 May 2010 07:29:30 -0700 (PDT) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by core3.amsl.com (Postfix) with ESMTP id D5F593A6885 for ; Mon, 10 May 2010 07:29:29 -0700 (PDT) Received: from BLU137-W19 ([65.55.116.74]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 May 2010 07:29:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a4dadc99-1009-47b9-94f2-62a39f5f5fd6_" X-Originating-IP: [66.243.40.183] From: Bernard Aboba To: , Date: Mon, 10 May 2010 07:29:18 -0700 Importance: Normal In-Reply-To: References: , , <4BDF5A25.2030208@nostrum.com>, , <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com>, , , <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail>, , <4BE1F958.9090604@cisco.com>, , <4BE45BEE.7000606@cisco.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 10 May 2010 14:29:19.0414 (UTC) FILETIME=[2D26B560:01CAF04D] Cc: martini@ietf.org Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 10 May 2010 14:29:30 -0000 --_a4dadc99-1009-47b9-94f2-62a39f5f5fd6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > You can ask whatever you want=2C but your SSP is not going to configure=20 > that for you unless you own the domain whitehouse.gov and are the=20 > person that is allowed to make such requests under the agreement=20 > between the SSP and company.com. Just to be clear -- this particular issue isn't unique to MARTINI. It's al= so not confined to dynamic registration. =20 = --_a4dadc99-1009-47b9-94f2-62a39f5f5fd6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B You can ask whatever you want=2C but your SSP is not going to config= ure
>=3B that for you unless you own the domain whitehouse.gov and ar= e the
>=3B person that is allowed to make such requests under the agr= eement
>=3B between the SSP and company.com.

Just to be clear = -- this particular issue isn't unique to MARTINI. =3B It's also not con= fined to dynamic registration. =3B
= --_a4dadc99-1009-47b9-94f2-62a39f5f5fd6_-- From pkyzivat@cisco.com Mon May 10 07:49:34 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 106FA3A6885 for ; Mon, 10 May 2010 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.96 X-Spam-Level: X-Spam-Status: No, score=-9.96 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 wrQI1f8f8l5S for ; Mon, 10 May 2010 07:49:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D63083A69D2 for ; Mon, 10 May 2010 07:49:28 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoDALq550tAaHtekWdsb2JhbACeHxUBAQEBCQsRESKjW5koglqCOgQ X-IronPort-AV: E=Sophos;i="4.52,362,1270425600"; d="scan'208";a="60995130" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-1.cisco.com with ESMTP; 10 May 2010 14:49:14 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4AEnBLC017340; Mon, 10 May 2010 14:49:12 GMT Message-ID: <4BE81CEC.6040005@cisco.com> Date: Mon, 10 May 2010 10:49:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Martien Huysmans References: <4BDF5A25.2030208@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141D4A68C9@zcarhxm1.corp.nortel.com> <430FC6BDED356B4C8498F634416644A91A8A5F1D9D@mail> <4BE1F958.9090604@cisco.com> <4BE45BEE.7000606@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) 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, 10 May 2010 14:49:34 -0000 Martien Huysmans wrote: > Paul > > The answer confuses me. You start by saying "I think this is not good enough'. > and then you email ends with "In principle that should be ok". And this for > a first and last paragraph that include similar questions. My "is not good enough" statement was in regard to there simply being an agreement between pbx and SSP that the ssp will direct traffic for some AOR to the pbx. IMO there needs to be a stronger meaning to "is responsible for", that is consistent with 3263. That is, unfortunately, currently lacking from 3261 and 3263. My latter statement was narrower: - it assumes that there is indeed a DNS registration, owned by the owner of the pbx, but pointing to the SSP's servers - that there is a way for the SSP to ascertain that DNS has been so provisioned > Isn't the domain name ownership really a security related question? I suppose so. At least, if strong e2e identity was in place then defects in routing would eventually be detected. But of course an e2e identity mechanism isn't widely in place. Having it would imply certs in place in the pbxes or phones behind them. That seems inconsistent with the assumptions of this work - that the pbx probably doesn't even have a domain name. Thanks, Paul > /Martien > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, May 07, 2010 8:29 PM > To: Hans Erik van Elburg > Cc: Bernard Aboba; martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Not the same thread (was Re: #36: Reg-event packageand individual extension state(section 7.2.2)) > > > > Hans Erik van Elburg wrote: >> On Thu, May 6, 2010 at 1:03 AM, Paul Kyzivat wrote: >>> Hans Erik van Elburg wrote: >>>> On Tue, May 4, 2010 at 5:03 PM, Hadriel Kaplan >>>> >>>> wrote: >>>> >>>>>> - An PBX registers with the SSP, to be able to send and receive calls. >>>>>> No >>>>>> astonishment >>>>> Right, but it's Registering for an AoR *belonging to the SSP*. >>>>> I.e., "sip:+12345@ssp.com". >>>>> >>>> [HE] Think it is more correct to say that it is registering >>>> reachability information for a bulk contact, which is then bound by >>>> the SSP to a bunch of implicitly registered AOR's. These AOR's dop >>>> not have to belong to the SSP, but they can. The SSP's proxy is >>>> responsible for handling them and forwarding them applying rules >>>> that apply to bulk contacts. >>> We've been through this before :-( >>> >> People still seem to misunderstand the implications though. Looking at >> the conclusions that people draw from this. >> >>> If the domain of the request, when it arrives at the SSP, is not a >>> domain it is responsible for, then it is bound to deliver it using 3261/3263 rules. >>> SSP.com has no business making side agreements on where to route >>> requests for other domains. >>> >> Correct. The key phrasing is here "responsible for". If the SSP has >> an agreement with the owner of the domain "company.com" that it will >> handle incoming traffic for that company, then the SSP's proxy is >> configured to be "responsible" for that domain. And it would also need >> to make this known into DNS so that traffic for that domain will be >> delivered to the SSP. > > I think this is not good enough. > If I come to the SSP and sign it up to forward incoming traffic for whitehouse.gov to me, how is it supposed to determine if I am the rightful owner of that domain? And if I am, now does it determine if I continue to be? > > You might argue: what's the harm? If I'm not the owner of whitehouse.gov then I won't be able to update DNS to direct whitehouse.gov traffic to the SSP. But there is still harm, because even without that I can then snag any traffic for whitehouse.gov that is originated by another of the SSP's customers. > > Its a different situation if the SSP acquires a domain name of my choice on my behalf. Then it clearly is responsible for the domain. > > The fuzzy area is where I acquire rights to the domain name, and update DNS to direct sip traffic to the SSP. In that case, what you suggest should work, if there was a way to ensure that I own the rights to that domain, and thus have the right to delegate responsibility for it to the SSP. In principle that should be ok, but I don't know how the SSP learns this and also learns if/when the ownership changes. > > Thanks, > Paul > >>> Otherwise, I'm going to sign up my pbx with your SSP and ask to have >>> sip:barack_obama@whitehouse.gov be one of my implicitly registered AORs. >>> >> You can ask watever you want, but your SSP is not going to configure >> that for you unless you own the domain whitehgouse.gov and are the >> person that is allowed to make such requests under the agreement >> between the SSP and company.com. >> >>> This kind of routing *must* be restricted to domains the SSP is >>> responsible for. >>> >> Yes, I agree. But if it is responsible for a domain it does not mean >> that it owns the domain. > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From pkyzivat@cisco.com Mon May 10 08:08: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 5B3273A69CF for ; Mon, 10 May 2010 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.146 X-Spam-Level: X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 p5su14MArChD for ; Mon, 10 May 2010 08:08:23 -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 57DF73A691D for ; Mon, 10 May 2010 08:08:23 -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: AvsEAPK950urRN+J/2dsb2JhbACeH3GjWpkohRQE X-IronPort-AV: E=Sophos;i="4.52,362,1270425600"; d="scan'208";a="324648732" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 10 May 2010 15:08:12 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4AF8BoV017058; Mon, 10 May 2010 15:08:12 GMT Message-ID: <4BE82159.5020303@cisco.com> Date: Mon, 10 May 2010 11:08:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Martien Huysmans References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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, 10 May 2010 15:08:24 -0000 Maybe I'm missing something, because I don't understand the issue. AFAIK the use of "on behalf of X" in this requirement is just another way of saying "the To-URI of the REGISTER will be X". IOW, its equivalent to the following rewording: REQ4 - The mechanism MUST NOT prevent UAs attached to a SIP-PBX registering with the SIP-PBX using a To-URI 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. Section 10.2 of 3261 uses "on behalf of" in this same way. Thanks, Paul Martien Huysmans wrote: > John > > The "problem" is trying to understand why the text includes "on behalf of". > This document is input for the other martini document and it should make > sense to me or anybody else. > > I looked at RFC3261 on the usage of "on behalf of". > Section 10.2: > Registration on behalf of a particular address-of-record can be performed > by a suitably authorized third party. > I have the impression that your text is not talking about "3rd party registration". > But I may be wrong. > > You asked for a proposition. Here is an attempt. > > 1) remove the sentence in section 1. > Rationale: The information feels superluous compared to the > sentences before this sentence. > > 2) Update REQ4 to: > The mechanism MUST allow an UA to register with a SIP-PBX > without needing to involve the SSP in the registration process, > in order to receive requests targeted at assigned telephone numbers. > > Rationale: > - it uses MUST instead of "MUST NOT". > - 3rd party registration is a "basic mechanims" according RFC3261. So > no need to repeat that. > > /Martien > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, May 07, 2010 3:02 PM > To: Martien Huysmans; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". > > Each UA that has credentials for a particular AOR can register a contact URI on behalf of that AOR. What is the problem with that? What preposition would you prefer? > > John > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans >> Sent: 07 May 2010 07:54 >> To: martini@ietf.org >> Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf >> of AOR". >> >> Question on draft-ietf-martini-reqs-06.txt. >> >> The text talks twice about "UAs register with the SIP-PBX on behalf of >> the AORs concerned". >> What does this mean? >> How does an UA register with an SIP-PBX "on behalf of" an AOR? >> >> /Martien >> >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From spencer@wonderhamster.org Mon May 10 15:18: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 B86AE3A6A77 for ; Mon, 10 May 2010 15:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227, 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 DwEvTqf03SdT for ; Mon, 10 May 2010 15:18:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id F21B63A6A6F for ; Mon, 10 May 2010 15:18:12 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MfVoJ-1Nx7Vv031H-00OI9N; Mon, 10 May 2010 18:17:59 -0400 Message-ID: From: "Spencer Dawkins" To: "Elwell, John" , "Martien Huysmans" , References: Date: Mon, 10 May 2010 17:17:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19FfKuhy3dTHC7iojGnpnCxgQP1yjdWdayN+Dg aaIClqNy3vBZTQfkIzPNaL06+S0/Ef0kwOvsHCOYl1qkGdnfOX Z6LxanOueZUQ1u1r2CtV52UWUPBn/TIgKc7D9equWI= Subject: Re: [martini] draft-ietf-martini-reqs-06: textual comments 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, 10 May 2010 22:18:24 -0000 Speaking as co-chair, > Martien, > > The WGLC finished several weeks ago, but nevertheless your comments are > appreciated. My expression of disappointment was not aimed at you > personally, but the continued delays in getting this document, which is > only Informational, out of the door. I have taken on board your comments > in my working copy (with some slight changes - see below), but I will hold > back for a day or so before publishing 07 to see if further comments > arrive. Bernard and I both agreed that we didn't need a second WGLC, because - the changes we've made have been small, - they've been discuss on the mailing list, with enough time for people to look at them, and - (most of all) when we request publication, there's ANOTHER two-week IETF Last Call, an opportunity for anyone, inside or outside the working group, to provide comments, that the working group will then consider. We do appreciate the comments that we've gotten so fair, including the comments received recently, and it's ok with us for John to hang onto the draft for another day or two, but we're really going to send it to Gonzalo this week, unless the sky falls, and probably earlier rather than later. Thanks, Spencer, as co-chair From john.elwell@siemens-enterprise.com Tue May 11 00:05: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 1D3C63A6AFA for ; Tue, 11 May 2010 00:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_50=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 0jD+++ZgU-pH for ; Tue, 11 May 2010 00:05:34 -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 AE1E03A69A6 for ; Tue, 11 May 2010 00:05:33 -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-126189; Tue, 11 May 2010 09:05:22 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 1AC421EB82AB; Tue, 11 May 2010 09:05:22 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 11 May 2010 09:05:22 +0200 From: "Elwell, John" To: Spencer Dawkins , Martien Huysmans , "martini@ietf.org" Date: Tue, 11 May 2010 09:05:19 +0200 Thread-Topic: [martini] draft-ietf-martini-reqs-06: textual comments Thread-Index: AcrwjqdmeP36tPvqQQq6kdV1pGjVpgAQRzVg 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] draft-ietf-martini-reqs-06: textual comments 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, 11 May 2010 07:05:38 -0000 Spencer, Thanks for your support. I will give it 24 hours, and post a new version to= morrow morning my time. John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 10 May 2010 23:18 > To: Elwell, John; Martien Huysmans; martini@ietf.org > Subject: Re: [martini] draft-ietf-martini-reqs-06: textual comments >=20 > Speaking as co-chair, >=20 >=20 > > Martien, > > > > The WGLC finished several weeks ago, but nevertheless your=20 > comments are=20 > > appreciated. My expression of disappointment was not aimed at you=20 > > personally, but the continued delays in getting this=20 > document, which is=20 > > only Informational, out of the door. I have taken on board=20 > your comments=20 > > in my working copy (with some slight changes - see below),=20 > but I will hold=20 > > back for a day or so before publishing 07 to see if further=20 > comments=20 > > arrive. >=20 > Bernard and I both agreed that we didn't need a second WGLC, because >=20 > - the changes we've made have been small, >=20 > - they've been discuss on the mailing list, with enough time=20 > for people to=20 > look at them, and >=20 > - (most of all) when we request publication, there's ANOTHER=20 > two-week IETF=20 > Last Call, an opportunity for anyone, inside or outside the=20 > working group,=20 > to provide comments, that the working group will then consider. >=20 > We do appreciate the comments that we've gotten so fair,=20 > including the=20 > comments received recently, and it's ok with us for John to=20 > hang onto the=20 > draft for another day or two, but we're really going to send=20 > it to Gonzalo=20 > this week, unless the sky falls, and probably earlier rather=20 > than later. >=20 > Thanks, >=20 > Spencer, as co-chair=20 >=20 > = From martien.huysmans@ericsson.com Tue May 11 00:37:53 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 48BBD3A6907 for ; Tue, 11 May 2010 00:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_50=0.001, GB_I_INVITATION=-2, 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 H7VCTCNPdso6 for ; Tue, 11 May 2010 00:37:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 100783A689A for ; Tue, 11 May 2010 00:37:51 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-8b-4be90943f34f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EB.DB.21861.34909EB4; Tue, 11 May 2010 09:37:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 11 May 2010 09:37:39 +0200 From: Martien Huysmans To: "Elwell, John" , "martini@ietf.org" Date: Tue, 11 May 2010 09:37:36 +0200 Thread-Topic: draft-ietf-martini-reqs-06: textual comments Thread-Index: AcrtszYoAIBIFInCSg+Z+kBAkRnSyAAMIpJwAJSYuYAAA54KsAAlvCRw 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] draft-ietf-martini-reqs-06: textual comments 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, 11 May 2010 07:37:53 -0000 Ok with your proposal. Discussion closed. /Martien -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, May 10, 2010 3:43 PM To: Martien Huysmans; martini@ietf.org Subject: RE: draft-ietf-martini-reqs-06: textual comments Martien, The WGLC finished several weeks ago, but nevertheless your comments are app= reciated. My expression of disappointment was not aimed at you personally, = but the continued delays in getting this document, which is only Informatio= nal, out of the door. I have taken on board your comments in my working cop= y (with some slight changes - see below), but I will hold back for a day or= so before publishing 07 to see if further comments arrive.=20 > -----Original Message----- > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com] > Sent: 10 May 2010 14:17 > To: Elwell, John; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06: textual comments >=20 > John >=20 > I appologize for any inconvience. I am new to IETF and rather late=20 > into the MARTINI discussion. > I saw the WGLC, which I thought is an invitation for (last0 comments. >=20 > Other comments below.. >=20 > /Martien >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, May 07, 2010 3:04 PM > To: Martien Huysmans; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06: textual comments >=20 > I have started to make changes in my working copy, but it is most=20 > disappointing to receive comments right after I posted a new version=20 > on text that has been around for weeks. I will let the chairs advise=20 > me what to do. See also below: >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > > Sent: 07 May 2010 08:02 > > To: martini@ietf.org > > Subject: [martini] draft-ietf-martini-reqs-06: textual comments > >=20 > > Some minor textual comments > > =20 > > - the document uses the terms client, subscriber and user. > > where I have the feeling that they may mean the same > [JRE] The term "subscriber" is probably wrong and should probably be=20 > changed to user, but it is used in various contexts such as "normal=20 > subscriber UA" where it should perhaps just be deleted. Please provide=20 > text proposals for all instances you want changed. As for "client",=20 > that should be "user". > [MAHU] Subscriber is used at number of places. Here is overview and=20 > proposed changes: > Section 3: "typical subscriber UA" -> "normal user" > Section 3.1.1: "normal subscriber Uas" -> "normal user" > "subscriber Uas" -> "user" > Section 5, DES1: "ordinary subscribers" -> "normal users" [JRE] I prefer to keep "UA" in place, so I have changed to "typical user's = UA" and "normal UAs". >=20 > > =20 > > - ch 3 talks about "normal" first-party SIP REGISTER. > > I suggest to remove "first-party". > [JRE] "first party" was added to distinguish from "third party" - what=20 > is the problem with that? > [MAHU] I understand the distinction. But the current text/document=20 > doesn't talk about "third party". > The current text is: > In all respects, it appears on the wire as a "normal"=20 > first-party SIP REGISTER request,=20 > as if from a typical subscriber UA. > This sentence has some redundancy: "normal", "first-part" and "as if=20 > from a typical subscriber UA" > all seem to convey the same message. >=20 > This is a minor thing. If you like the proposal, ok. If not, also ok. [JRE] I have done as you suggest. John >=20 > > =20 > > - chapter 6 talks about "numbers", where it should say "telephone=20 > > numbers" > [JRE] Thanks. >=20 > John >=20 > > =20 > > /Martien > > = From martien.huysmans@ericsson.com Tue May 11 00:45: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 1552A3A6B1B for ; Tue, 11 May 2010 00:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=-0.909, 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 RHQ39TNcVvtd for ; Tue, 11 May 2010 00:45:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C6F1C3A6B15 for ; Tue, 11 May 2010 00:45:09 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-ca-4be90af989f4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6E.0D.21861.9FA09EB4; Tue, 11 May 2010 09:44:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 11 May 2010 09:44:57 +0200 From: Martien Huysmans To: "Elwell, John" , "martini@ietf.org" Date: Tue, 11 May 2010 09:44:56 +0200 Thread-Topic: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Thread-Index: AcrtshwWqHqa9So2TYGa8e5DGI//gQAMtdgAAJJtG7AABly/EAAlYPug 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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, 11 May 2010 07:45:15 -0000 John How about: The mechanism MUST NOT prevent UAs attached to a SIP-PBX registering AORs with the SIP-PBX 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. =20 /Martien=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, May 10, 2010 3:58 PM To: Martien Huysmans; martini@ietf.org Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". =20 > -----Original Message----- > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com] > Sent: 10 May 2010 12:44 > To: Elwell, John; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of=20 > AOR". >=20 > John >=20 > The "problem" is trying to understand why the text includes "on behalf=20 > of". > This document is input for the other martini document and it should=20 > make sense to me or anybody else. >=20 > I looked at RFC3261 on the usage of "on behalf of". > Section 10.2:=20 > Registration on behalf of a particular address-of-record can be=20 > performed > by a suitably authorized third party.=20 > I have the impression that your text is not talking about "3rd party=20 > registration". > But I may be wrong. >=20 > You asked for a proposition. Here is an attempt. >=20 > 1) remove the sentence in section 1. > Rationale: The information feels superluous compared to the=20 > sentences before this sentence. [JRE] I will do this. >=20 > 2) Update REQ4 to: > The mechanism MUST allow an UA to register with a SIP-PBX=20 > without needing to involve the SSP in the registration process, > in order to receive requests targeted at assigned telephone=20 > numbers. [JRE] I liked the existing "MUST NOT prevent" formulation, because clearly,= even without MARTINI, UAs behind a PBX can register with the PBX, so we ju= st want to make sure the MARTINI mechanism does not prevent this. I think w= e can change "on behalf of" to "for", if that helps. Again, changes are in my working copy - I will wait a day or two before pub= lishing reqs-07. John >=20 > Rationale: > - it uses MUST instead of "MUST NOT". > - 3rd party registration is a "basic mechanims" according RFC3261.=20 > So > no need to repeat that. >=20 > /Martien >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, May 07, 2010 3:02 PM > To: Martien Huysmans; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of=20 > AOR". >=20 > Each UA that has credentials for a particular AOR can register a=20 > contact URI on behalf of that AOR. What is the problem with that? What=20 > preposition would you prefer? >=20 > John >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > > Sent: 07 May 2010 07:54 > > To: martini@ietf.org > > Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4:=20 > "on behalf > > of AOR". > >=20 > > Question on draft-ietf-martini-reqs-06.txt.=20 > > =20 > > The text talks twice about "UAs register with the SIP-PBX > on behalf of > > the AORs concerned". > > What does this mean? > > How does an UA register with an SIP-PBX "on behalf of" an AOR? > > =20 > > /Martien > > =20 > > = From martien.huysmans@ericsson.com Tue May 11 01:01:13 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 E24D03A6B4F for ; Tue, 11 May 2010 01:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=-0.833, 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 KgV7OZ8wRVkt for ; Tue, 11 May 2010 01:01:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C0CE03A6B27 for ; Tue, 11 May 2010 00:57:04 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-d2-4be90dc40482 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D8.0F.21861.4CD09EB4; Tue, 11 May 2010 09:56:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 11 May 2010 09:56:52 +0200 From: Martien Huysmans To: Paul Kyzivat Date: Tue, 11 May 2010 09:56:50 +0200 Thread-Topic: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Thread-Index: AcrwUqBWN4mr/zZcT1W7iQHMgmyPHQAi8GuA Message-ID: References: <4BE82159.5020303@cisco.com> In-Reply-To: <4BE82159.5020303@cisco.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-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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, 11 May 2010 08:01:13 -0000 Paul RFC3261, section 10.2 mentions the on-behalf-of registration or third-party= registration. I think that in case, the From-URI is different, not the To-URI. RFC3261, section 10.2 states: From: The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a third- party registration. You propose to change the wording of REQ 4. For me the discussion started with trying to understand WHY the "on behalf = of"=20 was included in the first place. I think you text is probably equivelant to what I an John discussed in anot= her email. But following the style of the requirement document, I rather use AOR, then= talk about a specific parameter in the REGISTER. /Martien -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, May 10, 2010 5:08 PM To: Martien Huysmans Cc: Elwell, John; martini@ietf.org Subject: Re: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of= AOR". Maybe I'm missing something, because I don't understand the issue. AFAIK the use of "on behalf of X" in this requirement is just another way o= f saying "the To-URI of the REGISTER will be X". IOW, its equivalent to the= following rewording: REQ4 - The mechanism MUST NOT prevent UAs attached to a SIP-PBX registering with the SIP-PBX using a To-URI 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. Section 10.2 of 3261 uses "on behalf of" in this same way. Thanks, Paul Martien Huysmans wrote: > John >=20 > The "problem" is trying to understand why the text includes "on behalf of= ". > This document is input for the other martini document and it should=20 > make sense to me or anybody else. >=20 > I looked at RFC3261 on the usage of "on behalf of". > Section 10.2:=20 > Registration on behalf of a particular address-of-record can be perfor= med=20 > by a suitably authorized third party.=20 > I have the impression that your text is not talking about "3rd party regi= stration". > But I may be wrong. >=20 > You asked for a proposition. Here is an attempt. >=20 > 1) remove the sentence in section 1. > Rationale: The information feels superluous compared to the=20 > sentences before this sentence. >=20 > 2) Update REQ4 to: > The mechanism MUST allow an UA to register with a SIP-PBX=20 > without needing to involve the SSP in the registration process, > in order to receive requests targeted at assigned telephone numbers. >=20 > Rationale: > - it uses MUST instead of "MUST NOT". > - 3rd party registration is a "basic mechanims" according RFC3261. So > no need to repeat that. >=20 > /Martien >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, May 07, 2010 3:02 PM > To: Martien Huysmans; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". >=20 > Each UA that has credentials for a particular AOR can register a contact = URI on behalf of that AOR. What is the problem with that? What preposition = would you prefer? >=20 > John >=20 >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans >> Sent: 07 May 2010 07:54 >> To: martini@ietf.org >> Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf=20 >> of AOR". >> >> Question on draft-ietf-martini-reqs-06.txt.=20 >> =20 >> The text talks twice about "UAs register with the SIP-PBX on behalf=20 >> of the AORs concerned". >> What does this mean? >> How does an UA register with an SIP-PBX "on behalf of" an AOR? >> =20 >> /Martien >> =20 >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From john.elwell@siemens-enterprise.com Tue May 11 01:13: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 D3AC43A6B18 for ; Tue, 11 May 2010 01:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_05=-1.11, 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 yW0vHlpyGNuC for ; Tue, 11 May 2010 01:13:23 -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 3B84C3A6B1F for ; Tue, 11 May 2010 01:13:15 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-127145; Tue, 11 May 2010 10:13:04 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 819C71EB82AE; Tue, 11 May 2010 10:13:04 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 11 May 2010 10:13:04 +0200 From: "Elwell, John" To: Martien Huysmans , "martini@ietf.org" Date: Tue, 11 May 2010 10:13:03 +0200 Thread-Topic: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Thread-Index: AcrtshwWqHqa9So2TYGa8e5DGI//gQAMtdgAAJJtG7AABly/EAAlYPugAADZlfA= 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] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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, 11 May 2010 08:13:23 -0000 =20 > -----Original Message----- > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com]=20 > Sent: 11 May 2010 08:45 > To: Elwell, John; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on=20 > behalf of AOR". >=20 > John >=20 > How about: >=20 > The mechanism MUST NOT prevent UAs attached to a SIP-PBX > registering AORs with the SIP-PBX 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. =20 [JRE] The point is, I don't think an entity registers an AOR, I think an en= tity registers a contact for an AOR. So I still prefer the text in my worki= ng copy: "The mechanism MUST NOT prevent UAs attached to a SIP-PBX registering with = the SIP-PBX for AORs based on assigned telephone numbers, in order to...". (In fact I really preferred my original "on behalf of" if changing this to = "for" did not help). Regards, John >=20 > /Martien=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Monday, May 10, 2010 3:58 PM > To: Martien Huysmans; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on=20 > behalf of AOR". >=20 > =20 >=20 > > -----Original Message----- > > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com] > > Sent: 10 May 2010 12:44 > > To: Elwell, John; martini@ietf.org > > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of=20 > > AOR". > >=20 > > John > >=20 > > The "problem" is trying to understand why the text includes=20 > "on behalf=20 > > of". > > This document is input for the other martini document and it should=20 > > make sense to me or anybody else. > >=20 > > I looked at RFC3261 on the usage of "on behalf of". > > Section 10.2:=20 > > Registration on behalf of a particular address-of-record can be=20 > > performed > > by a suitably authorized third party.=20 > > I have the impression that your text is not talking about=20 > "3rd party=20 > > registration". > > But I may be wrong. > >=20 > > You asked for a proposition. Here is an attempt. > >=20 > > 1) remove the sentence in section 1. > > Rationale: The information feels superluous compared to the=20 > > sentences before this sentence. > [JRE] I will do this. >=20 > >=20 > > 2) Update REQ4 to: > > The mechanism MUST allow an UA to register with a SIP-PBX=20 > > without needing to involve the SSP in the registration process, > > in order to receive requests targeted at assigned telephone=20 > > numbers. > [JRE] I liked the existing "MUST NOT prevent" formulation,=20 > because clearly, even without MARTINI, UAs behind a PBX can=20 > register with the PBX, so we just want to make sure the=20 > MARTINI mechanism does not prevent this. I think we can=20 > change "on behalf of" to "for", if that helps. >=20 > Again, changes are in my working copy - I will wait a day or=20 > two before publishing reqs-07. >=20 > John >=20 >=20 >=20 >=20 > >=20 > > Rationale: > > - it uses MUST instead of "MUST NOT". > > - 3rd party registration is a "basic mechanims"=20 > according RFC3261.=20 > > So > > no need to repeat that. > >=20 > > /Martien > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, May 07, 2010 3:02 PM > > To: Martien Huysmans; martini@ietf.org > > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of=20 > > AOR". > >=20 > > Each UA that has credentials for a particular AOR can register a=20 > > contact URI on behalf of that AOR. What is the problem with=20 > that? What=20 > > preposition would you prefer? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > > > Sent: 07 May 2010 07:54 > > > To: martini@ietf.org > > > Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4:=20 > > "on behalf > > > of AOR". > > >=20 > > > Question on draft-ietf-martini-reqs-06.txt.=20 > > > =20 > > > The text talks twice about "UAs register with the SIP-PBX > > on behalf of > > > the AORs concerned". > > > What does this mean? > > > How does an UA register with an SIP-PBX "on behalf of" an AOR? > > > =20 > > > /Martien > > > =20 > > > = From martien.huysmans@ericsson.com Tue May 11 05:53: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 204AF28C17E for ; Tue, 11 May 2010 05:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.141 X-Spam-Level: X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=-0.769, 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 ptblk6ca4FwB for ; Tue, 11 May 2010 05:53:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 831D13A68FC for ; Tue, 11 May 2010 05:50:51 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-34-4be9529fe3ac Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 03.CD.21861.F9259EB4; Tue, 11 May 2010 14:50:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 11 May 2010 14:50:39 +0200 From: Martien Huysmans To: "Elwell, John" , "martini@ietf.org" Date: Tue, 11 May 2010 14:50:37 +0200 Thread-Topic: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". Thread-Index: AcrtshwWqHqa9So2TYGa8e5DGI//gQAMtdgAAJJtG7AABly/EAAlYPugAADZlfAACcPeAA== 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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, 11 May 2010 12:53:05 -0000 John=20 I agree with your "an entity registers a contact for an AOR". I still do not like the "on behalf of", so your proposal with "for" is ok f= or me. /Martien -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Tuesday, May 11, 2010 10:13 AM To: Martien Huysmans; martini@ietf.org Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". =20 > -----Original Message----- > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com] > Sent: 11 May 2010 08:45 > To: Elwell, John; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of=20 > AOR". >=20 > John >=20 > How about: >=20 > The mechanism MUST NOT prevent UAs attached to a SIP-PBX > registering AORs with the SIP-PBX 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. =20 [JRE] The point is, I don't think an entity registers an AOR, I think an en= tity registers a contact for an AOR. So I still prefer the text in my worki= ng copy: "The mechanism MUST NOT prevent UAs attached to a SIP-PBX registering with = the SIP-PBX for AORs based on assigned telephone numbers, in order to...". (In fact I really preferred my original "on behalf of" if changing this to = "for" did not help). Regards, John >=20 > /Martien >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, May 10, 2010 3:58 PM > To: Martien Huysmans; martini@ietf.org > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of=20 > AOR". >=20 > =20 >=20 > > -----Original Message----- > > From: Martien Huysmans [mailto:martien.huysmans@ericsson.com] > > Sent: 10 May 2010 12:44 > > To: Elwell, John; martini@ietf.org > > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of=20 > > AOR". > >=20 > > John > >=20 > > The "problem" is trying to understand why the text includes > "on behalf > > of". > > This document is input for the other martini document and it should=20 > > make sense to me or anybody else. > >=20 > > I looked at RFC3261 on the usage of "on behalf of". > > Section 10.2:=20 > > Registration on behalf of a particular address-of-record can be=20 > > performed > > by a suitably authorized third party.=20 > > I have the impression that your text is not talking about > "3rd party > > registration". > > But I may be wrong. > >=20 > > You asked for a proposition. Here is an attempt. > >=20 > > 1) remove the sentence in section 1. > > Rationale: The information feels superluous compared to the=20 > > sentences before this sentence. > [JRE] I will do this. >=20 > >=20 > > 2) Update REQ4 to: > > The mechanism MUST allow an UA to register with a SIP-PBX=20 > > without needing to involve the SSP in the registration process, > > in order to receive requests targeted at assigned telephone=20 > > numbers. > [JRE] I liked the existing "MUST NOT prevent" formulation, because=20 > clearly, even without MARTINI, UAs behind a PBX can register with the=20 > PBX, so we just want to make sure the MARTINI mechanism does not=20 > prevent this. I think we can change "on behalf of" to "for", if that=20 > helps. >=20 > Again, changes are in my working copy - I will wait a day or two=20 > before publishing reqs-07. >=20 > John >=20 >=20 >=20 >=20 > >=20 > > Rationale: > > - it uses MUST instead of "MUST NOT". > > - 3rd party registration is a "basic mechanims"=20 > according RFC3261.=20 > > So > > no need to repeat that. > >=20 > > /Martien > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, May 07, 2010 3:02 PM > > To: Martien Huysmans; martini@ietf.org > > Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of=20 > > AOR". > >=20 > > Each UA that has credentials for a particular AOR can register a=20 > > contact URI on behalf of that AOR. What is the problem with > that? What > > preposition would you prefer? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans > > > Sent: 07 May 2010 07:54 > > > To: martini@ietf.org > > > Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4:=20 > > "on behalf > > > of AOR". > > >=20 > > > Question on draft-ietf-martini-reqs-06.txt.=20 > > > =20 > > > The text talks twice about "UAs register with the SIP-PBX > > on behalf of > > > the AORs concerned". > > > What does this mean? > > > How does an UA register with an SIP-PBX "on behalf of" an AOR? > > > =20 > > > /Martien > > > =20 > > > = From pkyzivat@cisco.com Tue May 11 07:17:04 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 D96DB3A6D11 for ; Tue, 11 May 2010 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, 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 oSDnnY35fb+W for ; Tue, 11 May 2010 07:17:01 -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 E6E623A68A0 for ; Tue, 11 May 2010 07:14:50 -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: AvsEAMsC6UtAZnwN/2dsb2JhbACeK3GhUZleglqCNgQ X-IronPort-AV: E=Sophos;i="4.53,207,1272844800"; d="scan'208";a="110038542" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 May 2010 14:14:39 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4BEEdCm008244; Tue, 11 May 2010 14:14:39 GMT Message-ID: <4BE96650.9010001@cisco.com> Date: Tue, 11 May 2010 10:14:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Martien Huysmans References: <4BE82159.5020303@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] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". 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, 11 May 2010 14:17:04 -0000 Martin, I'm happy with what you and John worked out. But just in the interest of closing this discussion on behalf of "behalf" - 3261 section 10.2 says: REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding between an address-of-record and one or more contact addresses. Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of- record. The use of "on behalf" in that paragraph may be unfortunate, but it seems clear to be that the "on behalf" is referring to the AOR that is the target of registration, and not to the identity of the party that is doing the registration. Consider the following variations that might have been said: 1) Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party. 2) Registration (for/with/to) a particular address-of-record can be performed on behalf of a suitably authorized third party. 3) Registration on behalf of a particular address-of-record can be performed by a user agent representing that address-of-record. Of those, (1) is the as-written case, talking about third party registration. (2) shifts the use of "on behalf of" to refer to the third party. I expect this is they way you have been interpreting it. Its also, IMO, a more natural way of using "on behalf of". (3) is applying the original phrasing to first party registration. It still "works". I had to go back and study this in 3261 to be certain of this. But I presume it was this usage that John was copying in REQ 4. Because of the precedent I did not have an issue with it. But phrasing that doesn't use "on behalf of" will probably help prevent confusion. I've personally always had difficulty deciding how to phrase this. And I've indicated that in (2) by showing the alternatives to/with/for. None of them seem ideal, though I usually use "to". Thanks, Paul Martien Huysmans wrote: > Paul > > RFC3261, section 10.2 mentions the on-behalf-of registration or third-party registration. > I think that in case, the From-URI is different, not the To-URI. > > RFC3261, section 10.2 states: > > From: The From header field contains the address-of-record of the > person responsible for the registration. The value is the > same as the To header field unless the request is a third- > party registration. > > You propose to change the wording of REQ 4. > For me the discussion started with trying to understand WHY the "on behalf of" > was included in the first place. > > I think you text is probably equivelant to what I an John discussed in another email. > But following the style of the requirement document, I rather use AOR, then talk about > a specific parameter in the REGISTER. > > /Martien > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, May 10, 2010 5:08 PM > To: Martien Huysmans > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". > > Maybe I'm missing something, because I don't understand the issue. > AFAIK the use of "on behalf of X" in this requirement is just another way of saying "the To-URI of the REGISTER will be X". IOW, its equivalent to the following rewording: > > REQ4 - The mechanism MUST NOT prevent UAs attached to a SIP-PBX > registering with the SIP-PBX using a To-URI 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. > > Section 10.2 of 3261 uses "on behalf of" in this same way. > > Thanks, > Paul > > > Martien Huysmans wrote: >> John >> >> The "problem" is trying to understand why the text includes "on behalf of". >> This document is input for the other martini document and it should >> make sense to me or anybody else. >> >> I looked at RFC3261 on the usage of "on behalf of". >> Section 10.2: >> Registration on behalf of a particular address-of-record can be performed >> by a suitably authorized third party. >> I have the impression that your text is not talking about "3rd party registration". >> But I may be wrong. >> >> You asked for a proposition. Here is an attempt. >> >> 1) remove the sentence in section 1. >> Rationale: The information feels superluous compared to the >> sentences before this sentence. >> >> 2) Update REQ4 to: >> The mechanism MUST allow an UA to register with a SIP-PBX >> without needing to involve the SSP in the registration process, >> in order to receive requests targeted at assigned telephone numbers. >> >> Rationale: >> - it uses MUST instead of "MUST NOT". >> - 3rd party registration is a "basic mechanims" according RFC3261. So >> no need to repeat that. >> >> /Martien >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Friday, May 07, 2010 3:02 PM >> To: Martien Huysmans; martini@ietf.org >> Subject: RE: draft-ietf-martini-reqs-06.txt: req 4: "on behalf of AOR". >> >> Each UA that has credentials for a particular AOR can register a contact URI on behalf of that AOR. What is the problem with that? What preposition would you prefer? >> >> John >> >>> -----Original Message----- >>> From: martini-bounces@ietf.org >>> [mailto:martini-bounces@ietf.org] On Behalf Of Martien Huysmans >>> Sent: 07 May 2010 07:54 >>> To: martini@ietf.org >>> Subject: [martini] draft-ietf-martini-reqs-06.txt: req 4: "on behalf >>> of AOR". >>> >>> Question on draft-ietf-martini-reqs-06.txt. >>> >>> The text talks twice about "UAs register with the SIP-PBX on behalf >>> of the AORs concerned". >>> What does this mean? >>> How does an UA register with an SIP-PBX "on behalf of" an AOR? >>> >>> /Martien >>> >>> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > From bernard_aboba@hotmail.com Tue May 11 15:11:06 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 E174E3A69C1 for ; Tue, 11 May 2010 15:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.63 X-Spam-Level: X-Spam-Status: No, score=0.63 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] 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 PlzWNpnhXFbK for ; Tue, 11 May 2010 15:11:03 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id 73C0E3A6989 for ; Tue, 11 May 2010 15:10:50 -0700 (PDT) Received: from BLU137-W7 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 15:10:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3d89070f-bb0a-45fb-8d9d-29868602efd9_" X-Originating-IP: [131.107.0.105] From: Bernard Aboba To: Date: Tue, 11 May 2010 15:10:39 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 May 2010 22:10:40.0215 (UTC) FILETIME=[CA9B7E70:01CAF156] Subject: [martini] Draft minutes from MARTINI Virtual Interim IV 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, 11 May 2010 22:11:06 -0000 --_3d89070f-bb0a-45fb-8d9d-29868602efd9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minutes of Martini Virtual Interim IV April 29=2C 2010 Minute takers: David Hancock=2C Dean Willis Agenda bash: No changes to Agenda 1. Requirements discussion led by John Elwell Issue #39=2C explanatory text in Section 1. John Elwell - Do we keep issue #39=2C or does it go in a solutions draft (s= uch as Olive)? Spencer prefers it stay in the requirements draft=2C since we're producing = only one of these and it'll be easier to find. Discussion moved on while Hadriel reviewed text. On review=2C Hadriel beli= eves the first paragraph is just wrong (Background on the Issues)=2C and ne= eds to be tailored to unique contacts=2C not unique AORs. Hadriel proposes = removing this text.=20 John Elwell: don't mind deleting it=2C but was asked to add it by Jon Peter= son at IETF 77 mtg. Propose taking this to the list - and give reasons and = get consensus to remove it.=20 Spencer Dawkins: if list decides that it should be somewhere - would that p= lace be the olive draft (or whatever document addresses solution for the 15= /16 requirements). Hadriel Kaplan: the Olive draft does cover this already=2C so that's covere= d=20 Issue #15=2C #16 non-E.164 and extensibility to any AOR 5 alternative paths have been proposed. John proposes #1 or #3 (nothing or = add as desirable). Adam suggests 6th option to be phase 1 deliverable=2C with a plan to do a s= econd phase 2 requirements document for phase 2 deliverables. Noted that several people from list supported adopting requirements as they= stand. Discussion of 2 phase approach and meaning of requirements followed. Hadriel Kaplan: I thought these were desirable. At least 16 - the extensibi= lity one.=20 Dean Willis: we specifically excluded #15 for phase-1 - to limit to E.164 n= umbers.=20 Keith Drage: if we do this - how do we meet/handle these requirement in the= solutions draft?=20 Adam Roach: by demonstrating in another draft (e.g.=2C olive) how the exten= sion could be supported.=20 Spencer Dawkins: understand that everyone on group supports the requirement= for non-e.164 numbers.=20 John Elwell: yes=2C would like 15/16 to be supported eventually=2C just not= in phase-1.=20 Spencer Dawkins (as chair): would not want to ignore these. Should address = them as required or desirable. So=2C should the working group continue adva= ncing Olive?=20 Martin Dolly: there was a contingent of folks that saw the need to address = these now - as in phase-1.=20 Dean Willis: does that mean stop working on GIN until we figure out how it = can support 15/16.=20 Martin Dolly: a requirement is a requirement. There is never a question of = phasing requirements. If you choose to defer meeting a requirement=2C then = it is still a requirement=2C just at a later date.=20 Adam Roach: what I'm hearing is to reverse the MARTINI-II meeting agreement= to limit phase-1 to E.164 numbers.=20 Dean Willis: no=2C Martin is just saying these are requirements=2C we just = need to decide schedule.=20 Keith Drage: there is also a desire that these requirements can be supporte= d by MARTINI GIN extension=2C and not a whole new solution.=20 Bernard Aboba: The MARTINI charter specifically states that the solution m= ust support E.164 numbers=2C and may support others. So those insisting tha= t non-E.164 support is a requirement are effectively attempting to change t= he MARTINI WG charter after it was approved.=20 John Elwell: adding a requirement that solution should be extensible is wit= hin charter.=20 Dean Willis and Bernard Aboba: agree.=20 Dean Willis: charter says must support E.164=2C may support others.=20 John Elwell: am hearing that we add req's for 15 & 16=2C reworded to say so= ln "must be extensible". =20 Spencer Dawkins=2C Adam Roach: agree.=20 ** General Agreement - Add requirement(s) that the phase-1 solution must be= extensible to support 15 & 16. =20 ** General agreement -- Will take 15/16 & 39 to the list. 2. Adam - GIN slides Changes reviewed. Issue: Ticket 28 user=3Dphone Proposed at IETF 77 to say that if pbx needs user=3Dphone=2C it registers u= ser=3Dphone. Doug Sauder: The SSP is the one who knows whether this is a phone number or= not=2C so it should be the one to add it. If you do option-1=2C you will t= hen have trouble reconciling with Olive=3B for example=2C PBX specifies use= r=3Dphone in REGISTER request=2C and at the same time wants to support non-= E.164 numbers that wouldn't have user=3Dphone Martin Dolly: AT&T expects to see user=3Dphone on the INVITE and requires P= BXes to support it. Since PBXes do not currently register=2C it is less ce= rtain.=20 Hadriel Kaplan: noted that surrogate registration currently does NOT includ= e user=3Dphone. Adam Roach: I thought there were some implementations that required user=3D= phone. Hadriel Kaplan: yes and there are some implementations that require it for = E.164 numbers=2C and other implementations that ignore this parameter.=20 Martin Dolly: there is a difference between not dropping a call=2C versus r= equiring it.=20 Hadriel Kaplan: the problem the 1st option is that it is treating user=3Dph= one an opaque parameter in the contact. The problem is that it really isn't= opaque - it has meaning in the INVITE.=20 Someone: There is a 4th option=2C which is to let the SSP decide whether "u= ser=3Dphone" is required.=20 Hadriel Kaplan: Noted that there is a 5th option=2C where user=3Dphone is a= feature of the registration. If you register with user=3Dphone=2C you get = only phone numbers=3B without you get all URIs. Some devices fail with user= =3Dphone=2C some require it. Extended discussion on contact routing=2C GRUU=2C etc=2C followed. Question: Is there any text suggesting that user=3Dphone can be used in the= current draft? Proposed that we pull user=3Dphone out of the examples. Adam Roach: the fact is that this has caused so much confusion - the docume= nt should talk about it at least to say something. John Elwell: likes option-2 - let the SSP decide whether or not to put user= =3Dphone in request URI (based on what is stored in location db). The user= =3Dphone is really an extension of the user part=2C and since the user part= is the expansion of the template provided in the bulk REGISTER Contact URI= =2C the u=3Dp parm should be configured in the SSP as part of that expansion. I.E. Whether it is there o= r not is based on provisioning. It's possible for two diff users to have an= AOR - same E.164 - one with u=3Dp and one without. How does this compare to a normal registration? If there is no user=3Dphone= on registered Contact and one comes back in the INVITE=2C what happens. (i= t depends...) Debate continued between Hadriel=2C Olle=2C John=2C and Adam. Then broadene= d. Doug Sauder: propose adding an indicator/parameter somewhere in the REGISTE= R indicating that the PBX requires user=3Dphone for AORs containing E.164 n= umbers. Similar to option 1 =2C but PBX is making it explicit - I need a us= er=3Dphone for E.164 numbers.=20 Adam Roach/Hadriel Kaplan: this may be a good option. =20 Martin Dolly: want to emphasize that user=3Dphone is required.=20 Adam Roach: this means that if you're testing a PBX in your lab that claims= compliance with GIN (and we make proposed change)=2C you would expect to s= ee it indicate that it needs the user=3Dphone parameter.=20 Keith Drage: solution should state what is mandatory vs=2C optional for the= PBX and SSP to support. Multiple people agree.=20 ** Agreement -- Adam will propose text for this new user=3Dphone option.=20 Issue: Ticket #36 regevent handling Who serves the regevent subscription -- SSP or PBX? Question: Is the SSP knowledge ever useful information=2C or does it just s= how whether or not the PBX is online. Yes=3B there may be multiple registr= ations for a user at the SSP. Question: How does this apply to dialog event?=20 Keith Drage: is there a use-case we have in mind=2C where the SSP needs to = respond to reg-event when PBX is offline? And would it work any different t= han other packages such as dialog-event? Hadriel - the reg-event package ro= uting is differently than other packages. The reg-event SUBSCRIBE is routed= to the registrar of the AOR in the Request URI. Therefore=2C since the enterprise-= user AORs belong to the SSP=2C the reg-event SUBSCRIBE is routed to the SSP= . Having it go to the SSP makes sense -- say the target AOR can be register= ed simultaneously to the PBX and directly to the SSP.=20 Adam Roach: case where same AOR is registered to the SSP directly=2C and to= the PBX=2C is a corner case.=20 Adam Roach: To header in REGISTER represents the PBX. You can subscribe reg= -event to it to get its registration state. But if you subscribe to the act= ual enterprise user AOR=2C then you want the actual registration state on the P= BX of the enterprise user. What if my phone is registered to two PBXs for r= edundancy?=20 Adam Roach: this supports it - you get two separate answers.=20 Hadriel Kaplan: reg-event SUBSCRIBE request URI is owned by the SSP - there= fore the SSP should respond. It shouldn't goto the PBX. In fact there may b= e no registration at the PBX=3B e.g.=2C the PBX supports non-SIP endpoints.= =20 Adam Roach: But sending the SWUBSCRIBE to the SSP doesn't provide any valua= ble information=2C since the it only reflects whether the PBX is registered= or not=2C and 99.99% of the time it will be registered. =20 Spencer Dawkins: suggest taking this to the list. Agreed.=20 Issue: Other open tickets Final slide - need a volunteer for outbound analysis. Dean Willis suggests = Paul Kyzivat. =20 Spencer Dawkins & Bernard Aboba: will follow up with Paul and Cullen Jennin= gs. 3. Hadriel Kaplan: Olive presentation Spencer Dawkins: had recently asked list about whether the result of bulk = registration is the same as the result of multiple =20 individual regitrations. Is the right place inside Olive?=20 Keith Drage: this assumption is part of why gin is fundamentally broken= =3B we need something that works differently from conventional contact-rout= ing. Debate ensued=3B inconclusive. Keith Drage: we would have avoided the whole subscribe to reg-event if we h= ad followed the IMS implicit registration model.=20 Adam Roach=2C Dean Willis: no - the problem would still be there=2C basical= ly because RFC 3261 does not have a good model for transitive registration= =2C which is what both IMS and GIN bulk registration are. Dean Willis: this is still broken for reg-event.=20 Adam Roach: agree. Solving it for GIN will solve it for olive as well. In f= act Hadriel's solution is the GIN draft extended to non-164 numbers. =20 Keith Drage: not sure if you would ever explicitly register a local number.= In IMS it would only be implicitly registered. Register global explicitly= =2C and register local implicitly.=20 Hadriel Kaplan: but GIN is a compression/decompression rule for explicitly= registrations. So what would an explicit registration of a local number lo= ok like? =20 Keith Drage: where is the lack-of-uniqueness problem?=20 Adam Roach: we were trying to make user-names globally unique to avoid the = ambiguity that occurs when two PBXs have overlapping private numbers.=20 Hadriel Kaplan: solves this problem by adding context to make local numbers= unique. Problem is a PBX could have both a public and private numbers. The= re are two ways to handle this - either two separate logical trunks=2C or s= omething in the actual URI portion that makes local numbers unique.=20 4. WG Chairs: next steps Spencer Dawkins: enumerates agreements for moving (disposition of issues 15= =2C16=2C39=2C Paul Kyzivat and Cullen Jennings solicited for review of outb= ound=2C etc.) Keith Drage: is it possible for Hadriel to submit a draft-01 of Olive?=20 Hadriel Kaplan: yes.=20 Keith Drage: therefore we'll hold discussion until we see -01.=20 John Elwell: reqs draft - assuming there is no pushback on 15=2C16=2C39 fro= m list - are we going to progress the requirements draft?=20 Bernard/Spencer: yes. Once we hafve no issues on the requirements document= =2C we will progress it.=20 Meeting adjourned... = --_3d89070f-bb0a-45fb-8d9d-29868602efd9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minutes of Martini Virtual Interim IV
April 29=2C 2010

Minute tak= ers: David Hancock=2C Dean Willis

Agenda bash: =3B No changes to= Agenda

1. Requirements discussion led by John Elwell

Issue #= 39=2C explanatory text in Section 1.

John Elwell - Do we keep issue = #39=2C or does it go in a solutions draft (such as Olive)?

Spencer p= refers it stay in the requirements draft=2C since we're producing only one = of these and it'll be easier to find.

Discussion moved on while Hadr= iel reviewed text. On review=2C Hadriel =3B believes the first paragrap= h is just wrong (Background on the Issues)=2C and needs to be tailored to u= nique contacts=2C not unique AORs. Hadriel proposes removing this text.
John Elwell: don't mind deleting it=2C but was asked to add it by Jon = Peterson at IETF 77 mtg. Propose taking this to the list - and give reasons= and get consensus to remove it.

Spencer Dawkins: if list decides t= hat it should be somewhere - would that place be the olive draft (or whatev= er document addresses solution for the 15/16 requirements).

Hadriel = Kaplan: the Olive draft does cover this already=2C so that's covered
Issue #15=2C #16 non-E.164 and extensibility to any AOR

5 alternat= ive paths have been proposed. John proposes #1 or #3 (nothing or add as des= irable).

Adam suggests 6th option to be phase 1 deliverable=2C with = a plan to do a second phase 2 requirements document for phase 2 deliverable= s.

Noted that several people from list supported adopting requiremen= ts as they stand.

Discussion of 2 phase approach and meaning of requ= irements followed.

Hadriel Kaplan: I thought these were desirable. A= t least 16 - the extensibility one.

Dean Willis: we specifically ex= cluded #15 for phase-1 - to limit to E.164 numbers.

Keith Drage: if= we do this - how do we meet/handle these requirement in the solutions draf= t?

Adam Roach: by demonstrating in another draft (e.g.=2C olive) ho= w the extension could be supported.

Spencer Dawkins: understand tha= t everyone on group supports the requirement for non-e.164 numbers.
John Elwell: yes=2C would like 15/16 to be supported eventually=2C just no= t in phase-1.

Spencer Dawkins (as chair): would not want to ignore = these. Should address them as required or desirable. So=2C should the worki= ng group continue advancing Olive?

Martin Dolly: there was a contin= gent of folks that saw the need to address these now - as in phase-1.
<= br>Dean Willis: does that mean stop working on GIN until we figure out how = it can support 15/16.

Martin Dolly: a requirement is a requirement.= There is never a question of phasing requirements. If you choose to defer = meeting a requirement=2C then it is still a requirement=2C just at a later = date.

Adam Roach: what I'm hearing is to reverse the MARTINI-II mee= ting agreement to limit phase-1 to E.164 numbers.

Dean Willis: no= =2C Martin is just saying these are requirements=2C we just need to decide = schedule.

Keith Drage: there is also a desire that these requiremen= ts can be supported by MARTINI GIN extension=2C and not a whole new solutio= n.

Bernard Aboba: =3B The MARTINI charter specifically states t= hat the solution must support E.164 numbers=2C and may support others. So t= hose insisting that non-E.164 support is a requirement are effectively atte= mpting to change the MARTINI WG charter after it was approved.

John= Elwell: adding a requirement that solution should be extensible is within = charter.

Dean Willis and Bernard Aboba: agree.

Dean Willis:= charter says must support E.164=2C may support others.

John Elwell= : am hearing that we add req's for 15 &=3B 16=2C reworded to say soln "m= ust be extensible".  =3B

Spencer Dawkins=2C Adam Roach: agree. <= br>
** General Agreement - Add requirement(s) that the phase-1 solution = must be extensible to support 15 &=3B 16.  =3B

** General agr= eement -- Will take 15/16 &=3B 39 to the list.

2. Adam - GIN slid= es

Changes reviewed.

Issue: Ticket 28 user=3Dphone

Pro= posed at IETF 77 to say that if pbx needs user=3Dphone=2C it registers user= =3Dphone.

Doug Sauder: The SSP is the one who knows whether this is = a phone number or not=2C so it should be the one to add it. If you do optio= n-1=2C you will then have trouble reconciling with Olive=3B for example=2C = PBX specifies user=3Dphone in REGISTER request=2C and at the same time want= s to support non-E.164 numbers that wouldn't have user=3Dphone

Marti= n Dolly: AT&=3BT expects to see user=3Dphone on the INVITE and requires = PBXes to support it. =3B Since PBXes do not currently register=2C it is= less certain.

Hadriel Kaplan: noted that surrogate registration cu= rrently does NOT include user=3Dphone.

Adam Roach: I thought there w= ere some implementations that required user=3Dphone.

Hadriel Kaplan:= yes and there are some implementations that require it for E.164 numbers= =2C and other implementations that ignore this parameter.

Martin Do= lly: there is a difference between not dropping a call=2C versus requiring = it.

Hadriel Kaplan: the problem the 1st option is that it is treati= ng user=3Dphone an opaque parameter in the contact. The problem is that it = really isn't opaque - it has meaning in the INVITE.

Someone: There = is a 4th option=2C which is to let the SSP decide whether "user=3Dphone" is= required.

Hadriel Kaplan: Noted that there is a 5th option=2C wher= e user=3Dphone is a feature of the registration. If you register with user= =3Dphone=2C you get only phone numbers=3B without you get all URIs. Some de= vices fail with user=3Dphone=2C some require it.

Extended discussion= on contact routing=2C GRUU=2C etc=2C followed.

Question: Is there a= ny text suggesting that user=3Dphone can be used in the current draft?
<= br>Proposed that we pull user=3Dphone out of the examples.

Adam Roac= h: the fact is that this has caused so much confusion - the document should= talk about it at least to say something.

John Elwell: likes option-= 2 - let the SSP decide whether or not to put user=3Dphone in request URI (b= ased on what is stored in location db). The user=3Dphone is really an exten= sion of the user part=2C and since the user part is the expansion of the te= mplate provided in the bulk REGISTER Contact URI=2C the u=3Dp parm should b= e
configured in the SSP as part of that expansion. I.E. Whether it is th= ere or not is based on provisioning. It's possible for two diff users to ha= ve an AOR - same E.164 - one with u=3Dp and one without.

How does th= is compare to a normal registration? If there is no user=3Dphone on registe= red Contact and one comes back in the INVITE=2C what happens. (it depends..= .)

Debate continued between Hadriel=2C Olle=2C John=2C and Adam. The= n broadened.

Doug Sauder: propose adding an indicator/parameter some= where in the REGISTER indicating that the PBX requires user=3Dphone for AOR= s containing E.164 numbers. Similar to option 1 =2C but PBX is making it ex= plicit - I need a user=3Dphone for E.164 numbers.

Adam Roach/Hadrie= l Kaplan: this may be a good option.  =3B

Martin Dolly: want to = emphasize that user=3Dphone is required.

Adam Roach: this means tha= t if you're testing a PBX in your lab that claims compliance with GIN (and = we make proposed change)=2C you would expect to see it indicate that it nee= ds the user=3Dphone parameter.

Keith Drage: solution should state w= hat is mandatory vs=2C optional for the PBX and SSP to support. Multiple pe= ople agree.


** Agreement -- Adam will propose text for this new= user=3Dphone option.

Issue: Ticket #36 regevent handling

Wh= o serves the regevent subscription -- SSP or PBX?

Question: Is the S= SP knowledge ever useful information=2C or does it just show whether or not= the PBX is online. Yes=3B there may be multiple =3B registrations for = a user at the SSP.

Question: How does this apply to dialog event?
Keith Drage: is there a use-case we have in mind=2C where the SSP nee= ds to respond to reg-event when PBX is offline? And would it work any diffe= rent than other packages such as dialog-event? Hadriel - the reg-event pack= age routing is differently than other packages. The reg-event SUBSCRIBE is = routed to the
registrar of the AOR in the Request URI. Therefore=2C sinc= e the enterprise-user AORs belong to the SSP=2C the reg-event SUBSCRIBE is = routed to the SSP. Having it go to the SSP makes sense -- say the target AO= R can be registered simultaneously to the PBX and directly to the SSP.
=
Adam Roach: case where same AOR is registered to the SSP directly=2C an= d to the PBX=2C is a corner case.

Adam Roach: To header in REGISTER= represents the PBX. You can subscribe reg-event to it to get its registrat= ion state. But if you subscribe to the actual
enterprise user AOR=2C the= n you want the actual registration state on the PBX of the enterprise user.= What if my phone is registered to two PBXs for redundancy?

Adam Ro= ach: this supports it - you get two separate answers.

Hadriel Kapla= n: reg-event SUBSCRIBE request URI is owned by the SSP - therefore the SSP = should respond. It shouldn't goto the PBX. In fact there may be no registra= tion at the PBX=3B e.g.=2C the PBX supports non-SIP endpoints.

Adam= Roach: But sending the SWUBSCRIBE to the SSP doesn't provide any valuable = information=2C since the it only reflects whether the PBX is registered or = not=2C and 99.99% of the time it will be registered.  =3B

Spence= r Dawkins: suggest taking this to the list. Agreed.

Issue: Other op= en tickets

Final slide - need a volunteer for outbound analysis. Dea= n Willis suggests Paul Kyzivat.  =3B

Spencer Dawkins &=3B Ber= nard Aboba: will follow up with Paul and Cullen Jennings.

3. Hadriel= Kaplan: Olive presentation

Spencer Dawkins: had recently asked list= about whether the =3B result of bulk registration is the same as the r= esult of multiple  =3B
individual regitrations. Is the right place i= nside Olive?

Keith Drage: =3B =3B this assumption is part o= f why gin is fundamentally broken=3B we need something that works different= ly from conventional contact-routing. =3B Debate ensued=3B inconclusive= .

Keith Drage: we would have avoided the whole subscribe to reg-even= t if we had followed the IMS implicit registration model.

Adam Roac= h=2C Dean Willis: no - the problem would still be there=2C basically becaus= e RFC 3261 does not have a good model for transitive registration=2C which = is
what both IMS and GIN bulk registration are.

Dean Willis: this= is still broken for reg-event.

Adam Roach: agree. Solving it for G= IN will solve it for olive as well. In fact Hadriel's solution is the GIN d= raft extended to non-164 numbers.  =3B

Keith Drage: not sure if = you would ever explicitly register a local number. In IMS it would only be = implicitly registered. Register global explicitly=2C and register local imp= licitly.

Hadriel Kaplan: =3B but GIN is a compression/decompres= sion rule for explicitly registrations. So what would an explicit registrat= ion of a local number look like?  =3B

Keith Drage: =3B where= is the lack-of-uniqueness problem?

Adam Roach: we were trying to m= ake user-names globally unique to avoid the ambiguity that occurs when two = PBXs have overlapping private numbers.

Hadriel Kaplan: solves this = problem by adding context to make local numbers unique. Problem is a PBX co= uld have both a public and private numbers. There are two ways to handle th= is - either two separate logical trunks=2C or something in the actual URI p= ortion that makes local numbers unique.

4. WG Chairs: next steps
Spencer Dawkins: enumerates agreements for moving (disposition of issu= es 15=2C16=2C39=2C Paul Kyzivat and Cullen Jennings solicited for review of= outbound=2C etc.)

Keith Drage: is it possible for Hadriel to submit= a draft-01 of Olive?

Hadriel Kaplan: yes.

Keith Drage: the= refore we'll hold discussion until we see -01.

John Elwell: reqs dr= aft - assuming there is no pushback on 15=2C16=2C39 from list - are we goin= g to progress the requirements draft?

Bernard/Spencer: yes. =3B= Once we hafve no issues on the requirements document=2C we will progress i= t.

Meeting adjourned...

= --_3d89070f-bb0a-45fb-8d9d-29868602efd9_-- From bernard_aboba@hotmail.com Tue May 11 15:42:02 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 CE4473A6915 for ; Tue, 11 May 2010 15:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.329 X-Spam-Level: * X-Spam-Status: No, score=1.329 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_80=2, 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 uXX6NZBOTM5S for ; Tue, 11 May 2010 15:42:02 -0700 (PDT) Received: from blu0-omc2-s38.blu0.hotmail.com (blu0-omc2-s38.blu0.hotmail.com [65.55.111.113]) by core3.amsl.com (Postfix) with ESMTP id 253D03A6908 for ; Tue, 11 May 2010 15:42:02 -0700 (PDT) Received: from BLU137-W7 ([65.55.111.71]) by blu0-omc2-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 15:41:51 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a5ed8a57-2f7b-4377-b2f5-646dbce30747_" X-Originating-IP: [131.107.0.81] From: Bernard Aboba To: Date: Tue, 11 May 2010 15:41:51 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 May 2010 22:41:51.0929 (UTC) FILETIME=[263C6290:01CAF15B] Subject: [martini] MARTINI Virtual Interim V date/time; June 16, 2010 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, 11 May 2010 22:42:02 -0000 --_a5ed8a57-2f7b-4377-b2f5-646dbce30747_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking through the Doodle poll results=2C it appears that the best time fo= r MARTINI Virtual Interim V is Wednesday June 16=2C 2010 from 11 AM - 1 PM = PT.=20 = --_a5ed8a57-2f7b-4377-b2f5-646dbce30747_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking through the Doodle poll results=2C it appears that the best time fo= r MARTINI Virtual Interim V is Wednesday June 16=2C 2010 from 11 AM - 1 PM = PT.


= --_a5ed8a57-2f7b-4377-b2f5-646dbce30747_-- From bernard_aboba@hotmail.com Tue May 11 15:43:20 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 955683A6915 for ; Tue, 11 May 2010 15:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.836 X-Spam-Level: X-Spam-Status: No, score=0.836 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_60=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 yWaY8bpNoID2 for ; Tue, 11 May 2010 15:43:20 -0700 (PDT) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by core3.amsl.com (Postfix) with ESMTP id 057A53A6908 for ; Tue, 11 May 2010 15:43:18 -0700 (PDT) Received: from BLU137-DS13 ([65.55.111.71]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 15:43:07 -0700 X-Originating-IP: [131.107.0.117] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 11 May 2010 15:43:05 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxW1IDDLBhmE10RcGXYhVD9UG93wAAAAGg Content-Language: en-us X-OriginalArrivalTime: 11 May 2010 22:43:07.0807 (UTC) FILETIME=[537672F0:01CAF15B] Subject: [martini] MARTINI Virtual Interim V 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, 11 May 2010 22:43:20 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN=martini@ietf.org;RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100511T224305Z DESCRIPTION:When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: Teleconference\, details TBD\n\nNote: T he GMT offset above does not reflect daylight saving time adjustments.\n\n *~*~*~*~*~*~*~*~*~*\n\n\n DTEND:20100616T200000Z DTSTAMP:20100511T224305Z DTSTART:20100616T180000Z LAST-MODIFIED:20100511T224305Z LOCATION:Teleconference\, details TBD ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:0 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim V TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000C00DA4A520F1CA01000000000000000 0100000008ECA0F9EA2FCB34AA7A950A9AB259A9D X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Teleconference\, details TBD\n\n

Note: The GMT off set above does not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~* ~*~*

\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From john.elwell@siemens-enterprise.com Wed May 12 00:19:11 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 928A63A68C3 for ; Wed, 12 May 2010 00:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.241, 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 vdWrwN+Gdj1W for ; Wed, 12 May 2010 00:19:10 -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 A15DF3A6AF7 for ; Wed, 12 May 2010 00:18:59 -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-142292 for martini@ietf.org; Wed, 12 May 2010 09:18:47 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 2432423F0278 for ; Wed, 12 May 2010 09:18:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 12 May 2010 09:18:47 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Wed, 12 May 2010 09:18:45 +0200 Thread-Topic: Reqs-07 posted Thread-Index: Acrxo1vaCQ0UUZKcTW2yYUnoBgOJnQ== Message-ID: 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: [martini] Reqs-07 posted 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, 12 May 2010 07:19:11 -0000 http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-07.txt This just fixes a number of nits, including those found by Martien and some= others I found. There are no outstanding issues, and as far as I am concer= ned this is ready to go. John From root@core3.amsl.com Wed May 12 00:30: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 65B793A69A6; Wed, 12 May 2010 00:30: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: <20100512073002.65B793A69A6@core3.amsl.com> Date: Wed, 12 May 2010 00:30:02 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-reqs-07.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: Wed, 12 May 2010 07:30: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 : 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-07.txt Pages : 12 Date : 2010-05-12 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. This work is being discussed on the martini@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-07.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-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-12001653.I-D@ietf.org> --NextPart-- From adam@nostrum.com Wed May 12 06:51:20 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 8CB4A28C1CA for ; Wed, 12 May 2010 06:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, 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 Q0BrvRxyx5mg for ; Wed, 12 May 2010 06:51:19 -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 ED72D28C2FF for ; Wed, 12 May 2010 06:39:53 -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 o4CDdACA094009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 12 May 2010 08:39:41 -0500 (CDT) (envelope-from adam@nostrum.com) From: Adam Roach Content-Type: multipart/alternative; boundary=Apple-Mail-5--988361852 Date: Wed, 12 May 2010 08:39:41 -0500 X-Mail-Calendar-Part: Yes To: martini@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [martini] iCal event invitation: MARTINI Virtual Interim V 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, 12 May 2010 13:51:20 -0000 --Apple-Mail-5--988361852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Adam Roach has invited you to the iCal event: MARTINI Virtual Interim V, = scheduled for June 16, 2010 at 6:00 PM (GMT+00:00). To accept or decline = this invitation, click the link below.= --Apple-Mail-5--988361852 Content-Type: multipart/mixed; boundary=Apple-Mail-6--988361852 --Apple-Mail-6--988361852 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Adam Roach has invited you to the iCal event: MARTINI Virtual Interim V, scheduled for June 16, 2010 at 6:00 PM (GMT+00:00). To accept or decline this invitation, click the link below.
--Apple-Mail-6--988361852 Content-Disposition: attachment; filename=iCal-20100512-083941.ics Content-Type: text/calendar; name="iCal-20100512-083941.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A= METHOD:REQUEST=0D=0APRODID:-//Apple=20Inc.//iCal=204.0.2//EN=0D=0A= BEGIN:VEVENT=0D=0ADTEND:20100616T200000Z=0D=0ATRANSP:OPAQUE=0D=0A= ORGANIZER;CN=3D"Adam=20Roach":mailto:adam@estacado.net=0D=0A= UID:6F3AC348-E90A-4FFE-981D-E8AAF901B5F0=0D=0ADTSTAMP:20100512T133939Z=0D= =0ALOCATION:Teleconference\,=20details=20TBD=0D=0ADESCRIPTION:When:=20= Wednesday\,=20June=2016\,=202010=2011:00=20AM-1:00=20PM=20(UTC-08:00=0D=0A= =20)=20Pacific=20Time=20(US=20&=20Canada).\nWhere:=20Teleconference\,=20= details=20TBD\n\nNo=0D=0A=20te:=20The=20GMT=20offset=20above=20does=20= not=20reflect=20daylight=20saving=20time=20adjustmen=0D=0A=20= ts.\n\n*~*~*~*~*~*~*~*~*~*\n\n\n=0D=0ASEQUENCE:1=0D=0ASUMMARY:MARTINI=20= Virtual=20Interim=20V=0D=0ADTSTART:20100616T180000Z=0D=0A= CREATED:20100511T224305Z=0D=0A= ATTENDEE;CN=3D"martini@ietf.org";CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTI= ON;R=0D=0A=20SVP=3DTRUE:mailto:martini@ietf.org=0D=0AATTENDEE;CN=3D"Adam=20= Roach";CUTYPE=3DINDIVIDUAL;PARTSTAT=3DACCEPTED:mailto:adam=0D=0A=20= @estacado.net=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=0A= --Apple-Mail-6--988361852 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail-6--988361852-- --Apple-Mail-5--988361852-- From adam@nostrum.com Wed May 12 07:43:03 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 6BF973A6CC1 for ; Wed, 12 May 2010 07:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=1.223, BAYES_00=-2.599, GB_I_INVITATION=-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 S+r-cqYWbpJ0 for ; Wed, 12 May 2010 07:43:02 -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 B61C828C2CD for ; Wed, 12 May 2010 07:27:15 -0700 (PDT) Received: from dn3-110.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 o4CER3cl098023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 May 2010 09:27:04 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BEABAB7.3040901@nostrum.com> Date: Wed, 12 May 2010 09:27:03 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: martini@ietf.org 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) Subject: Re: [martini] iCal event invitation: MARTINI Virtual Interim V 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, 12 May 2010 14:43:03 -0000 Sorry for the confusion -- tools malfunction. Apparently iCal decided to send an invitation to the entire working group simply because I accepted it into my calendar. *sigh* /a On 5/12/10 8:39 AM, Adam Roach wrote: > Adam Roach has invited you to the iCal event: MARTINI Virtual Interim > V, scheduled for June 16, 2010 at 6:00 PM (GMT+00:00). To accept or > decline this invitation, click the link below. > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From root@core3.amsl.com Thu May 13 10:00:01 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 EBDB83A6B12; Thu, 13 May 2010 10:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100513170001.EBDB83A6B12@core3.amsl.com> Date: Thu, 13 May 2010 10:00:01 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] MARTINI WG Virtual Interim Meeting, June 16, 2010 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, 13 May 2010 17:00:02 -0000 The MARTINI WG will be having a Virtual Interim meeting on June 16, 2010 from 11 AM - 1 PM Pacific Time. Conference parameters for the meeting will be announced on the MARTINI WG mailing list: http://www.ietf.org/mail-archive/web/martini/current/maillist.html From martien.huysmans@ericsson.com Tue May 18 07:05:17 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 689AB3A686E for ; Tue, 18 May 2010 07:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-1.901, 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 wLTQYx-k8lSq for ; Tue, 18 May 2010 07:05:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CC7B928C0E2 for ; Tue, 18 May 2010 07:04:26 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-f6-4bf29e613416 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 88.FA.21861.16E92FB4; Tue, 18 May 2010 16:04:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.40]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 18 May 2010 15:34:53 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Tue, 18 May 2010 15:15:02 +0200 Thread-Topic: Status Martini-Gin-01 Thread-Index: Acr2jB/Y5IxG323+Q2yO/jm+i1kFtA== 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_B5CE2B521539624E8364D395B6F76B5C1DCF2449D9ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] Status Martini-Gin-01 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, 18 May 2010 14:05:17 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DCF2449D9ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I plan to study the Martini Gin draft. What is the status of the draft-ietf-martini-gin-01? Is the outcome of the discussions on the mailing list included in this vers= ion? /Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DCF2449D9ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
I plan to study the Martini Gin draft.
What is the status of the draft-ietf-martini-gin-01?
Is the outcome of the discussions on the mailing list included in this= version?
 
/Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DCF2449D9ESESSCMS0356e_-- From adam@nostrum.com Tue May 18 14:38:17 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 90CC33A68FC for ; Tue, 18 May 2010 14:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.303, 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 VGqwTgcINx3L for ; Tue, 18 May 2010 14:38:16 -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 55DF63A67F5 for ; Tue, 18 May 2010 14:38:16 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4ILc7BU014185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 May 2010 16:38:07 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF308BF.5030709@nostrum.com> Date: Tue, 18 May 2010 16:38:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 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: 70.249.147.216 is authenticated by a trusted mechanism) Subject: [martini] New GIN Draft 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, 18 May 2010 21:38:17 -0000 Based on the conversation we had about "user=phone" at the most recent interim, I have put some strawman text into the GIN document. Please look at the revamped section 5 -- section 5.3, in particular -- in the new version, and let me know whether you have any concerns about this proposed resolution. New version: http://www.ietf.org/id/draft-ietf-martini-gin-02.txt Diffs: http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-02.txt This version also removes ";user=phone" from all the examples, as was proposed during the phone call. The issue around registration remains open, and I'll be sending an email to the list shortly to discuss it. /a From root@core3.amsl.com Tue May 18 14:45:04 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 A6DA03A6AE1; Tue, 18 May 2010 14:45:03 -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: <20100518214503.A6DA03A6AE1@core3.amsl.com> Date: Tue, 18 May 2010 14:45:03 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-gin-02.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, 18 May 2010 21:45:04 -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-02.txt Pages : 24 Date : 2010-05-18 This document defines a mechanism by which a SIP server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for terminals 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-18143009.I-D@ietf.org> --NextPart-- From adam@nostrum.com Tue May 18 15:12:55 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 F3DFC3A6875 for ; Tue, 18 May 2010 15:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_50=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 fLCvbY6TSYee for ; Tue, 18 May 2010 15:12: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 DF33C3A67B5 for ; Tue, 18 May 2010 15:12:52 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4IMCh1P016876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 May 2010 17:12:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF310DB.1000700@nostrum.com> Date: Tue, 18 May 2010 17:12:43 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 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: 70.249.147.216 is authenticated by a trusted mechanism) Subject: [martini] Open Issue #36: GIN and "reg" event package 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, 18 May 2010 22:12:55 -0000 We're down to a fairly small number of open issues on GIN. Currently, section 7.2.2 of the GIN document describes some fairly specific behavior for "reg" event handling. In particular, it says that subscriptions to the state of a single phone number are forwarded by the SSP to the PBX. There's some logic in the document about why I thought this was a Good Idea, and even "important." At the most recent interim, we had a fairly long discussion about whether this was actually the "right" thing to do. Hadriel made some convincing arguments that the SSP should service the subscriptions, since it really "owns" the URIs in question. The "vermouth" draft delves a bit deeper into some related issues, but it's somewhat less developed than GIN at this point. We don't want to make GIN dependent on vermouth, and we really can't leave a treatment of the "reg" event package out of GIN: GIN deals intimately with registration. Under any reasonable "you break it you buy it" principle, we're on the hook for coming up with a sane treatment of the "reg" event package. After an off-list exchange with Hadriel, I *think* we're both okay if that treatment is as simple as "here are the properties if you handle it at the SSP, here are the properties if you handle it at the PBX, and which you choose is a matter of policy." (I don't mean to put words in Hadriel's mouth, and I'm sure he'll correct me if my summary isn't consistent with his position). This approach is actually pretty well in line with the way that event packages are handled in general. It also allows for some clever (if complicated) solutions to the problem in which the SSP services the subscription, but incorporates information it has learned from the PBX (say, through back-end subscriptions). Basically, it gets us back to what the IETF does well -- defining protocol mechanisms -- while leaving concrete architectures up to other organizations. Please comment on whether you think this is a reasonable way to address this open issue. If there is enough support, I'll craft some formal text and put it in GIN. /a From fluffy@cisco.com Tue May 18 18:18:39 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 4E2B23A69A0 for ; Tue, 18 May 2010 18:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.643 X-Spam-Level: X-Spam-Status: No, score=-108.643 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_50=0.001, 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 0aRUGHhXRx0j for ; Tue, 18 May 2010 18:18:36 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A47043A6852 for ; Tue, 18 May 2010 18:18:36 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkGAOrY8kurR7H+/2dsb2JhbACeCGsGowGZZYUQBINA X-IronPort-AV: E=Sophos;i="4.53,258,1272844800"; d="scan'208";a="131513438" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 May 2010 01:18:29 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4J1IS5s015587 for ; Wed, 19 May 2010 01:18:29 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Tue, 18 May 2010 19:18:27 -0600 Message-Id: <9579A5DE-F6F2-4717-AA1F-4AD0951C9611@cisco.com> To: "martini@ietf.org" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [martini] Review of GIN and outbound interaction 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, 19 May 2010 01:18:40 -0000 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.=20= 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.=20 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.=20 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.=20 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.=20 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.=20 Cullen Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Tue May 18 18:18:41 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 9CAF03A69A0 for ; Tue, 18 May 2010 18:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.622 X-Spam-Level: X-Spam-Status: No, score=-108.622 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_50=0.001, 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 WGDcDiEEhZxd for ; Tue, 18 May 2010 18:18:39 -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 0E9703A68EB for ; Tue, 18 May 2010 18:18:39 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkGAOrY8kurR7H+/2dsb2JhbACeCGsGowGZZYUQBINA X-IronPort-AV: E=Sophos;i="4.53,258,1272844800"; d="scan'208";a="199281468" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 19 May 2010 01:18:31 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4J1IS5t015587 for ; Wed, 19 May 2010 01:18:31 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Tue, 18 May 2010 19:18:31 -0600 Message-Id: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> To: "martini@ietf.org" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [martini] GIN and anonymous GRUUS 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, 19 May 2010 01:18:41 -0000 I think the anonymous public GRUUs need some work. Imagine that I have a = small PBX at a women's shelter. Say they are 5 to 10 phones or so and = this PBX connects to an SSP. I think this is one of the use cases we = need anonymous calls to work for and when someone makes a call from one = of these phones, it can not reveal they are at the women's shelter. = Anonymizing which room they are in at the women's shelter is not enough. = I'll ignore the self make GRUU section because if you could to that, = well you would not need GIN in the first place.=20 Moving on to the Approach 2 - it seem that the PBX needs to get an = anonymous GRUU from the SSP then use that to fabricate it's anonymous = GRUU. I think that if you modified what you have in the draft now to use = anonymous GRUUs from the SSP, you could get this to work.=20 I think it would be worth adding an example showing an anonymous call. I = know lots of people goes "who cares, that's a corner case" but many of = the environments where we want to deploy GIN, it will be a requirement = to support anonymous call - not many people need them but governments = are pretty adamant about making sure the people who do need them can = have them.=20 Could you put a Note telling the RFC Ed to remove section 9. If anyone = ever needs to read that they can find the draft.=20 Nice draft - can't say I like it but I can live with it and I suspect = most people will come to the same conclusion after thinking about it for = awhile. Something most people can live with I view as huge success for = this topic. It will be infinitely better than the current situation of = many things that sounds close but when you look at them in detail don't = interoperate.=20 Thanks, Cullen Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Tue May 18 18:26:29 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 CC58A3A69A0 for ; Tue, 18 May 2010 18:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.654 X-Spam-Level: X-Spam-Status: No, score=-109.654 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, 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 nT7civgmrzXx for ; Tue, 18 May 2010 18:26:28 -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 6859B3A6A2B for ; Tue, 18 May 2010 18:26:26 -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: AvsEAEPb8kurRN+J/2dsb2JhbACeCHGjFZlohRAEg0A X-IronPort-AV: E=Sophos;i="4.53,258,1272844800"; d="scan'208";a="531880350" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 19 May 2010 01:26:19 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4J1QIS5006579; Wed, 19 May 2010 01:26:19 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4BF308BF.5030709@nostrum.com> Date: Tue, 18 May 2010 19:26:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <13D20A43-9E19-40A1-BEC9-713381EDEA83@cisco.com> References: <4BF308BF.5030709@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1078) Cc: "martini@ietf.org" Subject: Re: [martini] New GIN Draft 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, 19 May 2010 01:26:30 -0000 On May 18, 2010, at 3:38 PM, Adam Roach wrote: > Based on the conversation we had about "user=3Dphone" at the most = recent interim, I have put some strawman text into the GIN document. = Please look at the revamped section 5 -- section 5.3, in particular -- = in the new version, and let me know whether you have any concerns about = this proposed resolution. Trying to fix the looser=3Dphone problem by adding some auto magic is = doomed to failure. I rather just have clarify what needs to be done (in = some document other than GIN, perhaps the SIP Forum doc) and just fix = stuff to work or at least not fail in a bad way.=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Tue May 18 18:33:41 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 22E983A6A15 for ; Tue, 18 May 2010 18:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.656 X-Spam-Level: X-Spam-Status: No, score=-107.656 tagged_above=-999 required=5 tests=[AWL=-1.549, BAYES_50=0.001, J_CHICKENPOX_45=0.6, MISSING_HEADERS=1.292, 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 N4lFon1PZZbL for ; Tue, 18 May 2010 18:33:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 46F083A68EB for ; Tue, 18 May 2010 18:33:39 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG/c8kurR7Ht/2dsb2JhbACdJWNxox2ZaIUQBINA X-IronPort-AV: E=Sophos;i="4.53,258,1272844800"; d="scan'208";a="223082964" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 19 May 2010 01:33:32 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4J1XUtc002319 for ; Wed, 19 May 2010 01:33:31 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Tue, 18 May 2010 19:33:25 -0600 Cc: Content-Transfer-Encoding: quoted-printable Message-Id: <18DAACAB-3B64-42F4-A20C-5F75557B0854@cisco.com> References: X-Mailer: Apple Mail (2.1078) Subject: Re: [martini] Draft minutes from MARTINI Virtual Interim IV 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, 19 May 2010 01:33:41 -0000 Uh, these notes don't really make much sense to someone who was not = there. Sorting out if I agree with proposal #1 or #3 for issue #15 is = just not something I'm willing to go do. I'm not asking anyone to redo = the minutes, I probably could figure it all out if I spent enough time = but I'll just wait to comment on the drafts as that seems a better use = of time. Just don't take my silence as agreement with anything that = happened at the interim.=20 On May 11, 2010, at 4:10 PM, Bernard Aboba wrote: > Minutes of Martini Virtual Interim IV > April 29, 2010 >=20 > Minute takers: David Hancock, Dean Willis >=20 > Agenda bash: No changes to Agenda >=20 > 1. Requirements discussion led by John Elwell >=20 > Issue #39, explanatory text in Section 1. >=20 > John Elwell - Do we keep issue #39, or does it go in a solutions draft = (such as Olive)? >=20 > Spencer prefers it stay in the requirements draft, since we're = producing only one of these and it'll be easier to find. >=20 > Discussion moved on while Hadriel reviewed text. On review, Hadriel = believes the first paragraph is just wrong (Background on the Issues), = and needs to be tailored to unique contacts, not unique AORs. Hadriel = proposes removing this text.=20 >=20 > John Elwell: don't mind deleting it, but was asked to add it by Jon = Peterson at IETF 77 mtg. Propose taking this to the list - and give = reasons and get consensus to remove it.=20 >=20 > Spencer Dawkins: if list decides that it should be somewhere - would = that place be the olive draft (or whatever document addresses solution = for the 15/16 requirements). >=20 > Hadriel Kaplan: the Olive draft does cover this already, so that's = covered=20 >=20 > Issue #15, #16 non-E.164 and extensibility to any AOR >=20 > 5 alternative paths have been proposed. John proposes #1 or #3 = (nothing or add as desirable). >=20 > Adam suggests 6th option to be phase 1 deliverable, with a plan to do = a second phase 2 requirements document for phase 2 deliverables. >=20 > Noted that several people from list supported adopting requirements as = they stand. >=20 > Discussion of 2 phase approach and meaning of requirements followed. >=20 > Hadriel Kaplan: I thought these were desirable. At least 16 - the = extensibility one.=20 >=20 > Dean Willis: we specifically excluded #15 for phase-1 - to limit to = E.164 numbers.=20 >=20 > Keith Drage: if we do this - how do we meet/handle these requirement = in the solutions draft?=20 >=20 > Adam Roach: by demonstrating in another draft (e.g., olive) how the = extension could be supported.=20 >=20 > Spencer Dawkins: understand that everyone on group supports the = requirement for non-e.164 numbers.=20 >=20 > John Elwell: yes, would like 15/16 to be supported eventually, just = not in phase-1.=20 >=20 > Spencer Dawkins (as chair): would not want to ignore these. Should = address them as required or desirable. So, should the working group = continue advancing Olive?=20 >=20 > Martin Dolly: there was a contingent of folks that saw the need to = address these now - as in phase-1.=20 >=20 > Dean Willis: does that mean stop working on GIN until we figure out = how it can support 15/16.=20 >=20 > Martin Dolly: a requirement is a requirement. There is never a = question of phasing requirements. If you choose to defer meeting a = requirement, then it is still a requirement, just at a later date.=20 >=20 > Adam Roach: what I'm hearing is to reverse the MARTINI-II meeting = agreement to limit phase-1 to E.164 numbers.=20 >=20 > Dean Willis: no, Martin is just saying these are requirements, we just = need to decide schedule.=20 >=20 > Keith Drage: there is also a desire that these requirements can be = supported by MARTINI GIN extension, and not a whole new solution.=20 >=20 > Bernard Aboba: The MARTINI charter specifically states that the = solution must support E.164 numbers, and may support others. So those = insisting that non-E.164 support is a requirement are effectively = attempting to change the MARTINI WG charter after it was approved.=20 >=20 > John Elwell: adding a requirement that solution should be extensible = is within charter.=20 >=20 > Dean Willis and Bernard Aboba: agree.=20 >=20 > Dean Willis: charter says must support E.164, may support others.=20 >=20 > John Elwell: am hearing that we add req's for 15 & 16, reworded to say = soln "must be extensible". =20 >=20 > Spencer Dawkins, Adam Roach: agree.=20 >=20 > ** General Agreement - Add requirement(s) that the phase-1 solution = must be extensible to support 15 & 16. =20 >=20 > ** General agreement -- Will take 15/16 & 39 to the list. >=20 > 2. Adam - GIN slides >=20 > Changes reviewed. >=20 > Issue: Ticket 28 user=3Dphone >=20 > Proposed at IETF 77 to say that if pbx needs user=3Dphone, it = registers user=3Dphone. >=20 > Doug Sauder: The SSP is the one who knows whether this is a phone = number or not, so it should be the one to add it. If you do option-1, = you will then have trouble reconciling with Olive; for example, PBX = specifies user=3Dphone in REGISTER request, and at the same time wants = to support non-E.164 numbers that wouldn't have user=3Dphone >=20 > Martin Dolly: AT&T expects to see user=3Dphone on the INVITE and = requires PBXes to support it. Since PBXes do not currently register, it = is less certain.=20 >=20 > Hadriel Kaplan: noted that surrogate registration currently does NOT = include user=3Dphone. >=20 > Adam Roach: I thought there were some implementations that required = user=3Dphone. >=20 > Hadriel Kaplan: yes and there are some implementations that require it = for E.164 numbers, and other implementations that ignore this parameter.=20= >=20 > Martin Dolly: there is a difference between not dropping a call, = versus requiring it.=20 >=20 > Hadriel Kaplan: the problem the 1st option is that it is treating = user=3Dphone an opaque parameter in the contact. The problem is that it = really isn't opaque - it has meaning in the INVITE.=20 >=20 > Someone: There is a 4th option, which is to let the SSP decide whether = "user=3Dphone" is required.=20 >=20 > Hadriel Kaplan: Noted that there is a 5th option, where user=3Dphone = is a feature of the registration. If you register with user=3Dphone, you = get only phone numbers; without you get all URIs. Some devices fail with = user=3Dphone, some require it. >=20 > Extended discussion on contact routing, GRUU, etc, followed. >=20 > Question: Is there any text suggesting that user=3Dphone can be used = in the current draft? >=20 > Proposed that we pull user=3Dphone out of the examples. >=20 > Adam Roach: the fact is that this has caused so much confusion - the = document should talk about it at least to say something. >=20 > John Elwell: likes option-2 - let the SSP decide whether or not to put = user=3Dphone in request URI (based on what is stored in location db). = The user=3Dphone is really an extension of the user part, and since the = user part is the expansion of the template provided in the bulk REGISTER = Contact URI, the u=3Dp parm should be > configured in the SSP as part of that expansion. I.E. Whether it is = there or not is based on provisioning. It's possible for two diff users = to have an AOR - same E.164 - one with u=3Dp and one without. >=20 > How does this compare to a normal registration? If there is no = user=3Dphone on registered Contact and one comes back in the INVITE, = what happens. (it depends...) >=20 > Debate continued between Hadriel, Olle, John, and Adam. Then = broadened. >=20 > Doug Sauder: propose adding an indicator/parameter somewhere in the = REGISTER indicating that the PBX requires user=3Dphone for AORs = containing E.164 numbers. Similar to option 1 , but PBX is making it = explicit - I need a user=3Dphone for E.164 numbers.=20 >=20 > Adam Roach/Hadriel Kaplan: this may be a good option. =20 >=20 > Martin Dolly: want to emphasize that user=3Dphone is required.=20 >=20 > Adam Roach: this means that if you're testing a PBX in your lab that = claims compliance with GIN (and we make proposed change), you would = expect to see it indicate that it needs the user=3Dphone parameter.=20 >=20 > Keith Drage: solution should state what is mandatory vs, optional for = the PBX and SSP to support. Multiple people agree.=20 >=20 >=20 > ** Agreement -- Adam will propose text for this new user=3Dphone = option.=20 >=20 > Issue: Ticket #36 regevent handling >=20 > Who serves the regevent subscription -- SSP or PBX? >=20 > Question: Is the SSP knowledge ever useful information, or does it = just show whether or not the PBX is online. Yes; there may be multiple = registrations for a user at the SSP. >=20 > Question: How does this apply to dialog event?=20 >=20 > Keith Drage: is there a use-case we have in mind, where the SSP needs = to respond to reg-event when PBX is offline? And would it work any = different than other packages such as dialog-event? Hadriel - the = reg-event package routing is differently than other packages. The = reg-event SUBSCRIBE is routed to the > registrar of the AOR in the Request URI. Therefore, since the = enterprise-user AORs belong to the SSP, the reg-event SUBSCRIBE is = routed to the SSP. Having it go to the SSP makes sense -- say the target = AOR can be registered simultaneously to the PBX and directly to the SSP.=20= >=20 > Adam Roach: case where same AOR is registered to the SSP directly, and = to the PBX, is a corner case.=20 >=20 > Adam Roach: To header in REGISTER represents the PBX. You can = subscribe reg-event to it to get its registration state. But if you = subscribe to the actual > enterprise user AOR, then you want the actual registration state on = the PBX of the enterprise user. What if my phone is registered to two = PBXs for redundancy?=20 >=20 > Adam Roach: this supports it - you get two separate answers.=20 >=20 > Hadriel Kaplan: reg-event SUBSCRIBE request URI is owned by the SSP - = therefore the SSP should respond. It shouldn't goto the PBX. In fact = there may be no registration at the PBX; e.g., the PBX supports non-SIP = endpoints.=20 >=20 > Adam Roach: But sending the SWUBSCRIBE to the SSP doesn't provide any = valuable information, since the it only reflects whether the PBX is = registered or not, and 99.99% of the time it will be registered. =20 >=20 > Spencer Dawkins: suggest taking this to the list. Agreed.=20 >=20 > Issue: Other open tickets >=20 > Final slide - need a volunteer for outbound analysis. Dean Willis = suggests Paul Kyzivat. =20 >=20 > Spencer Dawkins & Bernard Aboba: will follow up with Paul and Cullen = Jennings. >=20 > 3. Hadriel Kaplan: Olive presentation >=20 > Spencer Dawkins: had recently asked list about whether the result of = bulk registration is the same as the result of multiple =20 > individual regitrations. Is the right place inside Olive?=20 >=20 > Keith Drage: this assumption is part of why gin is fundamentally = broken; we need something that works differently from conventional = contact-routing. Debate ensued; inconclusive. >=20 > Keith Drage: we would have avoided the whole subscribe to reg-event if = we had followed the IMS implicit registration model.=20 >=20 > Adam Roach, Dean Willis: no - the problem would still be there, = basically because RFC 3261 does not have a good model for transitive = registration, which is > what both IMS and GIN bulk registration are. >=20 > Dean Willis: this is still broken for reg-event.=20 >=20 > Adam Roach: agree. Solving it for GIN will solve it for olive as well. = In fact Hadriel's solution is the GIN draft extended to non-164 numbers. = =20 >=20 > Keith Drage: not sure if you would ever explicitly register a local = number. In IMS it would only be implicitly registered. Register global = explicitly, and register local implicitly.=20 >=20 > Hadriel Kaplan: but GIN is a compression/decompression rule for = explicitly registrations. So what would an explicit registration of a = local number look like? =20 >=20 > Keith Drage: where is the lack-of-uniqueness problem?=20 >=20 > Adam Roach: we were trying to make user-names globally unique to avoid = the ambiguity that occurs when two PBXs have overlapping private = numbers.=20 >=20 > Hadriel Kaplan: solves this problem by adding context to make local = numbers unique. Problem is a PBX could have both a public and private = numbers. There are two ways to handle this - either two separate logical = trunks, or something in the actual URI portion that makes local numbers = unique.=20 >=20 > 4. WG Chairs: next steps >=20 > Spencer Dawkins: enumerates agreements for moving (disposition of = issues 15,16,39, Paul Kyzivat and Cullen Jennings solicited for review = of outbound, etc.) >=20 > Keith Drage: is it possible for Hadriel to submit a draft-01 of Olive?=20= >=20 > Hadriel Kaplan: yes.=20 >=20 > Keith Drage: therefore we'll hold discussion until we see -01.=20 >=20 > John Elwell: reqs draft - assuming there is no pushback on 15,16,39 = from list - are we going to progress the requirements draft?=20 >=20 > Bernard/Spencer: yes. Once we hafve no issues on the requirements = document, we will progress it.=20 >=20 > Meeting adjourned... >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Tue May 18 18:44:53 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 507193A67D9 for ; Tue, 18 May 2010 18:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.974 X-Spam-Level: X-Spam-Status: No, score=-109.974 tagged_above=-999 required=5 tests=[AWL=0.625, 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 9wd5R607Cb2F for ; Tue, 18 May 2010 18:44:51 -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 B8F5D3A691E for ; Tue, 18 May 2010 18:44:51 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPLf8kurRN+J/2dsb2JhbACeCHGjCZlnhRAEg0A X-IronPort-AV: E=Sophos;i="4.53,258,1272844800"; d="scan'208";a="199287688" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 May 2010 01:44:44 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4J1ihTm013043; Wed, 19 May 2010 01:44:44 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <074.ebb4a3094b410cb67bdf1424b8795605@tools.ietf.org> Date: Tue, 18 May 2010 19:44:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <122F1D6A-D3C5-4001-B6B5-46E5A1988A60@cisco.com> References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> <074.ebb4a3094b410cb67bdf1424b8795605@tools.ietf.org> To: Bernard Aboba , Spencer Dawkins X-Mailer: Apple Mail (2.1078) Cc: martini@ietf.org Subject: Re: [martini] #15: support for non E.164 numbers 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, 19 May 2010 01:44:53 -0000 I barely care about the proposed change but I will note that change take = you outside the scope of your charter. I can't even figure out what the = change is by reading the list traffic which suggests we have a serious = problem in how we are using the tracker. Imagine the difficult of some = new AD coming in a year from now to deal with an appeal and trying to = figure out what was agreed to using the email archives only. I think we = need to find a better way to use the tracker.=20 On Apr 30, 2010, at 9:03 AM, martini issue tracker wrote: > #15: support for non E.164 numbers > = -------------------------------------+------------------------------------= -- > Reporter: ietf.hanserik@=85 | Owner: =20 > Type: defect | Status: reopened =20 > Priority: critical | Milestone: milestone1 > Component: reqs | Version: 1.0 =20 > Severity: In WG Last Call | Resolution: =20 > Keywords: | =20 > = -------------------------------------+------------------------------------= -- > Changes (by john.elwell@=85): >=20 > * status: closed =3D> reopened > * resolution: wontfix =3D> >=20 >=20 > Comment: >=20 > Reopened due to ongoing discussion on the list. Discussion during the > MARTINI interim meeting 2010-04-29 revealed support for accepting this > change with rewording along the lines of "The mechanism MUST be = extensible > to allow..." (i.e. similar to ticket #16). If there are no objections = I > will close this as 'fixed' (subject to that wording change). >=20 > --=20 > Ticket URL: = > martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From francois.audet@skype.net Tue May 18 20:36:51 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 7998F3A6897 for ; Tue, 18 May 2010 20:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 HWTMcUIkNYYc for ; Tue, 18 May 2010 20:36:49 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 334643A6876 for ; Tue, 18 May 2010 20:36:45 -0700 (PDT) Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 765091703; Wed, 19 May 2010 05:36:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=skype.net; s=mx; t=1274240197; bh=Eq8eAyseYMg71ZYSWE5PXEMmRekjv7gNGPUweEVfmVE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Y2d0SFEq8T+3 lHFOln7cNce0gspZc417TrTM80OCe+9X+x5wmr2R2fcnqAniLaN1OiYTdCHsW5u+mSg 2qYiDK2S12quY6tOMXMXJu8ibr3Qm/QJRTqf29f43GAdELwBhXWTwwNRpVLZZ3NVxjH BvCPQOS6kGqM+tEHZkrsLOM5s= Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 48FDC3506ECB; Wed, 19 May 2010 05:36:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pByQ5PSfmhWu; Wed, 19 May 2010 05:36:36 +0200 (CEST) Received: from [10.0.1.2] (adsl-75-55-212-141.dsl.pltn13.sbcglobal.net [75.55.212.141]) by zimbra.skype.net (Postfix) with ESMTPSA id B31263506EC6; Wed, 19 May 2010 05:36:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?AUDET_Fran=E7ois?= In-Reply-To: <9579A5DE-F6F2-4717-AA1F-4AD0951C9611@cisco.com> Date: Tue, 18 May 2010 20:36:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <595F197E-FC24-4042-B417-41DE4C561879@skype.net> References: <9579A5DE-F6F2-4717-AA1F-4AD0951C9611@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1078) Cc: "martini@ietf.org" Subject: Re: [martini] Review of GIN and outbound interaction 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, 19 May 2010 03:36:51 -0000 For all it's worth, the only case I've ever considered for this is what = you call the B2BUA-type PBX case (i.e. one instance-id). And yes, = indeed, the whole concept of caller prefs wouldn't apply to a sip trunk. = This should just work. I haven't really considered at all the = PBX-as-a-proxy case, because it doesn't really make sense to me (I would = think domain-to-domain arrangement would apply in this context). I believe your analysis is right. I think for GIN, I would say it = applies only to the B2BUA case of PBX. But I don't think it will be very obvious to the reader where outbound = stops and where GIN begins. But then again, it wasn't so obvious with = GRUU and outbound... On May 18, 2010, at 18:18 , Cullen Jennings wrote: >=20 > 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). >=20 > 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.=20= >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > Cullen >=20 >=20 >=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From dean.willis@softarmor.com Tue May 18 23:58:17 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 414C63A6A5B for ; Tue, 18 May 2010 23:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_50=0.001, J_CHICKENPOX_45=0.6] 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 bCBHV8IUWEyF for ; Tue, 18 May 2010 23:58:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5DB8A3A6B11 for ; Tue, 18 May 2010 23:58:15 -0700 (PDT) Received: from [192.168.2.143] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4J6w46A015054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 May 2010 01:58:06 -0500 X-User-Agent: K-9 Mail for Android In-Reply-To: <18DAACAB-3B64-42F4-A20C-5F75557B0854@cisco.com> References: <18DAACAB-3B64-42F4-A20C-5F75557B0854@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit From: Dean Willis Date: Wed, 19 May 2010 01:57:59 -0500 To: Cullen Jennings Message-ID: <9f03b106-a0b9-47c2-97b7-34c081287117@email.android.com> Cc: martini@ietf.org Subject: Re: [martini] Draft minutes from MARTINI Virtual Interim IV 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, 19 May 2010 06:58:17 -0000 Well, if you also looked at the slides that are part if the proceedings. I think the discussion will make more sense. -- Dean Willis "Cullen Jennings" wrote: > >Uh, these notes don't really make much sense to someone who was not there. Sorting out if I agree with proposal #1 or #3 for issue #15 is just not something I'm willing to go do. I'm not asking anyone to redo the minutes, I probably could figure it all out if I spent enough time but I'll just wait to comment on the drafts as that seems a better use of time. Just don't take my silence as agreement with anything that happened at the interim. > >On May 11, 2010, at 4:10 PM, Bernard Aboba wrote: > >> Minutes of Martini Virtual Interim IV >> April 29, 2010 >> >> Minute takers: David Hancock, Dean Willis >> >> Agenda bash: No changes to Agenda >> >> 1. Requirements discussion led by John Elwell >> >> Issue #39, explanatory text in Section 1. >> >> John Elwell - Do we keep issue #39, or does it go in a solutions draft (such as Olive)? >> >> Spencer prefers it stay in the requirements draft, since we're producing only one of these and it'll be easier to find. >> >> Discussion moved on while Hadriel reviewed text. On review, Hadriel believes the first paragraph is just wrong (Background on the Issues), and needs to be tailored to unique contacts, not unique AORs. Hadriel proposes removing this text. >> >> John Elwell: don't mind deleting it, but was asked to add it by Jon Peterson at IETF 77 mtg. Propose taking this to the list - and give reasons and get consensus to remove it. >> >> Spencer Dawkins: if list decides that it should be somewhere - would that place be the olive draft (or whatever document addresses solution for the 15/16 requirements). >> >> Hadriel Kaplan: the Olive draft does cover this already, so that's covered >> >> Issue #15, #16 non-E.164 and extensibility to any AOR >> >> 5 alternative paths have been proposed. John proposes #1 or #3 (nothing or add as desirable). >> >> Adam suggests 6th option to be phase 1 deliverable, with a plan to do a second phase 2 requirements document for phase 2 deliverables. >> >> Noted that several people from list supported adopting requirements as they stand. >> >> Discussion of 2 phase approach and meaning of requirements followed. >> >> Hadriel Kaplan: I thought these were desirable. At least 16 - the extensibility one. >> >> Dean Willis: we specifically excluded #15 for phase-1 - to limit to E.164 numbers. >> >> Keith Drage: if we do this - how do we meet/handle these requirement in the solutions draft? >> >> Adam Roach: by demonstrating in another draft (e.g., olive) how the extension could be supported. >> >> Spencer Dawkins: understand that everyone on group supports the requirement for non-e.164 numbers. >> >> John Elwell: yes, would like 15/16 to be supported eventually, just not in phase-1. >> >> Spencer Dawkins (as chair): would not want to ignore these. Should address them as required or desirable. So, should the working group continue advancing Olive? >> >> Martin Dolly: there was a contingent of folks that saw the need to address these now - as in phase-1. >> >> Dean Willis: does that mean stop working on GIN until we figure out how it can support 15/16. >> >> Martin Dolly: a requirement is a requirement. There is never a question of phasing requirements. If you choose to defer meeting a requirement, then it is still a requirement, just at a later date. >> >> Adam Roach: what I'm hearing is to reverse the MARTINI-II meeting agreement to limit phase-1 to E.164 numbers. >> >> Dean Willis: no, Martin is just saying these are requirements, we just need to decide schedule. >> >> Keith Drage: there is also a desire that these requirements can be supported by MARTINI GIN extension, and not a whole new solution. >> >> Bernard Aboba: The MARTINI charter specifically states that the solution must support E.164 numbers, and may support others. So those insisting that non-E.164 support is a requirement are effectively attempting to change the MARTINI WG charter after it was approved. >> >> John Elwell: adding a requirement that solution should be extensible is within charter. >> >> Dean Willis and Bernard Aboba: agree. >> >> Dean Willis: charter says must support E.164, may support others. >> >> John Elwell: am hearing that we add req's for 15 & 16, reworded to say soln "must be extensible". >> >> Spencer Dawkins, Adam Roach: agree. >> >> ** General Agreement - Add requirement(s) that the phase-1 solution must be extensible to support 15 & 16. >> >> ** General agreement -- Will take 15/16 & 39 to the list. >> >> 2. Adam - GIN slides >> >> Changes reviewed. >> >> Issue: Ticket 28 user=phone >> >> Proposed at IETF 77 to say that if pbx needs user=phone, it registers user=phone. >> >> Doug Sauder: The SSP is the one who knows whether this is a phone number or not, so it should be the one to add it. If you do option-1, you will then have trouble reconciling with Olive; for example, PBX specifies user=phone in REGISTER request, and at the same time wants to support non-E.164 numbers that wouldn't have user=phone >> >> Martin Dolly: AT&T expects to see user=phone on the INVITE and requires PBXes to support it. Since PBXes do not currently register, it is less certain. >> >> Hadriel Kaplan: noted that surrogate registration currently does NOT include user=phone. >> >> Adam Roach: I thought there were some implementations that required user=phone. >> >> Hadriel Kaplan: yes and there are some implementations that require it for E.164 numbers, and other implementations that ignore this parameter. >> >> Martin Dolly: there is a difference between not dropping a call, versus requiring it. >> >> Hadriel Kaplan: the problem the 1st option is that it is treating user=phone an opaque parameter in the contact. The problem is that it really isn't opaque - it has meaning in the INVITE. >> >> Someone: There is a 4th option, which is to let the SSP decide whether "user=phone" is required. >> >> Hadriel Kaplan: Noted that there is a 5th option, where user=phone is a feature of the registration. If you register with user=phone, you get only phone numbers; without you get all URIs. Some devices fail with user=phone, some require it. >> >> Extended discussion on contact routing, GRUU, etc, followed. >> >> Question: Is there any text suggesting that user=phone can be used in the current draft? >> >> Proposed that we pull user=phone out of the examples. >> >> Adam Roach: the fact is that this has caused so much confusion - the document should talk about it at least to say something. >> >> John Elwell: likes option-2 - let the SSP decide whether or not to put user=phone in request URI (based on what is stored in location db). The user=phone is really an extension of the user part, and since the user part is the expansion of the template provided in the bulk REGISTER Contact URI, the u=p parm should be >> configured in the SSP as part of that expansion. I.E. Whether it is there or not is based on provisioning. It's possible for two diff users to have an AOR - same E.164 - one with u=p and one without. >> >> How does this compare to a normal registration? If there is no user=phone on registered Contact and one comes back in the INVITE, what happens. (it depends...) >> >> Debate continued between Hadriel, Olle, John, and Adam. Then broadened. >> >> Doug Sauder: propose adding an indicator/parameter somewhere in the REGISTER indicating that the PBX requires user=phone for AORs containing E.164 numbers. Similar to option 1 , but PBX is making it explicit - I need a user=phone for E.164 numbers. >> >> Adam Roach/Hadriel Kaplan: this may be a good option. >> >> Martin Dolly: want to emphasize that user=phone is required. >> >> Adam Roach: this means that if you're testing a PBX in your lab that claims compliance with GIN (and we make proposed change), you would expect to see it indicate that it needs the user=phone parameter. >> >> Keith Drage: solution should state what is mandatory vs, optional for the PBX and SSP to support. Multiple people agree. >> >> >> ** Agreement -- Adam will propose text for this new user=phone option. >> >> Issue: Ticket #36 regevent handling >> >> Who serves the regevent subscription -- SSP or PBX? >> >> Question: Is the SSP knowledge ever useful information, or does it just show whether or not the PBX is online. Yes; there may be multiple registrations for a user at the SSP. >> >> Question: How does this apply to dialog event? >> >> Keith Drage: is there a use-case we have in mind, where the SSP needs to respond to reg-event when PBX is offline? And would it work any different than other packages such as dialog-event? Hadriel - the reg-event package routing is differently than other packages. The reg-event SUBSCRIBE is routed to the >> registrar of the AOR in the Request URI. Therefore, since the enterprise-user AORs belong to the SSP, the reg-event SUBSCRIBE is routed to the SSP. Having it go to the SSP makes sense -- say the target AOR can be registered simultaneously to the PBX and directly to the SSP. >> >> Adam Roach: case where same AOR is registered to the SSP directly, and to the PBX, is a corner case. >> >> Adam Roach: To header in REGISTER represents the PBX. You can subscribe reg-event to it to get its registration state. But if you subscribe to the actual >> enterprise user AOR, then you want the actual registration state on the PBX of the enterprise user. What if my phone is registered to two PBXs for redundancy? >> >> Adam Roach: this supports it - you get two separate answers. >> >> Hadriel Kaplan: reg-event SUBSCRIBE request URI is owned by the SSP - therefore the SSP should respond. It shouldn't goto the PBX. In fact there may be no registration at the PBX; e.g., the PBX supports non-SIP endpoints. >> >> Adam Roach: But sending the SWUBSCRIBE to the SSP doesn't provide any valuable information, since the it only reflects whether the PBX is registered or not, and 99.99% of the time it will be registered. >> >> Spencer Dawkins: suggest taking this to the list. Agreed. >> >> Issue: Other open tickets >> >> Final slide - need a volunteer for outbound analysis. Dean Willis suggests Paul Kyzivat. >> >> Spencer Dawkins & Bernard Aboba: will follow up with Paul and Cullen Jennings. >> >> 3. Hadriel Kaplan: Olive presentation >> >> Spencer Dawkins: had recently asked list about whether the result of bulk registration is the same as the result of multiple >> individual regitrations. Is the right place inside Olive? >> >> Keith Drage: this assumption is part of why gin is fundamentally broken; we need something that works differently from conventional contact-routing. Debate ensued; inconclusive. >> >> Keith Drage: we would have avoided the whole subscribe to reg-event if we had followed the IMS implicit registration model. >> >> Adam Roach, Dean Willis: no - the problem would still be there, basically because RFC 3261 does not have a good model for transitive registration, which is >> what both IMS and GIN bulk registration are. >> >> Dean Willis: this is still broken for reg-event. >> >> Adam Roach: agree. Solving it for GIN will solve it for olive as well. In fact Hadriel's solution is the GIN draft extended to non-164 numbers. >> >> Keith Drage: not sure if you would ever explicitly register a local number. In IMS it would only be implicitly registered. Register global explicitly, and register local implicitly. >> >> Hadriel Kaplan: but GIN is a compression/decompression rule for explicitly registrations. So what would an explicit registration of a local number look like? >> >> Keith Drage: where is the lack-of-uniqueness problem? >> >> Adam Roach: we were trying to make user-names globally unique to avoid the ambiguity that occurs when two PBXs have overlapping private numbers. >> >> Hadriel Kaplan: solves this problem by adding context to make local numbers unique. Problem is a PBX could have both a public and private numbers. There are two ways to handle this - either two separate logical trunks, or something in the actual URI portion that makes local numbers unique. >> >> 4. WG Chairs: next steps >> >> Spencer Dawkins: enumerates agreements for moving (disposition of issues 15,16,39, Paul Kyzivat and Cullen Jennings solicited for review of outbound, etc.) >> >> Keith Drage: is it possible for Hadriel to submit a draft-01 of Olive? >> >> Hadriel Kaplan: yes. >> >> Keith Drage: therefore we'll hold discussion until we see -01. >> >> John Elwell: reqs draft - assuming there is no pushback on 15,16,39 from list - are we going to progress the requirements draft? >> >> Bernard/Spencer: yes. Once we hafve no issues on the requirements document, we will progress it. >> >> Meeting adjourned... >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > >Cullen Jennings >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > >_______________________________________________ >martini mailing list >martini@ietf.org >https://www.ietf.org/mailman/listinfo/martini > From john.elwell@siemens-enterprise.com Wed May 19 00:49:44 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 63CB13A6B49 for ; Wed, 19 May 2010 00:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_40=-0.185, J_CHICKENPOX_45=0.6] 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 42o5OJ6hdFZx for ; Wed, 19 May 2010 00:49:43 -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 55B5D3A672E for ; Wed, 19 May 2010 00:45:47 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-216946; Wed, 19 May 2010 09:45:40 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id EA83423F028E; Wed, 19 May 2010 09:45:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 19 May 2010 09:45:40 +0200 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Wed, 19 May 2010 09:45:38 +0200 Thread-Topic: [martini] New GIN Draft Thread-Index: Acr20mtoBb6jTx3DT5mtxHQGQ6f8WwAU4DJg Message-ID: References: <4BF308BF.5030709@nostrum.com> In-Reply-To: <4BF308BF.5030709@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 Subject: Re: [martini] New GIN Draft 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, 19 May 2010 07:49:44 -0000 Although this might work, I view the autouser addition as probably going be= yond what is necessary. As I think I mentioned on the call, I tend to view the user=3D parameter as= an extension of the user part. So it should not be included in the Contact= URI of the REGISTER request, but should be included in the Request-URI of = inbound requests if the user-part requires it (e.g., user=3Dphone if the us= er part is a telephone-subscriber string) - this would be a matter for prov= isioning. I don't think this requires the autouser parameter. By the way, there seems to be some duplication of normative statements in -= 02: "A registrar that receives a URI with both a "bnc" parameter and a user portion MAY discard the user portion and process the the request as if it were not present. Alternately, the registrar MAY return a 400 (Bad Request) error in response." and later: "A registrar that receives such a URI MAY discard the "user" parameter and process the the request as if the parameter were not present. Alternately, it MAY return a 400 (Bad Request) error in response." Also both have a repeated "the". John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 18 May 2010 22:38 > To: martini@ietf.org > Subject: [martini] New GIN Draft >=20 > Based on the conversation we had about "user=3Dphone" at the=20 > most recent=20 > interim, I have put some strawman text into the GIN document. Please=20 > look at the revamped section 5 -- section 5.3, in particular=20 > -- in the=20 > new version, and let me know whether you have any concerns about this=20 > proposed resolution. >=20 > New version: > http://www.ietf.org/id/draft-ietf-martini-gin-02.txt >=20 > Diffs: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-martini-gin-02.txt >=20 > This version also removes ";user=3Dphone" from all the examples, as was=20 > proposed during the phone call. >=20 > The issue around registration remains open, and I'll be=20 > sending an email=20 > to the list shortly to discuss it. >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Wed May 19 01:25: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 9D2543A6B5A for ; Wed, 19 May 2010 01:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_50=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 AuLOV9OMCAar for ; Wed, 19 May 2010 01:25:29 -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 2CA2E3A6B64 for ; Wed, 19 May 2010 01:19:56 -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-218702; Wed, 19 May 2010 10:19:48 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6716B23F0278; Wed, 19 May 2010 10:19:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 19 May 2010 10:19:48 +0200 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Wed, 19 May 2010 10:19:46 +0200 Thread-Topic: [martini] Open Issue #36: GIN and "reg" event package Thread-Index: Acr210EPQpi1vSj1Q9aQRf40XhGClgAUYEsQ Message-ID: References: <4BF310DB.1000700@nostrum.com> In-Reply-To: <4BF310DB.1000700@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 Subject: Re: [martini] Open Issue #36: GIN and "reg" event package 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, 19 May 2010 08:25:30 -0000 Adam, I think leaving it open in this way seems reasonable. However, I was thinking about the case where a UA behind a PBX issues a reg= -event SUBSCRIBE to one of the PBX's telephone numbers. If it is targeted a= t sip:+12345@192.168.0.1, I guess it would be handled within the PBX. If it= is targeted at sip:+12345@ssp.com, it could either be handled within the P= BX or routed to the SSP. However, if routed to the SSP, the SSP might end u= p routing it back to the PBX. So, as part of provisioning, the PBX would ne= ed to know how to handle such a subscription. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 18 May 2010 23:13 > To: martini@ietf.org > Subject: [martini] Open Issue #36: GIN and "reg" event package >=20 > We're down to a fairly small number of open issues on GIN. >=20 > Currently, section 7.2.2 of the GIN document describes some fairly=20 > specific behavior for "reg" event handling. In particular, it=20 > says that=20 > subscriptions to the state of a single phone number are=20 > forwarded by the=20 > SSP to the PBX. There's some logic in the document about why=20 > I thought=20 > this was a Good Idea, and even "important." >=20 > At the most recent interim, we had a fairly long discussion about=20 > whether this was actually the "right" thing to do. Hadriel made some=20 > convincing arguments that the SSP should service the subscriptions,=20 > since it really "owns" the URIs in question. >=20 > The "vermouth" draft delves a bit deeper into some related=20 > issues, but=20 > it's somewhat less developed than GIN at this point. We don't want to=20 > make GIN dependent on vermouth, and we really can't leave a=20 > treatment of=20 > the "reg" event package out of GIN: GIN deals > intimately with registration. Under any reasonable "you break=20 > it you buy=20 > it" principle, we're on the hook for coming up with a sane=20 > treatment of=20 > the "reg" event package. >=20 > After an off-list exchange with Hadriel, I *think* we're both okay if=20 > that treatment is as simple as "here are the properties if=20 > you handle it=20 > at the SSP, here are the properties if you handle it at the PBX, and=20 > which you choose is a matter of policy." (I don't mean to put=20 > words in=20 > Hadriel's mouth, and I'm sure he'll correct me if my summary isn't=20 > consistent with his position). >=20 > This approach is actually pretty well in line with the way that event=20 > packages are handled in general. It also allows for some clever (if=20 > complicated) solutions to the problem in which the SSP services the=20 > subscription, but incorporates information it has learned=20 > from the PBX=20 > (say, through back-end subscriptions). Basically, it gets us back to=20 > what the IETF does well -- defining protocol mechanisms --=20 > while leaving=20 > concrete architectures up to other organizations. >=20 > Please comment on whether you think this is a reasonable way=20 > to address=20 > this open issue. If there is enough support, I'll craft some=20 > formal text=20 > and put it in GIN. >=20 > /a >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Wed May 19 01:34:09 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 A49B83A6929 for ; Wed, 19 May 2010 01:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_50=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 anwVDGCcazRC for ; Wed, 19 May 2010 01:34:07 -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 0DF303A6BB0 for ; Wed, 19 May 2010 01:29:17 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-217626; Wed, 19 May 2010 10:29:10 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6692223F0278; Wed, 19 May 2010 10:29:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 19 May 2010 10:29:10 +0200 From: "Elwell, John" To: Cullen Jennings , "martini@ietf.org" Date: Wed, 19 May 2010 10:29:08 +0200 Thread-Topic: [martini] GIN and anonymous GRUUS Thread-Index: Acr28ThEBaKdeR1KRMGL/x/txa4hVAAO935g Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> In-Reply-To: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.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] GIN and anonymous GRUUS 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, 19 May 2010 08:34:09 -0000 Cullen makes a good point. In general, MARTINI is targeted at small PBXs, s= o often an "anonymous" GRUU that still reveals the name of the business wil= l not be sufficient, since the number of users might be very small, they al= l might be located in the same office, and so on. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 19 May 2010 02:19 > To: martini@ietf.org > Subject: [martini] GIN and anonymous GRUUS >=20 >=20 > I think the anonymous public GRUUs need some work. Imagine=20 > that I have a small PBX at a women's shelter. Say they are 5=20 > to 10 phones or so and this PBX connects to an SSP. I think=20 > this is one of the use cases we need anonymous calls to work=20 > for and when someone makes a call from one of these phones,=20 > it can not reveal they are at the women's shelter.=20 > Anonymizing which room they are in at the women's shelter is=20 > not enough. I'll ignore the self make GRUU section because if=20 > you could to that, well you would not need GIN in the first place.=20 >=20 > Moving on to the Approach 2 - it seem that the PBX needs to=20 > get an anonymous GRUU from the SSP then use that to fabricate=20 > it's anonymous GRUU. I think that if you modified what you=20 > have in the draft now to use anonymous GRUUs from the SSP,=20 > you could get this to work.=20 >=20 > I think it would be worth adding an example showing an=20 > anonymous call. I know lots of people goes "who cares, that's=20 > a corner case" but many of the environments where we want to=20 > deploy GIN, it will be a requirement to support anonymous=20 > call - not many people need them but governments are pretty=20 > adamant about making sure the people who do need them can have them.=20 >=20 > Could you put a Note telling the RFC Ed to remove section 9.=20 > If anyone ever needs to read that they can find the draft.=20 >=20 > Nice draft - can't say I like it but I can live with it and I=20 > suspect most people will come to the same conclusion after=20 > thinking about it for awhile. Something most people can live=20 > with I view as huge success for this topic. It will be=20 > infinitely better than the current situation of many things=20 > that sounds close but when you look at them in detail don't=20 > interoperate.=20 >=20 > Thanks, Cullen >=20 >=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Wed May 19 01:43: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 53BAD3A6BA5 for ; Wed, 19 May 2010 01:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 jF97yQCt3h3M for ; Wed, 19 May 2010 01:43:06 -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 6D76C3A6B3A for ; Wed, 19 May 2010 01:38:52 -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-218151; Wed, 19 May 2010 10:38:44 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 61D2F1EB82AB; Wed, 19 May 2010 10:38:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 19 May 2010 10:38:44 +0200 From: "Elwell, John" To: Cullen Jennings , Bernard Aboba , Spencer Dawkins Date: Wed, 19 May 2010 10:38:43 +0200 Thread-Topic: [martini] #15: support for non E.164 numbers Thread-Index: Acr29QlALHSJZYPfTOagDWo51XoLhwAOOd8w Message-ID: References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> <074.ebb4a3094b410cb67bdf1424b8795605@tools.ietf.org> <122F1D6A-D3C5-4001-B6B5-46E5A1988A60@cisco.com> In-Reply-To: <122F1D6A-D3C5-4001-B6B5-46E5A1988A60@cisco.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" Subject: Re: [martini] #15: support for non E.164 numbers 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, 19 May 2010 08:43:07 -0000 Cullen, One thing about the tracker is that all messages on the mailing list relati= ng to a particular issue tend to have the issue number in the subject line,= e.g., #15 in this case (i.e., if the message came from the tracker or was = in reply to such a message). Furthermore, everything done on the tracker ge= ts automatically posted to the list (modulo a bug in the tracker a few week= s ago, that led to a few messages not appearing). So I really don't see how= use of the tracker makes things worse than the usual chaos on a mailing li= st. John =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 19 May 2010 02:45 > To: Bernard Aboba; Spencer Dawkins > Cc: martini@ietf.org > Subject: Re: [martini] #15: support for non E.164 numbers >=20 >=20 > I barely care about the proposed change but I will note that=20 > change take you outside the scope of your charter. I can't=20 > even figure out what the change is by reading the list=20 > traffic which suggests we have a serious problem in how we=20 > are using the tracker. Imagine the difficult of some new AD=20 > coming in a year from now to deal with an appeal and trying=20 > to figure out what was agreed to using the email archives=20 > only. I think we need to find a better way to use the tracker.=20 >=20 > On Apr 30, 2010, at 9:03 AM, martini issue tracker wrote: >=20 > > #15: support for non E.164 numbers > >=20 > -------------------------------------+------------------------ > -------------- > > Reporter: ietf.hanserik@... | Owner: =20 > > Type: defect | Status: reopened =20 > > Priority: critical | Milestone: milestone1 > > Component: reqs | Version: 1.0 =20 > > Severity: In WG Last Call | Resolution: =20 > > Keywords: | =20 > >=20 > -------------------------------------+------------------------ > -------------- > > Changes (by john.elwell@...): > >=20 > > * status: closed =3D> reopened > > * resolution: wontfix =3D> > >=20 > >=20 > > Comment: > >=20 > > Reopened due to ongoing discussion on the list. Discussion=20 > during the > > MARTINI interim meeting 2010-04-29 revealed support for=20 > accepting this > > change with rewording along the lines of "The mechanism=20 > MUST be extensible > > to allow..." (i.e. similar to ticket #16). If there are no=20 > objections I > > will close this as 'fixed' (subject to that wording change). > >=20 > > --=20 > > Ticket URL:=20 > > > martini > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From adam@nostrum.com Wed May 19 07:08: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 5A01D3A6847 for ; Wed, 19 May 2010 07:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.78 X-Spam-Level: X-Spam-Status: No, score=-0.78 tagged_above=-999 required=5 tests=[AWL=-1.380, BAYES_50=0.001, J_CHICKENPOX_45=0.6, 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 6aVDL53gQyAM for ; Wed, 19 May 2010 07:08:48 -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 12EFE3A690A for ; Wed, 19 May 2010 07:08:47 -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 o4JE8cGR091643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 09:08:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF3F0E6.8090603@nostrum.com> Date: Wed, 19 May 2010 09:08:38 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Elwell, John" References: <4BF308BF.5030709@nostrum.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] New GIN Draft 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, 19 May 2010 14:08:49 -0000 On 5/19/10 2:45 AM, Elwell, John wrote: > Although this might work, I view the autouser addition as probably going beyond what is necessary. > > As I think I mentioned on the call, I tend to view the user= parameter as an extension of the user part. So it should not be included in the Contact URI of the REGISTER request, but should be included in the Request-URI of inbound requests if the user-part requires it (e.g., user=phone if the user part is a telephone-subscriber string) - this would be a matter for provisioning. I don't think this requires the autouser parameter. I'm happy to take things that way also, but it's not what I heard people supporting on the call. As I said in my slides, I think this issue is bike-shed painting of the worst kind. I really, *really* don't think it matters which of the six or seven options we discussed are selected -- they all work -- but we *need* to choose one and move forward. > By the way, there seems to be some duplication of normative statements in -02: > "A registrar that receives a URI with both a "bnc" parameter and a > user portion MAY discard the user portion and process the the request > as if it were not present. Alternately, the registrar MAY return a > 400 (Bad Request) error in response." > and later: > "A registrar that receives such a > URI MAY discard the "user" parameter and process the the request as > if the parameter were not present. Alternately, it MAY return a 400 > (Bad Request) error in response." > They're different statements. The first one talks about the "user portion" of a URI: sip:2145551212@nostrum.com;user=phone ^^^^^^^^^^ While the second one talks about the "user parameter" of a URI: sip:2145551212@nostrum.com;user=phone ^^^^^^^^^^ I can see how that is a bit confusing, but don't know how to make it crystal clear that we're talking about different things. I would have hoped that the context of the text that comes immediately before those statements would have helped people recognize the URI component under discussion. Since the existing text wasn't clear enough to avoid your confusion, can you propose some text that would make this clearer? > Also both have a repeated "the". Good catch. I'll fix that. /a From adam@nostrum.com Wed May 19 07:19:53 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 A66953A6C61 for ; Wed, 19 May 2010 07:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.056 X-Spam-Level: X-Spam-Status: No, score=-1.056 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_50=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 Zy6TYJU3fp0i for ; Wed, 19 May 2010 07:19: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 C61A93A6BEF for ; Wed, 19 May 2010 07:17:44 -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 o4JEHWZj092375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 09:17:32 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF3F2FC.8090609@nostrum.com> Date: Wed, 19 May 2010 09:17:32 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Elwell, John" References: <94280B93-31C5-49A6-A086-7297F14DE00A@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 and anonymous GRUUS 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, 19 May 2010 14:19:54 -0000 I'm sympathetic to the point, but don't think it's something that MARTINI can appropriately solve. What's critical here is to realize that GIN does not make this problem any better or worse than the base GRUU mechanism. For example, in a "normal" (i.e., 3263-routed, GIN-free) environment, imagine you came into possession of a temp GRUU "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat.com". And, after a little research, you determine that the company does, in fact, consist of exactly two guys and their goat. You can be pretty certain that the call came from one of the two guys who comprise the company (unless the goat is really quite talented). So, yeah, it's a shortcoming of GRUUs in general. If you want to solve this problem, what is really needed is for you to take an rfc5627bis to DISPATCH. But I think it's a bit of a stretch to say "GRUUs as currently defined have this shortcoming. You mentioned GRUUs, and in doing so, inherited the shortcoming. Now fix it!" /a On 5/19/10 3:29 AM, Elwell, John wrote: > Cullen makes a good point. In general, MARTINI is targeted at small PBXs, so often an "anonymous" GRUU that still reveals the name of the business will not be sufficient, since the number of users might be very small, they all might be located in the same office, and so on. > > John > > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: 19 May 2010 02:19 >> To: martini@ietf.org >> Subject: [martini] GIN and anonymous GRUUS >> >> >> I think the anonymous public GRUUs need some work. Imagine >> that I have a small PBX at a women's shelter. Say they are 5 >> to 10 phones or so and this PBX connects to an SSP. I think >> this is one of the use cases we need anonymous calls to work >> for and when someone makes a call from one of these phones, >> it can not reveal they are at the women's shelter. >> Anonymizing which room they are in at the women's shelter is >> not enough. I'll ignore the self make GRUU section because if >> you could to that, well you would not need GIN in the first place. >> >> Moving on to the Approach 2 - it seem that the PBX needs to >> get an anonymous GRUU from the SSP then use that to fabricate >> it's anonymous GRUU. I think that if you modified what you >> have in the draft now to use anonymous GRUUs from the SSP, >> you could get this to work. >> >> I think it would be worth adding an example showing an >> anonymous call. I know lots of people goes "who cares, that's >> a corner case" but many of the environments where we want to >> deploy GIN, it will be a requirement to support anonymous >> call - not many people need them but governments are pretty >> adamant about making sure the people who do need them can have them. >> >> Could you put a Note telling the RFC Ed to remove section 9. >> If anyone ever needs to read that they can find the draft. >> >> Nice draft - can't say I like it but I can live with it and I >> suspect most people will come to the same conclusion after >> thinking about it for awhile. Something most people can live >> with I view as huge success for this topic. It will be >> infinitely better than the current situation of many things >> that sounds close but when you look at them in detail don't >> interoperate. >> >> Thanks, Cullen >> >> >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> _______________________________________________ >> 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 john.elwell@siemens-enterprise.com Wed May 19 07:26:41 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 3C2573A6BB0 for ; Wed, 19 May 2010 07:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_50=0.001, J_CHICKENPOX_45=0.6] 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 maP1VCOYpT1l for ; Wed, 19 May 2010 07:26:40 -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 73B773A6C4F for ; Wed, 19 May 2010 07:23:07 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-224150; Wed, 19 May 2010 16:22:48 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EFB311EB82AB; Wed, 19 May 2010 16:22:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 19 May 2010 16:22:48 +0200 From: "Elwell, John" To: Adam Roach Date: Wed, 19 May 2010 16:22:45 +0200 Thread-Topic: [martini] New GIN Draft Thread-Index: Acr3XMqR2fzHQpczRBalIzBSmzHuqQAAX/6A Message-ID: References: <4BF308BF.5030709@nostrum.com> <4BF3F0E6.8090603@nostrum.com> In-Reply-To: <4BF3F0E6.8090603@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: "martini@ietf.org" Subject: Re: [martini] New GIN Draft 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, 19 May 2010 14:26:41 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 19 May 2010 15:09 > To: Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] New GIN Draft >=20 > On 5/19/10 2:45 AM, Elwell, John wrote: > > Although this might work, I view the autouser addition as=20 > probably going beyond what is necessary. > > > > As I think I mentioned on the call, I tend to view the=20 > user=3D parameter as an extension of the user part. So it=20 > should not be included in the Contact URI of the REGISTER=20 > request, but should be included in the Request-URI of inbound=20 > requests if the user-part requires it (e.g., user=3Dphone if=20 > the user part is a telephone-subscriber string) - this would=20 > be a matter for provisioning. I don't think this requires the=20 > autouser parameter. >=20 > I'm happy to take things that way also, but it's not what I=20 > heard people=20 > supporting on the call. >=20 > As I said in my slides, I think this issue is bike-shed=20 > painting of the=20 > worst kind. I really, *really* don't think it matters which=20 > of the six=20 > or seven options we discussed are selected -- they all work -- but we=20 > *need* to choose one and move forward. [JRE] I agree, so I would have preferred the simpler solution (without the = autouser parameter), but it that is what others want I can live with it. >=20 >=20 > > By the way, there seems to be some duplication of normative=20 > statements in -02: > > "A registrar that receives a URI with both a "bnc" parameter and a > > user portion MAY discard the user portion and process=20 > the the request > > as if it were not present. Alternately, the registrar=20 > MAY return a > > 400 (Bad Request) error in response." > > and later: > > "A registrar that receives such a > > URI MAY discard the "user" parameter and process the=20 > the request as > > if the parameter were not present. Alternately, it MAY=20 > return a 400 > > (Bad Request) error in response." > > >=20 > They're different statements. The first one talks about the "user=20 > portion" of a URI: >=20 > sip:2145551212@nostrum.com;user=3Dphone > ^^^^^^^^^^ >=20 > While the second one talks about the "user parameter" of a URI: >=20 > sip:2145551212@nostrum.com;user=3Dphone > ^^^^^^^^^^ >=20 > I can see how that is a bit confusing, but don't know how to make it=20 > crystal clear that we're talking about different things. I would have=20 > hoped that the context of the text that comes immediately=20 > before those=20 > statements would have helped people recognize the URI component under=20 > discussion. Since the existing text wasn't clear enough to avoid your=20 > confusion, can you propose some text that would make this clearer? [JRE] Sorry, my careless reading. No need to change. John >=20 > > Also both have a repeated "the". >=20 > Good catch. I'll fix that. >=20 > /a > = From john.elwell@siemens-enterprise.com Wed May 19 07:32:32 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 9FE043A69E1 for ; Wed, 19 May 2010 07:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.788, 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 ZBbzivun+LbF for ; Wed, 19 May 2010 07:32: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 EA3B03A67B7 for ; Wed, 19 May 2010 07:32:28 -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-225533; Wed, 19 May 2010 16:32:21 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id F254923F0278; Wed, 19 May 2010 16:32:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 19 May 2010 16:32:21 +0200 From: "Elwell, John" To: Adam Roach Date: Wed, 19 May 2010 16:32:18 +0200 Thread-Topic: [martini] GIN and anonymous GRUUS Thread-Index: Acr3Xgp7n3/1kAJlS5yDcKb52i+EyQAAcrzA Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> In-Reply-To: <4BF3F2FC.8090609@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: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 19 May 2010 14:32:32 -0000 Adam, Although I was generalising the use case that Cullen put forward, doesn't t= he existing approach 2 satisfy this anyway? John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 19 May 2010 15:18 > To: Elwell, John > Cc: Cullen Jennings; martini@ietf.org > Subject: Re: [martini] GIN and anonymous GRUUS >=20 > I'm sympathetic to the point, but don't think it's something that=20 > MARTINI can appropriately solve. What's critical here is to=20 > realize that=20 > GIN does not make this problem any better or worse than the base GRUU=20 > mechanism. >=20 > For example, in a "normal" (i.e., 3263-routed, GIN-free) environment,=20 > imagine you came into possession of a temp GRUU=20 > "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat. > com". And,=20 > after a little research, you determine that the company does,=20 > in fact,=20 > consist of exactly two guys and their goat. You can be pretty certain=20 > that the call came from one of the two guys who comprise the company=20 > (unless the goat is really quite talented). >=20 > So, yeah, it's a shortcoming of GRUUs in general. If you want=20 > to solve=20 > this problem, what is really needed is for you to take an=20 > rfc5627bis to=20 > DISPATCH. >=20 > But I think it's a bit of a stretch to say "GRUUs as=20 > currently defined=20 > have this shortcoming. You mentioned GRUUs, and in doing so,=20 > inherited=20 > the shortcoming. Now fix it!" >=20 > /a >=20 > On 5/19/10 3:29 AM, Elwell, John wrote: > > Cullen makes a good point. In general, MARTINI is targeted=20 > at small PBXs, so often an "anonymous" GRUU that still=20 > reveals the name of the business will not be sufficient,=20 > since the number of users might be very small, they all might=20 > be located in the same office, and so on. > > > > John > > > > =20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings > >> Sent: 19 May 2010 02:19 > >> To: martini@ietf.org > >> Subject: [martini] GIN and anonymous GRUUS > >> > >> > >> I think the anonymous public GRUUs need some work. Imagine > >> that I have a small PBX at a women's shelter. Say they are 5 > >> to 10 phones or so and this PBX connects to an SSP. I think > >> this is one of the use cases we need anonymous calls to work > >> for and when someone makes a call from one of these phones, > >> it can not reveal they are at the women's shelter. > >> Anonymizing which room they are in at the women's shelter is > >> not enough. I'll ignore the self make GRUU section because if > >> you could to that, well you would not need GIN in the first place. > >> > >> Moving on to the Approach 2 - it seem that the PBX needs to > >> get an anonymous GRUU from the SSP then use that to fabricate > >> it's anonymous GRUU. I think that if you modified what you > >> have in the draft now to use anonymous GRUUs from the SSP, > >> you could get this to work. > >> > >> I think it would be worth adding an example showing an > >> anonymous call. I know lots of people goes "who cares, that's > >> a corner case" but many of the environments where we want to > >> deploy GIN, it will be a requirement to support anonymous > >> call - not many people need them but governments are pretty > >> adamant about making sure the people who do need them can=20 > have them. > >> > >> Could you put a Note telling the RFC Ed to remove section 9. > >> If anyone ever needs to read that they can find the draft. > >> > >> Nice draft - can't say I like it but I can live with it and I > >> suspect most people will come to the same conclusion after > >> thinking about it for awhile. Something most people can live > >> with I view as huge success for this topic. It will be > >> infinitely better than the current situation of many things > >> that sounds close but when you look at them in detail don't > >> interoperate. > >> > >> Thanks, Cullen > >> > >> > >> > >> > >> Cullen Jennings > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > >> > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > >> =20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > =20 >=20 > = From spencer@wonderhamster.org Wed May 19 07:48:31 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 4BC4A3A6C33 for ; Wed, 19 May 2010 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_50=0.001, 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 pwYDSnzhtDzk for ; Wed, 19 May 2010 07:48:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 8E2D23A6C75 for ; Wed, 19 May 2010 07:43:15 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MHGpv-1O0fzX1Tmd-00DFmb; Wed, 19 May 2010 10:42:35 -0400 Message-ID: <35AD2908525D4803BCB57FBAADBC0E20@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "Adam Roach" References: <4BF308BF.5030709@nostrum.com><4BF3F0E6.8090603@nostrum.com> Date: Wed, 19 May 2010 09:42:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Provags-ID: V01U2FsdGVkX19C4bX71C/IeiMx0byt6r5Gy6MZr4/avo1Yrxu DTQNAdUUzSYdjhAgSUHXoC6gsuZJnanu7kE9zRcnrWS+L28uTh j8OUAbGOyqG4WdPfs2HBzDxtluFAqZLGppd3stfgv0= Cc: martini@ietf.org Subject: Re: [martini] New GIN Draft 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, 19 May 2010 14:48:31 -0000 Speaking as co-chair (first time this week - I feel like I've been slacking off)... >> > By the way, there seems to be some duplication of normative >> statements in -02: >> > "A registrar that receives a URI with both a "bnc" parameter and a >> > user portion MAY discard the user portion and process >> the the request >> > as if it were not present. Alternately, the registrar >> MAY return a >> > 400 (Bad Request) error in response." >> > and later: >> > "A registrar that receives such a >> > URI MAY discard the "user" parameter and process the >> the request as >> > if the parameter were not present. Alternately, it MAY >> return a 400 >> > (Bad Request) error in response." >> > >> >> They're different statements. The first one talks about the "user >> portion" of a URI: >> >> sip:2145551212@nostrum.com;user=phone >> ^^^^^^^^^^ >> >> While the second one talks about the "user parameter" of a URI: >> >> sip:2145551212@nostrum.com;user=phone >> ^^^^^^^^^^ >> >> I can see how that is a bit confusing, but don't know how to make it >> crystal clear that we're talking about different things. I would have >> hoped that the context of the text that comes immediately >> before those >> statements would have helped people recognize the URI component under >> discussion. Since the existing text wasn't clear enough to avoid your >> confusion, can you propose some text that would make this clearer? > [JRE] Sorry, my careless reading. No need to change. I'm getting what Adam is saying, but I'm thinking that if this fuzzballed John Elwell, that will be a problem when GIN goes for wider review. What helped ME (and, perhaps, John) was the two examples that Adam provided. Ordinarily, I wouldn't suggest including them, but I'm thinking that we'll have this conversations multiple times with various ADs, review teams, and other members of the RAI community who are busy - so would it be wrong if Adam added the examples to the text, just so everyone has that clue on first reading? Thanks, Spencer, as co-chair From adam@nostrum.com Wed May 19 08:15:53 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 392153A6944 for ; Wed, 19 May 2010 08:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, SPF_PASS=-0.001, URI_HEX=0.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 QXpoijwAHIcp for ; Wed, 19 May 2010 08:15: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 384D73A6A3F for ; Wed, 19 May 2010 08:15:00 -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 o4JFEmQq096834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 10:14:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF40068.3020502@nostrum.com> Date: Wed, 19 May 2010 10:14:48 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Elwell, John" References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.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 and anonymous GRUUS 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, 19 May 2010 15:15:53 -0000 Actually, you're right. I just re-read the "anonymous public GRUU" section again, and it doesn't reveal the information that we're fretting about. (I also found a minor error in some of the examples, but I'm fixing that in -03). The example that the document gives for one of these GRUUs looks like this: sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P Going to Cullen's concern: if I got one of these URIs, it's not clear what part of that I could mine to find out whether it was a Women's Shelter (unless example.com has precisely one customer, in which case I don't think there's anything we can do anyway). Cullen: can you elaborate on your use case, providing specific examples of the URIs that you think leak information? /a On 5/19/10 9:32 AM, Elwell, John wrote: > Adam, > > Although I was generalising the use case that Cullen put forward, doesn't the existing approach 2 satisfy this anyway? > > John > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 19 May 2010 15:18 >> To: Elwell, John >> Cc: Cullen Jennings; martini@ietf.org >> Subject: Re: [martini] GIN and anonymous GRUUS >> >> I'm sympathetic to the point, but don't think it's something that >> MARTINI can appropriately solve. What's critical here is to >> realize that >> GIN does not make this problem any better or worse than the base GRUU >> mechanism. >> >> For example, in a "normal" (i.e., 3263-routed, GIN-free) environment, >> imagine you came into possession of a temp GRUU >> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat. >> com". And, >> after a little research, you determine that the company does, >> in fact, >> consist of exactly two guys and their goat. You can be pretty certain >> that the call came from one of the two guys who comprise the company >> (unless the goat is really quite talented). >> >> So, yeah, it's a shortcoming of GRUUs in general. If you want >> to solve >> this problem, what is really needed is for you to take an >> rfc5627bis to >> DISPATCH. >> >> But I think it's a bit of a stretch to say "GRUUs as >> currently defined >> have this shortcoming. You mentioned GRUUs, and in doing so, >> inherited >> the shortcoming. Now fix it!" >> >> /a >> >> On 5/19/10 3:29 AM, Elwell, John wrote: >> >>> Cullen makes a good point. In general, MARTINI is targeted >>> >> at small PBXs, so often an "anonymous" GRUU that still >> reveals the name of the business will not be sufficient, >> since the number of users might be very small, they all might >> be located in the same office, and so on. >> >>> John >>> >>> >>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org >>>> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings >>>> Sent: 19 May 2010 02:19 >>>> To: martini@ietf.org >>>> Subject: [martini] GIN and anonymous GRUUS >>>> >>>> >>>> I think the anonymous public GRUUs need some work. Imagine >>>> that I have a small PBX at a women's shelter. Say they are 5 >>>> to 10 phones or so and this PBX connects to an SSP. I think >>>> this is one of the use cases we need anonymous calls to work >>>> for and when someone makes a call from one of these phones, >>>> it can not reveal they are at the women's shelter. >>>> Anonymizing which room they are in at the women's shelter is >>>> not enough. I'll ignore the self make GRUU section because if >>>> you could to that, well you would not need GIN in the first place. >>>> >>>> Moving on to the Approach 2 - it seem that the PBX needs to >>>> get an anonymous GRUU from the SSP then use that to fabricate >>>> it's anonymous GRUU. I think that if you modified what you >>>> have in the draft now to use anonymous GRUUs from the SSP, >>>> you could get this to work. >>>> >>>> I think it would be worth adding an example showing an >>>> anonymous call. I know lots of people goes "who cares, that's >>>> a corner case" but many of the environments where we want to >>>> deploy GIN, it will be a requirement to support anonymous >>>> call - not many people need them but governments are pretty >>>> adamant about making sure the people who do need them can >>>> >> have them. >> >>>> Could you put a Note telling the RFC Ed to remove section 9. >>>> If anyone ever needs to read that they can find the draft. >>>> >>>> Nice draft - can't say I like it but I can live with it and I >>>> suspect most people will come to the same conclusion after >>>> thinking about it for awhile. Something most people can live >>>> with I view as huge success for this topic. It will be >>>> infinitely better than the current situation of many things >>>> that sounds close but when you look at them in detail don't >>>> interoperate. >>>> >>>> Thanks, Cullen >>>> >>>> >>>> >>>> >>>> Cullen Jennings >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Wed May 19 08:32: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 272C23A6944 for ; Wed, 19 May 2010 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=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 AR+kzxn6JyuT for ; Wed, 19 May 2010 08:32:11 -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 F083C3A6861 for ; Wed, 19 May 2010 08:32:10 -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 o4JFW1xK098252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 10:32:01 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF40471.9080109@nostrum.com> Date: Wed, 19 May 2010 10:32:01 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> In-Reply-To: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.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" Subject: Re: [martini] GIN and anonymous GRUUS 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, 19 May 2010 15:32:12 -0000 On 5/18/10 8:18 PM, Cullen Jennings wrote: > I'll ignore the self make GRUU section because if you could to that, well you would not need GIN in the first place. I'm not so certain that's true. The only thing that would preclude this use case in normal situations would the the presence of an intervening NAT. And, while that's actually pretty common, I would argue that it's not 100% universal in SOHO deployments. I can still pay my DSL provider for 5 public IP addresses if I so desire (it's actually a /29, but you lose three addresses to network, broadcast, and router). It's not far-fetched to imagine situations where I've done that, but still want to use an SSP for my VoIP needs. And, if the SSP is only willing to do SIP trunking using a dynamic registration scheme, then I'll have to use GIN or something similar. Does this work everywhere? No, of course not. Some people will put their PBXes behind NATs. Will there be enough situations where this works to make it worthwhile mentioning? Yeah, I think so -- especially when we move to IPv6. (This isn't a pipe-dream anymore. Comcast is in trials, and plans system-wide roll-out by 2012. I've seen rumors that they're doing proper subnet delegation -- at least for one of three variations they're trialing -- meaning customers will have several thousand routable addresses instead of the 5 I mention.) /a From adam@nostrum.com Wed May 19 08:43:28 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 5DD1C3A6BD0 for ; Wed, 19 May 2010 08:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.277, 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 uPiaoulrBcEX for ; Wed, 19 May 2010 08:43:27 -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 2114A3A6B97 for ; Wed, 19 May 2010 08:42:21 -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 o4JFgDvm099154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 10:42:13 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF406D5.1010000@nostrum.com> Date: Wed, 19 May 2010 10:42:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Spencer Dawkins References: <4BF308BF.5030709@nostrum.com><4BF3F0E6.8090603@nostrum.com> <35AD2908525D4803BCB57FBAADBC0E20@china.huawei.com> In-Reply-To: <35AD2908525D4803BCB57FBAADBC0E20@china.huawei.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 Subject: Re: [martini] New GIN Draft 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, 19 May 2010 15:43:28 -0000 On 5/19/10 9:42 AM, Spencer Dawkins wrote: > ... > I'm getting what Adam is saying, but I'm thinking that if this > fuzzballed John Elwell, that will be a problem when GIN goes for wider > review. What helped ME (and, perhaps, John) was the two examples that > Adam provided. Ordinarily, I wouldn't suggest including them, but I'm > thinking that we'll have this conversations multiple times with > various ADs, review teams, and other members of the RAI community who > are busy - so would it be wrong if Adam added the examples to the > text, just so everyone has that clue on first reading? I've added it to my draft for the sake of clarity. It will appear in the -03 version. /a From adam@nostrum.com Wed May 19 08:44:39 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 A555D3A659A for ; Wed, 19 May 2010 08:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.273, 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 vKjr38vGhzs2 for ; Wed, 19 May 2010 08:44:38 -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 ADA2F3A69A4 for ; Wed, 19 May 2010 08:44:33 -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 o4JFiNes099298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 10:44:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF40757.1040009@nostrum.com> Date: Wed, 19 May 2010 10:44:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> In-Reply-To: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.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" Subject: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 19 May 2010 15:44:39 -0000 On 5/18/10 8:18 PM, Cullen Jennings wrote: > Could you put a Note telling the RFC Ed to remove section 9. If anyone ever needs to read that they can find the draft. > I'm indifferent as to whether it stays in. Does anyone object to removing it? /a From md3135@att.com Wed May 19 08:46: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 F00033A68C5 for ; Wed, 19 May 2010 08:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.389 X-Spam-Level: X-Spam-Status: No, score=-106.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Maglg9l85qzK for ; Wed, 19 May 2010 08:46:07 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id AB4073A68CC for ; Wed, 19 May 2010 08:46:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-11.tower-161.messagelabs.com!1274283957!6798264!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 2911 invoked from network); 19 May 2010 15:45:58 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 May 2010 15:45:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4JFjd4n006034 for ; Wed, 19 May 2010 11:45:39 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4JFjZbX005967 for ; Wed, 19 May 2010 11:45:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 May 2010 11:45:52 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <4BF40757.1040009@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] GIN: Removing Section 9 (Requirements Analysis)? Thread-Index: Acr3ajQ12Bplr9AOQDaW6O93HBdBqAAABVbg References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> From: "DOLLY, MARTIN C (ATTLABS)" To: "Adam Roach" , "Cullen Jennings" Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 19 May 2010 15:46:08 -0000 They can find it where? please -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Wednesday, May 19, 2010 11:44 AM To: Cullen Jennings Cc: martini@ietf.org Subject: [martini] GIN: Removing Section 9 (Requirements Analysis)? On 5/18/10 8:18 PM, Cullen Jennings wrote: > Could you put a Note telling the RFC Ed to remove section 9. If anyone ever needs to read that they can find the draft. > =20 I'm indifferent as to whether it stays in. Does anyone object to=20 removing it? /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Wed May 19 08:58:29 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 228CC3A6BAE for ; Wed, 19 May 2010 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.269, 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 GHz6kdgn91sz for ; Wed, 19 May 2010 08:58:28 -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 5C8AF3A6A46 for ; Wed, 19 May 2010 08:58:26 -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 o4JFwE2m000524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 10:58:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF40A96.3040600@nostrum.com> Date: Wed, 19 May 2010 10:58:14 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.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" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 19 May 2010 15:58:29 -0000 I'm not sure the question is whether the information can be found later, as much as whether it's useful as an artifact. Sure, we need to make sure the solution satisfies the requirements document -- but does it make sense to include that analysis in the RFC? Like I said, I don't really care one way or another. But I do want to make sure we're focusing on the right question here: "is this information useful to retain?" Being able to find useless information at a future date is pretty inconsequential. /a On 5/19/10 10:45 AM, DOLLY, MARTIN C (ATTLABS) wrote: > They can find it where? please > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Wednesday, May 19, 2010 11:44 AM > To: Cullen Jennings > Cc: martini@ietf.org > Subject: [martini] GIN: Removing Section 9 (Requirements Analysis)? > > On 5/18/10 8:18 PM, Cullen Jennings wrote: > >> Could you put a Note telling the RFC Ed to remove section 9. If anyone >> > ever needs to read that they can find the draft. > >> >> > I'm indifferent as to whether it stays in. Does anyone object to > removing it? > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From spencer@wonderhamster.org Wed May 19 09:41:51 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 E66D53A6C22 for ; Wed, 19 May 2010 09:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_50=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 Y7t-dQGaEfS7 for ; Wed, 19 May 2010 09:41:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id B83A13A692D for ; Wed, 19 May 2010 09:41:49 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lxh11-1NE2gb3a27-016pIO; Wed, 19 May 2010 12:41:42 -0400 Message-ID: <8A5604DC38944987832B5F196565F28F@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" References: <4BF308BF.5030709@nostrum.com><4BF3F0E6.8090603@nostrum.com> <35AD2908525D4803BCB57FBAADBC0E20@china.huawei.com> <4BF406D5.1010000@nostrum.com> Date: Wed, 19 May 2010 11:41:32 -0500 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: V01U2FsdGVkX1+YPvuJjL0rqs5G4rLqSPOCOodtBPcuqUOIfwE TYHeBf+erwtELcN1QFzMaG+i+riTo/isJm6VXwFKPAIObwkPty 3BPzvzfQAn1SLScd6nkeBGNJjer7G5Ck35QjCH6RW4= Cc: martini@ietf.org Subject: Re: [martini] New GIN Draft 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, 19 May 2010 16:41:52 -0000 Adam, Thanks! >> I'm getting what Adam is saying, but I'm thinking that if this >> fuzzballed John Elwell, that will be a problem when GIN goes for wider >> review. What helped ME (and, perhaps, John) was the two examples that >> Adam provided. Ordinarily, I wouldn't suggest including them, but I'm >> thinking that we'll have this conversations multiple times with >> various ADs, review teams, and other members of the RAI community who >> are busy - so would it be wrong if Adam added the examples to the >> text, just so everyone has that clue on first reading? > > I've added it to my draft for the sake of clarity. It will appear in the > -03 version. Spencer From pkyzivat@cisco.com Wed May 19 09:46: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 557A53A6818 for ; Wed, 19 May 2010 09:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.658 X-Spam-Level: X-Spam-Status: No, score=-8.658 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_50=0.001, J_CHICKENPOX_38=0.6, 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 8jij4K1cTsiJ for ; Wed, 19 May 2010 09:46:23 -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 62DE03A6893 for ; Wed, 19 May 2010 09:46:22 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,264,1272844800"; d="scan'208";a="112587121" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 May 2010 16:46:15 +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 o4JGkErM010937; Wed, 19 May 2010 16:46:15 GMT Message-ID: <4BF415C9.7040508@cisco.com> Date: Wed, 19 May 2010 12:46:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: <9579A5DE-F6F2-4717-AA1F-4AD0951C9611@cisco.com> In-Reply-To: <9579A5DE-F6F2-4717-AA1F-4AD0951C9611@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] Review of GIN and outbound interaction 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, 19 May 2010 16:46:24 -0000 Cullen Jennings wrote: > 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. Anything that uses callerprefs based on sip.instance in an attempt to select a particular phone will be problematic. It *could* still work, using a preference for the sip.instance value the actual UA registered with the pbx. But how the caller would ever learn about that is a little hard to see. I guess the reg event package, if handled by the pbx, would provide it. But picking it out of the remote contact from a prior call won't work as things are currently defined. But whether the call would even make it to the pbx will depend on how the preference criteria are framed. Done wrong and the call will be rejected at the SSP. Callerprefs by instance id has always been problematic. GRUUs are a better solution to that. Thanks, Paul > 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 > > > > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From christer.holmberg@ericsson.com Wed May 19 09:46:58 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 AAFBF3A6847 for ; Wed, 19 May 2010 09:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=-0.632, 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 3seS1ZBag53q for ; Wed, 19 May 2010 09:46:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6F9903A6818 for ; Wed, 19 May 2010 09:46:57 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-d2-4bf415f9f7a2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C0.A6.21861.9F514FB4; Wed, 19 May 2010 18:46:49 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 19 May 2010 18:46:49 +0200 From: Christer Holmberg To: Adam Roach , "DOLLY, MARTIN C (ATTLABS)" Date: Wed, 19 May 2010 18:45:37 +0200 Thread-Topic: [martini] GIN: Removing Section 9 (Requirements Analysis)? Thread-Index: Acr3bChHq5OB6zNsQ9a4NupL48qRJgABo06/ Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com>, <4BF40A96.3040600@nostrum.com> In-Reply-To: <4BF40A96.3040600@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-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 19 May 2010 16:46:58 -0000 Hi, I don't have any strong opinions regarding the actual analysis, but I think= it at least should be indicated that the draft fulfills all requirements i= n the req draft. Regards, Christer ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Adam= Roach [adam@nostrum.com] Sent: Wednesday, May 19, 2010 6:58 PM To: DOLLY, MARTIN C (ATTLABS) Cc: martini@ietf.org Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? I'm not sure the question is whether the information can be found later, as much as whether it's useful as an artifact. Sure, we need to make sure the solution satisfies the requirements document -- but does it make sense to include that analysis in the RFC? Like I said, I don't really care one way or another. But I do want to make sure we're focusing on the right question here: "is this information useful to retain?" Being able to find useless information at a future date is pretty inconsequential. /a On 5/19/10 10:45 AM, DOLLY, MARTIN C (ATTLABS) wrote: > They can find it where? please > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Wednesday, May 19, 2010 11:44 AM > To: Cullen Jennings > Cc: martini@ietf.org > Subject: [martini] GIN: Removing Section 9 (Requirements Analysis)? > > On 5/18/10 8:18 PM, Cullen Jennings wrote: > >> Could you put a Note telling the RFC Ed to remove section 9. If anyone >> > ever needs to read that they can find the draft. > >> >> > I'm indifferent as to whether it stays in. Does anyone object to > removing it? > > /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 spencer@wonderhamster.org Wed May 19 10:11:54 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 9FB243A6B62 for ; Wed, 19 May 2010 10:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_40=-0.185, 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 4LE9aa299kmJ for ; Wed, 19 May 2010 10:11:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id B84163A6B8E for ; Wed, 19 May 2010 10:11:05 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MKHde-1OEEok0Hyw-001NEM; Wed, 19 May 2010 13:10:16 -0400 Message-ID: From: "Spencer Dawkins" To: "Christer Holmberg" , "Adam Roach" , "DOLLY, MARTIN C \(ATTLABS\)" References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com><4BF40757.1040009@nostrum.com><14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com>, <4BF40A96.3040600@nostrum.com> Date: Wed, 19 May 2010 12:10:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Provags-ID: V01U2FsdGVkX1+os7TRVy13LKOr5QvY5xMt9eGvxnAXzGTBu6R ZFgZJVkOxbQkHkwsQb7amBfh77SXnQBIY1F8SIuYpVqGGhvCCa omQrYWIZueE9/zOFOBkFAwj1vnOggBKydF5qyyi4tk= Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 19 May 2010 17:11:54 -0000 Speaking as an individual: OK, a couple of things ... I'm seeing IETF-hosted web pages for RFCs that point back to all previous draft versions of the document, so it's not IMPOSSIBLE for someone to find section 9 in a draft, when they're looking at the RFC using those pages, but a lot of versions of RFC URLs don't have this attribute, so it's harder than it should be, and likely to stay harder than it should be for a few years at a minumum. I think if we pull section 9, there will be a lot more people who never see it, who are left to wonder how GIN meets the MARTINI requirements. I would like to retain section 9, but if the working group doesn't have conensus to do that, I'd like to see Christers suggestion taken to heart, so we don't lose track of the discussion when looking back, but at a minimum, we need to say "yes, this matches the requirements - we checked". Thanks, Spencer ----- Original Message ----- From: "Christer Holmberg" To: "Adam Roach" ; "DOLLY, MARTIN C (ATTLABS)" Cc: "martini@ietf.org" Sent: Wednesday, May 19, 2010 11:45 AM Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? > Hi, > > I don't have any strong opinions regarding the actual analysis, but I > think it at least should be indicated that the draft fulfills all > requirements in the req draft. > > Regards, > > Christer > > ________________________________________ > From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of > Adam Roach [adam@nostrum.com] > Sent: Wednesday, May 19, 2010 6:58 PM > To: DOLLY, MARTIN C (ATTLABS) > Cc: martini@ietf.org > Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? > > I'm not sure the question is whether the information can be found later, > as much as whether it's useful as an artifact. Sure, we need to make > sure the solution satisfies the requirements document -- but does it > make sense to include that analysis in the RFC? > > Like I said, I don't really care one way or another. But I do want to > make sure we're focusing on the right question here: "is this > information useful to retain?" Being able to find useless information at > a future date is pretty inconsequential. > > /a > > On 5/19/10 10:45 AM, DOLLY, MARTIN C (ATTLABS) wrote: >> They can find it where? please >> >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf Of Adam Roach >> Sent: Wednesday, May 19, 2010 11:44 AM >> To: Cullen Jennings >> Cc: martini@ietf.org >> Subject: [martini] GIN: Removing Section 9 (Requirements Analysis)? >> >> On 5/18/10 8:18 PM, Cullen Jennings wrote: >> >>> Could you put a Note telling the RFC Ed to remove section 9. If anyone >>> >> ever needs to read that they can find the draft. >> >>> >>> >> I'm indifferent as to whether it stays in. Does anyone object to >> removing it? >> >> /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 pkyzivat@cisco.com Wed May 19 10:12: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 F09FA3A6A0D for ; Wed, 19 May 2010 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.86 X-Spam-Level: X-Spam-Status: No, score=-8.86 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.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 klKlqAOizhjB for ; Wed, 19 May 2010 10:12:21 -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 39BAA3A6AB3 for ; Wed, 19 May 2010 10:12:03 -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: AvsEAAu480tAZnwN/2dsb2JhbACddnGkfZljhRAE X-IronPort-AV: E=Sophos;i="4.53,264,1272844800"; d="scan'208";a="112594528" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 May 2010 17:11:55 +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 o4JHBtpC020121; Wed, 19 May 2010 17:11:55 GMT Message-ID: <4BF41BDC.7050902@cisco.com> Date: Wed, 19 May 2010 13:11:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> In-Reply-To: <4BF40068.3020502@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 19 May 2010 17:12:24 -0000 Adam Roach wrote: > Actually, you're right. I just re-read the "anonymous public GRUU" > section again, and it doesn't reveal the information that we're fretting > about. (I also found a minor error in some of the examples, but I'm > fixing that in -03). > > The example that the document gives for one of these GRUUs looks like this: > > sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P The above doesn't sound right. A public gruu for the pbx ought to look like: sip:pbx@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 So anything derived off of it, for use as temp gruus, would also contain the identification of the pbx. If the pbx also got a temp-gruu assigned by the ssp, then it could derive its own temp gruus off of that. But assigning temp gruus for a pbx registration is going to be problematic: *Every* time a REGISTER (or re-REGISTER) request is processed, if the registrar supports temp-gruus and the registering UA supports gruu, then a new temp-gruu is assigned and returned. In principle that applies to implicitly registered AORs as well. There will be a new temp-gruu for *each* implicitly registered AOR. Those aren't returned, but if there is a subscription to the reg event package convering those AORs, then it will need to generate a notification containing all those temp-gruus. (See RFC 5628.) There is no good way to know if those are desired, so they are to be generated regardless. This works for the small numbers of implicit AORs used in IMS (ignoring the pbx stuff). But it could be a lot of work to generate, and a big notification to deliver all those temp gruus. And it will happen again every time the registration is refreshed. So, till now we GIN says not to generate temp gruus. If we need the SSP to generate a temp gruu for the pbx to use in generating its own temp gruus, but we don't want the ssp to generate temp gruus for all the implicitly registered AORs, then some added specification is required. Thanks, Paul > Going to Cullen's concern: if I got one of these URIs, it's not clear > what part of that I could mine to find out whether it was a Women's > Shelter (unless example.com has precisely one customer, in which case I > don't think there's anything we can do anyway). > > Cullen: can you elaborate on your use case, providing specific examples > of the URIs that you think leak information? > > /a > > On 5/19/10 9:32 AM, Elwell, John wrote: >> Adam, >> >> Although I was generalising the use case that Cullen put forward, >> doesn't the existing approach 2 satisfy this anyway? >> >> John >> >> >> >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> Sent: 19 May 2010 15:18 >>> To: Elwell, John >>> Cc: Cullen Jennings; martini@ietf.org >>> Subject: Re: [martini] GIN and anonymous GRUUS >>> >>> I'm sympathetic to the point, but don't think it's something that >>> MARTINI can appropriately solve. What's critical here is to >>> realize that >>> GIN does not make this problem any better or worse than the base GRUU >>> mechanism. >>> >>> For example, in a "normal" (i.e., 3263-routed, GIN-free) environment, >>> imagine you came into possession of a temp GRUU >>> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat. >>> com". And, >>> after a little research, you determine that the company does, >>> in fact, >>> consist of exactly two guys and their goat. You can be pretty certain >>> that the call came from one of the two guys who comprise the company >>> (unless the goat is really quite talented). >>> >>> So, yeah, it's a shortcoming of GRUUs in general. If you want >>> to solve >>> this problem, what is really needed is for you to take an >>> rfc5627bis to >>> DISPATCH. >>> >>> But I think it's a bit of a stretch to say "GRUUs as >>> currently defined >>> have this shortcoming. You mentioned GRUUs, and in doing so, >>> inherited >>> the shortcoming. Now fix it!" >>> >>> /a >>> >>> On 5/19/10 3:29 AM, Elwell, John wrote: >>> >>>> Cullen makes a good point. In general, MARTINI is targeted >>>> >>> at small PBXs, so often an "anonymous" GRUU that still >>> reveals the name of the business will not be sufficient, >>> since the number of users might be very small, they all might >>> be located in the same office, and so on. >>> >>>> John >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: martini-bounces@ietf.org >>>>> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings >>>>> Sent: 19 May 2010 02:19 >>>>> To: martini@ietf.org >>>>> Subject: [martini] GIN and anonymous GRUUS >>>>> >>>>> >>>>> I think the anonymous public GRUUs need some work. Imagine >>>>> that I have a small PBX at a women's shelter. Say they are 5 >>>>> to 10 phones or so and this PBX connects to an SSP. I think >>>>> this is one of the use cases we need anonymous calls to work >>>>> for and when someone makes a call from one of these phones, >>>>> it can not reveal they are at the women's shelter. >>>>> Anonymizing which room they are in at the women's shelter is >>>>> not enough. I'll ignore the self make GRUU section because if >>>>> you could to that, well you would not need GIN in the first place. >>>>> >>>>> Moving on to the Approach 2 - it seem that the PBX needs to >>>>> get an anonymous GRUU from the SSP then use that to fabricate >>>>> it's anonymous GRUU. I think that if you modified what you >>>>> have in the draft now to use anonymous GRUUs from the SSP, >>>>> you could get this to work. >>>>> >>>>> I think it would be worth adding an example showing an >>>>> anonymous call. I know lots of people goes "who cares, that's >>>>> a corner case" but many of the environments where we want to >>>>> deploy GIN, it will be a requirement to support anonymous >>>>> call - not many people need them but governments are pretty >>>>> adamant about making sure the people who do need them can >>>>> >>> have them. >>> >>>>> Could you put a Note telling the RFC Ed to remove section 9. >>>>> If anyone ever needs to read that they can find the draft. >>>>> >>>>> Nice draft - can't say I like it but I can live with it and I >>>>> suspect most people will come to the same conclusion after >>>>> thinking about it for awhile. Something most people can live >>>>> with I view as huge success for this topic. It will be >>>>> infinitely better than the current situation of many things >>>>> that sounds close but when you look at them in detail don't >>>>> interoperate. >>>>> >>>>> Thanks, Cullen >>>>> >>>>> >>>>> >>>>> >>>>> Cullen Jennings >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Wed May 19 11:33:57 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 E3F933A6D32 for ; Wed, 19 May 2010 11:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, SPF_PASS=-0.001, URI_HEX=0.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 hUF1FH1in3qo for ; Wed, 19 May 2010 11:33:56 -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 276F328C166 for ; Wed, 19 May 2010 11:25:53 -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 o4JIPhU7011604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 13:25:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF42D26.6080601@nostrum.com> Date: Wed, 19 May 2010 13:25:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> In-Reply-To: <4BF41BDC.7050902@cisco.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" Subject: Re: [martini] GIN and anonymous GRUUS 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, 19 May 2010 18:33:58 -0000 On 5/19/10 12:11 PM, Paul Kyzivat wrote: > > > Adam Roach wrote: >> Actually, you're right. I just re-read the "anonymous public GRUU" >> section again, and it doesn't reveal the information that we're >> fretting about. (I also found a minor error in some of the examples, >> but I'm fixing that in -03). >> >> The example that the document gives for one of these GRUUs looks like >> this: >> >> sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P > > > The above doesn't sound right. A public gruu for the pbx ought to look > like: > > sip:pbx@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 Not in this context. Remember that what we're doing is semantically equivalent to registering multiple AORs, not a single AOR. And the public GRUU for each of those AORs needs to be the AOR itself, plus the gruu parameters. So, at least for a "bnc" contact, we need to get back a "bnc" public gruu. It is a username-free template, just like the "bnc" contact itself. (The PBX is responsible for "expanding" the template before handing it to its endpoints). Now, if you included a non-"bnc" contact in a REGISTER request, it would be associated with a public gruu of the format you describe. But that's not what we're discussing here. /a From pkyzivat@cisco.com Wed May 19 11:56:40 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 808283A6DB4 for ; Wed, 19 May 2010 11:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.314 X-Spam-Level: X-Spam-Status: No, score=-9.314 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.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 xI4xn4f64RAv for ; Wed, 19 May 2010 11:56:39 -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 2EB8228C0F5 for ; Wed, 19 May 2010 11:47:45 -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: AvsEABLP80tAZnwN/2dsb2JhbACddnGjdJlbglqCNgQ X-IronPort-AV: E=Sophos;i="4.53,265,1272844800"; d="scan'208";a="112755890" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 May 2010 18:47:37 +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 o4JIlbEa018636; Wed, 19 May 2010 18:47:37 GMT Message-ID: <4BF4324B.5020005@cisco.com> Date: Wed, 19 May 2010 14:47:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <4BF42D26.6080601@nostrum.com> In-Reply-To: <4BF42D26.6080601@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 19 May 2010 18:56:40 -0000 Adam Roach wrote: > On 5/19/10 12:11 PM, Paul Kyzivat wrote: >> >> Adam Roach wrote: >>> Actually, you're right. I just re-read the "anonymous public GRUU" >>> section again, and it doesn't reveal the information that we're >>> fretting about. (I also found a minor error in some of the examples, >>> but I'm fixing that in -03). >>> >>> The example that the document gives for one of these GRUUs looks like >>> this: >>> >>> sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P >> >> The above doesn't sound right. A public gruu for the pbx ought to look >> like: >> >> sip:pbx@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 > > Not in this context. > > Remember that what we're doing is semantically equivalent to registering > multiple AORs, not a single AOR. And the public GRUU for each of those > AORs needs to be the AOR itself, plus the gruu parameters. So, at least > for a "bnc" contact, we need to get back a "bnc" public gruu. It is a > username-free template, just like the "bnc" contact itself. (The PBX is > responsible for "expanding" the template before handing it to its > endpoints). Hmm. That is different than what one would expect without the BNC but with implicit registration. But it is what you have in the draft. Assuming it works that way, the returned pub-gruu: sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 is just a template for pub-gruus for each registered AOR. The *actual* pub-gruus are then: sip:pbx@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 sip:+12145550102@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 etc. AFAIK there is no implication that sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 is itself a valid gruu, since it doesn't correspond to any AOR. Hence I think one must take one of the *actual* gruus to derive the temp gruus. And those would, in some sense, expose the identity of the pbx, which is Cullen's issue. Thanks Paul From fluffy@cisco.com Wed May 19 16:41: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 289593A6A02 for ; Wed, 19 May 2010 16:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.555 X-Spam-Level: X-Spam-Status: No, score=-108.555 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001, 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 QM6gs1gxDJ6O for ; Wed, 19 May 2010 16:41:22 -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 53C443A69DF for ; Wed, 19 May 2010 16:41:21 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACcU9EurR7Hu/2dsb2JhbACeAXGkQplJhRAEg0A X-IronPort-AV: E=Sophos;i="4.53,266,1272844800"; d="scan'208";a="199863497" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 May 2010 23:41:14 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4JNfD3t021604; Wed, 19 May 2010 23:41:13 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4BF3F2FC.8090609@nostrum.com> Date: Wed, 19 May 2010 17:41:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <49F628C2-4E97-4109-A01B-2D36BC038C60@cisco.com> References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1078) Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 19 May 2010 23:41:24 -0000 On May 19, 2010, at 8:17 AM, Adam Roach wrote: > I'm sympathetic to the point, but don't think it's something that > MARTINI can appropriately solve. I'm not asking martini to solve anything, just not break anything that's = already in 3261 and 5627.=20 > What's critical here is to realize that > GIN does not make this problem any better or worse than the base GRUU > mechanism. >=20 > For example, in a "normal" (i.e., 3263-routed, GIN-free) environment, > imagine you came into possession of a temp GRUU > "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat.com". = And, > after a little research, you determine that the company does, in fact, > consist of exactly two guys and their goat. You can be pretty certain > that the call came from one of the two guys who comprise the company > (unless the goat is really quite talented). So I really don't care that the people can track it down to the level of = SSP. In the use cases most people are concerned with the SSP is large = enough that it is OK. If the goat running the SSP wants to protect it's = privacy it could easily go and get a free domain from dyndsn such as = really-im-a-dog.doesntexist.com and use that domain to form the GRUU.=20 5627 put a ton of work into making sure this all works and was no worse = than 3261 - it did this with the temp gruu. What I think you need to do = here is use the temp gruu instead of the public gruu for anonymous call. = It's really not much different than what the draft has now.=20 >=20 > So, yeah, it's a shortcoming of GRUUs in general. If you want to solve > this problem, what is really needed is for you to take an rfc5627bis = to > DISPATCH. Luckily, 5627 already has a solution that solves the problem to the = level I care about. >=20 > But I think it's a bit of a stretch to say "GRUUs as currently defined > have this shortcoming. You mentioned GRUUs, and in doing so, inherited > the shortcoming. Now fix it!" sure - I'm not asking for that. And when we did 5627, we did not try and = deal with the parts that 3261 did not have a solution too ( that being = the IP addresses the RTP packets might be going to) but we decided not = to make the situation work as well as 3261.=20 >=20 > /a >=20 > On 5/19/10 3:29 AM, Elwell, John wrote: > > Cullen makes a good point. In general, MARTINI is targeted at small = PBXs, so often an "anonymous" GRUU that still reveals the name of the = business will not be sufficient, since the number of users might be very = small, they all might be located in the same office, and so on. > > > > John > > > > =20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings > >> Sent: 19 May 2010 02:19 > >> To: martini@ietf.org > >> Subject: [martini] GIN and anonymous GRUUS > >> > >> > >> I think the anonymous public GRUUs need some work. Imagine > >> that I have a small PBX at a women's shelter. Say they are 5 > >> to 10 phones or so and this PBX connects to an SSP. I think > >> this is one of the use cases we need anonymous calls to work > >> for and when someone makes a call from one of these phones, > >> it can not reveal they are at the women's shelter. > >> Anonymizing which room they are in at the women's shelter is > >> not enough. I'll ignore the self make GRUU section because if > >> you could to that, well you would not need GIN in the first place. > >> > >> Moving on to the Approach 2 - it seem that the PBX needs to > >> get an anonymous GRUU from the SSP then use that to fabricate > >> it's anonymous GRUU. I think that if you modified what you > >> have in the draft now to use anonymous GRUUs from the SSP, > >> you could get this to work. > >> > >> I think it would be worth adding an example showing an > >> anonymous call. I know lots of people goes "who cares, that's > >> a corner case" but many of the environments where we want to > >> deploy GIN, it will be a requirement to support anonymous > >> call - not many people need them but governments are pretty > >> adamant about making sure the people who do need them can have = them. > >> > >> Could you put a Note telling the RFC Ed to remove section 9. > >> If anyone ever needs to read that they can find the draft. > >> > >> Nice draft - can't say I like it but I can live with it and I > >> suspect most people will come to the same conclusion after > >> thinking about it for awhile. Something most people can live > >> with I view as huge success for this topic. It will be > >> infinitely better than the current situation of many things > >> that sounds close but when you look at them in detail don't > >> interoperate. > >> > >> Thanks, Cullen > >> > >> > >> > >> > >> Cullen Jennings > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > >> > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > >> =20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > =20 >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed May 19 16:46:36 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 D5B4A3A67A2 for ; Wed, 19 May 2010 16:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.009 X-Spam-Level: X-Spam-Status: No, score=-110.009 tagged_above=-999 required=5 tests=[AWL=0.590, 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 Gv3T6l3oyDHt for ; Wed, 19 May 2010 16:46:35 -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 DA5D03A6925 for ; Wed, 19 May 2010 16:46:35 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,266,1272844800"; d="scan'208";a="199866581" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 May 2010 23:46:29 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4JNkSmS020324; Wed, 19 May 2010 23:46:28 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4BF415C9.7040508@cisco.com> Date: Wed, 19 May 2010 17:46:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <26234623-4187-4752-8D5A-AF812AAB6904@cisco.com> References: <9579A5DE-F6F2-4717-AA1F-4AD0951C9611@cisco.com> <4BF415C9.7040508@cisco.com> To: Paul Kyzivat (pkyzivat) X-Mailer: Apple Mail (2.1078) Cc: "martini@ietf.org" Subject: Re: [martini] Review of GIN and outbound interaction 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, 19 May 2010 23:46:36 -0000 On May 19, 2010, at 10:46 AM, Paul Kyzivat (pkyzivat) wrote: > Callerprefs by instance id has always been problematic. GRUUs are a > better solution to that. >=20 > Thanks, > Paul Right ... it all comes back to me. Thanks Paul - I think that is more or = less the answer. The part I was worried about does not really matter as = is fine as long as systems uses GRUUs instead of the instance-ids in = caller prefs. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From pkyzivat@cisco.com Wed May 19 17:07: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 92D113A69BD for ; Wed, 19 May 2010 17:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_05=-1.11, 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 DziN-np4oc9i for ; Wed, 19 May 2010 17:07:23 -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 00F453A694E for ; Wed, 19 May 2010 17:07:22 -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,266,1272844800"; d="scan'208";a="112839895" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 May 2010 00:07:15 +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 o4K07FdC023993; Thu, 20 May 2010 00:07:15 GMT Message-ID: <4BF47D33.2020307@cisco.com> Date: Wed, 19 May 2010 20:07:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <49F628C2-4E97-4109-A01B-2D36BC038C60@cisco.com> In-Reply-To: <49F628C2-4E97-4109-A01B-2D36BC038C60@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 20 May 2010 00:07:24 -0000 Cullen Jennings wrote: > On May 19, 2010, at 8:17 AM, Adam Roach wrote: > >> I'm sympathetic to the point, but don't think it's something that >> MARTINI can appropriately solve. > > I'm not asking martini to solve anything, just not break anything that's already in 3261 and 5627. > > >> What's critical here is to realize that >> GIN does not make this problem any better or worse than the base GRUU >> mechanism. >> >> For example, in a "normal" (i.e., 3263-routed, GIN-free) environment, >> imagine you came into possession of a temp GRUU >> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat.com". And, >> after a little research, you determine that the company does, in fact, >> consist of exactly two guys and their goat. You can be pretty certain >> that the call came from one of the two guys who comprise the company >> (unless the goat is really quite talented). > > So I really don't care that the people can track it down to the level of SSP. In the use cases most people are concerned with the SSP is large enough that it is OK. If the goat running the SSP wants to protect it's privacy it could easily go and get a free domain from dyndsn such as really-im-a-dog.doesntexist.com and use that domain to form the GRUU. > > 5627 put a ton of work into making sure this all works and was no worse than 3261 - it did this with the temp gruu. What I think you need to do here is use the temp gruu instead of the public gruu for anonymous call. It's really not much different than what the draft has now. I commented on this approach in: http://www.ietf.org/mail-archive/web/martini/current/msg01565.html I think we would at least have to tweak the ssp temp gruu mechanism so that it doesn't have to generate a unique temp gruu for every phone on the pbx, and notify with them, every time the pbx refreshes its registration. Thanks, Paul From fluffy@cisco.com Thu May 20 06:41:21 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 E6AF93A68B8 for ; Thu, 20 May 2010 06:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.905 X-Spam-Level: X-Spam-Status: No, score=-108.905 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_20=-0.74, 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 cx6x3atFQEm1 for ; Thu, 20 May 2010 06:41:20 -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 8C60C3A67F7 for ; Thu, 20 May 2010 06:41:20 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAzZ9EurR7Hu/2dsb2JhbACeCHGjXZlShRIEg0A X-IronPort-AV: E=Sophos;i="4.53,271,1272844800"; d="scan'208";a="200213036" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 May 2010 13:41:13 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4KDfCFr005572; Thu, 20 May 2010 13:41:13 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings X-Priority: 3 In-Reply-To: Date: Thu, 20 May 2010 07:41:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com><4BF40757.1040009@nostrum.com><14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com>, <4BF40A96.3040600@nostrum.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1078) Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 20 May 2010 13:41:22 -0000 I'd rather see the analysis of if the GIN draft meets the requirements = done in the requirements draft and the GIN draft have an reference to = the requirements draft. I don't really care much one way or the other = but I am getting steadily more allergic to drafts that huge swaths of = text that totally useless to people trying to implement the protocol. It = just convinces implementors it is big and complicated and they don't = want to do it.=20 On May 19, 2010, at 11:10 AM, Spencer Dawkins wrote: > Speaking as an individual: >=20 > OK, a couple of things ... >=20 > I'm seeing IETF-hosted web pages for RFCs that point back to all = previous draft versions of the document, so it's not IMPOSSIBLE for = someone to find section 9 in a draft, when they're looking at the RFC = using those pages, but a lot of versions of RFC URLs don't have this = attribute, so it's harder than it should be, and likely to stay harder = than it should be for a few years at a minumum. I think if we pull = section 9, there will be a lot more people who never see it, who are = left to wonder how GIN meets the MARTINI requirements. >=20 > I would like to retain section 9, but if the working group doesn't = have conensus to do that, I'd like to see Christers suggestion taken to = heart, so we don't lose track of the discussion when looking back, but = at a minimum, we need to say "yes, this matches the requirements - we = checked". >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message ----- From: "Christer Holmberg" = > To: "Adam Roach" ; "DOLLY, MARTIN C (ATTLABS)" = > Cc: "martini@ietf.org" > Sent: Wednesday, May 19, 2010 11:45 AM > Subject: Re: [martini] GIN: Removing Section 9 (Requirements = Analysis)? >=20 >=20 >> Hi, >>=20 >> I don't have any strong opinions regarding the actual analysis, but I = think it at least should be indicated that the draft fulfills all = requirements in the req draft. >>=20 >> Regards, >>=20 >> Christer >>=20 >> ________________________________________ >> From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf = Of Adam Roach [adam@nostrum.com] >> Sent: Wednesday, May 19, 2010 6:58 PM >> To: DOLLY, MARTIN C (ATTLABS) >> Cc: martini@ietf.org >> Subject: Re: [martini] GIN: Removing Section 9 (Requirements = Analysis)? >>=20 >> I'm not sure the question is whether the information can be found = later, >> as much as whether it's useful as an artifact. Sure, we need to make >> sure the solution satisfies the requirements document -- but does it >> make sense to include that analysis in the RFC? >>=20 >> Like I said, I don't really care one way or another. But I do want to >> make sure we're focusing on the right question here: "is this >> information useful to retain?" Being able to find useless information = at >> a future date is pretty inconsequential. >>=20 >> /a >>=20 >> On 5/19/10 10:45 AM, DOLLY, MARTIN C (ATTLABS) wrote: >>> They can find it where? please >>>=20 >>> -----Original Message----- >>> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >>> Behalf Of Adam Roach >>> Sent: Wednesday, May 19, 2010 11:44 AM >>> To: Cullen Jennings >>> Cc: martini@ietf.org >>> Subject: [martini] GIN: Removing Section 9 (Requirements Analysis)? >>>=20 >>> On 5/18/10 8:18 PM, Cullen Jennings wrote: >>>=20 >>>> Could you put a Note telling the RFC Ed to remove section 9. If = anyone >>>>=20 >>> ever needs to read that they can find the draft. >>>=20 >>>>=20 >>>>=20 >>> I'm indifferent as to whether it stays in. Does anyone object to >>> removing it? >>>=20 >>> /a >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >>>=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 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From john.elwell@siemens-enterprise.com Thu May 20 06:51: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 CB1BD3A6C17 for ; Thu, 20 May 2010 06:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 e0IiD2IjI5YI for ; Thu, 20 May 2010 06:50:59 -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 160B33A6C10 for ; Thu, 20 May 2010 06:50:56 -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-238749; Thu, 20 May 2010 15:50:49 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D333E23F0278; Thu, 20 May 2010 15:50:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 20 May 2010 15:50:49 +0200 From: "Elwell, John" To: Cullen Jennings , Spencer Dawkins Date: Thu, 20 May 2010 15:50:48 +0200 Thread-Topic: [martini] GIN: Removing Section 9 (Requirements Analysis)? Thread-Index: Acr4Ih/Xc2bEA7bRS/G6awOMGZGfrQAAIUrg Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com><4BF40757.1040009@nostrum.com><14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com>, <4BF40A96.3040600@nostrum.com> 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 Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 20 May 2010 13:51:00 -0000 Cullen, I think that is the wrong way round. A requirements document is generally w= ritten before solution documents. And suppose some requirements are not met= until a later solutions document, e.g., olive. Does that mean we can't put= the requirements document to bed before olive is finished? On the other hand, I tend to agree with you that implementers don't like to= o much useless material. We had a pretty good evaluation of gin against req= uirements at IETF#77 on slides, and it is that that is captured in the late= st gin draft. The analysis has changed very little, except that a couple of= new requirements have been added. The IETF#77 MARTINI minutes, with pointe= r to the slides, goes a long way to showing that we have done due diligence= in ensuring the solution meets the requirements. OR we could post updated = text on the mailing list, so that it appears in the archive. Do we really n= eed to encumber either draft with this lengthy text? John =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 20 May 2010 14:41 > To: Spencer Dawkins > Cc: martini@ietf.org > Subject: Re: [martini] GIN: Removing Section 9 (Requirements=20 > Analysis)? >=20 >=20 > I'd rather see the analysis of if the GIN draft meets the=20 > requirements done in the requirements draft and the GIN draft=20 > have an reference to the requirements draft. I don't really=20 > care much one way or the other but I am getting steadily more=20 > allergic to drafts that huge swaths of text that totally=20 > useless to people trying to implement the protocol. It just=20 > convinces implementors it is big and complicated and they=20 > don't want to do it.=20 >=20 >=20 >=20 > On May 19, 2010, at 11:10 AM, Spencer Dawkins wrote: >=20 > > Speaking as an individual: > >=20 > > OK, a couple of things ... > >=20 > > I'm seeing IETF-hosted web pages for RFCs that point back=20 > to all previous draft versions of the document, so it's not=20 > IMPOSSIBLE for someone to find section 9 in a draft, when=20 > they're looking at the RFC using those pages, but a lot of=20 > versions of RFC URLs don't have this attribute, so it's=20 > harder than it should be, and likely to stay harder than it=20 > should be for a few years at a minumum. I think if we pull=20 > section 9, there will be a lot more people who never see it,=20 > who are left to wonder how GIN meets the MARTINI requirements. > >=20 > > I would like to retain section 9, but if the working group=20 > doesn't have conensus to do that, I'd like to see Christers=20 > suggestion taken to heart, so we don't lose track of the=20 > discussion when looking back, but at a minimum, we need to=20 > say "yes, this matches the requirements - we checked". > >=20 > > Thanks, > >=20 > > Spencer > >=20 > > ----- Original Message ----- From: "Christer Holmberg"=20 > > > To: "Adam Roach" ; "DOLLY, MARTIN C=20 > (ATTLABS)" > > Cc: "martini@ietf.org" > > Sent: Wednesday, May 19, 2010 11:45 AM > > Subject: Re: [martini] GIN: Removing Section 9=20 > (Requirements Analysis)? > >=20 > >=20 > >> Hi, > >>=20 > >> I don't have any strong opinions regarding the actual=20 > analysis, but I think it at least should be indicated that=20 > the draft fulfills all requirements in the req draft. > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >> ________________________________________ > >> From: martini-bounces@ietf.org [martini-bounces@ietf.org]=20 > On Behalf Of Adam Roach [adam@nostrum.com] > >> Sent: Wednesday, May 19, 2010 6:58 PM > >> To: DOLLY, MARTIN C (ATTLABS) > >> Cc: martini@ietf.org > >> Subject: Re: [martini] GIN: Removing Section 9=20 > (Requirements Analysis)? > >>=20 > >> I'm not sure the question is whether the information can=20 > be found later, > >> as much as whether it's useful as an artifact. Sure, we=20 > need to make > >> sure the solution satisfies the requirements document --=20 > but does it > >> make sense to include that analysis in the RFC? > >>=20 > >> Like I said, I don't really care one way or another. But I=20 > do want to > >> make sure we're focusing on the right question here: "is this > >> information useful to retain?" Being able to find useless=20 > information at > >> a future date is pretty inconsequential. > >>=20 > >> /a > >>=20 > >> On 5/19/10 10:45 AM, DOLLY, MARTIN C (ATTLABS) wrote: > >>> They can find it where? please > >>>=20 > >>> -----Original Message----- > >>> From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On > >>> Behalf Of Adam Roach > >>> Sent: Wednesday, May 19, 2010 11:44 AM > >>> To: Cullen Jennings > >>> Cc: martini@ietf.org > >>> Subject: [martini] GIN: Removing Section 9 (Requirements=20 > Analysis)? > >>>=20 > >>> On 5/18/10 8:18 PM, Cullen Jennings wrote: > >>>=20 > >>>> Could you put a Note telling the RFC Ed to remove=20 > section 9. If anyone > >>>>=20 > >>> ever needs to read that they can find the draft. > >>>=20 > >>>>=20 > >>>>=20 > >>> I'm indifferent as to whether it stays in. Does anyone object to > >>> removing it? > >>>=20 > >>> /a > >>> _______________________________________________ > >>> martini mailing list > >>> martini@ietf.org > >>> https://www.ietf.org/mailman/listinfo/martini > >>>=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 > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From fluffy@cisco.com Thu May 20 07:04:40 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 659713A659C for ; Thu, 20 May 2010 07:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.948 X-Spam-Level: X-Spam-Status: No, score=-108.948 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.368, 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 5h1zVgLbLpQ9 for ; Thu, 20 May 2010 07:04:38 -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 70AD53A6A81 for ; Thu, 20 May 2010 07:04:36 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,271,1272844800"; d="scan'208";a="532673841" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 20 May 2010 14:04:30 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4KE4SmR012204; Thu, 20 May 2010 14:04:29 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4BF41BDC.7050902@cisco.com> Date: Thu, 20 May 2010 08:04:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> To: "martini@ietf.org" , Paul Kyzivat , Adam Roach X-Mailer: Apple Mail (2.1078) Subject: Re: [martini] GIN and anonymous GRUUS 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, 20 May 2010 14:04:40 -0000 So I think this conversation is going a good way to find a solution to = this. For a second, lets just consider the B2BUA style PBX.=20 Lets say that the PBX has 10 phones that register with the PBX and the = PBX does one registration with the SSP that uses GIN with GRUU. The = phones may not even support GRUU and their registration have very little = to do with the registration to the SSP. I realize that to get a temp = GRUU to each of the phones, we would either need a way for the PBX to = generate multiple temp GRUU based on some template it got from the SSP = or the PBX would need to get multiple temp GRUU from the SSP. We should = look at if there is a reasonable design to achieve either of those that = does not require changes to GRUU. I suspect their might be. But even if = there is not, I think there is a simple solution to this. Keep in mind my issue is not the phones all all temp gruu, my issues is = that anonymous calls need to not reveal which PBX it is. So one solution = would be to have the PBX get a single temp GRUU and when the PBX makes = an anonymous call to the SSP use the temp gruu then get some more temp = gruu for future use. This would probably work better if it had a small = pool of available temp gruu for use when a temp gruu is need but you get = the idea.=20 Another option would be just to have the GIN draft request the number of = temp GRUU that the PBX wants the SSP to return.=20 There's a ton of way to skin this cat but I am strongly against = depreciating anonymous call support of 3261 when using the GIN draft - I = view that as GIN breaking SIP. It's a critical feature when using SIP = for PSTN replacement and I believe it has very important value many = types of SIP communication.=20 On May 19, 2010, at 11:11 AM, Paul Kyzivat wrote: >=20 >=20 > Adam Roach wrote: >> Actually, you're right. I just re-read the "anonymous public GRUU" = section again, and it doesn't reveal the information that we're fretting = about. (I also found a minor error in some of the examples, but I'm = fixing that in -03). >> The example that the document gives for one of these GRUUs looks like = this: >> = sip:ssp.example.com;gr=3Durn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=3D= 0UYYRV046P=20 >=20 > The above doesn't sound right. A public gruu for the pbx ought to look = like: >=20 > = sip:pbx@ssp.example.com;gr=3Durn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6= >=20 > So anything derived off of it, for use as temp gruus, would also = contain the identification of the pbx. >=20 > If the pbx also got a temp-gruu assigned by the ssp, then it could = derive its own temp gruus off of that. But assigning temp gruus for a = pbx registration is going to be problematic: >=20 > *Every* time a REGISTER (or re-REGISTER) request is processed, if the = registrar supports temp-gruus and the registering UA supports gruu, then = a new temp-gruu is assigned and returned. In principle that applies to = implicitly registered AORs as well. There will be a new temp-gruu for = *each* implicitly registered AOR. Those aren't returned, but if there is = a subscription to the reg event package convering those AORs, then it = will need to generate a notification containing all those temp-gruus. = (See RFC 5628.) There is no good way to know if those are desired, so = they are to be generated regardless. This works for the small numbers of = implicit AORs used in IMS (ignoring the pbx stuff). But it could be a = lot of work to generate, and a big notification to deliver all those = temp gruus. And it will happen again every time the registration is = refreshed. >=20 > So, till now we GIN says not to generate temp gruus. >=20 > If we need the SSP to generate a temp gruu for the pbx to use in = generating its own temp gruus, but we don't want the ssp to generate = temp gruus for all the implicitly registered AORs, then some added = specification is required. >=20 > Thanks, > Paul >=20 >> Going to Cullen's concern: if I got one of these URIs, it's not clear = what part of that I could mine to find out whether it was a Women's = Shelter (unless example.com has precisely one customer, in which case I = don't think there's anything we can do anyway). >> Cullen: can you elaborate on your use case, providing specific = examples of the URIs that you think leak information? >> /a >> On 5/19/10 9:32 AM, Elwell, John wrote: >>> Adam, >>>=20 >>> Although I was generalising the use case that Cullen put forward, = doesn't the existing approach 2 satisfy this anyway? >>>=20 >>> John >>>=20 >>>=20 >>> =20 >>>> -----Original Message----- >>>> From: Adam Roach [mailto:adam@nostrum.com] >>>> Sent: 19 May 2010 15:18 >>>> To: Elwell, John >>>> Cc: Cullen Jennings; martini@ietf.org >>>> Subject: Re: [martini] GIN and anonymous GRUUS >>>>=20 >>>> I'm sympathetic to the point, but don't think it's something that >>>> MARTINI can appropriately solve. What's critical here is to >>>> realize that >>>> GIN does not make this problem any better or worse than the base = GRUU >>>> mechanism. >>>>=20 >>>> For example, in a "normal" (i.e., 3263-routed, GIN-free) = environment, >>>> imagine you came into possession of a temp GRUU >>>> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat. >>>> com". And, >>>> after a little research, you determine that the company does, >>>> in fact, >>>> consist of exactly two guys and their goat. You can be pretty = certain >>>> that the call came from one of the two guys who comprise the = company >>>> (unless the goat is really quite talented). >>>>=20 >>>> So, yeah, it's a shortcoming of GRUUs in general. If you want >>>> to solve >>>> this problem, what is really needed is for you to take an >>>> rfc5627bis to >>>> DISPATCH. >>>>=20 >>>> But I think it's a bit of a stretch to say "GRUUs as >>>> currently defined >>>> have this shortcoming. You mentioned GRUUs, and in doing so, >>>> inherited >>>> the shortcoming. Now fix it!" >>>>=20 >>>> /a >>>>=20 >>>> On 5/19/10 3:29 AM, Elwell, John wrote: >>>> =20 >>>>> Cullen makes a good point. In general, MARTINI is targeted >>>>> =20 >>>> at small PBXs, so often an "anonymous" GRUU that still >>>> reveals the name of the business will not be sufficient, >>>> since the number of users might be very small, they all might >>>> be located in the same office, and so on. >>>> =20 >>>>> John >>>>>=20 >>>>>=20 >>>>> =20 >>>>>> -----Original Message----- >>>>>> From: martini-bounces@ietf.org >>>>>> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings >>>>>> Sent: 19 May 2010 02:19 >>>>>> To: martini@ietf.org >>>>>> Subject: [martini] GIN and anonymous GRUUS >>>>>>=20 >>>>>>=20 >>>>>> I think the anonymous public GRUUs need some work. Imagine >>>>>> that I have a small PBX at a women's shelter. Say they are 5 >>>>>> to 10 phones or so and this PBX connects to an SSP. I think >>>>>> this is one of the use cases we need anonymous calls to work >>>>>> for and when someone makes a call from one of these phones, >>>>>> it can not reveal they are at the women's shelter. >>>>>> Anonymizing which room they are in at the women's shelter is >>>>>> not enough. I'll ignore the self make GRUU section because if >>>>>> you could to that, well you would not need GIN in the first = place. >>>>>>=20 >>>>>> Moving on to the Approach 2 - it seem that the PBX needs to >>>>>> get an anonymous GRUU from the SSP then use that to fabricate >>>>>> it's anonymous GRUU. I think that if you modified what you >>>>>> have in the draft now to use anonymous GRUUs from the SSP, >>>>>> you could get this to work. >>>>>>=20 >>>>>> I think it would be worth adding an example showing an >>>>>> anonymous call. I know lots of people goes "who cares, that's >>>>>> a corner case" but many of the environments where we want to >>>>>> deploy GIN, it will be a requirement to support anonymous >>>>>> call - not many people need them but governments are pretty >>>>>> adamant about making sure the people who do need them can >>>>>> =20 >>>> have them. >>>> =20 >>>>>> Could you put a Note telling the RFC Ed to remove section 9. >>>>>> If anyone ever needs to read that they can find the draft. >>>>>>=20 >>>>>> Nice draft - can't say I like it but I can live with it and I >>>>>> suspect most people will come to the same conclusion after >>>>>> thinking about it for awhile. Something most people can live >>>>>> with I view as huge success for this topic. It will be >>>>>> infinitely better than the current situation of many things >>>>>> that sounds close but when you look at them in detail don't >>>>>> interoperate. >>>>>>=20 >>>>>> Thanks, Cullen >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Cullen Jennings >>>>>> For corporate legal information go to: >>>>>> = http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> martini mailing list >>>>>> martini@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/martini >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>> _______________________________________________ >>>>> martini mailing list >>>>> martini@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/martini >>>>>=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 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From pkyzivat@cisco.com Thu May 20 07:24:48 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 F3B183A6D46 for ; Thu, 20 May 2010 07:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.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 x0g-Wj7EnxGl for ; Thu, 20 May 2010 07:24:41 -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 CD8693A6CA1 for ; Thu, 20 May 2010 07:21:50 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,272,1272844800"; d="scan'208";a="112918757" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 May 2010 14:21:43 +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 o4KELhiQ004569; Thu, 20 May 2010 14:21:43 GMT Message-ID: <4BF54577.4000909@cisco.com> Date: Thu, 20 May 2010 10:21:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> In-Reply-To: <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 20 May 2010 14:24:48 -0000 Cullen, Focusing on the B2BUA PBX case, the contact address that the outside world sees will be one inserted by the pbx b2bua, not the one inserted by the phone. In that case, there are two issues: - how does the phone indicate it wants to make an anonymous call? (Privacy header?) - how does the pbx get a supply of anonymous gruus? There is in that case no need to convey anonymous gruus to the phones. (The above assumes privacy only for calls to the outside world. Privacy on calls between phones connected to the same pbx is a *little* different. If there is still a b2bua in the path, its more or less the same, except that contact used probably won't be a gruu at all, just something cooked up by the b2bua for local use.) So, in this case the hard part is to get a temp gruu for the pbx to use. Assuming the ssp registrar supports temp gruus, this is doable, but there are potential efficiency issues. I'm now wondering if those need to be investigated, or if they can be left as implementation issues. We haven't spoken much about the pbx-as-proxy case. That is a bit more difficult, because it becomes necessary to convey temp gruus to the phones. Thanks, Paul Cullen Jennings wrote: > So I think this conversation is going a good way to find a solution to this. For a second, lets just consider the B2BUA style PBX. > > Lets say that the PBX has 10 phones that register with the PBX and the PBX does one registration with the SSP that uses GIN with GRUU. The phones may not even support GRUU and their registration have very little to do with the registration to the SSP. I realize that to get a temp GRUU to each of the phones, we would either need a way for the PBX to generate multiple temp GRUU based on some template it got from the SSP or the PBX would need to get multiple temp GRUU from the SSP. We should look at if there is a reasonable design to achieve either of those that does not require changes to GRUU. I suspect their might be. But even if there is not, I think there is a simple solution to this. > > Keep in mind my issue is not the phones all all temp gruu, my issues is that anonymous calls need to not reveal which PBX it is. So one solution would be to have the PBX get a single temp GRUU and when the PBX makes an anonymous call to the SSP use the temp gruu then get some more temp gruu for future use. This would probably work better if it had a small pool of available temp gruu for use when a temp gruu is need but you get the idea. > > Another option would be just to have the GIN draft request the number of temp GRUU that the PBX wants the SSP to return. > > There's a ton of way to skin this cat but I am strongly against depreciating anonymous call support of 3261 when using the GIN draft - I view that as GIN breaking SIP. It's a critical feature when using SIP for PSTN replacement and I believe it has very important value many types of SIP communication. > > > > On May 19, 2010, at 11:11 AM, Paul Kyzivat wrote: > >> >> Adam Roach wrote: >>> Actually, you're right. I just re-read the "anonymous public GRUU" section again, and it doesn't reveal the information that we're fretting about. (I also found a minor error in some of the examples, but I'm fixing that in -03). >>> The example that the document gives for one of these GRUUs looks like this: >>> sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P >> The above doesn't sound right. A public gruu for the pbx ought to look like: >> >> sip:pbx@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >> >> So anything derived off of it, for use as temp gruus, would also contain the identification of the pbx. >> >> If the pbx also got a temp-gruu assigned by the ssp, then it could derive its own temp gruus off of that. But assigning temp gruus for a pbx registration is going to be problematic: >> >> *Every* time a REGISTER (or re-REGISTER) request is processed, if the registrar supports temp-gruus and the registering UA supports gruu, then a new temp-gruu is assigned and returned. In principle that applies to implicitly registered AORs as well. There will be a new temp-gruu for *each* implicitly registered AOR. Those aren't returned, but if there is a subscription to the reg event package convering those AORs, then it will need to generate a notification containing all those temp-gruus. (See RFC 5628.) There is no good way to know if those are desired, so they are to be generated regardless. This works for the small numbers of implicit AORs used in IMS (ignoring the pbx stuff). But it could be a lot of work to generate, and a big notification to deliver all those temp gruus. And it will happen again every time the registration is refreshed. >> >> So, till now we GIN says not to generate temp gruus. >> >> If we need the SSP to generate a temp gruu for the pbx to use in generating its own temp gruus, but we don't want the ssp to generate temp gruus for all the implicitly registered AORs, then some added specification is required. >> >> Thanks, >> Paul >> >>> Going to Cullen's concern: if I got one of these URIs, it's not clear what part of that I could mine to find out whether it was a Women's Shelter (unless example.com has precisely one customer, in which case I don't think there's anything we can do anyway). >>> Cullen: can you elaborate on your use case, providing specific examples of the URIs that you think leak information? >>> /a >>> On 5/19/10 9:32 AM, Elwell, John wrote: >>>> Adam, >>>> >>>> Although I was generalising the use case that Cullen put forward, doesn't the existing approach 2 satisfy this anyway? >>>> >>>> John >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>> Sent: 19 May 2010 15:18 >>>>> To: Elwell, John >>>>> Cc: Cullen Jennings; martini@ietf.org >>>>> Subject: Re: [martini] GIN and anonymous GRUUS >>>>> >>>>> I'm sympathetic to the point, but don't think it's something that >>>>> MARTINI can appropriately solve. What's critical here is to >>>>> realize that >>>>> GIN does not make this problem any better or worse than the base GRUU >>>>> mechanism. >>>>> >>>>> For example, in a "normal" (i.e., 3263-routed, GIN-free) environment, >>>>> imagine you came into possession of a temp GRUU >>>>> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat. >>>>> com". And, >>>>> after a little research, you determine that the company does, >>>>> in fact, >>>>> consist of exactly two guys and their goat. You can be pretty certain >>>>> that the call came from one of the two guys who comprise the company >>>>> (unless the goat is really quite talented). >>>>> >>>>> So, yeah, it's a shortcoming of GRUUs in general. If you want >>>>> to solve >>>>> this problem, what is really needed is for you to take an >>>>> rfc5627bis to >>>>> DISPATCH. >>>>> >>>>> But I think it's a bit of a stretch to say "GRUUs as >>>>> currently defined >>>>> have this shortcoming. You mentioned GRUUs, and in doing so, >>>>> inherited >>>>> the shortcoming. Now fix it!" >>>>> >>>>> /a >>>>> >>>>> On 5/19/10 3:29 AM, Elwell, John wrote: >>>>> >>>>>> Cullen makes a good point. In general, MARTINI is targeted >>>>>> >>>>> at small PBXs, so often an "anonymous" GRUU that still >>>>> reveals the name of the business will not be sufficient, >>>>> since the number of users might be very small, they all might >>>>> be located in the same office, and so on. >>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: martini-bounces@ietf.org >>>>>>> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings >>>>>>> Sent: 19 May 2010 02:19 >>>>>>> To: martini@ietf.org >>>>>>> Subject: [martini] GIN and anonymous GRUUS >>>>>>> >>>>>>> >>>>>>> I think the anonymous public GRUUs need some work. Imagine >>>>>>> that I have a small PBX at a women's shelter. Say they are 5 >>>>>>> to 10 phones or so and this PBX connects to an SSP. I think >>>>>>> this is one of the use cases we need anonymous calls to work >>>>>>> for and when someone makes a call from one of these phones, >>>>>>> it can not reveal they are at the women's shelter. >>>>>>> Anonymizing which room they are in at the women's shelter is >>>>>>> not enough. I'll ignore the self make GRUU section because if >>>>>>> you could to that, well you would not need GIN in the first place. >>>>>>> >>>>>>> Moving on to the Approach 2 - it seem that the PBX needs to >>>>>>> get an anonymous GRUU from the SSP then use that to fabricate >>>>>>> it's anonymous GRUU. I think that if you modified what you >>>>>>> have in the draft now to use anonymous GRUUs from the SSP, >>>>>>> you could get this to work. >>>>>>> >>>>>>> I think it would be worth adding an example showing an >>>>>>> anonymous call. I know lots of people goes "who cares, that's >>>>>>> a corner case" but many of the environments where we want to >>>>>>> deploy GIN, it will be a requirement to support anonymous >>>>>>> call - not many people need them but governments are pretty >>>>>>> adamant about making sure the people who do need them can >>>>>>> >>>>> have them. >>>>> >>>>>>> Could you put a Note telling the RFC Ed to remove section 9. >>>>>>> If anyone ever needs to read that they can find the draft. >>>>>>> >>>>>>> Nice draft - can't say I like it but I can live with it and I >>>>>>> suspect most people will come to the same conclusion after >>>>>>> thinking about it for awhile. Something most people can live >>>>>>> with I view as huge success for this topic. It will be >>>>>>> infinitely better than the current situation of many things >>>>>>> that sounds close but when you look at them in detail don't >>>>>>> interoperate. >>>>>>> >>>>>>> Thanks, Cullen >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cullen Jennings >>>>>>> For corporate legal information go to: >>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > From adam@nostrum.com Thu May 20 10:37:54 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 5BFD53A6840 for ; Thu, 20 May 2010 10:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, SPF_PASS=-0.001, URI_HEX=0.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 u6LvaEQFN+aG for ; Thu, 20 May 2010 10:37: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 2204C3A67F8 for ; Thu, 20 May 2010 10:37:51 -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 o4KHbgUT019815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 12:37:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF57366.1060205@nostrum.com> Date: Thu, 20 May 2010 12:37:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> <4BF54577.4000909@cisco.com> In-Reply-To: <4BF54577.4000909@cisco.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" Subject: Re: [martini] GIN and anonymous GRUUS 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, 20 May 2010 17:37:54 -0000 Okay, wait. Before we go trundling down the "let's re-engineer this" hole, I'd like someone to concisely state what's wrong with the currently proposed mechanism. There's a lot of back-to-the-drawing-board proposals implied by the last few messages, without any clear indication why. The one use "issue," raised by Cullen, appears to be based on a misunderstanding. Everything else looks like an "ooh, shiny!" race off to see if we can design something else just for the fun of it. /a On 5/20/10 9:21 AM, Paul Kyzivat wrote: > Cullen, > > Focusing on the B2BUA PBX case, the contact address that the outside > world sees will be one inserted by the pbx b2bua, not the one inserted > by the phone. In that case, there are two issues: > - how does the phone indicate it wants to make an anonymous call? > (Privacy header?) > - how does the pbx get a supply of anonymous gruus? > There is in that case no need to convey anonymous gruus to the phones. > > (The above assumes privacy only for calls to the outside world. > Privacy on calls between phones connected to the same pbx is a > *little* different. If there is still a b2bua in the path, its more or > less the same, except that contact used probably won't be a gruu at > all, just something cooked up by the b2bua for local use.) > > So, in this case the hard part is to get a temp gruu for the pbx to > use. Assuming the ssp registrar supports temp gruus, this is doable, > but there are potential efficiency issues. I'm now wondering if those > need to be investigated, or if they can be left as implementation issues. > > We haven't spoken much about the pbx-as-proxy case. That is a bit more > difficult, because it becomes necessary to convey temp gruus to the > phones. > > Thanks, > Paul > > Cullen Jennings wrote: >> So I think this conversation is going a good way to find a solution >> to this. For a second, lets just consider the B2BUA style PBX. >> Lets say that the PBX has 10 phones that register with the PBX and >> the PBX does one registration with the SSP that uses GIN with GRUU. >> The phones may not even support GRUU and their registration have very >> little to do with the registration to the SSP. I realize that to get >> a temp GRUU to each of the phones, we would either need a way for the >> PBX to generate multiple temp GRUU based on some template it got from >> the SSP or the PBX would need to get multiple temp GRUU from the SSP. >> We should look at if there is a reasonable design to achieve either >> of those that does not require changes to GRUU. I suspect their might >> be. But even if there is not, I think there is a simple solution to >> this. >> >> Keep in mind my issue is not the phones all all temp gruu, my issues >> is that anonymous calls need to not reveal which PBX it is. So one >> solution would be to have the PBX get a single temp GRUU and when the >> PBX makes an anonymous call to the SSP use the temp gruu then get >> some more temp gruu for future use. This would probably work better >> if it had a small pool of available temp gruu for use when a temp >> gruu is need but you get the idea. >> Another option would be just to have the GIN draft request the number >> of temp GRUU that the PBX wants the SSP to return. >> There's a ton of way to skin this cat but I am strongly against >> depreciating anonymous call support of 3261 when using the GIN draft >> - I view that as GIN breaking SIP. It's a critical feature when using >> SIP for PSTN replacement and I believe it has very important value >> many types of SIP communication. >> >> >> On May 19, 2010, at 11:11 AM, Paul Kyzivat wrote: >> >>> >>> Adam Roach wrote: >>>> Actually, you're right. I just re-read the "anonymous public GRUU" >>>> section again, and it doesn't reveal the information that we're >>>> fretting about. (I also found a minor error in some of the >>>> examples, but I'm fixing that in -03). >>>> The example that the document gives for one of these GRUUs looks >>>> like this: >>>> sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P >>> >>> The above doesn't sound right. A public gruu for the pbx ought to >>> look like: >>> >>> sip:pbx@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>> >>> >>> So anything derived off of it, for use as temp gruus, would also >>> contain the identification of the pbx. >>> >>> If the pbx also got a temp-gruu assigned by the ssp, then it could >>> derive its own temp gruus off of that. But assigning temp gruus for >>> a pbx registration is going to be problematic: >>> >>> *Every* time a REGISTER (or re-REGISTER) request is processed, if >>> the registrar supports temp-gruus and the registering UA supports >>> gruu, then a new temp-gruu is assigned and returned. In principle >>> that applies to implicitly registered AORs as well. There will be a >>> new temp-gruu for *each* implicitly registered AOR. Those aren't >>> returned, but if there is a subscription to the reg event package >>> convering those AORs, then it will need to generate a notification >>> containing all those temp-gruus. (See RFC 5628.) There is no good >>> way to know if those are desired, so they are to be generated >>> regardless. This works for the small numbers of implicit AORs used >>> in IMS (ignoring the pbx stuff). But it could be a lot of work to >>> generate, and a big notification to deliver all those temp gruus. >>> And it will happen again every time the registration is refreshed. >>> >>> So, till now we GIN says not to generate temp gruus. >>> >>> If we need the SSP to generate a temp gruu for the pbx to use in >>> generating its own temp gruus, but we don't want the ssp to generate >>> temp gruus for all the implicitly registered AORs, then some added >>> specification is required. >>> >>> Thanks, >>> Paul >>> >>>> Going to Cullen's concern: if I got one of these URIs, it's not >>>> clear what part of that I could mine to find out whether it was a >>>> Women's Shelter (unless example.com has precisely one customer, in >>>> which case I don't think there's anything we can do anyway). >>>> Cullen: can you elaborate on your use case, providing specific >>>> examples of the URIs that you think leak information? >>>> /a >>>> On 5/19/10 9:32 AM, Elwell, John wrote: >>>>> Adam, >>>>> >>>>> Although I was generalising the use case that Cullen put forward, >>>>> doesn't the existing approach 2 satisfy this anyway? >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>> Sent: 19 May 2010 15:18 >>>>>> To: Elwell, John >>>>>> Cc: Cullen Jennings; martini@ietf.org >>>>>> Subject: Re: [martini] GIN and anonymous GRUUS >>>>>> >>>>>> I'm sympathetic to the point, but don't think it's something that >>>>>> MARTINI can appropriately solve. What's critical here is to >>>>>> realize that >>>>>> GIN does not make this problem any better or worse than the base >>>>>> GRUU >>>>>> mechanism. >>>>>> >>>>>> For example, in a "normal" (i.e., 3263-routed, GIN-free) >>>>>> environment, >>>>>> imagine you came into possession of a temp GRUU >>>>>> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat. >>>>>> com". And, >>>>>> after a little research, you determine that the company does, >>>>>> in fact, >>>>>> consist of exactly two guys and their goat. You can be pretty >>>>>> certain >>>>>> that the call came from one of the two guys who comprise the company >>>>>> (unless the goat is really quite talented). >>>>>> >>>>>> So, yeah, it's a shortcoming of GRUUs in general. If you want >>>>>> to solve >>>>>> this problem, what is really needed is for you to take an >>>>>> rfc5627bis to >>>>>> DISPATCH. >>>>>> >>>>>> But I think it's a bit of a stretch to say "GRUUs as >>>>>> currently defined >>>>>> have this shortcoming. You mentioned GRUUs, and in doing so, >>>>>> inherited >>>>>> the shortcoming. Now fix it!" >>>>>> >>>>>> /a >>>>>> >>>>>> On 5/19/10 3:29 AM, Elwell, John wrote: >>>>>>> Cullen makes a good point. In general, MARTINI is targeted >>>>>> at small PBXs, so often an "anonymous" GRUU that still >>>>>> reveals the name of the business will not be sufficient, >>>>>> since the number of users might be very small, they all might >>>>>> be located in the same office, and so on. >>>>>>> John >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: martini-bounces@ietf.org >>>>>>>> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings >>>>>>>> Sent: 19 May 2010 02:19 >>>>>>>> To: martini@ietf.org >>>>>>>> Subject: [martini] GIN and anonymous GRUUS >>>>>>>> >>>>>>>> >>>>>>>> I think the anonymous public GRUUs need some work. Imagine >>>>>>>> that I have a small PBX at a women's shelter. Say they are 5 >>>>>>>> to 10 phones or so and this PBX connects to an SSP. I think >>>>>>>> this is one of the use cases we need anonymous calls to work >>>>>>>> for and when someone makes a call from one of these phones, >>>>>>>> it can not reveal they are at the women's shelter. >>>>>>>> Anonymizing which room they are in at the women's shelter is >>>>>>>> not enough. I'll ignore the self make GRUU section because if >>>>>>>> you could to that, well you would not need GIN in the first place. >>>>>>>> >>>>>>>> Moving on to the Approach 2 - it seem that the PBX needs to >>>>>>>> get an anonymous GRUU from the SSP then use that to fabricate >>>>>>>> it's anonymous GRUU. I think that if you modified what you >>>>>>>> have in the draft now to use anonymous GRUUs from the SSP, >>>>>>>> you could get this to work. >>>>>>>> >>>>>>>> I think it would be worth adding an example showing an >>>>>>>> anonymous call. I know lots of people goes "who cares, that's >>>>>>>> a corner case" but many of the environments where we want to >>>>>>>> deploy GIN, it will be a requirement to support anonymous >>>>>>>> call - not many people need them but governments are pretty >>>>>>>> adamant about making sure the people who do need them can >>>>>> have them. >>>>>>>> Could you put a Note telling the RFC Ed to remove section 9. >>>>>>>> If anyone ever needs to read that they can find the draft. >>>>>>>> >>>>>>>> Nice draft - can't say I like it but I can live with it and I >>>>>>>> suspect most people will come to the same conclusion after >>>>>>>> thinking about it for awhile. Something most people can live >>>>>>>> with I view as huge success for this topic. It will be >>>>>>>> infinitely better than the current situation of many things >>>>>>>> that sounds close but when you look at them in detail don't >>>>>>>> interoperate. >>>>>>>> >>>>>>>> Thanks, Cullen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cullen Jennings >>>>>>>> For corporate legal information go to: >>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> From adam@nostrum.com Thu May 20 14:25:44 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 D18BD3A68B9 for ; Thu, 20 May 2010 14:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, SPF_PASS=-0.001, URI_HEX=0.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 T4rQxY6KUgS2 for ; Thu, 20 May 2010 14:25:42 -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 4DBBE3A68AA for ; Thu, 20 May 2010 14:25:31 -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 o4KLPLcU037312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 16:25:21 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF5A8C1.7070108@nostrum.com> Date: Thu, 20 May 2010 16:25:21 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> <4BF54577.4000909@cisco.com> <4BF57366.1060205@nostrum.com> In-Reply-To: <4BF57366.1060205@nostrum.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" Subject: Re: [martini] GIN and anonymous GRUUS 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, 20 May 2010 21:25:44 -0000 So, I had a pretty long conversation with Cullen, and it turns out that the issue (and I think he's convinced me that it's a real issue) is that the "gr" portion of the anonymous public GRUUs is invariant across multiple temp-gruus. So, using the "women's shelter" example, the issue is that someone receiving a call from a shelter could capture the inbound contact (a temp gruu), and then attempt to contact all the shelters in the area (not a difficult feat). Once he got a contact back with a matching "gr" parameter, he knows precisely which shelter the call originated from. Assuming we need to address this situation, there are really only two watertight solutions that I can think of. To Paul's point (below), I think it's critical that this solution works with phones in the same way that GRUUs do in general. In other words, the b2bua approach in which the phone is telling the PBX that it wants privacy, and the PBX is invoking GRUU procedures is pretty much a non-starter. It's not enabling GRUU procedures; it's enabling some hybrid approach that I don't think gets us to where we want to be. So, the first kind of solution involves the SSP somehow minting a new temp GRUU for each extension, and communicating all the temp GRUUs to the PBX (in a confidential manner, of course). This approach also requires the ability for the PBX to request a new temp GRUU whenever a terminal registers (since a new registration causes creation of a new temp GRUU). I don't think that's tenable, since you basically end up having to send a lot of per-extension state back and forth between the PBX and the SSP. It pretty much negates any benefit of using GIN. In other words, for all the traffic and complication, you'd probably be better off registering each extension individually instead. So I'm not interested in pursuing that one. The second approach involves a kind of distributed cookie factory. I know this sounds complicated at first blush, but I think it's actually pretty easy to do correctly, especially if we leverage the procedure in appendix A.2 of RFC 5627. Go read that appendix now, since it's pretty important to understand what I'm talking about. Effectively, what we would do is pass along some information from the SSP to the PBX that the PBX uses to mix into the temp-gruu when it generates it. This information could be sent in the REGISTER response. At that point, the PBX could generate temp-gruus that the SSP could correlate to the proper PBX; that the PBX could correlate to the proper terminal; and that outside parties would be unable to correlate to any other temp-gruus. I'm about halfway done with the description of how this would be done, and will post a proposal to the MARTINI list when I think I have something that works. /a On 5/20/10 12:37 PM, Adam Roach wrote: > Okay, wait. Before we go trundling down the "let's re-engineer this" > hole, I'd like someone to concisely state what's wrong with the > currently proposed mechanism. There's a lot of > back-to-the-drawing-board proposals implied by the last few messages, > without any clear indication why. The one use "issue," raised by > Cullen, appears to be based on a misunderstanding. Everything else > looks like an "ooh, shiny!" race off to see if we can design something > else just for the fun of it. > > /a > > On 5/20/10 9:21 AM, Paul Kyzivat wrote: >> Cullen, >> >> Focusing on the B2BUA PBX case, the contact address that the outside >> world sees will be one inserted by the pbx b2bua, not the one >> inserted by the phone. In that case, there are two issues: >> - how does the phone indicate it wants to make an anonymous call? >> (Privacy header?) >> - how does the pbx get a supply of anonymous gruus? >> There is in that case no need to convey anonymous gruus to the phones. >> >> (The above assumes privacy only for calls to the outside world. >> Privacy on calls between phones connected to the same pbx is a >> *little* different. If there is still a b2bua in the path, its more >> or less the same, except that contact used probably won't be a gruu >> at all, just something cooked up by the b2bua for local use.) >> >> So, in this case the hard part is to get a temp gruu for the pbx to >> use. Assuming the ssp registrar supports temp gruus, this is doable, >> but there are potential efficiency issues. I'm now wondering if those >> need to be investigated, or if they can be left as implementation >> issues. >> >> We haven't spoken much about the pbx-as-proxy case. That is a bit >> more difficult, because it becomes necessary to convey temp gruus to >> the phones. >> >> Thanks, >> Paul >> >> Cullen Jennings wrote: >>> So I think this conversation is going a good way to find a solution >>> to this. For a second, lets just consider the B2BUA style PBX. >>> Lets say that the PBX has 10 phones that register with the PBX and >>> the PBX does one registration with the SSP that uses GIN with GRUU. >>> The phones may not even support GRUU and their registration have >>> very little to do with the registration to the SSP. I realize that >>> to get a temp GRUU to each of the phones, we would either need a way >>> for the PBX to generate multiple temp GRUU based on some template it >>> got from the SSP or the PBX would need to get multiple temp GRUU >>> from the SSP. We should look at if there is a reasonable design to >>> achieve either of those that does not require changes to GRUU. I >>> suspect their might be. But even if there is not, I think there is a >>> simple solution to this. >>> >>> Keep in mind my issue is not the phones all all temp gruu, my issues >>> is that anonymous calls need to not reveal which PBX it is. So one >>> solution would be to have the PBX get a single temp GRUU and when >>> the PBX makes an anonymous call to the SSP use the temp gruu then >>> get some more temp gruu for future use. This would probably work >>> better if it had a small pool of available temp gruu for use when a >>> temp gruu is need but you get the idea. >>> Another option would be just to have the GIN draft request the >>> number of temp GRUU that the PBX wants the SSP to return. >>> There's a ton of way to skin this cat but I am strongly against >>> depreciating anonymous call support of 3261 when using the GIN draft >>> - I view that as GIN breaking SIP. It's a critical feature when >>> using SIP for PSTN replacement and I believe it has very important >>> value many types of SIP communication. >>> >>> >>> On May 19, 2010, at 11:11 AM, Paul Kyzivat wrote: >>> >>>> >>>> Adam Roach wrote: >>>>> Actually, you're right. I just re-read the "anonymous public GRUU" >>>>> section again, and it doesn't reveal the information that we're >>>>> fretting about. (I also found a minor error in some of the >>>>> examples, but I'm fixing that in -03). >>>>> The example that the document gives for one of these GRUUs looks >>>>> like this: >>>>> sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P >>>> >>>> >>>> The above doesn't sound right. A public gruu for the pbx ought to >>>> look like: >>>> >>>> sip:pbx@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>> >>>> >>>> So anything derived off of it, for use as temp gruus, would also >>>> contain the identification of the pbx. >>>> >>>> If the pbx also got a temp-gruu assigned by the ssp, then it could >>>> derive its own temp gruus off of that. But assigning temp gruus for >>>> a pbx registration is going to be problematic: >>>> >>>> *Every* time a REGISTER (or re-REGISTER) request is processed, if >>>> the registrar supports temp-gruus and the registering UA supports >>>> gruu, then a new temp-gruu is assigned and returned. In principle >>>> that applies to implicitly registered AORs as well. There will be a >>>> new temp-gruu for *each* implicitly registered AOR. Those aren't >>>> returned, but if there is a subscription to the reg event package >>>> convering those AORs, then it will need to generate a notification >>>> containing all those temp-gruus. (See RFC 5628.) There is no good >>>> way to know if those are desired, so they are to be generated >>>> regardless. This works for the small numbers of implicit AORs used >>>> in IMS (ignoring the pbx stuff). But it could be a lot of work to >>>> generate, and a big notification to deliver all those temp gruus. >>>> And it will happen again every time the registration is refreshed. >>>> >>>> So, till now we GIN says not to generate temp gruus. >>>> >>>> If we need the SSP to generate a temp gruu for the pbx to use in >>>> generating its own temp gruus, but we don't want the ssp to >>>> generate temp gruus for all the implicitly registered AORs, then >>>> some added specification is required. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Going to Cullen's concern: if I got one of these URIs, it's not >>>>> clear what part of that I could mine to find out whether it was a >>>>> Women's Shelter (unless example.com has precisely one customer, in >>>>> which case I don't think there's anything we can do anyway). >>>>> Cullen: can you elaborate on your use case, providing specific >>>>> examples of the URIs that you think leak information? >>>>> /a >>>>> On 5/19/10 9:32 AM, Elwell, John wrote: >>>>>> Adam, >>>>>> >>>>>> Although I was generalising the use case that Cullen put forward, >>>>>> doesn't the existing approach 2 satisfy this anyway? >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>>> Sent: 19 May 2010 15:18 >>>>>>> To: Elwell, John >>>>>>> Cc: Cullen Jennings; martini@ietf.org >>>>>>> Subject: Re: [martini] GIN and anonymous GRUUS >>>>>>> >>>>>>> I'm sympathetic to the point, but don't think it's something that >>>>>>> MARTINI can appropriately solve. What's critical here is to >>>>>>> realize that >>>>>>> GIN does not make this problem any better or worse than the base >>>>>>> GRUU >>>>>>> mechanism. >>>>>>> >>>>>>> For example, in a "normal" (i.e., 3263-routed, GIN-free) >>>>>>> environment, >>>>>>> imagine you came into possession of a temp GRUU >>>>>>> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat. >>>>>>> com". And, >>>>>>> after a little research, you determine that the company does, >>>>>>> in fact, >>>>>>> consist of exactly two guys and their goat. You can be pretty >>>>>>> certain >>>>>>> that the call came from one of the two guys who comprise the >>>>>>> company >>>>>>> (unless the goat is really quite talented). >>>>>>> >>>>>>> So, yeah, it's a shortcoming of GRUUs in general. If you want >>>>>>> to solve >>>>>>> this problem, what is really needed is for you to take an >>>>>>> rfc5627bis to >>>>>>> DISPATCH. >>>>>>> >>>>>>> But I think it's a bit of a stretch to say "GRUUs as >>>>>>> currently defined >>>>>>> have this shortcoming. You mentioned GRUUs, and in doing so, >>>>>>> inherited >>>>>>> the shortcoming. Now fix it!" >>>>>>> >>>>>>> /a >>>>>>> >>>>>>> On 5/19/10 3:29 AM, Elwell, John wrote: >>>>>>>> Cullen makes a good point. In general, MARTINI is targeted >>>>>>> at small PBXs, so often an "anonymous" GRUU that still >>>>>>> reveals the name of the business will not be sufficient, >>>>>>> since the number of users might be very small, they all might >>>>>>> be located in the same office, and so on. >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: martini-bounces@ietf.org >>>>>>>>> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings >>>>>>>>> Sent: 19 May 2010 02:19 >>>>>>>>> To: martini@ietf.org >>>>>>>>> Subject: [martini] GIN and anonymous GRUUS >>>>>>>>> >>>>>>>>> >>>>>>>>> I think the anonymous public GRUUs need some work. Imagine >>>>>>>>> that I have a small PBX at a women's shelter. Say they are 5 >>>>>>>>> to 10 phones or so and this PBX connects to an SSP. I think >>>>>>>>> this is one of the use cases we need anonymous calls to work >>>>>>>>> for and when someone makes a call from one of these phones, >>>>>>>>> it can not reveal they are at the women's shelter. >>>>>>>>> Anonymizing which room they are in at the women's shelter is >>>>>>>>> not enough. I'll ignore the self make GRUU section because if >>>>>>>>> you could to that, well you would not need GIN in the first >>>>>>>>> place. >>>>>>>>> >>>>>>>>> Moving on to the Approach 2 - it seem that the PBX needs to >>>>>>>>> get an anonymous GRUU from the SSP then use that to fabricate >>>>>>>>> it's anonymous GRUU. I think that if you modified what you >>>>>>>>> have in the draft now to use anonymous GRUUs from the SSP, >>>>>>>>> you could get this to work. >>>>>>>>> >>>>>>>>> I think it would be worth adding an example showing an >>>>>>>>> anonymous call. I know lots of people goes "who cares, that's >>>>>>>>> a corner case" but many of the environments where we want to >>>>>>>>> deploy GIN, it will be a requirement to support anonymous >>>>>>>>> call - not many people need them but governments are pretty >>>>>>>>> adamant about making sure the people who do need them can >>>>>>> have them. >>>>>>>>> Could you put a Note telling the RFC Ed to remove section 9. >>>>>>>>> If anyone ever needs to read that they can find the draft. >>>>>>>>> >>>>>>>>> Nice draft - can't say I like it but I can live with it and I >>>>>>>>> suspect most people will come to the same conclusion after >>>>>>>>> thinking about it for awhile. Something most people can live >>>>>>>>> with I view as huge success for this topic. It will be >>>>>>>>> infinitely better than the current situation of many things >>>>>>>>> that sounds close but when you look at them in detail don't >>>>>>>>> interoperate. >>>>>>>>> >>>>>>>>> Thanks, Cullen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Cullen Jennings >>>>>>>>> For corporate legal information go to: >>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>> >>> >>> Cullen Jennings >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> >>> >>> > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Thu May 20 15:46:04 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 4A4273A67B5 for ; Thu, 20 May 2010 15:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.754 X-Spam-Level: X-Spam-Status: No, score=-8.754 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.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 tesZX7OAprvI for ; Thu, 20 May 2010 15:46:01 -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 338803A67B2 for ; Thu, 20 May 2010 15:46:01 -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: AvsEAMNY9UtAZnwM/2dsb2JhbACeHXGlc5lMhRIE X-IronPort-AV: E=Sophos;i="4.53,273,1272844800"; d="scan'208";a="113221393" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 May 2010 22:45:54 +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 o4KMjsZ9029775; Thu, 20 May 2010 22:45:54 GMT Message-ID: <4BF5BBA3.2080300@cisco.com> Date: Thu, 20 May 2010 18:45:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> <4BF54577.4000909@cisco.com> <4BF57366.1060205@nostrum.com> <4BF5A8C1.7070108@nostrum.com> In-Reply-To: <4BF5A8C1.7070108@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 20 May 2010 22:46:04 -0000 Adam Roach wrote: > So, I had a pretty long conversation with Cullen, and it turns out that > the issue (and I think he's convinced me that it's a real issue) is that > the "gr" portion of the anonymous public GRUUs is invariant across > multiple temp-gruus. > > So, using the "women's shelter" example, the issue is that someone > receiving a call from a shelter could capture the inbound contact (a > temp gruu), and then attempt to contact all the shelters in the area > (not a difficult feat). Once he got a contact back with a matching "gr" > parameter, he knows precisely which shelter the call originated from. > > Assuming we need to address this situation, there are really only two > watertight solutions that I can think of. > > To Paul's point (below), I think it's critical that this solution works > with phones in the same way that GRUUs do in general. In other words, > the b2bua approach in which the phone is telling the PBX that it wants > privacy, and the PBX is invoking GRUU procedures is pretty much a > non-starter. It's not enabling GRUU procedures; it's enabling some > hybrid approach that I don't think gets us to where we want to be. AFAIK we have no documented approach to anonymity using gruus with b2buas, or even with using gruus at all with b2buas. Typically the b2bua is going to replace the contact address supplied by the phone with an address that terminates on the B2BUA. If that contact is a gruu, and the b2bua is the issuer of that gruu, then with luck it will recognize it. If its really clever, it will then decide that it doesn't need to replace it, because it already terminates on the b2bua. If the b2bua is upstream of the proxy/registrar that assigned the gruu the phone is using, then the b2bua will probably not recognize it, and so will replace it with something of its own. When incoming requests reach that address, it will replace with the original (phone-gruu) and forward on. That will work. But it might lose anonymity if it was a temp gruu. If the contact is a gruu assigned by the SSP which is downstream from the b2bua then things get messy. The b2bua may not recognize this, and so replace it. That will then result in a spiral through the SSP. If the b2bua recognizes this (it was an SSP assigned gruu with additions by the pbx to generate a gruu for the phone, then it could leave it alone and things will probably work ok. So it probably can be made to work, but it will take some care, and the precise things that must be done may vary by topology. This needs further investigation. > So, the first kind of solution involves the SSP somehow minting a new > temp GRUU for each extension, and communicating all the temp GRUUs to > the PBX (in a confidential manner, of course). This approach also > requires the ability for the PBX to request a new temp GRUU whenever a > terminal registers (since a new registration causes creation of a new > temp GRUU). When temp gruus were introduced, there was consideration of ways to request new ones. That was discarded since it didn't fit in well with the registration approach to gruu assignment. Instead, the decision was to assign a new temp gruu at every registration, including refreshes. Hence a UA that wants a new temp gruu can get it by re-registering. The cost of this is assigning new temp gruus each registration even if the register was not for that purpose. (Might have been a mistake, but it is what it is.) When I started looking into the gruu reg event extension, and the implications of implicit registrations, it turned out that we had to depend on the reg event package to get temp gruus for implicitly registered AORs. And it implied that every registration refresh had to generate a new temp gruu for every implicitly registered AOR. That wasn't so bad when there might be 1 or 2 implicit registrations per explicit registration. Its not nearly as acceptable when there might be 100-200+ of them. Also, every time this happens, you need to generate a NOTIFY containing all that stuff to any subscriber to any of the implicitly registered AORs. (At least thats how I think it works for IMS.) > I don't think that's tenable, since you basically end up having to send > a lot of per-extension state back and forth between the PBX and the SSP. Yup, that's the bottom line. > It pretty much negates any benefit of using GIN. In other words, for all > the traffic and complication, you'd probably be better off registering > each extension individually instead. > > So I'm not interested in pursuing that one. > > The second approach involves a kind of distributed cookie factory. I > know this sounds complicated at first blush, but I think it's actually > pretty easy to do correctly, especially if we leverage the procedure in > appendix A.2 of RFC 5627. Go read that appendix now, since it's pretty > important to understand what I'm talking about. > > Effectively, what we would do is pass along some information from the > SSP to the PBX that the PBX uses to mix into the temp-gruu when it > generates it. This information could be sent in the REGISTER response. > At that point, the PBX could generate temp-gruus that the SSP could > correlate to the proper PBX; that the PBX could correlate to the proper > terminal; and that outside parties would be unable to correlate to any > other temp-gruus. Note that if you can do this once, you can probably do it twice, so that the phone can generate *its* own gruus using a seed passed to it. Then you wouldn't need all the repetitive gruu generation on every register. But of course it would not be backward compatible. > I'm about halfway done with the description of how this would be done, > and will post a proposal to the MARTINI list when I think I have > something that works. What I learned in several years of working, off and on, on gruu is that side effects keep popping up all over the place. For instance, does this require another extension to the reg event package? Or will it even be possible to discover gruus that way? I don't consider this to be a small undertaking. If we are to do it, I think we should consider if it should apply more broadly than to martini. I'd prefer if we could see fit to postpone this part to a follow on effort. Until then, maybe those outfits that can't live with their pbx being identifiable might have to do something else. Thanks, Paul > /a > > On 5/20/10 12:37 PM, Adam Roach wrote: >> Okay, wait. Before we go trundling down the "let's re-engineer this" >> hole, I'd like someone to concisely state what's wrong with the >> currently proposed mechanism. There's a lot of >> back-to-the-drawing-board proposals implied by the last few messages, >> without any clear indication why. The one use "issue," raised by >> Cullen, appears to be based on a misunderstanding. Everything else >> looks like an "ooh, shiny!" race off to see if we can design something >> else just for the fun of it. >> >> /a >> >> On 5/20/10 9:21 AM, Paul Kyzivat wrote: >>> Cullen, >>> >>> Focusing on the B2BUA PBX case, the contact address that the outside >>> world sees will be one inserted by the pbx b2bua, not the one >>> inserted by the phone. In that case, there are two issues: >>> - how does the phone indicate it wants to make an anonymous call? >>> (Privacy header?) >>> - how does the pbx get a supply of anonymous gruus? >>> There is in that case no need to convey anonymous gruus to the phones. >>> >>> (The above assumes privacy only for calls to the outside world. >>> Privacy on calls between phones connected to the same pbx is a >>> *little* different. If there is still a b2bua in the path, its more >>> or less the same, except that contact used probably won't be a gruu >>> at all, just something cooked up by the b2bua for local use.) >>> >>> So, in this case the hard part is to get a temp gruu for the pbx to >>> use. Assuming the ssp registrar supports temp gruus, this is doable, >>> but there are potential efficiency issues. I'm now wondering if those >>> need to be investigated, or if they can be left as implementation >>> issues. >>> >>> We haven't spoken much about the pbx-as-proxy case. That is a bit >>> more difficult, because it becomes necessary to convey temp gruus to >>> the phones. >>> >>> Thanks, >>> Paul >>> >>> Cullen Jennings wrote: >>>> So I think this conversation is going a good way to find a solution >>>> to this. For a second, lets just consider the B2BUA style PBX. >>>> Lets say that the PBX has 10 phones that register with the PBX and >>>> the PBX does one registration with the SSP that uses GIN with GRUU. >>>> The phones may not even support GRUU and their registration have >>>> very little to do with the registration to the SSP. I realize that >>>> to get a temp GRUU to each of the phones, we would either need a way >>>> for the PBX to generate multiple temp GRUU based on some template it >>>> got from the SSP or the PBX would need to get multiple temp GRUU >>>> from the SSP. We should look at if there is a reasonable design to >>>> achieve either of those that does not require changes to GRUU. I >>>> suspect their might be. But even if there is not, I think there is a >>>> simple solution to this. >>>> >>>> Keep in mind my issue is not the phones all all temp gruu, my issues >>>> is that anonymous calls need to not reveal which PBX it is. So one >>>> solution would be to have the PBX get a single temp GRUU and when >>>> the PBX makes an anonymous call to the SSP use the temp gruu then >>>> get some more temp gruu for future use. This would probably work >>>> better if it had a small pool of available temp gruu for use when a >>>> temp gruu is need but you get the idea. >>>> Another option would be just to have the GIN draft request the >>>> number of temp GRUU that the PBX wants the SSP to return. >>>> There's a ton of way to skin this cat but I am strongly against >>>> depreciating anonymous call support of 3261 when using the GIN draft >>>> - I view that as GIN breaking SIP. It's a critical feature when >>>> using SIP for PSTN replacement and I believe it has very important >>>> value many types of SIP communication. >>>> >>>> >>>> On May 19, 2010, at 11:11 AM, Paul Kyzivat wrote: >>>> >>>>> >>>>> Adam Roach wrote: >>>>>> Actually, you're right. I just re-read the "anonymous public GRUU" >>>>>> section again, and it doesn't reveal the information that we're >>>>>> fretting about. (I also found a minor error in some of the >>>>>> examples, but I'm fixing that in -03). >>>>>> The example that the document gives for one of these GRUUs looks >>>>>> like this: >>>>>> sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P >>>>> >>>>> >>>>> >>>>> The above doesn't sound right. A public gruu for the pbx ought to >>>>> look like: >>>>> >>>>> sip:pbx@ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>> >>>>> >>>>> So anything derived off of it, for use as temp gruus, would also >>>>> contain the identification of the pbx. >>>>> >>>>> If the pbx also got a temp-gruu assigned by the ssp, then it could >>>>> derive its own temp gruus off of that. But assigning temp gruus for >>>>> a pbx registration is going to be problematic: >>>>> >>>>> *Every* time a REGISTER (or re-REGISTER) request is processed, if >>>>> the registrar supports temp-gruus and the registering UA supports >>>>> gruu, then a new temp-gruu is assigned and returned. In principle >>>>> that applies to implicitly registered AORs as well. There will be a >>>>> new temp-gruu for *each* implicitly registered AOR. Those aren't >>>>> returned, but if there is a subscription to the reg event package >>>>> convering those AORs, then it will need to generate a notification >>>>> containing all those temp-gruus. (See RFC 5628.) There is no good >>>>> way to know if those are desired, so they are to be generated >>>>> regardless. This works for the small numbers of implicit AORs used >>>>> in IMS (ignoring the pbx stuff). But it could be a lot of work to >>>>> generate, and a big notification to deliver all those temp gruus. >>>>> And it will happen again every time the registration is refreshed. >>>>> >>>>> So, till now we GIN says not to generate temp gruus. >>>>> >>>>> If we need the SSP to generate a temp gruu for the pbx to use in >>>>> generating its own temp gruus, but we don't want the ssp to >>>>> generate temp gruus for all the implicitly registered AORs, then >>>>> some added specification is required. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Going to Cullen's concern: if I got one of these URIs, it's not >>>>>> clear what part of that I could mine to find out whether it was a >>>>>> Women's Shelter (unless example.com has precisely one customer, in >>>>>> which case I don't think there's anything we can do anyway). >>>>>> Cullen: can you elaborate on your use case, providing specific >>>>>> examples of the URIs that you think leak information? >>>>>> /a >>>>>> On 5/19/10 9:32 AM, Elwell, John wrote: >>>>>>> Adam, >>>>>>> >>>>>>> Although I was generalising the use case that Cullen put forward, >>>>>>> doesn't the existing approach 2 satisfy this anyway? >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>>>> Sent: 19 May 2010 15:18 >>>>>>>> To: Elwell, John >>>>>>>> Cc: Cullen Jennings; martini@ietf.org >>>>>>>> Subject: Re: [martini] GIN and anonymous GRUUS >>>>>>>> >>>>>>>> I'm sympathetic to the point, but don't think it's something that >>>>>>>> MARTINI can appropriately solve. What's critical here is to >>>>>>>> realize that >>>>>>>> GIN does not make this problem any better or worse than the base >>>>>>>> GRUU >>>>>>>> mechanism. >>>>>>>> >>>>>>>> For example, in a "normal" (i.e., 3263-routed, GIN-free) >>>>>>>> environment, >>>>>>>> imagine you came into possession of a temp GRUU >>>>>>>> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat. >>>>>>>> com". And, >>>>>>>> after a little research, you determine that the company does, >>>>>>>> in fact, >>>>>>>> consist of exactly two guys and their goat. You can be pretty >>>>>>>> certain >>>>>>>> that the call came from one of the two guys who comprise the >>>>>>>> company >>>>>>>> (unless the goat is really quite talented). >>>>>>>> >>>>>>>> So, yeah, it's a shortcoming of GRUUs in general. If you want >>>>>>>> to solve >>>>>>>> this problem, what is really needed is for you to take an >>>>>>>> rfc5627bis to >>>>>>>> DISPATCH. >>>>>>>> >>>>>>>> But I think it's a bit of a stretch to say "GRUUs as >>>>>>>> currently defined >>>>>>>> have this shortcoming. You mentioned GRUUs, and in doing so, >>>>>>>> inherited >>>>>>>> the shortcoming. Now fix it!" >>>>>>>> >>>>>>>> /a >>>>>>>> >>>>>>>> On 5/19/10 3:29 AM, Elwell, John wrote: >>>>>>>>> Cullen makes a good point. In general, MARTINI is targeted >>>>>>>> at small PBXs, so often an "anonymous" GRUU that still >>>>>>>> reveals the name of the business will not be sufficient, >>>>>>>> since the number of users might be very small, they all might >>>>>>>> be located in the same office, and so on. >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: martini-bounces@ietf.org >>>>>>>>>> [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings >>>>>>>>>> Sent: 19 May 2010 02:19 >>>>>>>>>> To: martini@ietf.org >>>>>>>>>> Subject: [martini] GIN and anonymous GRUUS >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think the anonymous public GRUUs need some work. Imagine >>>>>>>>>> that I have a small PBX at a women's shelter. Say they are 5 >>>>>>>>>> to 10 phones or so and this PBX connects to an SSP. I think >>>>>>>>>> this is one of the use cases we need anonymous calls to work >>>>>>>>>> for and when someone makes a call from one of these phones, >>>>>>>>>> it can not reveal they are at the women's shelter. >>>>>>>>>> Anonymizing which room they are in at the women's shelter is >>>>>>>>>> not enough. I'll ignore the self make GRUU section because if >>>>>>>>>> you could to that, well you would not need GIN in the first >>>>>>>>>> place. >>>>>>>>>> >>>>>>>>>> Moving on to the Approach 2 - it seem that the PBX needs to >>>>>>>>>> get an anonymous GRUU from the SSP then use that to fabricate >>>>>>>>>> it's anonymous GRUU. I think that if you modified what you >>>>>>>>>> have in the draft now to use anonymous GRUUs from the SSP, >>>>>>>>>> you could get this to work. >>>>>>>>>> >>>>>>>>>> I think it would be worth adding an example showing an >>>>>>>>>> anonymous call. I know lots of people goes "who cares, that's >>>>>>>>>> a corner case" but many of the environments where we want to >>>>>>>>>> deploy GIN, it will be a requirement to support anonymous >>>>>>>>>> call - not many people need them but governments are pretty >>>>>>>>>> adamant about making sure the people who do need them can >>>>>>>> have them. >>>>>>>>>> Could you put a Note telling the RFC Ed to remove section 9. >>>>>>>>>> If anyone ever needs to read that they can find the draft. >>>>>>>>>> >>>>>>>>>> Nice draft - can't say I like it but I can live with it and I >>>>>>>>>> suspect most people will come to the same conclusion after >>>>>>>>>> thinking about it for awhile. Something most people can live >>>>>>>>>> with I view as huge success for this topic. It will be >>>>>>>>>> infinitely better than the current situation of many things >>>>>>>>>> that sounds close but when you look at them in detail don't >>>>>>>>>> interoperate. >>>>>>>>>> >>>>>>>>>> Thanks, Cullen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cullen Jennings >>>>>>>>>> For corporate legal information go to: >>>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>> _______________________________________________ >>>>> martini mailing list >>>>> martini@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>>> >>>> Cullen Jennings >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> >>>> >>>> >>>> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > From adam@nostrum.com Thu May 20 17: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 CB33B3A6E07 for ; Thu, 20 May 2010 17:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.321, 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 XK8Ct4fA6I81 for ; Thu, 20 May 2010 17:33:18 -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 6971A3A6D8D for ; Thu, 20 May 2010 17:28:43 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4L0SXV0050459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2010 19:28:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF5D3B1.6050700@nostrum.com> Date: Thu, 20 May 2010 19:28:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> <4BF54577.4000909@cisco.com> <4BF57366.1060205@nostrum.com> <4BF5A8C1.7070108@nostrum.com> <4BF5BBA3.2080300@cisco.com> In-Reply-To: <4BF5BBA3.2080300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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: Fri, 21 May 2010 00:33:18 -0000 On 5/20/10 17:45, May 20, Paul Kyzivat wrote: > When I started looking into the gruu reg event extension, and the > implications of implicit registrations, it turned out that we had to > depend on the reg event package to get temp gruus for implicitly > registered AORs. And it implied that every registration refresh had to > generate a new temp gruu for every implicitly registered AOR. That > wasn't so bad when there might be 1 or 2 implicit registrations per > explicit registration. Its not nearly as acceptable when there might > be 100-200+ of them. > > Also, every time this happens, you need to generate a NOTIFY > containing all that stuff to any subscriber to any of the implicitly > registered AORs. (At least thats how I think it works for IMS.) I think that's probably also why the IMS solution works only for pub-gruus. A registered user can have an unbounded set of temp-gruus, so communicating them in a reg event document simply isn't realistic. Keep in mind that any reasonable GRUU server implementation isn't going to keep track of all the temp GRUUs for a user -- it'll use something like the algorithm in appendix A.2. Plus, publishing the temp-gruus right next to their associated AORs kinda defeats the purpose of their anonymity. :) /a From dean.willis@softarmor.com Thu May 20 19:56: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 0F60F3A6A24 for ; Thu, 20 May 2010 19:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_50=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 X5T5ccdYUY8C for ; Thu, 20 May 2010 19:56:37 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6BDC33A6FB4 for ; Thu, 20 May 2010 19:03:24 -0700 (PDT) Received: from [192.168.2.109] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4L21njp009117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 May 2010 21:01:51 -0500 From: Dean Willis To: "Elwell, John" In-Reply-To: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> , <4BF40A96.3040600@nostrum.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 20 May 2010 21:01:44 -0500 Message-ID: <1274407304.1374.2.camel@damnableubu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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: Fri, 21 May 2010 02:56:38 -0000 On Thu, 2010-05-20 at 15:50 +0200, Elwell, John wrote: > Cullen, > > I think that is the wrong way round. A requirements document is generally written before solution documents. And suppose some requirements are not met until a later solutions document, e.g., olive. Does that mean we can't put the requirements document to bed before olive is finished? > > On the other hand, I tend to agree with you that implementers don't like too much useless material. We had a pretty good evaluation of gin against requirements at IETF#77 on slides, and it is that that is captured in the latest gin draft. The analysis has changed very little, except that a couple of new requirements have been added. The IETF#77 MARTINI minutes, with pointer to the slides, goes a long way to showing that we have done due diligence in ensuring the solution meets the requirements. OR we could post updated text on the mailing list, so that it appears in the archive. Do we really need to encumber either draft with this lengthy text? > Easy solution. Publish the requirements, informational track. Publish gin, standards track, containing only that which is required to implement the spec, tight and testable. Make yet another draft, informational track, that shows how gin or gin +olive meet the requirements, and that revises the requirements if necessary. -- Dean From martien.huysmans@ericsson.com Fri May 21 01:43:13 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 0B9923A75F9 for ; Fri, 21 May 2010 01:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.073 X-Spam-Level: X-Spam-Status: No, score=-5.073 tagged_above=-999 required=5 tests=[AWL=1.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 882yDI0fsCrP for ; Fri, 21 May 2010 01:43:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0D1FC3A813E for ; Thu, 20 May 2010 23:09:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-67-4bf623a24da0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F6.E7.08537.2A326FB4; Fri, 21 May 2010 08:09:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 21 May 2010 08:09:38 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Fri, 21 May 2010 08:09:37 +0200 Thread-Topic: martini-gin-02: explicit registration & Reg Event Thread-Index: Acr4rDE8JGOb5qd9Q4SUSaaweNiYNw== 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_B5CE2B521539624E8364D395B6F76B5C1DD647A914ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] martini-gin-02: explicit registration & Reg Event 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: Fri, 21 May 2010 08:43:13 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A914ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi martini-gin-02 states in chapter 5.2: 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). Assume that an individual extension does a "normal, non-bulk" registratrati= on in additional to it's implcit registration. Question: How is a "reg" event SUBSCRIBE in such a case handled? Is it forwarded to t= he PBX? If so, does that PBX have knowledge of the "normal, non-bulk" registration? Regards Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A914ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
martini-gin-02 states in chapter 5.2:
 
A further implication of this property is that an
   individual extension that is implicitly registered may al= so be
   explicitly registered using a normal, non-bulk registrati= on (subject
   to SSP policy).
 
Assume that an individual extension does a "normal, non-bulk"= ; registratration
in additional to it's implcit registration.
 
Question:
How is a "reg" event SUBSCRIBE in such a case handled? Is it= forwarded to the PBX?
If so, does that PBX have knowledge of the "normal, non-bulk"= ; registration?
 
Regards Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A914ESESSCMS0356e_-- From martien.huysmans@ericsson.com Fri May 21 01:51:36 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 8CBE83A7A69 for ; Fri, 21 May 2010 01:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=-0.570, 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 dnJGXNCQvslS for ; Fri, 21 May 2010 01:51:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CD8F23A7A6F for ; Thu, 20 May 2010 23:17:22 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-9e-4bf6256aae7f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C0.F4.21861.A6526FB4; Fri, 21 May 2010 08:17:15 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 21 May 2010 08:17:14 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Fri, 21 May 2010 08:17:14 +0200 Thread-Topic: martini-gin-02: copying URI parameters from REGISTER to Contact Thread-Index: Acr4rUFNCn13hdqORj+orK8tIvCCQQ== 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_B5CE2B521539624E8364D395B6F76B5C1DD647A921ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] martini-gin-02: copying URI parameters from REGISTER to Contact 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: Fri, 21 May 2010 08:51:36 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A921ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi martini-gin-02 ,chapter 5.2 contains in the following text Aside from the "bnc" parameter, all URI parameters present on the "Contact" URI in the REGISTER message MUST be copied to the Contact value stored in the location service. Questions 1) isn't autouser also a URI parameter? If so, should that be returned? 2) Is such a statement future compatible? What if some other RFC in the future includes a URI parameter with simi= lar propery to bnc? /Regards Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A921ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
martini-gin-02 ,chapter 5.2 contains in the following text
   Aside from the "bnc" parameter, all URI paramet= ers present on the
   "Contact" URI in the REGISTER message MUST be c= opied to the Contact
   value stored in the location service.
 
Questions
 
1) isn't autouser also a URI parameter? If so, should that be returned= ?
 
2) Is such a statement future compatible?
    What if some other RFC in the future includes a URI= parameter with similar propery to bnc?
 
/Regards Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A921ESESSCMS0356e_-- From martien.huysmans@ericsson.com Fri May 21 02:04:20 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 00C353A6DDD for ; Fri, 21 May 2010 02:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=-0.536, 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 OnAS2bTnTZYo for ; Fri, 21 May 2010 02:04:19 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A6B9D3A7B7F for ; Thu, 20 May 2010 23:29:46 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-f7-4bf62853e00d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 26.36.21861.35826FB4; Fri, 21 May 2010 08:29:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 21 May 2010 08:29:39 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Fri, 21 May 2010 08:29:37 +0200 Thread-Topic: martini-gin-02: multiple contacts Thread-Index: Acr4rvx2We/KRELAQz+qQ1h9Tc+CPQ== 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_B5CE2B521539624E8364D395B6F76B5C1DD647A93AESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] martini-gin-02: multiple contacts 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: Fri, 21 May 2010 09:04:20 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A93AESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Martini-gin-02, chapter 5.1 contains the following text Second, in at least one "Contact" header field, it must include a Contact URI that contains the URI parameter "bnc", and no user portion (hence no "@" symbol). Assume that 2 Contact header fields are present, one with bnc and one witho= ut. This implies that for inbound SIP Request, forking would take place at the = SSP. 1) Is that always wanted behaviour, e.g. consider SUBSCRIBE in ch 6. 2) What is the use case that people had in mind, when adding this possibili= ty? Regards Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A93AESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Martini-gin-02, chapter 5.1 contains the following text
  Second, in at least one "Contact" header field, it mu= st include a
   Contact URI that contains the URI parameter "bnc&quo= t;, and no user
   portion (hence no "@" symbol).
 
Assume that 2 Contact header fields are present, one with bnc and one = without.
This implies that for inbound SIP Request, forking would take place at= the SSP.
 
1) Is that always wanted behaviour, e.g. consider SUBSCRIBE in ch 6.
 
2) What is the use case that people had in mind, when adding this poss= ibility?
 
Regards Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A93AESESSCMS0356e_-- From martien.huysmans@ericsson.com Fri May 21 02:28:32 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 35F553A80B2 for ; Fri, 21 May 2010 02:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.105 X-Spam-Level: X-Spam-Status: No, score=-5.105 tagged_above=-999 required=5 tests=[AWL=1.493, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 M9OQ-w9v6bOL for ; Fri, 21 May 2010 02:28:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5C7FC3A8B94 for ; Thu, 20 May 2010 23:42:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-ea-4bf62b39f91f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.2B.08537.93B26FB4; Fri, 21 May 2010 08:42:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 21 May 2010 08:42:01 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Fri, 21 May 2010 08:42:00 +0200 Thread-Topic: martini-gin-02: profound impact Thread-Index: Acr4sLb/5NPeOoR+Q62NU2PcO1pbsA== 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_B5CE2B521539624E8364D395B6F76B5C1DD647A94FESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] martini-gin-02: profound impact 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: Fri, 21 May 2010 09:28:32 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A94FESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable martini-gin-02, chapter 2 contains the following text The following paragraph is perhaps the most important in understanding the solution defined in this document. ... In terms of impact to the solution at hand, the following two constraints have the most profound effect: .... ... These are some heavy words: "most important" and "profound ". So I know that I really need understand this chapter. But I do not. Can somebody explain? /Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A94FESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
martini-gin-02, chapter 2 contains the following text
  The following paragraph is perhaps the most important in
  understanding the solution defined in this document.
  ...
  In terms of impact to the solution at hand,
  the following two constraints have the most profound effect: …= .
  ...
 
These are some heavy words: "most important" and "profo= und ".
So I know that I really need understand this chapter.
But I do not. Can somebody explain?
 
/Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A94FESESSCMS0356e_-- From martien.huysmans@ericsson.com Fri May 21 03:22:37 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 869683A853A for ; Fri, 21 May 2010 03:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.439 X-Spam-Level: X-Spam-Status: No, score=-4.439 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 hCxdgX93SxyT for ; Fri, 21 May 2010 03:22:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C1DB53A9311 for ; Thu, 20 May 2010 23:57:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-5b-4bf62ee26549 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.FC.08537.2EE26FB4; Fri, 21 May 2010 08:57:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 21 May 2010 08:57:38 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Fri, 21 May 2010 08:57:37 +0200 Thread-Topic: martini-gin-02: GRUU & BNC Thread-Index: Acr4suWdUowo7tYlT2SecM4rgBsbpA== 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_B5CE2B521539624E8364D395B6F76B5C1DD647A96CESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] martini-gin-02: GRUU & BNC 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: Fri, 21 May 2010 10:22:38 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A96CESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable martini-gin-02, chapter 7.1.1 contains the following text When a PBX registers a Bulk Number Contact (a Contact with a "bnc" parameter), and also invokes GRUU procedures for that Contact during registration, then the SSP will assign a public GRUU to the PBX in the normal fashion. Because the URI being registered contains a "bnc" parameter, the GRUU will also contain a "bnc" parameter. The last sentence states that the GRUU contains a bnc parameter. I guess that this refers 'stored" at the SSP. The GRUU returned to the PBX doesn't contain a "bnc". /Martien --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A96CESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
martini-gin-02, chapter 7.1.1 contains the following text
   When a PBX registers a Bulk Number Contact (a Contact wit= h a "bnc"
   parameter), and also invokes GRUU procedures for that Con= tact during
   registration, then the SSP will assign a public GRUU to t= he PBX in
   the normal fashion.  Because the URI being registere= d contains a
   "bnc" parameter, the GRUU will also contain a &= quot;bnc" parameter.
 
The last sentence states that the GRUU contains a bnc parameter.
I guess that this refers 'stored" at the SSP.
The GRUU returned to the PBX doesn't contain a "bnc".
/Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C1DD647A96CESESSCMS0356e_-- From adam@nostrum.com Fri May 21 09:07: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 0E71F3A6D17 for ; Fri, 21 May 2010 09:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.313, 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 2DfJ2zUU4621 for ; Fri, 21 May 2010 09:07:11 -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 D76723A7600 for ; Fri, 21 May 2010 06:05:31 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4LD5M7m011753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 08:05:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF68513.5020801@nostrum.com> Date: Fri, 21 May 2010 08:05:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> <4BF54577.4000909@cisco.com> <4BF57366.1060205@nostrum.com> <4BF5A8C1.7070108@nostrum.com> <4BF5BBA3.2080300@cisco.com> <4BF5D3B1.6050700@nostrum.com> <4BF67D3E.5020505@cisco.com> In-Reply-To: <4BF67D3E.5020505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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: Fri, 21 May 2010 16:07:12 -0000 On 5/21/10 07:31, May 21, Paul Kyzivat wrote: > > > Adam Roach wrote: >> On 5/20/10 17:45, May 20, Paul Kyzivat wrote: >>> When I started looking into the gruu reg event extension, and the >>> implications of implicit registrations, it turned out that we had to >>> depend on the reg event package to get temp gruus for implicitly >>> registered AORs. And it implied that every registration refresh had >>> to generate a new temp gruu for every implicitly registered AOR. >>> That wasn't so bad when there might be 1 or 2 implicit registrations >>> per explicit registration. Its not nearly as acceptable when there >>> might be 100-200+ of them. >>> >>> Also, every time this happens, you need to generate a NOTIFY >>> containing all that stuff to any subscriber to any of the implicitly >>> registered AORs. (At least thats how I think it works for IMS.) >> >> I think that's probably also why the IMS solution works only for >> pub-gruus. A registered user can have an unbounded set of temp-gruus, >> so communicating them in a reg event document simply isn't realistic. >> Keep in mind that any reasonable GRUU server implementation isn't >> going to keep track of all the temp GRUUs for a user -- it'll use >> something like the algorithm in appendix A.2. >> >> Plus, publishing the temp-gruus right next to their associated AORs >> kinda defeats the purpose of their anonymity. :) > > Well, one would expect that the publication of the temp gruus would be > constrained by policy. Okay. So what I said was "It's impossible. And, even if it were possible, it would be inadvisable." You spoke to the second half. I think we would need to address the first half also. :) /a From fluffy@cisco.com Fri May 21 10:20:34 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 4A48428C5BB for ; Fri, 21 May 2010 10:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.74 X-Spam-Level: X-Spam-Status: No, score=-108.74 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_50=0.001, 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 cwHDoXph2Pfb for ; Fri, 21 May 2010 10:20:32 -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 A2E9A3A853B for ; Fri, 21 May 2010 08:05:01 -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: AvsEADc+9kurRN+J/2dsb2JhbACeIHGkEZlmhRIEg0E X-IronPort-AV: E=Sophos;i="4.53,278,1272844800"; d="scan'208";a="533247236" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 21 May 2010 15:04:55 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4LF4s0W018884; Fri, 21 May 2010 15:04:54 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Fri, 21 May 2010 09:04:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> , <4BF40A96.3040600@nostrum.com> <1274407304.1374.2.camel@damnableubu> <57FFB2AC-118F-4D02-B446-F4808C768D70@cisco.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1078) Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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: Fri, 21 May 2010 17:20:34 -0000 On May 21, 2010, at 8:52 AM, Elwell, John wrote: > Cullen, >=20 > I agree with what you say, but the IETF (certainly RAI) has a history = of producing requirements RFCs, e.g., SPEERMINT, identification (RFC = 3324), e2m security (RFC 4189), trait-based authorisation (RFC 4484), = overload (RFC 5390), media security (5479), floor control (RFC 4376), = media control (RFC 5167), geopriv (RFC 3693), ecrit (RFC 5012)... In = some cases the charter even calls for this, although that is not true = for MARTINI. I think the decision was made at the start of the work to = produce a requirements document. If we want to use a less formal means = of publishing this, and include the write-up on how gin meets the = requirements, I don't mind. I just thought the WG was expecting an RFC. Yah - in this case the WG and the people doing the draft are expecting = an RFC. Changing that now seems bad so I think on this one we should = stay with publishing the the requirements as an RFC - I'm perfectly = happy with whatever the chair can convince the AD to do on this which I = assume will be more or less whatever the chairs want. It's really not a = big deal, I just have a slight preference for moving the analysis out of = the solution RFC.=20 >=20 > And by the way, I could probably cite a bunch more where requirements = and motivation are included in the solution RFC, but that is another = matter. Yep, and at some level the sipping process heavily encouraged this.=20 >=20 > John >=20 >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: 21 May 2010 15:20 > > To: Dean Willis > > Cc: Elwell, John; Spencer Dawkins; martini@ietf.org > > Subject: Re: [martini] GIN: Removing Section 9 (Requirements > > Analysis)? > > > > > > So, I should start with I really don't feel strongly about > > this and I can live with whatever happens .... > > > > Few points about Requirements - people always say they are > > written before the solutions. In all the examples I have seen > > at IETF this is farm more often not the case - certainly not > > true in this case. The requirements and solutions were > > evolved along in parallel over months or years starting in > > SIP Forum and eventually ending up where - I will point the > > requirements are still not done in the sense that they are > > not an RFC and are still changing and the solution is very > > close to WGLC. > > > > Next, I don't think there is any rule that the solution MUST > > meet the requirements. The question I think the WG should ask > > when it goes to publish the solution is basically "Are we > > happy enough with this that we have rough consensus to > > publish it". I very important piece of information for > > everyone to try and decide if they can say yes to that is the > > analysis of how well the solution meets the requirements but > > from a procedural point of view, if the solution does not > > meet all the requirements, the WG could still decide to pub > > request the doc. > > > > So from my point of view, it's nice to have a draft that has > > the requirements (could be same or different draft as the > > solution), it's nice to have a draft with the analysis of how > > well the solution meets the requirements. But once the work > > is done, none of this text has much value as an RFC. It's > > useful to have a pornier in the RFC to find this. The easiest > > way to do that is the names of the draft and just use google > > to find them. They really do last forever on the internet > > unlike whatever the front of them says about 6 months. The > > fundamental reasons we publish them as RFC is that people put > > a bunch of work into them and publishing it as a RFC with the > > person name on it is a way to say thanks for that work. > > > > But I do have a preference for moving text that is of no use > > out of RFC implementors need to read. It can move to another > > RFC, a draft, an email thread that is archived, whatever. > > When considering moving it to an RFC, keep in mind that even > > a simple information RFC takes a ton of time for the AD so > > that means something else is getting dropped. Well worth > > considering the load level on your AD based on reassured > > response time and task drop rate before asking them to > > publish something that would not have much more value as an > > RFC than as a draft. > > > > Oh yah, and +1 to Deans comments below and John I agree with > > your point we want to be able to put finished stuff to bead > > and not have it wait on some future doc. > > > > > > On May 20, 2010, at 8:01 PM, Dean Willis wrote: > > > > > On Thu, 2010-05-20 at 15:50 +0200, Elwell, John wrote: > > >> Cullen, > > >> > > >> I think that is the wrong way round. A requirements > > document is generally written before solution documents. And > > suppose some requirements are not met until a later solutions > > document, e.g., olive. Does that mean we can't put the > > requirements document to bed before olive is finished? > > >> > > >> On the other hand, I tend to agree with you that > > implementers don't like too much useless material. We had a > > pretty good evaluation of gin against requirements at IETF#77 > > on slides, and it is that that is captured in the latest gin > > draft. The analysis has changed very little, except that a > > couple of new requirements have been added. The IETF#77 > > MARTINI minutes, with pointer to the slides, goes a long way > > to showing that we have done due diligence in ensuring the > > solution meets the requirements. OR we could post updated > > text on the mailing list, so that it appears in the archive. > > Do we really need to encumber either draft with this lengthy text? > > >> > > > > > > Easy solution. > > > > > > Publish the requirements, informational track. > > > > > > Publish gin, standards track, containing only that which is > > required to > > > implement the spec, tight and testable. > > > > > > Make yet another draft, informational track, that shows how > > gin or gin > > > +olive meet the requirements, and that revises the requirements if > > > necessary. > > > > > > -- > > > Dean > > > > > > > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From pkyzivat@cisco.com Fri May 21 10:21: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 834E228C5BC for ; Fri, 21 May 2010 10:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.374, 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 PrvS3BsGs0A1 for ; Fri, 21 May 2010 10:21:11 -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 B8C043A7DE9 for ; Fri, 21 May 2010 05:32:24 -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: AvsEAKcZ9ktAZnwM/2dsb2JhbACeIXGicplZhRIE X-IronPort-AV: E=Sophos;i="4.53,278,1272844800"; d="scan'208";a="113273359" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 May 2010 12:31:58 +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 o4LCVvSR000590; Fri, 21 May 2010 12:31:57 GMT Message-ID: <4BF67D3E.5020505@cisco.com> Date: Fri, 21 May 2010 08:31:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> <4BF54577.4000909@cisco.com> <4BF57366.1060205@nostrum.com> <4BF5A8C1.7070108@nostrum.com> <4BF5BBA3.2080300@cisco.com> <4BF5D3B1.6050700@nostrum.com> In-Reply-To: <4BF5D3B1.6050700@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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: Fri, 21 May 2010 17:21:12 -0000 Adam Roach wrote: > On 5/20/10 17:45, May 20, Paul Kyzivat wrote: >> When I started looking into the gruu reg event extension, and the >> implications of implicit registrations, it turned out that we had to >> depend on the reg event package to get temp gruus for implicitly >> registered AORs. And it implied that every registration refresh had to >> generate a new temp gruu for every implicitly registered AOR. That >> wasn't so bad when there might be 1 or 2 implicit registrations per >> explicit registration. Its not nearly as acceptable when there might >> be 100-200+ of them. >> >> Also, every time this happens, you need to generate a NOTIFY >> containing all that stuff to any subscriber to any of the implicitly >> registered AORs. (At least thats how I think it works for IMS.) > > I think that's probably also why the IMS solution works only for > pub-gruus. A registered user can have an unbounded set of temp-gruus, so > communicating them in a reg event document simply isn't realistic. Keep > in mind that any reasonable GRUU server implementation isn't going to > keep track of all the temp GRUUs for a user -- it'll use something like > the algorithm in appendix A.2. > > Plus, publishing the temp-gruus right next to their associated AORs > kinda defeats the purpose of their anonymity. :) Well, one would expect that the publication of the temp gruus would be constrained by policy. Thanks, Paul From fluffy@cisco.com Fri May 21 10:40:14 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 C0B2428C746 for ; Fri, 21 May 2010 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.527 X-Spam-Level: X-Spam-Status: No, score=-108.527 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_50=0.001, 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 DBZE-LrzntHR for ; Fri, 21 May 2010 10:40:13 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7A5443A7774 for ; Fri, 21 May 2010 07:20:26 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPsy9kurR7H+/2dsb2JhbACeIHGkFZllhRIEg0E X-IronPort-AV: E=Sophos;i="4.53,278,1272844800"; d="scan'208";a="133017980" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 21 May 2010 14:20:07 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4LEK6hk021627; Fri, 21 May 2010 14:20:06 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <1274407304.1374.2.camel@damnableubu> Date: Fri, 21 May 2010 08:20:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <57FFB2AC-118F-4D02-B446-F4808C768D70@cisco.com> References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> , <4BF40A96.3040600@nostrum.com> <1274407304.1374.2.camel@damnableubu> To: Dean Willis X-Mailer: Apple Mail (2.1078) Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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: Fri, 21 May 2010 17:40:14 -0000 So, I should start with I really don't feel strongly about this and I = can live with whatever happens .... Few points about Requirements - people always say they are written = before the solutions. In all the examples I have seen at IETF this is = farm more often not the case - certainly not true in this case. The = requirements and solutions were evolved along in parallel over months or = years starting in SIP Forum and eventually ending up where - I will = point the requirements are still not done in the sense that they are not = an RFC and are still changing and the solution is very close to WGLC.=20 Next, I don't think there is any rule that the solution MUST meet the = requirements. The question I think the WG should ask when it goes to = publish the solution is basically "Are we happy enough with this that we = have rough consensus to publish it". I very important piece of = information for everyone to try and decide if they can say yes to that = is the analysis of how well the solution meets the requirements but from = a procedural point of view, if the solution does not meet all the = requirements, the WG could still decide to pub request the doc.=20 So from my point of view, it's nice to have a draft that has the = requirements (could be same or different draft as the solution), it's = nice to have a draft with the analysis of how well the solution meets = the requirements. But once the work is done, none of this text has much = value as an RFC. It's useful to have a pornier in the RFC to find this. = The easiest way to do that is the names of the draft and just use google = to find them. They really do last forever on the internet unlike = whatever the front of them says about 6 months. The fundamental reasons = we publish them as RFC is that people put a bunch of work into them and = publishing it as a RFC with the person name on it is a way to say thanks = for that work.=20 But I do have a preference for moving text that is of no use out of RFC = implementors need to read. It can move to another RFC, a draft, an email = thread that is archived, whatever. When considering moving it to an RFC, = keep in mind that even a simple information RFC takes a ton of time for = the AD so that means something else is getting dropped. Well worth = considering the load level on your AD based on reassured response time = and task drop rate before asking them to publish something that would = not have much more value as an RFC than as a draft.=20 Oh yah, and +1 to Deans comments below and John I agree with your point = we want to be able to put finished stuff to bead and not have it wait on = some future doc.=20 On May 20, 2010, at 8:01 PM, Dean Willis wrote: > On Thu, 2010-05-20 at 15:50 +0200, Elwell, John wrote: >> Cullen, >>=20 >> I think that is the wrong way round. A requirements document is = generally written before solution documents. And suppose some = requirements are not met until a later solutions document, e.g., olive. = Does that mean we can't put the requirements document to bed before = olive is finished? >>=20 >> On the other hand, I tend to agree with you that implementers don't = like too much useless material. We had a pretty good evaluation of gin = against requirements at IETF#77 on slides, and it is that that is = captured in the latest gin draft. The analysis has changed very little, = except that a couple of new requirements have been added. The IETF#77 = MARTINI minutes, with pointer to the slides, goes a long way to showing = that we have done due diligence in ensuring the solution meets the = requirements. OR we could post updated text on the mailing list, so that = it appears in the archive. Do we really need to encumber either draft = with this lengthy text? >>=20 >=20 > Easy solution. >=20 > Publish the requirements, informational track. >=20 > Publish gin, standards track, containing only that which is required = to > implement the spec, tight and testable. >=20 > Make yet another draft, informational track, that shows how gin or gin > +olive meet the requirements, and that revises the requirements if > necessary. >=20 > -- > Dean >=20 >=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 Fri May 21 11:12: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 ADBF13A74FF for ; Fri, 21 May 2010 11:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 42MUHkV9KLFQ for ; Fri, 21 May 2010 11:12:55 -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 389B728C1F7 for ; Fri, 21 May 2010 06:24:49 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4LDOcg9013119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 08:24:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF68996.2080900@nostrum.com> Date: Fri, 21 May 2010 08:24:38 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martien Huysmans References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000704080601040008050907" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: explicit registration & Reg Event 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: Fri, 21 May 2010 18:12:56 -0000 This is a multi-part message in MIME format. --------------000704080601040008050907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/21/10 01:09, May 21, Martien Huysmans wrote: > Hi > martini-gin-02 states in chapter 5.2: > 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). > Assume that an individual extension does a "normal, non-bulk" > registratration > in additional to it's implcit registration. > Question: > How is a "reg" event SUBSCRIBE in such a case handled? Is it forwarded > to the PBX? > If so, does that PBX have knowledge of the "normal, non-bulk" > registration? > I don't think so. It's not a GIN registration, so normal processing applies. /a --------------000704080601040008050907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/21/10 01:09, May 21, Martien Huysmans wrote:
Hi
 
martini-gin-02 states in chapter 5.2:
 
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).
 
Assume that an individual extension does a "normal, non-bulk" registratration
in additional to it's implcit registration.
 
Question:
How is a "reg" event SUBSCRIBE in such a case handled? Is it forwarded to the PBX?
If so, does that PBX have knowledge of the "normal, non-bulk" registration?
 

I don't think so. It's not a GIN registration, so normal processing applies.

/a
--------------000704080601040008050907-- From john.elwell@siemens-enterprise.com Fri May 21 13:16:20 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 D71BC3A6A46 for ; Fri, 21 May 2010 13:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_50=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 D2nB2Ob0TAFE for ; Fri, 21 May 2010 13:12:34 -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 2E0F73A6CA7 for ; Fri, 21 May 2010 07:52:27 -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-255493; Fri, 21 May 2010 16:52:20 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id AF1001EB82AB; Fri, 21 May 2010 16:52:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 21 May 2010 16:52:20 +0200 From: "Elwell, John" To: Cullen Jennings , Dean Willis Date: Fri, 21 May 2010 16:52:18 +0200 Thread-Topic: [martini] GIN: Removing Section 9 (Requirements Analysis)? Thread-Index: Acr48LiLSi0rzbSoRuCn7zAR16eEEwAAx0nw Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> , <4BF40A96.3040600@nostrum.com> <1274407304.1374.2.camel@damnableubu> <57FFB2AC-118F-4D02-B446-F4808C768D70@cisco.com> In-Reply-To: <57FFB2AC-118F-4D02-B446-F4808C768D70@cisco.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" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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: Fri, 21 May 2010 20:18:20 -0000 Cullen, I agree with what you say, but the IETF (certainly RAI) has a history of pr= oducing requirements RFCs, e.g., SPEERMINT, identification (RFC 3324), e2m = security (RFC 4189), trait-based authorisation (RFC 4484), overload (RFC 53= 90), media security (5479), floor control (RFC 4376), media control (RFC 51= 67), geopriv (RFC 3693), ecrit (RFC 5012)... In some cases the charter even= calls for this, although that is not true for MARTINI. I think the decisio= n was made at the start of the work to produce a requirements document. If = we want to use a less formal means of publishing this, and include the writ= e-up on how gin meets the requirements, I don't mind. I just thought the WG= was expecting an RFC. And by the way, I could probably cite a bunch more where requirements and m= otivation are included in the solution RFC, but that is another matter. John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 21 May 2010 15:20 > To: Dean Willis > Cc: Elwell, John; Spencer Dawkins; martini@ietf.org > Subject: Re: [martini] GIN: Removing Section 9 (Requirements=20 > Analysis)? >=20 >=20 > So, I should start with I really don't feel strongly about=20 > this and I can live with whatever happens .... >=20 > Few points about Requirements - people always say they are=20 > written before the solutions. In all the examples I have seen=20 > at IETF this is farm more often not the case - certainly not=20 > true in this case. The requirements and solutions were=20 > evolved along in parallel over months or years starting in=20 > SIP Forum and eventually ending up where - I will point the=20 > requirements are still not done in the sense that they are=20 > not an RFC and are still changing and the solution is very=20 > close to WGLC.=20 >=20 > Next, I don't think there is any rule that the solution MUST=20 > meet the requirements. The question I think the WG should ask=20 > when it goes to publish the solution is basically "Are we=20 > happy enough with this that we have rough consensus to=20 > publish it". I very important piece of information for=20 > everyone to try and decide if they can say yes to that is the=20 > analysis of how well the solution meets the requirements but=20 > from a procedural point of view, if the solution does not=20 > meet all the requirements, the WG could still decide to pub=20 > request the doc.=20 >=20 > So from my point of view, it's nice to have a draft that has=20 > the requirements (could be same or different draft as the=20 > solution), it's nice to have a draft with the analysis of how=20 > well the solution meets the requirements. But once the work=20 > is done, none of this text has much value as an RFC. It's=20 > useful to have a pornier in the RFC to find this. The easiest=20 > way to do that is the names of the draft and just use google=20 > to find them. They really do last forever on the internet=20 > unlike whatever the front of them says about 6 months. The=20 > fundamental reasons we publish them as RFC is that people put=20 > a bunch of work into them and publishing it as a RFC with the=20 > person name on it is a way to say thanks for that work.=20 >=20 > But I do have a preference for moving text that is of no use=20 > out of RFC implementors need to read. It can move to another=20 > RFC, a draft, an email thread that is archived, whatever.=20 > When considering moving it to an RFC, keep in mind that even=20 > a simple information RFC takes a ton of time for the AD so=20 > that means something else is getting dropped. Well worth=20 > considering the load level on your AD based on reassured=20 > response time and task drop rate before asking them to=20 > publish something that would not have much more value as an=20 > RFC than as a draft.=20 >=20 > Oh yah, and +1 to Deans comments below and John I agree with=20 > your point we want to be able to put finished stuff to bead=20 > and not have it wait on some future doc.=20 >=20 >=20 > On May 20, 2010, at 8:01 PM, Dean Willis wrote: >=20 > > On Thu, 2010-05-20 at 15:50 +0200, Elwell, John wrote: > >> Cullen, > >>=20 > >> I think that is the wrong way round. A requirements=20 > document is generally written before solution documents. And=20 > suppose some requirements are not met until a later solutions=20 > document, e.g., olive. Does that mean we can't put the=20 > requirements document to bed before olive is finished? > >>=20 > >> On the other hand, I tend to agree with you that=20 > implementers don't like too much useless material. We had a=20 > pretty good evaluation of gin against requirements at IETF#77=20 > on slides, and it is that that is captured in the latest gin=20 > draft. The analysis has changed very little, except that a=20 > couple of new requirements have been added. The IETF#77=20 > MARTINI minutes, with pointer to the slides, goes a long way=20 > to showing that we have done due diligence in ensuring the=20 > solution meets the requirements. OR we could post updated=20 > text on the mailing list, so that it appears in the archive.=20 > Do we really need to encumber either draft with this lengthy text? > >>=20 > >=20 > > Easy solution. > >=20 > > Publish the requirements, informational track. > >=20 > > Publish gin, standards track, containing only that which is=20 > required to > > implement the spec, tight and testable. > >=20 > > Make yet another draft, informational track, that shows how=20 > gin or gin > > +olive meet the requirements, and that revises the requirements if > > necessary. > >=20 > > -- > > Dean > >=20 > >=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > = From adam@nostrum.com Fri May 21 13:28:13 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 E86D63A6E66 for ; Fri, 21 May 2010 13:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 DFktKKR23AwQ for ; Fri, 21 May 2010 13:27:56 -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 003B128C778 for ; Fri, 21 May 2010 06:32:15 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4LDW5jO013761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 08:32:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF68B55.6010901@nostrum.com> Date: Fri, 21 May 2010 08:32:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martien Huysmans References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000200030208040802020407" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: GRUU & BNC 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: Fri, 21 May 2010 20:28:56 -0000 This is a multi-part message in MIME format. --------------000200030208040802020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/21/10 01:57, May 21, Martien Huysmans wrote: > martini-gin-02, chapter 7.1.1 contains the following text > When a PBX registers a Bulk Number Contact (a Contact with a "bnc" > parameter), and also invokes GRUU procedures for that Contact during > registration, then the SSP will assign a public GRUU to the PBX in > the normal fashion. Because the URI being registered contains a > "bnc" parameter, the GRUU will also contain a "bnc" parameter. > The last sentence states that the GRUU contains a bnc parameter. > I guess that this refers 'stored" at the SSP. > The GRUU returned to the PBX doesn't contain a "bnc". The text is correct; the example is wrong. In -02, it doesn't show the 'bnc' parameter, but it should. That's the "minor error" I referred to in this message: http://www.ietf.org/mail-archive/web/martini/current/msg01555.html I'm getting the impression that I should perhaps pull all the examples out of the document. For all documents we ever produce in the IETF, the text is *always* supposed to govern, with the examples being non-normative. But every time I've made an error in the GIN examples, people have assumed that the text is wrong and the example correct. Clearly the examples are causing more harm than good. /a --------------000200030208040802020407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/21/10 01:57, May 21, Martien Huysmans wrote:
martini-gin-02, chapter 7.1.1 contains the following text
   When a PBX registers a Bulk Number Contact (a Contact with a "bnc"
   parameter), and also invokes GRUU procedures for that Contact during
   registration, then the SSP will assign a public GRUU to the PBX in
   the normal fashion.  Because the URI being registered contains a
   "bnc" parameter, the GRUU will also contain a "bnc" parameter.
 
The last sentence states that the GRUU contains a bnc parameter.
I guess that this refers 'stored" at the SSP.
The GRUU returned to the PBX doesn't contain a "bnc".


The text is correct; the example is wrong. In -02, it doesn't show the 'bnc' parameter, but it should. That's the "minor error" I referred to in this message:

  http://www.ietf.org/mail-archive/web/martini/current/msg01555.html

I'm getting the impression that I should perhaps pull all the examples out of the document. For all documents we ever produce in the IETF, the text is *always* supposed to govern, with the examples being non-normative. But every time I've made an error in the GIN examples, people have assumed that the text is wrong and the example correct. Clearly the examples are causing more harm than good.

/a
--------------000200030208040802020407-- From adam@nostrum.com Fri May 21 13:33:08 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 6675B3A6E8A for ; Fri, 21 May 2010 13:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_50=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 cZ2JH1NS6eqO for ; Fri, 21 May 2010 13:32:56 -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 4800E3A817A for ; Fri, 21 May 2010 06:58:03 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4LDvsFf015653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 08:57:54 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF69162.8050802@nostrum.com> Date: Fri, 21 May 2010 08:57:54 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martien Huysmans References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: profound impact 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: Fri, 21 May 2010 20:33:56 -0000 On 5/21/10 01:42, May 21, Martien Huysmans wrote: > martini-gin-02, chapter 2 contains the following text > The following paragraph is perhaps the most important in > understanding the solution defined in this document. That can probably be tightened up. One can actually implement the solution without understanding these constraints, but such a person may be left boggled by why things are done the way they are. So I'll revise to read "...in understanding the reasons for the design decisions made in this document." > ... > In terms of impact to the solution at hand, > the following two constraints have the most profound effect: …. > ... > > These are some heavy words: "most important" and "profound ". > So I know that I really need understand this chapter. > But I do not. Can somebody explain? Wow. I thought the two highlighted constraints were written in clear, concise, unambiguous, and easy-to-understand language. Perhaps I presume too much knowledge on behalf of my audience. For your benefit, I'll try to explain these two constraints more explicitly below. Let me know if there's something regarding which you need further explanation. "(1) The PBX cannot be assumed to be assigned a static IP address" This means that the PBX may or may not have a static (unchanging) IP Address (the unique identifier used to indicate end-points on the Internet), and that we, as designers of the GIN solution, cannot make any assumptions one way or the other about whether this is true. "(2) No DNS entry can be relied upon to consistently resolve to the IP address of the PBX." This means that there may or may not be an entry in the global Domain Name Service database (the distributed database used on the internet to convert human-readable names into IP addresses) that, when resolved, produces that IP address of the PBX, and that we, as designers of the GIN solution, cannot make any assumptions one way or another about whether this is true. If your confusion was in relation to any of the other three sentences in the section, let me know, and I can try to clear up their intended meaning. They're less central to the thesis of this section, but I don't want them to leave you confused. And, if your confusion isn't regarding any single sentence, but rather the gestalt of the whole section, the short summary is: "This document proposes doing some things that seem pretty stupid to anyone who really understands SIP, but we have some good reasons for doing so. These reasons are explained by the requirements document, and here are the two that make the biggest difference." Does any of that help? /a From adam@nostrum.com Fri May 21 14:44:43 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 D8D8B3A6884 for ; Fri, 21 May 2010 14:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_50=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 mxUSZVNDvr+G for ; Fri, 21 May 2010 14:44:43 -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 910643A6407 for ; Fri, 21 May 2010 14:44:39 -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 o4LLiVoQ050909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 May 2010 16:44:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF6FEBF.4030403@nostrum.com> Date: Fri, 21 May 2010 16:44:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "martini@ietf.org" References: <4BF310DB.1000700@nostrum.com> In-Reply-To: <4BF310DB.1000700@nostrum.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) Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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: Fri, 21 May 2010 21:44:44 -0000 Okay, we're really trying to wind this draft down. If I don't hear any objections to the proposal below, I'm going to assume that no one cares except me and Hadriel. Unless you reply with an objection before COB Monday, I'm updating the document to reflect this proposal. /a On 5/18/10 5:12 PM, Adam Roach wrote: > We're down to a fairly small number of open issues on GIN. > > Currently, section 7.2.2 of the GIN document describes some fairly > specific behavior for "reg" event handling. In particular, it says > that subscriptions to the state of a single phone number are forwarded > by the SSP to the PBX. There's some logic in the document about why I > thought this was a Good Idea, and even "important." > > At the most recent interim, we had a fairly long discussion about > whether this was actually the "right" thing to do. Hadriel made some > convincing arguments that the SSP should service the subscriptions, > since it really "owns" the URIs in question. > > The "vermouth" draft delves a bit deeper into some related issues, but > it's somewhat less developed than GIN at this point. We don't want to > make GIN dependent on vermouth, and we really can't leave a treatment > of the "reg" event package out of GIN: GIN deals intimately with > registration. Under any reasonable "you break it you buy it" > principle, we're on the hook for coming up with a sane treatment of > the "reg" event package. > > After an off-list exchange with Hadriel, I *think* we're both okay if > that treatment is as simple as "here are the properties if you handle > it at the SSP, here are the properties if you handle it at the PBX, > and which you choose is a matter of policy." (I don't mean to put > words in Hadriel's mouth, and I'm sure he'll correct me if my summary > isn't consistent with his position). > > This approach is actually pretty well in line with the way that event > packages are handled in general. It also allows for some clever (if > complicated) solutions to the problem in which the SSP services the > subscription, but incorporates information it has learned from the PBX > (say, through back-end subscriptions). Basically, it gets us back to > what the IETF does well -- defining protocol mechanisms -- while > leaving concrete architectures up to other organizations. > > Please comment on whether you think this is a reasonable way to > address this open issue. If there is enough support, I'll craft some > formal text and put it in GIN. > > /a > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Fri May 21 14:51:14 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 D1C9B3A67F6 for ; Fri, 21 May 2010 14:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 xOEYuEp8DrCs for ; Fri, 21 May 2010 14:51: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 AF1163A657C for ; Fri, 21 May 2010 14:51: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 o4LLp3di051448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 16:51:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF70047.4010407@nostrum.com> Date: Fri, 21 May 2010 16:51:03 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Martien Huysmans References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080602050409070700000000" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: copying URI parameters from REGISTER to Contact 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: Fri, 21 May 2010 21:51:14 -0000 This is a multi-part message in MIME format. --------------080602050409070700000000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/21/10 1:17 AM, Martien Huysmans wrote: > Hi > martini-gin-02 ,chapter 5.2 contains in the following text > Aside from the "bnc" parameter, all URI parameters present on the > "Contact" URI in the REGISTER message MUST be copied to the Contact > value stored in the location service. > Questions > 1) isn't autouser also a URI parameter? If so, should that be returned? Good catch. I'll fix the text. > 2) Is such a statement future compatible? > What if some other RFC in the future includes a URI parameter with > similar propery to bnc? > Then it's their responsibility for making sure things work. That's the way protocol extensions in SIP are done. /a --------------080602050409070700000000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/21/10 1:17 AM, Martien Huysmans wrote:
Hi
 
martini-gin-02 ,chapter 5.2 contains in the following text
   Aside from the "bnc" parameter, all URI parameters present on the
   "Contact" URI in the REGISTER message MUST be copied to the Contact
   value stored in the location service.
 
Questions
 
1) isn't autouser also a URI parameter? If so, should that be returned?

Good catch. I'll fix the text.

 
2) Is such a statement future compatible?
    What if some other RFC in the future includes a URI parameter with similar propery to bnc?
 

Then it's their responsibility for making sure things work. That's the way protocol extensions in SIP are done.

/a
--------------080602050409070700000000-- From adam@nostrum.com Fri May 21 14:54:29 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 3B63D3A67F6 for ; Fri, 21 May 2010 14:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 o6jigKcPFrAM for ; Fri, 21 May 2010 14:54:28 -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 0225C3A6407 for ; Fri, 21 May 2010 14:54:27 -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 o4LLsImJ051634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 16:54:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF7010A.1000103@nostrum.com> Date: Fri, 21 May 2010 16:54:18 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Martien Huysmans References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070100070405080700080109" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: multiple contacts 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: Fri, 21 May 2010 21:54:29 -0000 This is a multi-part message in MIME format. --------------070100070405080700080109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/21/10 1:29 AM, Martien Huysmans wrote: > Martini-gin-02, chapter 5.1 contains the following text > Second, in at least one "Contact" header field, it must include a > Contact URI that contains the URI parameter "bnc", and no user > portion (hence no "@" symbol). > Assume that 2 Contact header fields are present, one with bnc and one > without. > This implies that for inbound SIP Request, forking would take place at > the SSP. Not "would." "Might." What a proxy does with registration data when a call arrives is always subject to local policy. So qsking about whether forking is "the right thing to do" doesn't make much sense. Proxies will do it if it's the right thing to do /according to their local policy/, and they won't if it isn't. > 2) What is the use case that people had in mind, when adding this > possibility? > We didn't add it -- it is implict in the use of the REGISTER method -- we simply don't prohibit it. /a --------------070100070405080700080109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/21/10 1:29 AM, Martien Huysmans wrote:
Martini-gin-02, chapter 5.1 contains the following text
  Second, in at least one "Contact" header field, it must include a
   Contact URI that contains the URI parameter "bnc", and no user
   portion (hence no "@" symbol).
 
Assume that 2 Contact header fields are present, one with bnc and one without.
This implies that for inbound SIP Request, forking would take place at the SSP.

Not "would." "Might." What a proxy does with registration data when a call arrives is always subject to local policy. So qsking about whether forking is "the right thing to do" doesn't make much sense. Proxies will do it if it's the right thing to do according to their local policy, and they won't if it isn't.


 
2) What is the use case that people had in mind, when adding this possibility?


We didn't add it -- it is implict in the use of the REGISTER method -- we simply don't prohibit it.

/a
--------------070100070405080700080109-- From adam@nostrum.com Fri May 21 15:09:31 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 5FD213A69C0 for ; Fri, 21 May 2010 15:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.287, 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 IT63fMvI454g for ; Fri, 21 May 2010 15:09:30 -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 361ED3A69A4 for ; Fri, 21 May 2010 15:09:29 -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 o4LM9GOS052897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 May 2010 17:09:17 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF7048B.4000208@nostrum.com> Date: Fri, 21 May 2010 17:09:15 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 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 version of GIN (-03) -- temp-gruu fix 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: Fri, 21 May 2010 22:09:31 -0000 Based on the recent discovery that the temp-gruu portion of GIN was actually broken as written, I've ripped out the previous mechanisms and replaced them with one based on the algorithm in Appendix A.2 of the GRUU RFC. The actual algorithm has been modified slightly to split duties between the SSP and the PBX, but the security properties should be substantially identical. This version also addresses some errors in the examples and other nits that have been brought to my attention. New version: http://www.ietf.org/id/draft-ietf-martini-gin-03.txt Diffs: http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-03.txt /a From adam@nostrum.com Fri May 21 15:11: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 EFF6D3A657C for ; Fri, 21 May 2010 15:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.283, 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 nKGP51UmEhwY for ; Fri, 21 May 2010 15:11:36 -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 82AE43A69D7 for ; Fri, 21 May 2010 15:11:35 -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 o4LMBRu1053096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 May 2010 17:11:27 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF7050F.9010708@nostrum.com> Date: Fri, 21 May 2010 17:11:27 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "martini@ietf.org" References: <4BF7048B.4000208@nostrum.com> In-Reply-To: <4BF7048B.4000208@nostrum.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) Subject: Re: [martini] New version of GIN (-03) -- temp-gruu fix 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: Fri, 21 May 2010 22:11:38 -0000 I recognize that this comes pretty swiftly on the heels of the -02 update. If you'd like to see a diff between -01 and -03, you can get one here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-03.txt&url1=draft-ietf-martini-gin-01.txt /a On 5/21/10 5:09 PM, Adam Roach wrote: > Based on the recent discovery that the temp-gruu portion of GIN was > actually broken as written, I've ripped out the previous mechanisms > and replaced them with one based on the algorithm in Appendix A.2 of > the GRUU RFC. The actual algorithm has been modified slightly to split > duties between the SSP and the PBX, but the security properties should > be substantially identical. > > This version also addresses some errors in the examples and other nits > that have been brought to my attention. > > New version: > http://www.ietf.org/id/draft-ietf-martini-gin-03.txt > > Diffs: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-03.txt > > /a From root@core3.amsl.com Fri May 21 15:15:17 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 A84E13A69B3; Fri, 21 May 2010 15:15:04 -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: <20100521221504.A84E13A69B3@core3.amsl.com> Date: Fri, 21 May 2010 15:15:04 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-gin-03.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: Fri, 21 May 2010 22:15:22 -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-03.txt Pages : 27 Date : 2010-05-21 This document defines a mechanism by which a SIP server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for terminals 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-21150232.I-D@ietf.org> --NextPart-- From md3135@att.com Fri May 21 15:28:14 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 575C43A6847 for ; Fri, 21 May 2010 15:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.102 X-Spam-Level: X-Spam-Status: No, score=-105.102 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, 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 VMIWSv-rkIxB for ; Fri, 21 May 2010 15:28:13 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id BD0EA3A681E for ; Fri, 21 May 2010 15:28:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1274480883!33056632!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27074 invoked from network); 21 May 2010 22:28:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 May 2010 22:28:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4LMRjBs013956 for ; Fri, 21 May 2010 18:27:45 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4LMRe5E013901 for ; Fri, 21 May 2010 18:27:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 21 May 2010 18:27:58 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4FBB@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr5MX/jSQhx+FH6QLWCEcP9ztlZRgAA113T From: "DOLLY, MARTIN C (ATTLABS)" To: , Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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: Fri, 21 May 2010 22:28:14 -0000 T2ssIEkgb2JqZWN0Lg0KDQpJIHF1ZXN0aW9uIHlvdXIgbGVhZGVyc2hpcA0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcgPG1hcnRp bmktYm91bmNlc0BpZXRmLm9yZz4NClRvOiBtYXJ0aW5pQGlldGYub3JnIDxtYXJ0aW5pQGlldGYu b3JnPg0KU2VudDogRnJpIE1heSAyMSAxNzo0NDozMSAyMDEwDQpTdWJqZWN0OiBbbWFydGluaV0g UkVTUE9OU0UgUkVRVUVTVEVEIFJlOiBPcGVuIElzc3VlICMzNjogR0lOIGFuZCAicmVnIiBldmVu dCBwYWNrYWdlDQoNCk9rYXksIHdlJ3JlIHJlYWxseSB0cnlpbmcgdG8gd2luZCB0aGlzIGRyYWZ0 IGRvd24uIElmIEkgZG9uJ3QgaGVhciBhbnkgDQpvYmplY3Rpb25zIHRvIHRoZSBwcm9wb3NhbCBi ZWxvdywgSSdtIGdvaW5nIHRvIGFzc3VtZSB0aGF0IG5vIG9uZSBjYXJlcyANCmV4Y2VwdCBtZSBh bmQgSGFkcmllbC4NCg0KVW5sZXNzIHlvdSByZXBseSB3aXRoIGFuIG9iamVjdGlvbiBiZWZvcmUg Q09CIE1vbmRheSwgSSdtIHVwZGF0aW5nIHRoZSANCmRvY3VtZW50IHRvIHJlZmxlY3QgdGhpcyBw cm9wb3NhbC4NCg0KL2ENCg0KT24gNS8xOC8xMCA1OjEyIFBNLCBBZGFtIFJvYWNoIHdyb3RlOg0K PiBXZSdyZSBkb3duIHRvIGEgZmFpcmx5IHNtYWxsIG51bWJlciBvZiBvcGVuIGlzc3VlcyBvbiBH SU4uDQo+DQo+IEN1cnJlbnRseSwgc2VjdGlvbiA3LjIuMiBvZiB0aGUgR0lOIGRvY3VtZW50IGRl c2NyaWJlcyBzb21lIGZhaXJseSANCj4gc3BlY2lmaWMgYmVoYXZpb3IgZm9yICJyZWciIGV2ZW50 IGhhbmRsaW5nLiBJbiBwYXJ0aWN1bGFyLCBpdCBzYXlzIA0KPiB0aGF0IHN1YnNjcmlwdGlvbnMg dG8gdGhlIHN0YXRlIG9mIGEgc2luZ2xlIHBob25lIG51bWJlciBhcmUgZm9yd2FyZGVkIA0KPiBi eSB0aGUgU1NQIHRvIHRoZSBQQlguIFRoZXJlJ3Mgc29tZSBsb2dpYyBpbiB0aGUgZG9jdW1lbnQg YWJvdXQgd2h5IEkgDQo+IHRob3VnaHQgdGhpcyB3YXMgYSBHb29kIElkZWEsIGFuZCBldmVuICJp bXBvcnRhbnQuIg0KPg0KPiBBdCB0aGUgbW9zdCByZWNlbnQgaW50ZXJpbSwgd2UgaGFkIGEgZmFp cmx5IGxvbmcgZGlzY3Vzc2lvbiBhYm91dCANCj4gd2hldGhlciB0aGlzIHdhcyBhY3R1YWxseSB0 aGUgInJpZ2h0IiB0aGluZyB0byBkby4gSGFkcmllbCBtYWRlIHNvbWUgDQo+IGNvbnZpbmNpbmcg YXJndW1lbnRzIHRoYXQgdGhlIFNTUCBzaG91bGQgc2VydmljZSB0aGUgc3Vic2NyaXB0aW9ucywg DQo+IHNpbmNlIGl0IHJlYWxseSAib3ducyIgdGhlIFVSSXMgaW4gcXVlc3Rpb24uDQo+DQo+IFRo ZSAidmVybW91dGgiIGRyYWZ0IGRlbHZlcyBhIGJpdCBkZWVwZXIgaW50byBzb21lIHJlbGF0ZWQg aXNzdWVzLCBidXQgDQo+IGl0J3Mgc29tZXdoYXQgbGVzcyBkZXZlbG9wZWQgdGhhbiBHSU4gYXQg dGhpcyBwb2ludC4gV2UgZG9uJ3Qgd2FudCB0byANCj4gbWFrZSBHSU4gZGVwZW5kZW50IG9uIHZl cm1vdXRoLCBhbmQgd2UgcmVhbGx5IGNhbid0IGxlYXZlIGEgdHJlYXRtZW50IA0KPiBvZiB0aGUg InJlZyIgZXZlbnQgcGFja2FnZSBvdXQgb2YgR0lOOiBHSU4gZGVhbHMgaW50aW1hdGVseSB3aXRo IA0KPiByZWdpc3RyYXRpb24uIFVuZGVyIGFueSByZWFzb25hYmxlICJ5b3UgYnJlYWsgaXQgeW91 IGJ1eSBpdCIgDQo+IHByaW5jaXBsZSwgd2UncmUgb24gdGhlIGhvb2sgZm9yIGNvbWluZyB1cCB3 aXRoIGEgc2FuZSB0cmVhdG1lbnQgb2YgDQo+IHRoZSAicmVnIiBldmVudCBwYWNrYWdlLg0KPg0K PiBBZnRlciBhbiBvZmYtbGlzdCBleGNoYW5nZSB3aXRoIEhhZHJpZWwsIEkgKnRoaW5rKiB3ZSdy ZSBib3RoIG9rYXkgaWYgDQo+IHRoYXQgdHJlYXRtZW50IGlzIGFzIHNpbXBsZSBhcyAiaGVyZSBh cmUgdGhlIHByb3BlcnRpZXMgaWYgeW91IGhhbmRsZSANCj4gaXQgYXQgdGhlIFNTUCwgaGVyZSBh cmUgdGhlIHByb3BlcnRpZXMgaWYgeW91IGhhbmRsZSBpdCBhdCB0aGUgUEJYLCANCj4gYW5kIHdo aWNoIHlvdSBjaG9vc2UgaXMgYSBtYXR0ZXIgb2YgcG9saWN5LiIgKEkgZG9uJ3QgbWVhbiB0byBw dXQgDQo+IHdvcmRzIGluIEhhZHJpZWwncyBtb3V0aCwgYW5kIEknbSBzdXJlIGhlJ2xsIGNvcnJl Y3QgbWUgaWYgbXkgc3VtbWFyeSANCj4gaXNuJ3QgY29uc2lzdGVudCB3aXRoIGhpcyBwb3NpdGlv bikuDQo+DQo+IFRoaXMgYXBwcm9hY2ggaXMgYWN0dWFsbHkgcHJldHR5IHdlbGwgaW4gbGluZSB3 aXRoIHRoZSB3YXkgdGhhdCBldmVudCANCj4gcGFja2FnZXMgYXJlIGhhbmRsZWQgaW4gZ2VuZXJh bC4gSXQgYWxzbyBhbGxvd3MgZm9yIHNvbWUgY2xldmVyIChpZiANCj4gY29tcGxpY2F0ZWQpIHNv bHV0aW9ucyB0byB0aGUgcHJvYmxlbSBpbiB3aGljaCB0aGUgU1NQIHNlcnZpY2VzIHRoZSANCj4g c3Vic2NyaXB0aW9uLCBidXQgaW5jb3Jwb3JhdGVzIGluZm9ybWF0aW9uIGl0IGhhcyBsZWFybmVk IGZyb20gdGhlIFBCWCANCj4gKHNheSwgdGhyb3VnaCBiYWNrLWVuZCBzdWJzY3JpcHRpb25zKS4g QmFzaWNhbGx5LCBpdCBnZXRzIHVzIGJhY2sgdG8gDQo+IHdoYXQgdGhlIElFVEYgZG9lcyB3ZWxs IC0tIGRlZmluaW5nIHByb3RvY29sIG1lY2hhbmlzbXMgLS0gd2hpbGUgDQo+IGxlYXZpbmcgY29u Y3JldGUgYXJjaGl0ZWN0dXJlcyB1cCB0byBvdGhlciBvcmdhbml6YXRpb25zLg0KPg0KPiBQbGVh c2UgY29tbWVudCBvbiB3aGV0aGVyIHlvdSB0aGluayB0aGlzIGlzIGEgcmVhc29uYWJsZSB3YXkg dG8gDQo+IGFkZHJlc3MgdGhpcyBvcGVuIGlzc3VlLiBJZiB0aGVyZSBpcyBlbm91Z2ggc3VwcG9y dCwgSSdsbCBjcmFmdCBzb21lIA0KPiBmb3JtYWwgdGV4dCBhbmQgcHV0IGl0IGluIEdJTi4NCj4N Cj4gL2ENCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbWFydGluaSBtYWlsaW5nIGxpc3QNCj4gbWFydGluaUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmkNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hcnRpbmkgbWFpbGluZyBsaXN0DQpt YXJ0aW5pQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h cnRpbmkNCg== From adam@nostrum.com Fri May 21 15:40:41 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 9C6573A6A4F for ; Fri, 21 May 2010 15:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_40=-0.185, 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 8iJzMt1y6OHo for ; Fri, 21 May 2010 15:40:40 -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 4558D3A696B for ; Fri, 21 May 2010 15:40:40 -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 o4LMeVib055195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 17:40:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF70BDE.7050701@nostrum.com> Date: Fri, 21 May 2010 17:40:30 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4FBB@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4FBB@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=UTF-8; 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] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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: Fri, 21 May 2010 22:40:41 -0000 Ah, I appear to have misspoken. When I said "objections," I meant "alternate proposals for a path forward." Thanks for giving me the opportunity to clear that up. /a On 5/21/10 5:27 PM, DOLLY, MARTIN C (ATTLABS) wrote: > Ok, I object. > > I question your leadership > > ----- Original Message ----- > From: martini-bounces@ietf.org > To: martini@ietf.org > Sent: Fri May 21 17:44:31 2010 > Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package > > Okay, we're really trying to wind this draft down. If I don't hear any > objections to the proposal below, I'm going to assume that no one cares > except me and Hadriel. > > Unless you reply with an objection before COB Monday, I'm updating the > document to reflect this proposal. > > /a > > On 5/18/10 5:12 PM, Adam Roach wrote: > >> We're down to a fairly small number of open issues on GIN. >> >> Currently, section 7.2.2 of the GIN document describes some fairly >> specific behavior for "reg" event handling. In particular, it says >> that subscriptions to the state of a single phone number are forwarded >> by the SSP to the PBX. There's some logic in the document about why I >> thought this was a Good Idea, and even "important." >> >> At the most recent interim, we had a fairly long discussion about >> whether this was actually the "right" thing to do. Hadriel made some >> convincing arguments that the SSP should service the subscriptions, >> since it really "owns" the URIs in question. >> >> The "vermouth" draft delves a bit deeper into some related issues, but >> it's somewhat less developed than GIN at this point. We don't want to >> make GIN dependent on vermouth, and we really can't leave a treatment >> of the "reg" event package out of GIN: GIN deals intimately with >> registration. Under any reasonable "you break it you buy it" >> principle, we're on the hook for coming up with a sane treatment of >> the "reg" event package. >> >> After an off-list exchange with Hadriel, I *think* we're both okay if >> that treatment is as simple as "here are the properties if you handle >> it at the SSP, here are the properties if you handle it at the PBX, >> and which you choose is a matter of policy." (I don't mean to put >> words in Hadriel's mouth, and I'm sure he'll correct me if my summary >> isn't consistent with his position). >> >> This approach is actually pretty well in line with the way that event >> packages are handled in general. It also allows for some clever (if >> complicated) solutions to the problem in which the SSP services the >> subscription, but incorporates information it has learned from the PBX >> (say, through back-end subscriptions). Basically, it gets us back to >> what the IETF does well -- defining protocol mechanisms -- while >> leaving concrete architectures up to other organizations. >> >> Please comment on whether you think this is a reasonable way to >> address this open issue. If there is enough support, I'll craft some >> formal text and put it in GIN. >> >> /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 richard@shockey.us Fri May 21 17:30:19 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 3D2DF3A68CF for ; Fri, 21 May 2010 17:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_50=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 x9UWAgJvVNLG for ; Fri, 21 May 2010 17:30:17 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 97AA13A6875 for ; Fri, 21 May 2010 17:30:17 -0700 (PDT) Received: (qmail 18664 invoked by uid 0); 22 May 2010 00:30:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 22 May 2010 00:30:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=niOw75ZMoMHQ/KdOltxV6Dk+c7vHxQWMSN54+KK+uDGi+fEFJU9WI8nYLr+TMFjegdv9u0VsJZkcvcPg9LPLh3Jop+YFSofq9No5nDZRHrsxxv8/rb2d0iTsNypIPrQX; 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 1OFcbT-00042v-6W; Fri, 21 May 2010 18:30:11 -0600 From: "Richard Shockey" To: "'Adam Roach'" , "'DOLLY, MARTIN C \(ATTLABS\)'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4FBB@gaalpa1msgusr7e.ugd.att.com> <4BF70BDE.7050701@nostrum.com> In-Reply-To: <4BF70BDE.7050701@nostrum.com> Date: Fri, 21 May 2010 20:30:03 -0400 Message-ID: <013501caf945$ec92be20$c5b83a60$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr5NqG0OCZ2DQ9WTGOV8NoBoHhfdQADur8w 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} Cc: martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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: Sat, 22 May 2010 00:30:19 -0000 So Marty ...what is your alternate text? Saying you don't like something is not helpful unless you can demonstrate to the WG exactly what is a technically rational counterproposal. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Friday, May 21, 2010 6:40 PM To: DOLLY, MARTIN C (ATTLABS) Cc: martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Ah, I appear to have misspoken. When I said "objections," I meant "alternate proposals for a path forward." Thanks for giving me the opportunity to clear that up. /a On 5/21/10 5:27 PM, DOLLY, MARTIN C (ATTLABS) wrote: > Ok, I object. > > I question your leadership > > ----- Original Message ----- > From: martini-bounces@ietf.org > To: martini@ietf.org > Sent: Fri May 21 17:44:31 2010 > Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package > > Okay, we're really trying to wind this draft down. If I don't hear any > objections to the proposal below, I'm going to assume that no one cares > except me and Hadriel. > > Unless you reply with an objection before COB Monday, I'm updating the > document to reflect this proposal. > > /a > > On 5/18/10 5:12 PM, Adam Roach wrote: > >> We're down to a fairly small number of open issues on GIN. >> >> Currently, section 7.2.2 of the GIN document describes some fairly >> specific behavior for "reg" event handling. In particular, it says >> that subscriptions to the state of a single phone number are forwarded >> by the SSP to the PBX. There's some logic in the document about why I >> thought this was a Good Idea, and even "important." >> >> At the most recent interim, we had a fairly long discussion about >> whether this was actually the "right" thing to do. Hadriel made some >> convincing arguments that the SSP should service the subscriptions, >> since it really "owns" the URIs in question. >> >> The "vermouth" draft delves a bit deeper into some related issues, but >> it's somewhat less developed than GIN at this point. We don't want to >> make GIN dependent on vermouth, and we really can't leave a treatment >> of the "reg" event package out of GIN: GIN deals intimately with >> registration. Under any reasonable "you break it you buy it" >> principle, we're on the hook for coming up with a sane treatment of >> the "reg" event package. >> >> After an off-list exchange with Hadriel, I *think* we're both okay if >> that treatment is as simple as "here are the properties if you handle >> it at the SSP, here are the properties if you handle it at the PBX, >> and which you choose is a matter of policy." (I don't mean to put >> words in Hadriel's mouth, and I'm sure he'll correct me if my summary >> isn't consistent with his position). >> >> This approach is actually pretty well in line with the way that event >> packages are handled in general. It also allows for some clever (if >> complicated) solutions to the problem in which the SSP services the >> subscription, but incorporates information it has learned from the PBX >> (say, through back-end subscriptions). Basically, it gets us back to >> what the IETF does well -- defining protocol mechanisms -- while >> leaving concrete architectures up to other organizations. >> >> Please comment on whether you think this is a reasonable way to >> address this open issue. If there is enough support, I'll craft some >> formal text and put it in GIN. >> >> /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 spencer@wonderhamster.org Sat May 22 06:22:59 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 0E0D13A6CC3 for ; Sat, 22 May 2010 06:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_50=0.001, 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 5o88wtMleCyI for ; Sat, 22 May 2010 06:22:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 0F3F63A6CB5 for ; Sat, 22 May 2010 06:22:42 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mar7C-1NzmuC2yxW-00K9cq; Sat, 22 May 2010 09:22:24 -0400 Message-ID: From: "Spencer Dawkins" To: References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4FBB@gaalpa1msgusr7e.ugd.att.com><4BF70BDE.7050701@nostrum.com> <013501caf945$ec92be20$c5b83a60$@us> Date: Sat, 22 May 2010 08:22:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Provags-ID: V01U2FsdGVkX1/XGQ9fASaEqdjC3xWuAQajcRjuDZQGCSE34ah kHa2dDy08cYNEjgwhywpztoY2tZB+F4Myg6P5wSMPXNvgxsn5x E/2QW6U6BQVjSGFCCB2jC57xL0x7MCZvoAIUbwLLHQ= Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg"event package 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: Sat, 22 May 2010 13:22:59 -0000 My apologies for not being able to concentrate on MARTINI much this weekend (I have BOTH inlaws down with pneumonia), but ... Speaking as co-chair. Our intention is to WGLC GIN very soon - we'd like to announce WGLC on June 1. It didn't make sense to us to issue WGLC for a version of the draft that has open issues in the tracker, that have been discussed on the mailing list, so Bernard and I reviewed the open issues for GIN (from http://trac.tools.ietf.org/wg/martini/trac/query?status=new&status=assigned&status=reopened&component=gin) earlier this week, and the path Adam and Hadriel are proposing below seemed to be in line with earlier mailing list discussions, so we asked Adam to focus on proposing text to resolve the open issues, which he has done for issue #36 (below). So, a couple of things. Adam is acting as editor for a working group draft, which means that he will reflect the consensus of the working group in draft revisions. If the proposal below doesn't work for people on the mailing list, please help us understand why. Alternate text is helpful, but first of all, we need to understand what does not work in this proposal - then we'll know what to look for, when considering revisions to this proposal, or considering other proposals. We're moving toward a two-week WGLC, so it's not like we're going to request publication for -03 without further working group involvement, but every issue that we can discuss now is an issue that we don't need to discuss during WGLC. So, for the group - if there are things that concern you in -03, and you can put a voice to those concerns before we start WGLC (currently scheduled to start on June 1), that would be very helpful. Thanks, Spencer, who will probably not see additional mailing list traffic this weekend From pkyzivat@cisco.com Sat May 22 10:43: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 3020F3A6D33 for ; Sat, 22 May 2010 10:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 HfEMyFni3h77 for ; Sat, 22 May 2010 10:43:45 -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 3C7F63A69DA for ; Sat, 22 May 2010 10:43:45 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEa090urR7Ht/2dsb2JhbACeEnGkHJh8hRME X-IronPort-AV: E=Sophos;i="4.53,283,1272844800"; d="scan'208";a="201250448" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 22 May 2010 17:43:37 +0000 Received: from [10.89.11.132] ([10.89.11.132]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4MHhaEc015713; Sat, 22 May 2010 17:43:37 GMT Message-ID: <4BF817D2.8060109@cisco.com> Date: Sat, 22 May 2010 13:43:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Spencer Dawkins References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4FBB@gaalpa1msgusr7e.ugd.att.com><4BF70BDE.7050701@nostrum.com> <013501caf945$ec92be20$c5b83a60$@us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg"event package 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: Sat, 22 May 2010 17:43:46 -0000 Spencer, The recent change in GRUU handling is, I think, quite a fundamental change. Hence I think it should be examined very carefully. I haven't had time to read the new version through. I'm uncertain if its reasonable to do that entirely during WGLC. Maybe that will work out, but maybe it will require more time, or more iterations. Maybe I'll be more comfortable abut this once I've read the changes and thought about them. But I've got other things keeping me busy right now so I may not be able to give it careful attention real soon. Hopefully there is somebody else who will give a thorough consideration of that. Thanks, Paul Spencer Dawkins wrote: > My apologies for not being able to concentrate on MARTINI much this > weekend (I have BOTH inlaws down with pneumonia), but ... > > Speaking as co-chair. > > Our intention is to WGLC GIN very soon - we'd like to announce WGLC on > June 1. > > It didn't make sense to us to issue WGLC for a version of the draft that > has open issues in the tracker, that have been discussed on the mailing > list, so Bernard and I reviewed the open issues for GIN (from > http://trac.tools.ietf.org/wg/martini/trac/query?status=new&status=assigned&status=reopened&component=gin) > earlier this week, and the path Adam and Hadriel are proposing below > seemed to be in line with earlier mailing list discussions, so we asked > Adam to focus on proposing text to resolve the open issues, which he has > done for issue #36 (below). > > So, a couple of things. > > Adam is acting as editor for a working group draft, which means that he > will reflect the consensus of the working group in draft revisions. If > the proposal below doesn't work for people on the mailing list, please > help us understand why. Alternate text is helpful, but first of all, we > need to understand what does not work in this proposal - then we'll know > what to look for, when considering revisions to this proposal, or > considering other proposals. > > We're moving toward a two-week WGLC, so it's not like we're going to > request publication for -03 without further working group involvement, > but every issue that we can discuss now is an issue that we don't need > to discuss during WGLC. So, for the group - if there are things that > concern you in -03, and you can put a voice to those concerns before we > start WGLC (currently scheduled to start on June 1), that would be very > helpful. > > Thanks, > > Spencer, who will probably not see additional mailing list traffic this > weekend > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From john.elwell@siemens-enterprise.com Mon May 24 01:09:29 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 6B9F73A67E6 for ; Mon, 24 May 2010 01:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_50=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 aHd5BsGDVkvl for ; Mon, 24 May 2010 01:09:28 -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 31DE93A6A50 for ; Mon, 24 May 2010 01:09:27 -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-264060; Mon, 24 May 2010 10:09:19 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id C586F23F0278; Mon, 24 May 2010 10:09:19 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 24 May 2010 10:09:19 +0200 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Mon, 24 May 2010 10:09:18 +0200 Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr5SJ623fTcT9xPSg+b2ok5WE7TgwBz8Jow Message-ID: References: <4BF310DB.1000700@nostrum.com> <4BF6FEBF.4030403@nostrum.com> In-Reply-To: <4BF6FEBF.4030403@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 Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 08:09:29 -0000 Sounds reasonable. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 21 May 2010 22:45 > To: martini@ietf.org > Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN=20 > and "reg" event package >=20 > Okay, we're really trying to wind this draft down. If I don't=20 > hear any=20 > objections to the proposal below, I'm going to assume that no=20 > one cares=20 > except me and Hadriel. >=20 > Unless you reply with an objection before COB Monday, I'm=20 > updating the=20 > document to reflect this proposal. >=20 > /a >=20 > On 5/18/10 5:12 PM, Adam Roach wrote: > > We're down to a fairly small number of open issues on GIN. > > > > Currently, section 7.2.2 of the GIN document describes some fairly=20 > > specific behavior for "reg" event handling. In particular, it says=20 > > that subscriptions to the state of a single phone number=20 > are forwarded=20 > > by the SSP to the PBX. There's some logic in the document=20 > about why I=20 > > thought this was a Good Idea, and even "important." > > > > At the most recent interim, we had a fairly long discussion about=20 > > whether this was actually the "right" thing to do. Hadriel=20 > made some=20 > > convincing arguments that the SSP should service the subscriptions,=20 > > since it really "owns" the URIs in question. > > > > The "vermouth" draft delves a bit deeper into some related=20 > issues, but=20 > > it's somewhat less developed than GIN at this point. We=20 > don't want to=20 > > make GIN dependent on vermouth, and we really can't leave a=20 > treatment=20 > > of the "reg" event package out of GIN: GIN deals intimately with=20 > > registration. Under any reasonable "you break it you buy it"=20 > > principle, we're on the hook for coming up with a sane treatment of=20 > > the "reg" event package. > > > > After an off-list exchange with Hadriel, I *think* we're=20 > both okay if=20 > > that treatment is as simple as "here are the properties if=20 > you handle=20 > > it at the SSP, here are the properties if you handle it at the PBX,=20 > > and which you choose is a matter of policy." (I don't mean to put=20 > > words in Hadriel's mouth, and I'm sure he'll correct me if=20 > my summary=20 > > isn't consistent with his position). > > > > This approach is actually pretty well in line with the way=20 > that event=20 > > packages are handled in general. It also allows for some clever (if=20 > > complicated) solutions to the problem in which the SSP services the=20 > > subscription, but incorporates information it has learned=20 > from the PBX=20 > > (say, through back-end subscriptions). Basically, it gets=20 > us back to=20 > > what the IETF does well -- defining protocol mechanisms -- while=20 > > leaving concrete architectures up to other organizations. > > > > Please comment on whether you think this is a reasonable way to=20 > > address this open issue. If there is enough support, I'll=20 > craft some=20 > > formal text and put it in GIN. > > > > /a > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Mon May 24 01:36:41 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 72F783A6AD4 for ; Mon, 24 May 2010 01:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_50=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 pn8qVmPgLQEu for ; Mon, 24 May 2010 01:36:40 -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 2316C3A6ACD for ; Mon, 24 May 2010 01:36:39 -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-265513; Mon, 24 May 2010 10:36:31 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id BD35F23F0278; Mon, 24 May 2010 10:36:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 24 May 2010 10:36:31 +0200 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Mon, 24 May 2010 10:36:30 +0200 Thread-Topic: Minor comment in example in 03 Thread-Index: Acr5TPLhCF2Q51dWTc+crOlTAqf2JABzP2Bw Message-ID: References: <4BF7048B.4000208@nostrum.com> In-Reply-To: <4BF7048B.4000208@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 Subject: [martini] Minor comment in example in 03 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, 24 May 2010 08:36:41 -0000 " A registrar that receives a URI with both a "bnc" parameter and a user portion MAY discard the user portion and process the request as if it were not present. Alternately, the registrar MAY return a 400 (Bad Request) error in response. Note that this requirement is talking about the user portion of a URI: sip:+12145550100@example.com;user=3Dphone ^^^^^^^^^^^^" Since this is specifically talking about the user portion, I would suggest = suppressing ";user=3Dphone" from this example. This is later text (in 5.3) = specifically outlawing the "user" parameter with "bnc", so including it in = the example in 5.2 is confusing. John =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 21 May 2010 23:09 > To: martini@ietf.org > Subject: [martini] New version of GIN (-03) -- temp-gruu fix >=20 > Based on the recent discovery that the temp-gruu portion of GIN was=20 > actually broken as written, I've ripped out the previous=20 > mechanisms and=20 > replaced them with one based on the algorithm in Appendix A.2 of the=20 > GRUU RFC. The actual algorithm has been modified slightly to split=20 > duties between the SSP and the PBX, but the security=20 > properties should=20 > be substantially identical. >=20 > This version also addresses some errors in the examples and=20 > other nits=20 > that have been brought to my attention. >=20 > New version: > http://www.ietf.org/id/draft-ietf-martini-gin-03.txt >=20 > Diffs: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-martini-gin-03.txt >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Mon May 24 01:58:26 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 2D2AA3A6AF7 for ; Mon, 24 May 2010 01:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, 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 zZlTFfJj1jU9 for ; Mon, 24 May 2010 01:58:25 -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 1017D3A6ADD for ; Mon, 24 May 2010 01:58:24 -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-264702; Mon, 24 May 2010 10:58:16 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id D426B1EB82AB; Mon, 24 May 2010 10:58:16 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 24 May 2010 10:58:16 +0200 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Mon, 24 May 2010 10:58:15 +0200 Thread-Topic: [martini] New version of GIN (-03) -- temp-gruu fix Thread-Index: Acr5TPLhCF2Q51dWTc+crOlTAqf2JABz0t9Q Message-ID: References: <4BF7048B.4000208@nostrum.com> In-Reply-To: <4BF7048B.4000208@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 Subject: Re: [martini] New version of GIN (-03) -- temp-gruu fix 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, 24 May 2010 08:58:26 -0000 Adam, "K_e2 is shared with the PBXes via provisioning."=20 It would be nice to avoid this. Any reason it can't be shared by means of t= he 2xx response to REGISTER? John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 21 May 2010 23:09 > To: martini@ietf.org > Subject: [martini] New version of GIN (-03) -- temp-gruu fix >=20 > Based on the recent discovery that the temp-gruu portion of GIN was=20 > actually broken as written, I've ripped out the previous=20 > mechanisms and=20 > replaced them with one based on the algorithm in Appendix A.2 of the=20 > GRUU RFC. The actual algorithm has been modified slightly to split=20 > duties between the SSP and the PBX, but the security=20 > properties should=20 > be substantially identical. >=20 > This version also addresses some errors in the examples and=20 > other nits=20 > that have been brought to my attention. >=20 > New version: > http://www.ietf.org/id/draft-ietf-martini-gin-03.txt >=20 > Diffs: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-martini-gin-03.txt >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From christer.holmberg@ericsson.com Mon May 24 05:03: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 885D93A6B82 for ; Mon, 24 May 2010 05:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.894 X-Spam-Level: X-Spam-Status: No, score=-3.894 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_50=0.001, 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 JptDq5r2TCo7 for ; Mon, 24 May 2010 05:03:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 76A843A6B30 for ; Mon, 24 May 2010 05:03:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-1e-4bfa6af8fce7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8D.7C.08537.8FA6AFB4; Mon, 24 May 2010 14:03:04 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 24 May 2010 14:03:04 +0200 From: Christer Holmberg To: "'Elwell, John'" , Cullen Jennings , Dean Willis Date: Mon, 24 May 2010 14:03:03 +0200 Thread-Topic: [martini] GIN: Removing Section 9 (Requirements Analysis)? Thread-Index: Acr48LiLSi0rzbSoRuCn7zAR16eEEwAAx0nwAJEjiOA= Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> , <4BF40A96.3040600@nostrum.com> <1274407304.1374.2.camel@damnableubu> <57FFB2AC-118F-4D02-B446-F4808C768D70@cisco.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 24 May 2010 12:03:18 -0000 Hi, One reason why I think it is important to have some kind of reference and t= racking of the requirements is because, as we know, GIN does not solve all = the requirements that some people need, and that MARTINI later might work o= n. We have accepted some limitations and restrictions for GIN. So, if we later work with another solution, which solves requirements that = we have chosen to not include for GIN, it is very useful to see what requir= ements the solutions solve, in order to evaluate them etc. I think the simplest solution is to simply list the requirements in the GIN= draft, but I have no strong preference how it's done. Regards, Christer =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Elwell, John Sent: 21. toukokuuta 2010 17:52 To: Cullen Jennings; Dean Willis Cc: martini@ietf.org Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? Cullen, I agree with what you say, but the IETF (certainly RAI) has a history of pr= oducing requirements RFCs, e.g., SPEERMINT, identification (RFC 3324), e2m = security (RFC 4189), trait-based authorisation (RFC 4484), overload (RFC 53= 90), media security (5479), floor control (RFC 4376), media control (RFC 51= 67), geopriv (RFC 3693), ecrit (RFC 5012)... In some cases the charter even= calls for this, although that is not true for MARTINI. I think the decisio= n was made at the start of the work to produce a requirements document. If = we want to use a less formal means of publishing this, and include the writ= e-up on how gin meets the requirements, I don't mind. I just thought the WG= was expecting an RFC. And by the way, I could probably cite a bunch more where requirements and m= otivation are included in the solution RFC, but that is another matter. John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 21 May 2010 15:20 > To: Dean Willis > Cc: Elwell, John; Spencer Dawkins; martini@ietf.org > Subject: Re: [martini] GIN: Removing Section 9 (Requirements=20 > Analysis)? >=20 >=20 > So, I should start with I really don't feel strongly about this and I=20 > can live with whatever happens .... >=20 > Few points about Requirements - people always say they are written=20 > before the solutions. In all the examples I have seen at IETF this is=20 > farm more often not the case - certainly not true in this case. The=20 > requirements and solutions were evolved along in parallel over months=20 > or years starting in SIP Forum and eventually ending up where - I will=20 > point the requirements are still not done in the sense that they are=20 > not an RFC and are still changing and the solution is very close to=20 > WGLC. >=20 > Next, I don't think there is any rule that the solution MUST meet the=20 > requirements. The question I think the WG should ask when it goes to=20 > publish the solution is basically "Are we happy enough with this that=20 > we have rough consensus to publish it". I very important piece of=20 > information for everyone to try and decide if they can say yes to that=20 > is the analysis of how well the solution meets the requirements but=20 > from a procedural point of view, if the solution does not meet all the=20 > requirements, the WG could still decide to pub request the doc. >=20 > So from my point of view, it's nice to have a draft that has the=20 > requirements (could be same or different draft as the solution), it's=20 > nice to have a draft with the analysis of how well the solution meets=20 > the requirements. But once the work is done, none of this text has=20 > much value as an RFC. It's useful to have a pornier in the RFC to find=20 > this. The easiest way to do that is the names of the draft and just=20 > use google to find them. They really do last forever on the internet=20 > unlike whatever the front of them says about 6 months. The fundamental=20 > reasons we publish them as RFC is that people put a bunch of work into=20 > them and publishing it as a RFC with the person name on it is a way to=20 > say thanks for that work. >=20 > But I do have a preference for moving text that is of no use out of=20 > RFC implementors need to read. It can move to another RFC, a draft, an=20 > email thread that is archived, whatever. > When considering moving it to an RFC, keep in mind that even a simple=20 > information RFC takes a ton of time for the AD so that means something=20 > else is getting dropped. Well worth considering the load level on your=20 > AD based on reassured response time and task drop rate before asking=20 > them to publish something that would not have much more value as an=20 > RFC than as a draft. >=20 > Oh yah, and +1 to Deans comments below and John I agree with your=20 > point we want to be able to put finished stuff to bead and not have it=20 > wait on some future doc. >=20 >=20 > On May 20, 2010, at 8:01 PM, Dean Willis wrote: >=20 > > On Thu, 2010-05-20 at 15:50 +0200, Elwell, John wrote: > >> Cullen, > >>=20 > >> I think that is the wrong way round. A requirements > document is generally written before solution documents. And suppose=20 > some requirements are not met until a later solutions document, e.g.,=20 > olive. Does that mean we can't put the requirements document to bed=20 > before olive is finished? > >>=20 > >> On the other hand, I tend to agree with you that > implementers don't like too much useless material. We had a pretty=20 > good evaluation of gin against requirements at IETF#77 on slides, and=20 > it is that that is captured in the latest gin draft. The analysis has=20 > changed very little, except that a couple of new requirements have=20 > been added. The IETF#77 MARTINI minutes, with pointer to the slides,=20 > goes a long way to showing that we have done due diligence in ensuring=20 > the solution meets the requirements. OR we could post updated text on=20 > the mailing list, so that it appears in the archive. > Do we really need to encumber either draft with this lengthy text? > >>=20 > >=20 > > Easy solution. > >=20 > > Publish the requirements, informational track. > >=20 > > Publish gin, standards track, containing only that which is > required to > > implement the spec, tight and testable. > >=20 > > Make yet another draft, informational track, that shows how > gin or gin > > +olive meet the requirements, and that revises the requirements if > > necessary. > >=20 > > -- > > Dean > >=20 > >=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From keith.drage@alcatel-lucent.com Mon May 24 07:40:53 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 0F31C3A68C6 for ; Mon, 24 May 2010 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=-2.312, BAYES_50=0.001, 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 APN0JdD+fLAk for ; Mon, 24 May 2010 07:40:52 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 6C4513A67F2 for ; Mon, 24 May 2010 07:40:35 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4OEeQ7e025864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 May 2010 16:40:26 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 24 May 2010 16:40:26 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , "martini@ietf.org" Date: Mon, 24 May 2010 16:40:25 +0200 Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr5Srqn1Qz33fa+TwKC6T+dS2ynDACBDq+Q Message-ID: References: <4BF310DB.1000700@nostrum.com> <4BF6FEBF.4030403@nostrum.com> In-Reply-To: <4BF6FEBF.4030403@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-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 14:40:53 -0000 Sorry, that is too short notice to find time to deal with this, and therefo= re unreasonable. Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, May 21, 2010 10:45 PM > To: martini@ietf.org > Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN=20 > and "reg" event package >=20 > Okay, we're really trying to wind this draft down. If I don't=20 > hear any objections to the proposal below, I'm going to=20 > assume that no one cares except me and Hadriel. >=20 > Unless you reply with an objection before COB Monday, I'm=20 > updating the document to reflect this proposal. >=20 > /a >=20 > On 5/18/10 5:12 PM, Adam Roach wrote: > > We're down to a fairly small number of open issues on GIN. > > > > Currently, section 7.2.2 of the GIN document describes some fairly=20 > > specific behavior for "reg" event handling. In particular, it says=20 > > that subscriptions to the state of a single phone number=20 > are forwarded=20 > > by the SSP to the PBX. There's some logic in the document=20 > about why I=20 > > thought this was a Good Idea, and even "important." > > > > At the most recent interim, we had a fairly long discussion about=20 > > whether this was actually the "right" thing to do. Hadriel=20 > made some=20 > > convincing arguments that the SSP should service the subscriptions,=20 > > since it really "owns" the URIs in question. > > > > The "vermouth" draft delves a bit deeper into some related=20 > issues, but=20 > > it's somewhat less developed than GIN at this point. We=20 > don't want to=20 > > make GIN dependent on vermouth, and we really can't leave a=20 > treatment=20 > > of the "reg" event package out of GIN: GIN deals intimately with=20 > > registration. Under any reasonable "you break it you buy it" > > principle, we're on the hook for coming up with a sane treatment of=20 > > the "reg" event package. > > > > After an off-list exchange with Hadriel, I *think* we're=20 > both okay if=20 > > that treatment is as simple as "here are the properties if=20 > you handle=20 > > it at the SSP, here are the properties if you handle it at the PBX,=20 > > and which you choose is a matter of policy." (I don't mean to put=20 > > words in Hadriel's mouth, and I'm sure he'll correct me if=20 > my summary=20 > > isn't consistent with his position). > > > > This approach is actually pretty well in line with the way=20 > that event=20 > > packages are handled in general. It also allows for some clever (if > > complicated) solutions to the problem in which the SSP services the=20 > > subscription, but incorporates information it has learned=20 > from the PBX=20 > > (say, through back-end subscriptions). Basically, it gets=20 > us back to=20 > > what the IETF does well -- defining protocol mechanisms -- while=20 > > leaving concrete architectures up to other organizations. > > > > Please comment on whether you think this is a reasonable way to=20 > > address this open issue. If there is enough support, I'll=20 > craft some=20 > > formal text and put it in GIN. > > > > /a > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From adam@nostrum.com Mon May 24 07:48:21 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 C0A933A6852 for ; Mon, 24 May 2010 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_50=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 DnRlAedE9MA8 for ; Mon, 24 May 2010 07:48:20 -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 72A873A6832 for ; Mon, 24 May 2010 07:48:20 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4OEm8Fa047500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 09:48:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BFA91A8.5070508@nostrum.com> Date: Mon, 24 May 2010 09:48:08 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BF310DB.1000700@nostrum.com> <4BF6FEBF.4030403@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 14:48:21 -0000 Keith: Fair enough. Six days is just under half the time typically allocated for a WGLC on a whole document. Since that isn't, in your opinion, long enough for a single (relatively inconsequential) issue... then how long is? /a On 5/24/10 09:40, May 24, DRAGE, Keith (Keith) wrote: > Sorry, that is too short notice to find time to deal with this, and therefore unreasonable. > > Keith > > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: Friday, May 21, 2010 10:45 PM >> To: martini@ietf.org >> Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN >> and "reg" event package >> >> Okay, we're really trying to wind this draft down. If I don't >> hear any objections to the proposal below, I'm going to >> assume that no one cares except me and Hadriel. >> >> Unless you reply with an objection before COB Monday, I'm >> updating the document to reflect this proposal. >> >> /a >> >> On 5/18/10 5:12 PM, Adam Roach wrote: >> >>> We're down to a fairly small number of open issues on GIN. >>> >>> Currently, section 7.2.2 of the GIN document describes some fairly >>> specific behavior for "reg" event handling. In particular, it says >>> that subscriptions to the state of a single phone number >>> >> are forwarded >> >>> by the SSP to the PBX. There's some logic in the document >>> >> about why I >> >>> thought this was a Good Idea, and even "important." >>> >>> At the most recent interim, we had a fairly long discussion about >>> whether this was actually the "right" thing to do. Hadriel >>> >> made some >> >>> convincing arguments that the SSP should service the subscriptions, >>> since it really "owns" the URIs in question. >>> >>> The "vermouth" draft delves a bit deeper into some related >>> >> issues, but >> >>> it's somewhat less developed than GIN at this point. We >>> >> don't want to >> >>> make GIN dependent on vermouth, and we really can't leave a >>> >> treatment >> >>> of the "reg" event package out of GIN: GIN deals intimately with >>> registration. Under any reasonable "you break it you buy it" >>> principle, we're on the hook for coming up with a sane treatment of >>> the "reg" event package. >>> >>> After an off-list exchange with Hadriel, I *think* we're >>> >> both okay if >> >>> that treatment is as simple as "here are the properties if >>> >> you handle >> >>> it at the SSP, here are the properties if you handle it at the PBX, >>> and which you choose is a matter of policy." (I don't mean to put >>> words in Hadriel's mouth, and I'm sure he'll correct me if >>> >> my summary >> >>> isn't consistent with his position). >>> >>> This approach is actually pretty well in line with the way >>> >> that event >> >>> packages are handled in general. It also allows for some clever (if >>> complicated) solutions to the problem in which the SSP services the >>> subscription, but incorporates information it has learned >>> >> from the PBX >> >>> (say, through back-end subscriptions). Basically, it gets >>> >> us back to >> >>> what the IETF does well -- defining protocol mechanisms -- while >>> leaving concrete architectures up to other organizations. >>> >>> Please comment on whether you think this is a reasonable way to >>> address this open issue. If there is enough support, I'll >>> >> craft some >> >>> formal text and put it in GIN. >>> >>> /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 keith.drage@alcatel-lucent.com Mon May 24 07:53:37 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 33EC53A6813 for ; Mon, 24 May 2010 07:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=-2.270, BAYES_50=0.001, 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 kf52oJsbg-nR for ; Mon, 24 May 2010 07:53:36 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 00E133A68C6 for ; Mon, 24 May 2010 07:53:34 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4OErPNW028536 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 May 2010 16:53:26 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 24 May 2010 16:53:25 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Mon, 24 May 2010 16:53:24 +0200 Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr7UCNLSCHm8PLiSBKT38FNQaJ/mQAAKSVg Message-ID: References: <4BF310DB.1000700@nostrum.com> <4BF6FEBF.4030403@nostrum.com> <4BFA91A8.5070508@nostrum.com> In-Reply-To: <4BFA91A8.5070508@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 14:53:37 -0000 I make after close of working time on Friday to close of working time on Mo= nday equal to 1 working day, not 6. Keith=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Monday, May 24, 2010 3:48 PM > To: DRAGE, Keith (Keith) > Cc: martini@ietf.org > Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36:=20 > GIN and "reg" event package >=20 > Keith: >=20 > Fair enough. >=20 > Six days is just under half the time typically allocated for=20 > a WGLC on a whole document. Since that isn't, in your=20 > opinion, long enough for a single (relatively=20 > inconsequential) issue... then how long is? >=20 > /a >=20 > On 5/24/10 09:40, May 24, DRAGE, Keith (Keith) wrote: > > Sorry, that is too short notice to find time to deal with=20 > this, and therefore unreasonable. > > > > Keith > > > > =20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > >> Sent: Friday, May 21, 2010 10:45 PM > >> To: martini@ietf.org > >> Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and=20 > >> "reg" event package > >> > >> Okay, we're really trying to wind this draft down. If I don't hear=20 > >> any objections to the proposal below, I'm going to assume=20 > that no one=20 > >> cares except me and Hadriel. > >> > >> Unless you reply with an objection before COB Monday, I'm updating=20 > >> the document to reflect this proposal. > >> > >> /a > >> > >> On 5/18/10 5:12 PM, Adam Roach wrote: > >> =20 > >>> We're down to a fairly small number of open issues on GIN. > >>> > >>> Currently, section 7.2.2 of the GIN document describes=20 > some fairly=20 > >>> specific behavior for "reg" event handling. In=20 > particular, it says=20 > >>> that subscriptions to the state of a single phone number > >>> =20 > >> are forwarded > >> =20 > >>> by the SSP to the PBX. There's some logic in the document > >>> =20 > >> about why I > >> =20 > >>> thought this was a Good Idea, and even "important." > >>> > >>> At the most recent interim, we had a fairly long discussion about=20 > >>> whether this was actually the "right" thing to do. Hadriel > >>> =20 > >> made some > >> =20 > >>> convincing arguments that the SSP should service the=20 > subscriptions,=20 > >>> since it really "owns" the URIs in question. > >>> > >>> The "vermouth" draft delves a bit deeper into some related > >>> =20 > >> issues, but > >> =20 > >>> it's somewhat less developed than GIN at this point. We > >>> =20 > >> don't want to > >> =20 > >>> make GIN dependent on vermouth, and we really can't leave a > >>> =20 > >> treatment > >> =20 > >>> of the "reg" event package out of GIN: GIN deals intimately with=20 > >>> registration. Under any reasonable "you break it you buy it" > >>> principle, we're on the hook for coming up with a sane=20 > treatment of=20 > >>> the "reg" event package. > >>> > >>> After an off-list exchange with Hadriel, I *think* we're > >>> =20 > >> both okay if > >> =20 > >>> that treatment is as simple as "here are the properties if > >>> =20 > >> you handle > >> =20 > >>> it at the SSP, here are the properties if you handle it=20 > at the PBX,=20 > >>> and which you choose is a matter of policy." (I don't mean to put=20 > >>> words in Hadriel's mouth, and I'm sure he'll correct me if > >>> =20 > >> my summary > >> =20 > >>> isn't consistent with his position). > >>> > >>> This approach is actually pretty well in line with the way > >>> =20 > >> that event > >> =20 > >>> packages are handled in general. It also allows for some=20 > clever (if > >>> complicated) solutions to the problem in which the SSP=20 > services the=20 > >>> subscription, but incorporates information it has learned > >>> =20 > >> from the PBX > >> =20 > >>> (say, through back-end subscriptions). Basically, it gets > >>> =20 > >> us back to > >> =20 > >>> what the IETF does well -- defining protocol mechanisms -- while=20 > >>> leaving concrete architectures up to other organizations. > >>> > >>> Please comment on whether you think this is a reasonable way to=20 > >>> address this open issue. If there is enough support, I'll > >>> =20 > >> craft some > >> =20 > >>> formal text and put it in GIN. > >>> > >>> /a > >>> > >>> _______________________________________________ > >>> martini mailing list > >>> martini@ietf.org > >>> https://www.ietf.org/mailman/listinfo/martini > >>> =20 > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> =20 >=20 > = From adam@nostrum.com Mon May 24 08:01:17 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 6A5E43A691F for ; Mon, 24 May 2010 08:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_20=-0.74, 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 NDXqGCYge-Qg for ; Mon, 24 May 2010 08:01:16 -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 E079F3A68C6 for ; Mon, 24 May 2010 08:01:15 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4OF153K048500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 10:01:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BFA94B1.4080900@nostrum.com> Date: Mon, 24 May 2010 10:01:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BF310DB.1000700@nostrum.com> <4BF6FEBF.4030403@nostrum.com> <4BFA91A8.5070508@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 15:01:17 -0000 I make May 18th (when I first posted for feedback on the issue) to May 24th to be six calendar days, four working days. Regardless of our disagreement on accounting, I think my question remains valid. You're effectively asking for more time, and that is reasonable in and of itself. Without proposing an alternate deadline, you're also effectively asking for an arbitrary, unbounded amount of additional time, which is not. So, how long do you want? /a On 5/24/10 09:53, May 24, DRAGE, Keith (Keith) wrote: > I make after close of working time on Friday to close of working time on Monday equal to 1 working day, not 6. > > Keith > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Monday, May 24, 2010 3:48 PM >> To: DRAGE, Keith (Keith) >> Cc: martini@ietf.org >> Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: >> GIN and "reg" event package >> >> Keith: >> >> Fair enough. >> >> Six days is just under half the time typically allocated for >> a WGLC on a whole document. Since that isn't, in your >> opinion, long enough for a single (relatively >> inconsequential) issue... then how long is? >> >> /a >> >> On 5/24/10 09:40, May 24, DRAGE, Keith (Keith) wrote: >> >>> Sorry, that is too short notice to find time to deal with >>> >> this, and therefore unreasonable. >> >>> Keith >>> >>> >>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org >>>> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach >>>> Sent: Friday, May 21, 2010 10:45 PM >>>> To: martini@ietf.org >>>> Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and >>>> "reg" event package >>>> >>>> Okay, we're really trying to wind this draft down. If I don't hear >>>> any objections to the proposal below, I'm going to assume >>>> >> that no one >> >>>> cares except me and Hadriel. >>>> >>>> Unless you reply with an objection before COB Monday, I'm updating >>>> the document to reflect this proposal. >>>> >>>> /a >>>> >>>> On 5/18/10 5:12 PM, Adam Roach wrote: >>>> >>>> >>>>> We're down to a fairly small number of open issues on GIN. >>>>> >>>>> Currently, section 7.2.2 of the GIN document describes >>>>> >> some fairly >> >>>>> specific behavior for "reg" event handling. In >>>>> >> particular, it says >> >>>>> that subscriptions to the state of a single phone number >>>>> >>>>> >>>> are forwarded >>>> >>>> >>>>> by the SSP to the PBX. There's some logic in the document >>>>> >>>>> >>>> about why I >>>> >>>> >>>>> thought this was a Good Idea, and even "important." >>>>> >>>>> At the most recent interim, we had a fairly long discussion about >>>>> whether this was actually the "right" thing to do. Hadriel >>>>> >>>>> >>>> made some >>>> >>>> >>>>> convincing arguments that the SSP should service the >>>>> >> subscriptions, >> >>>>> since it really "owns" the URIs in question. >>>>> >>>>> The "vermouth" draft delves a bit deeper into some related >>>>> >>>>> >>>> issues, but >>>> >>>> >>>>> it's somewhat less developed than GIN at this point. We >>>>> >>>>> >>>> don't want to >>>> >>>> >>>>> make GIN dependent on vermouth, and we really can't leave a >>>>> >>>>> >>>> treatment >>>> >>>> >>>>> of the "reg" event package out of GIN: GIN deals intimately with >>>>> registration. Under any reasonable "you break it you buy it" >>>>> principle, we're on the hook for coming up with a sane >>>>> >> treatment of >> >>>>> the "reg" event package. >>>>> >>>>> After an off-list exchange with Hadriel, I *think* we're >>>>> >>>>> >>>> both okay if >>>> >>>> >>>>> that treatment is as simple as "here are the properties if >>>>> >>>>> >>>> you handle >>>> >>>> >>>>> it at the SSP, here are the properties if you handle it >>>>> >> at the PBX, >> >>>>> and which you choose is a matter of policy." (I don't mean to put >>>>> words in Hadriel's mouth, and I'm sure he'll correct me if >>>>> >>>>> >>>> my summary >>>> >>>> >>>>> isn't consistent with his position). >>>>> >>>>> This approach is actually pretty well in line with the way >>>>> >>>>> >>>> that event >>>> >>>> >>>>> packages are handled in general. It also allows for some >>>>> >> clever (if >> >>>>> complicated) solutions to the problem in which the SSP >>>>> >> services the >> >>>>> subscription, but incorporates information it has learned >>>>> >>>>> >>>> from the PBX >>>> >>>> >>>>> (say, through back-end subscriptions). Basically, it gets >>>>> >>>>> >>>> us back to >>>> >>>> >>>>> what the IETF does well -- defining protocol mechanisms -- while >>>>> leaving concrete architectures up to other organizations. >>>>> >>>>> Please comment on whether you think this is a reasonable way to >>>>> address this open issue. If there is enough support, I'll >>>>> >>>>> >>>> craft some >>>> >>>> >>>>> formal text and put it in GIN. >>>>> >>>>> /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 adam@nostrum.com Mon May 24 08:02:25 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 461743A694E for ; Mon, 24 May 2010 08:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.349, 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 Y9p2nhF1pb69 for ; Mon, 24 May 2010 08:02:24 -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 1BAE93A691B for ; Mon, 24 May 2010 08:02:23 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4OF2Ei4048581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 10:02:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BFA94F6.3060306@nostrum.com> Date: Mon, 24 May 2010 10:02:14 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Elwell, John" References: <4BF7048B.4000208@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] New version of GIN (-03) -- temp-gruu fix 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, 24 May 2010 15:02:25 -0000 On 5/24/10 03:58, May 24, Elwell, John wrote: > Adam, > > "K_e2 is shared with the PBXes via > provisioning." > > It would be nice to avoid this. Any reason it can't be shared by means of the 2xx response to REGISTER? > It's a bit too large for that. Even for a 1024-bit key (which is pretty much the smallest RSA key one would consider using), you're looking at 171 bytes once you've base-64 encoded them. 2048-bit keys, which are not unrealistically large, would be 342 bytes long. I think these would pose very real problems in a REGISTER response. I did briefly think about using draft-ietf-sip-certs to get keys, but that introduced even *more* complexity. Plus, it can be added on as an extension at a later date if people really want it. But I think we'd be really getting out way in front of demand if we did that now. /a From richard@shockey.us Mon May 24 09:16: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 85E8F3A699C for ; Mon, 24 May 2010 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_50=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 2nxA0xXjXU0u for ; Mon, 24 May 2010 09:15:55 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 3A9B93A6BD2 for ; Mon, 24 May 2010 09:15:54 -0700 (PDT) Received: (qmail 2683 invoked by uid 0); 24 May 2010 16:15:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 24 May 2010 16:15:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=NaDMkcE9KBaMPIncBv9JBCZK7V0mD2LSI3SMjqbb5+bNiZgMaCuk+CBUCgLy8FWRsaRCqJU7EK2t3KjD/d/zAhIYn6Hoiw8LR67Uh+gXYMZ92IWy7xQK9k2CbbKBKzlL; 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 1OGaJb-0000wK-37; Mon, 24 May 2010 10:15:43 -0600 From: "Richard Shockey" To: "'Adam Roach'" , "'DRAGE, Keith \(Keith\)'" References: <4BF310DB.1000700@nostrum.com> <4BF6FEBF.4030403@nostrum.com> <4BFA91A8.5070508@nostrum.com> <4BFA94B1.4080900@nostrum.com> In-Reply-To: <4BFA94B1.4080900@nostrum.com> Date: Mon, 24 May 2010 12:15:35 -0400 Message-ID: <001001cafb5c$5850be10$08f23a30$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7UfLszUC+NODMTHSIe9CuKzCgFAAChzPg 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} Cc: martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 16:16:12 -0000 Thank you Adam .. what most of us want here is a solution sooner rather than later .. actually 6 months ago. What is most important now is closure and clarity of the solution(s). -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Monday, May 24, 2010 11:01 AM To: DRAGE, Keith (Keith) Cc: martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package I make May 18th (when I first posted for feedback on the issue) to May 24th to be six calendar days, four working days. Regardless of our disagreement on accounting, I think my question remains valid. You're effectively asking for more time, and that is reasonable in and of itself. Without proposing an alternate deadline, you're also effectively asking for an arbitrary, unbounded amount of additional time, which is not. So, how long do you want? /a On 5/24/10 09:53, May 24, DRAGE, Keith (Keith) wrote: > I make after close of working time on Friday to close of working time on Monday equal to 1 working day, not 6. > > Keith > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Monday, May 24, 2010 3:48 PM >> To: DRAGE, Keith (Keith) >> Cc: martini@ietf.org >> Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: >> GIN and "reg" event package >> >> Keith: >> >> Fair enough. >> >> Six days is just under half the time typically allocated for >> a WGLC on a whole document. Since that isn't, in your >> opinion, long enough for a single (relatively >> inconsequential) issue... then how long is? >> >> /a >> >> On 5/24/10 09:40, May 24, DRAGE, Keith (Keith) wrote: >> >>> Sorry, that is too short notice to find time to deal with >>> >> this, and therefore unreasonable. >> >>> Keith >>> >>> >>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org >>>> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach >>>> Sent: Friday, May 21, 2010 10:45 PM >>>> To: martini@ietf.org >>>> Subject: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and >>>> "reg" event package >>>> >>>> Okay, we're really trying to wind this draft down. If I don't hear >>>> any objections to the proposal below, I'm going to assume >>>> >> that no one >> >>>> cares except me and Hadriel. >>>> >>>> Unless you reply with an objection before COB Monday, I'm updating >>>> the document to reflect this proposal. >>>> >>>> /a >>>> >>>> On 5/18/10 5:12 PM, Adam Roach wrote: >>>> >>>> >>>>> We're down to a fairly small number of open issues on GIN. >>>>> >>>>> Currently, section 7.2.2 of the GIN document describes >>>>> >> some fairly >> >>>>> specific behavior for "reg" event handling. In >>>>> >> particular, it says >> >>>>> that subscriptions to the state of a single phone number >>>>> >>>>> >>>> are forwarded >>>> >>>> >>>>> by the SSP to the PBX. There's some logic in the document >>>>> >>>>> >>>> about why I >>>> >>>> >>>>> thought this was a Good Idea, and even "important." >>>>> >>>>> At the most recent interim, we had a fairly long discussion about >>>>> whether this was actually the "right" thing to do. Hadriel >>>>> >>>>> >>>> made some >>>> >>>> >>>>> convincing arguments that the SSP should service the >>>>> >> subscriptions, >> >>>>> since it really "owns" the URIs in question. >>>>> >>>>> The "vermouth" draft delves a bit deeper into some related >>>>> >>>>> >>>> issues, but >>>> >>>> >>>>> it's somewhat less developed than GIN at this point. We >>>>> >>>>> >>>> don't want to >>>> >>>> >>>>> make GIN dependent on vermouth, and we really can't leave a >>>>> >>>>> >>>> treatment >>>> >>>> >>>>> of the "reg" event package out of GIN: GIN deals intimately with >>>>> registration. Under any reasonable "you break it you buy it" >>>>> principle, we're on the hook for coming up with a sane >>>>> >> treatment of >> >>>>> the "reg" event package. >>>>> >>>>> After an off-list exchange with Hadriel, I *think* we're >>>>> >>>>> >>>> both okay if >>>> >>>> >>>>> that treatment is as simple as "here are the properties if >>>>> >>>>> >>>> you handle >>>> >>>> >>>>> it at the SSP, here are the properties if you handle it >>>>> >> at the PBX, >> >>>>> and which you choose is a matter of policy." (I don't mean to put >>>>> words in Hadriel's mouth, and I'm sure he'll correct me if >>>>> >>>>> >>>> my summary >>>> >>>> >>>>> isn't consistent with his position). >>>>> >>>>> This approach is actually pretty well in line with the way >>>>> >>>>> >>>> that event >>>> >>>> >>>>> packages are handled in general. It also allows for some >>>>> >> clever (if >> >>>>> complicated) solutions to the problem in which the SSP >>>>> >> services the >> >>>>> subscription, but incorporates information it has learned >>>>> >>>>> >>>> from the PBX >>>> >>>> >>>>> (say, through back-end subscriptions). Basically, it gets >>>>> >>>>> >>>> us back to >>>> >>>> >>>>> what the IETF does well -- defining protocol mechanisms -- while >>>>> leaving concrete architectures up to other organizations. >>>>> >>>>> Please comment on whether you think this is a reasonable way to >>>>> address this open issue. If there is enough support, I'll >>>>> >>>>> >>>> craft some >>>> >>>> >>>>> formal text and put it in GIN. >>>>> >>>>> /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 bernard_aboba@hotmail.com Mon May 24 09: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 AE2A03A6E1E for ; Mon, 24 May 2010 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.354 X-Spam-Level: X-Spam-Status: No, score=0.354 tagged_above=-999 required=5 tests=[AWL=0.352, 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 eBru3HOG88Mo for ; Mon, 24 May 2010 09:41:17 -0700 (PDT) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by core3.amsl.com (Postfix) with ESMTP id 6CE1C3A71CC for ; Mon, 24 May 2010 09:37:56 -0700 (PDT) Received: from BLU137-W33 ([65.55.111.72]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 May 2010 09:37:48 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ef55d6ca-fddf-42b2-85f8-71777f1cdd02_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Mon, 24 May 2010 09:37:48 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 May 2010 16:37:48.0824 (UTC) FILETIME=[7219D180:01CAFB5F] Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 16:41:18 -0000 --_ef55d6ca-fddf-42b2-85f8-71777f1cdd02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Hadriel's argument that the SSP should service the=20 subscriptions=2C since it "owns" the URIs.=20 I also agree that we=20 should not add a dependency on VERMOUTH.=20 What I'm not sure about is why servicing subscriptions at the SSP or PBX is a matter of=20 policy. Are there situations in which servicing the subscriptions at=20 the PBX would make sense? We're always talking about URIs owned by the=20 SSP=2C correct? On 5/18/10 5:12 PM=2C Adam Roach wrote: =20 We're down to a fairly small number of open issues on GIN. =20 Currently=2C section 7.2.2 of the GIN document describes some fairly=20 specific behavior for "reg" event handling. In particular=2C it says that=20 subscriptions to the state of a single phone number are forwarded by the SSP to the PBX. There's some logic in the document about why I thought=20 this was a Good Idea=2C and even "important." At the most=20 recent interim=2C we had a fairly long discussion about whether this was=20 actually the "right" thing to do. Hadriel made some convincing arguments that the SSP should service the subscriptions=2C since it really "owns"=20 the URIs in question. The "vermouth" draft delves a bit=20 deeper into some related issues=2C but it's somewhat less developed than=20 GIN at this point. We don't want to make GIN dependent on vermouth=2C and=20 we really can't leave a treatment of the "reg" event package out of GIN: GIN deals intimately with registration. Under any reasonable "you break it you buy it" principle=2C we're on the hook for coming up with a sane=20 treatment of the "reg" event package. After an off-list=20 exchange with Hadriel=2C I *think* we're both okay if that treatment is as simple as "here are the properties if you handle it at the SSP=2C here=20 are the properties if you handle it at the PBX=2C and which you choose is a matter of policy." (I don't mean to put words in Hadriel's mouth=2C and=20 I'm sure he'll correct me if my summary isn't consistent with his=20 position). This approach is actually pretty well in line with the way that event packages are handled in general. It also allows for=20 some clever (if complicated) solutions to the problem in which the SSP=20 services the subscription=2C but incorporates information it has learned=20 from the PBX (say=2C through back-end subscriptions). Basically=2C it gets= =20 us back to what the IETF does well -- defining protocol mechanisms --=20 while leaving concrete architectures up to other organizations. =20 Please comment on whether you think this is a reasonable way to address this open issue. If there is enough support=2C I'll craft some formal=20 text and put it in GIN. = --_ef55d6ca-fddf-42b2-85f8-71777f1cdd02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Hadriel's argument that the SSP should service the=20 subscriptions=2C since it "owns" the URIs.

I also agree that we=20 should not add a dependency on VERMOUTH.

What I'm not sure about is why servicing subscriptions at the SSP or PBX is a matter of=20 policy. =3B Are there situations in which servicing the subscriptions a= t=20 the PBX would make sense? =3B We're always talking about URIs owned by = the=20 SSP=2C correct?

On 5/18/10 5:12 PM=2C Adam Roach wrote:

 = =3B =3B =3B=20 We're down to a fairly small number of open issues on GIN.

 =3B&= nbsp=3B =3B=20 Currently=2C section 7.2.2 of the GIN document describes some fairly=20 specific behavior for "reg" event handling. In particular=2C it says that=20 subscriptions to the state of a single phone number are forwarded by the SSP to the PBX. There's some logic in the document about why I thought=20 this was a Good Idea=2C and even "important."

 =3B =3B = =3B At the most=20 recent interim=2C we had a fairly long discussion about whether this was=20 actually the "right" thing to do. Hadriel made some convincing arguments that the SSP should service the subscriptions=2C since it really "owns"=20 the URIs in question.

 =3B =3B =3B The "vermouth" draft = delves a bit=20 deeper into some related issues=2C but it's somewhat less developed than=20 GIN at this point. We don't want to make GIN dependent on vermouth=2C and=20 we really can't leave a treatment of the "reg" event package out of GIN: GIN deals intimately with registration. Under any reasonable "you break it you buy it" principle=2C we're on the hook for coming up with a sane=20 treatment of the "reg" event package.

 =3B =3B =3B After= an off-list=20 exchange with Hadriel=2C I *think* we're both okay if that treatment is as simple as "here are the properties if you handle it at the SSP=2C here=20 are the properties if you handle it at the PBX=2C and which you choose is a matter of policy." (I don't mean to put words in Hadriel's mouth=2C and=20 I'm sure he'll correct me if my summary isn't consistent with his=20 position).

 =3B =3B =3B This approach is actually pretty= well in line with the way that event packages are handled in general. It also allows for=20 some clever (if complicated) solutions to the problem in which the SSP=20 services the subscription=2C but incorporates information it has learned=20 from the PBX (say=2C through back-end subscriptions). Basically=2C it gets= =20 us back to what the IETF does well -- defining protocol mechanisms --=20 while leaving concrete architectures up to other organizations.

&nbs= p=3B =3B =3B Please comment on whether you think this is a reasonable way to address this open issue. If there is enough support=2C I'll craft some formal=20 text and put it in GIN. = --_ef55d6ca-fddf-42b2-85f8-71777f1cdd02_-- From pkyzivat@cisco.com Mon May 24 10:16: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 9A8263A6D6A for ; Mon, 24 May 2010 10:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.92 X-Spam-Level: X-Spam-Status: No, score=-8.92 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_50=0.001, 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 OhNCQcJBVkf9 for ; Mon, 24 May 2010 10:15:46 -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 079EA3A6C97 for ; Mon, 24 May 2010 10:15:33 -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: AvsEAHVR+ktAZnwN/2dsb2JhbACeEnGme5lbgmCCMwQ X-IronPort-AV: E=Sophos;i="4.53,292,1272844800"; d="scan'208";a="114304154" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2010 17:15:16 +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 o4OHFFDn015262; Mon, 24 May 2010 17:15:16 GMT Message-ID: <4BFAB424.2060309@cisco.com> Date: Mon, 24 May 2010 13:15:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 17:16:05 -0000 Bernard Aboba wrote: > I agree with Hadriel's argument that the SSP should service the > subscriptions, since it "owns" the URIs. > > I also agree that we should not add a dependency on VERMOUTH. > > What I'm not sure about is why servicing subscriptions at the SSP or PBX > is a matter of policy. Are there situations in which servicing the > subscriptions at the PBX would make sense? We're always talking about > URIs owned by the SSP, correct? They are *owned* by the SSP, but *delegated* to the PBX. The SSP doesn't know very much about those AORs - only that they are delegated to the PBX. The PBX has much more information - e.g. about registered UAs. You could think of this like a symbolic link in a file system, to a directory. Sometimes you want info about the link, sometimes about the target of the link. I guess you could have a subscription to sip:+12125551234@SSP.net just return the info that there is one registered contact: sip:+12125551234@. But then the subscriber would need to subscribe to that contact to get the interesting information. And we don't have a way to get a subscription there. Thanks, Paul > On 5/18/10 5:12 PM, Adam Roach wrote: > > We're down to a fairly small number of open issues on GIN. > > Currently, section 7.2.2 of the GIN document describes some fairly > specific behavior for "reg" event handling. In particular, it says that > subscriptions to the state of a single phone number are forwarded by the > SSP to the PBX. There's some logic in the document about why I thought > this was a Good Idea, and even "important." > > At the most recent interim, we had a fairly long discussion about > whether this was actually the "right" thing to do. Hadriel made some > convincing arguments that the SSP should service the subscriptions, > since it really "owns" the URIs in question. > > The "vermouth" draft delves a bit deeper into some related issues, > but it's somewhat less developed than GIN at this point. We don't want > to make GIN dependent on vermouth, and we really can't leave a treatment > of the "reg" event package out of GIN: GIN deals intimately with > registration. Under any reasonable "you break it you buy it" principle, > we're on the hook for coming up with a sane treatment of the "reg" event > package. > > After an off-list exchange with Hadriel, I *think* we're both okay > if that treatment is as simple as "here are the properties if you handle > it at the SSP, here are the properties if you handle it at the PBX, and > which you choose is a matter of policy." (I don't mean to put words in > Hadriel's mouth, and I'm sure he'll correct me if my summary isn't > consistent with his position). > > This approach is actually pretty well in line with the way that > event packages are handled in general. It also allows for some clever > (if complicated) solutions to the problem in which the SSP services the > subscription, but incorporates information it has learned from the PBX > (say, through back-end subscriptions). Basically, it gets us back to > what the IETF does well -- defining protocol mechanisms -- while leaving > concrete architectures up to other organizations. > > Please comment on whether you think this is a reasonable way to > address this open issue. If there is enough support, I'll craft some > formal text and put it in GIN. > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Mon May 24 10:17:42 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 E26753A6C81 for ; Mon, 24 May 2010 10:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_80=2, 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 05UoGiD1vrPX for ; Mon, 24 May 2010 10:17:40 -0700 (PDT) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by core3.amsl.com (Postfix) with ESMTP id 42F733A6CBD for ; Mon, 24 May 2010 10:17:37 -0700 (PDT) Received: from BLU137-W15 ([65.55.111.71]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 May 2010 10:17:29 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_4ffc6ff1-8bb4-4e38-b748-58f0dfcb8964_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Mon, 24 May 2010 10:17:29 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 May 2010 17:17:29.0653 (UTC) FILETIME=[FD2F7E50:01CAFB64] Subject: [martini] MARTINI Dot Racing (was RESPONSE REQUESTED) 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, 24 May 2010 17:17:42 -0000 --_4ffc6ff1-8bb4-4e38-b748-58f0dfcb8964_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In this particular case=2C we have the MARTINI equivalent of "dot racing"= =2C where we seem to have three potential choices:=20 a. Service the reg-event subscriptions at the PBX (green dot) b. Service the reg-event subscriptions at the SSP (yellow dot)=20 c. Service the reg-event subscriptions at either the SSP=2C or PBX dependin= g on policy (red dot)=20 Adam's original proposal was a)=2C Hadriel proposed b)=2C and the current p= roposal is c).=20 So the question posted to the WG was essentially whether to place a wager o= n the green=2C yellow or red dot.=20 Given the limited potential outcomes=2C it does not seem unreasonable to re= quest feedback from the WG within a week.=20 I'd also note that in the context of a dot race=2C one can certainly object= to the race on a number of grounds.=20 However=2C typically this will not stop the race.=20 Adam Roach said: "alternate proposals for a path forward." "Ah=2C I appear to have misspoken. When I said 'objections=2C' I meant "al= ternate proposals for a path forward." Thanks for giving me the opportunity= to clear that up." Richard Shockey said: "So Marty ...what is your alternate text? Saying you don't like something i= s not helpful unless you can demonstrate to the WG exactly what is a technically rational counterproposal. " = --_4ffc6ff1-8bb4-4e38-b748-58f0dfcb8964_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
In this particular case=2C we have the MARTINI equivalent of "dot =
racing"=2C where we seem to have three potential choices: 

a. Servic=
e the reg-event subscriptions at the PBX (green dot)
b. Service the reg-=
event subscriptions at the SSP (yellow dot) 
c. Service the reg-event su=
bscriptions at either the SSP=2C or PBX depending on policy (red dot) 
<=
br>Adam's original proposal was a)=2C Hadriel proposed b)=2C and the curren=
t proposal is c). 

So the question posted to the WG was essentially =
whether to place a wager on the green=2C yellow or red dot. 

Given t=
he limited potential outcomes=2C it does not seem unreasonable to request f=
eedback from the WG within a week. 

I'd also note that in the contex=
t of a dot race=2C one can certainly object to the race on a number of grou=
nds. 

However=2C typically this will not stop the race. 

Adam=
 Roach said:

"alternate proposals for a path forward."

"Ah=2C=
 I appear to have misspoken.  When I said 'objections=2C' I meant "alternat=
e proposals for a path forward." Thanks for giving me the opportunity to cl=
ear that up."

Richard Shockey said:

"So Marty ...what is your=
 alternate text? Saying you don't like something is
not helpful unless y=
ou can demonstrate to the WG exactly what is a
technically rational coun=
terproposal. "
= --_4ffc6ff1-8bb4-4e38-b748-58f0dfcb8964_-- From christer.holmberg@ericsson.com Mon May 24 10:59:21 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 2FE0E3A6D93 for ; Mon, 24 May 2010 10:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=1.402, 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 WFWZSrSnrHSe for ; Mon, 24 May 2010 10:59:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E72AF3A6BBF for ; Mon, 24 May 2010 10:59:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-21-4bfabe689e6e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E2.AA.08537.86EBAFB4; Mon, 24 May 2010 19:59:04 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 24 May 2010 19:59:04 +0200 From: Christer Holmberg To: "martini@ietf.org" Date: Mon, 24 May 2010 19:59:03 +0200 Thread-Topic: Usage of autouser outside GIN Thread-Index: AQHK+2rLGPoIpumzL0ar3I02f6ifWg== Message-ID: 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: [martini] Usage of autouser outside 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: Mon, 24 May 2010 17:59:21 -0000 Hi, I appologize if the following question has been asked and discussed before = (I have been disconnected from MARTINI for a while). The GIN draft defines the "autouser" parameter, and describes how it is use= d by PBXs and SSPs using GIN. But, I can't find any text whether the usage is only restricted to GIN, or = whether it could also be used elsewhere. If it is restricted to GIN, I think it would be useful to specify that. Oth= erwise people may start using it in other scenarios also... I ASSUME something similar may apply to the "sg" parameter, but I haven't c= hecked that. Thanks! Regards, Christer= From adam@nostrum.com Mon May 24 11:38:01 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 0E8313A6EEC for ; Mon, 24 May 2010 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.292, 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 REgA8nQ5gHHu for ; Mon, 24 May 2010 11:38:00 -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 08F633A67FB for ; Mon, 24 May 2010 11:32:42 -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 o4OIWVKn064872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 13:32:32 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BFAC63F.4070301@nostrum.com> Date: Mon, 24 May 2010 13:32:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Christer Holmberg 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] Usage of autouser outside 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: Mon, 24 May 2010 18:38:01 -0000 On 5/24/10 12:59 PM, Christer Holmberg wrote: > Hi, > > I appologize if the following question has been asked and discussed before (I have been disconnected from MARTINI for a while). > > The GIN draft defines the "autouser" parameter, and describes how it is used by PBXs and SSPs using GIN. > > But, I can't find any text whether the usage is only restricted to GIN, or whether it could also be used elsewhere. > > If it is restricted to GIN, I think it would be useful to specify that. Otherwise people may start using it in other scenarios also... > > I ASSUME something similar may apply to the "sg" parameter, but I haven't checked that. > Yes, they are both specific to GIN's usage. I'll include text to that effect in -04. Thanks! /a From adam@nostrum.com Mon May 24 12:29: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 922103A6CDB for ; Mon, 24 May 2010 12:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_05=-1.11, 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 Fl8glR7FYbOn for ; Mon, 24 May 2010 12:29:37 -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 5EA953A704F for ; Mon, 24 May 2010 12:29:12 -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 o4OJT2th075282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 14:29:02 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BFAD37E.6040000@nostrum.com> Date: Mon, 24 May 2010 14:29:02 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050800010107050409040204" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 19:29:38 -0000 This is a multi-part message in MIME format. --------------050800010107050409040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/24/10 11:37 AM, Bernard Aboba wrote: > I agree with Hadriel's argument that the SSP should service the > subscriptions, since it "owns" the URIs. > > I also agree that we should not add a dependency on VERMOUTH. > > What I'm not sure about is why servicing subscriptions at the SSP or > PBX is a matter of policy. Are there situations in which servicing > the subscriptions at the PBX would make sense? Definitely. For reg-event, the PBX is the only entity that will know stuff like "this extension has three terminals registered." It's the only one that can say stuff like "the terminal for +12143290491 has registered a callee capability of 'video'". The SSP won't have the first foggy clue that these kinds of things are true. All that said, I *understand* the position that you and Hadriel have put forth, and can see that it makes sense in certain architectures. Emphasis on the last three words of that sentence. Which is why I've proposed the third way of putting in a discussion about the properties of servicing at the SSP versus the properties of servicing at the PBX, and leaving the actual decision -- which comes down to network architecture -- to SDOs who claim to do network architecture. /a --------------050800010107050409040204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/24/10 11:37 AM, Bernard Aboba wrote:
I agree with Hadriel's argument that the SSP should service the subscriptions, since it "owns" the URIs.

I also agree that we should not add a dependency on VERMOUTH.

What I'm not sure about is why servicing subscriptions at the SSP or PBX is a matter of policy.  Are there situations in which servicing the subscriptions at the PBX would make sense?

Definitely. For reg-event, the PBX is the only entity that will know stuff like "this extension has three terminals registered." It's the only one that can say stuff like "the terminal for +12143290491 has registered a callee capability of 'video'". The SSP won't have the first foggy clue that these kinds of things are true.

All that said, I *understand* the position that you and Hadriel have put forth, and can see that it makes sense in certain architectures. Emphasis on the last three words of that sentence.

Which is why I've proposed the third way of putting in a discussion about the properties of servicing at the SSP versus the properties of servicing at the PBX, and leaving the actual decision -- which comes down to network architecture -- to SDOs who claim to do network architecture.

/a
--------------050800010107050409040204-- From christer.holmberg@ericsson.com Mon May 24 12:54:57 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 C1A673A6812 for ; Mon, 24 May 2010 12:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=-0.605, 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 UrzD-1W6kGac for ; Mon, 24 May 2010 12:54:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A8C123A6FB2 for ; Mon, 24 May 2010 12:54:56 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-f1-4bfad987118a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 13.AA.21861.789DAFB4; Mon, 24 May 2010 21:54:47 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 24 May 2010 21:54:46 +0200 From: Christer Holmberg To: "martini@ietf.org" Date: Mon, 24 May 2010 21:54:45 +0200 Thread-Topic: SIP-PBX, PBX and IP-PBX Thread-Index: AQHK+3r19vNzhcVo3EKLjiWQpoH58A== Message-ID: 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-Brightmail-Tracker: AAAAAA== Subject: [martini] SIP-PBX, PBX and IP-PBX 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, 24 May 2010 19:54:57 -0000 Hi, The requirements talk about SIP-PBXs, GIN talks about PBXs, and VERMOUTH ta= lks about IP-PBXs :) I think we should try to use common terminology, because I assume we are ta= lking about the same thing in all cases, aren't we?. Regards, Christer From spencer@wonderhamster.org Mon May 24 13:08:40 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 C5FD43A6B0A for ; Mon, 24 May 2010 13:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.868, 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 P9yIVdfEDq+z for ; Mon, 24 May 2010 13:08:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id E58B63A6CC9 for ; Mon, 24 May 2010 13:08:39 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MNqOx-1O9kJy2elf-006cJY; Mon, 24 May 2010 16:08:31 -0400 Message-ID: <98F231212C8349989F818717F48F0494@china.huawei.com> From: "Spencer Dawkins" To: "Christer Holmberg" , References: Date: Mon, 24 May 2010 15:08:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Provags-ID: V01U2FsdGVkX1/xbnR3Am1QdB0sc0fqUPCEWlBgaQ6fLFUBP30 WRrIBZ6TBqpCizBtHVaRoG+A1QvOsSF5xJsEGaAMAZrM/i/JjE J8UCDy5xxuWYlnujnAJWGbYFsQYOyZpF+JiiiFLYn4= Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 24 May 2010 20:08:40 -0000 Speaking as chair, that would be lovely :D Spencer > Hi, > > The requirements talk about SIP-PBXs, GIN talks about PBXs, and VERMOUTH > talks about IP-PBXs :) > > I think we should try to use common terminology, because I assume we are > talking about the same thing in all cases, aren't we?. > > Regards, > > Christer From adam@nostrum.com Mon May 24 13:34:08 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 79CD03A6EA5 for ; Mon, 24 May 2010 13:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.294, 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 omxXXmCBz4Gg for ; Mon, 24 May 2010 13:34: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 2077C3A67AC for ; Mon, 24 May 2010 13:34: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 o4OKXtxj024271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 15:33:55 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BFAE2B3.6070602@nostrum.com> Date: Mon, 24 May 2010 15:33:55 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Spencer Dawkins References: <98F231212C8349989F818717F48F0494@china.huawei.com> In-Reply-To: <98F231212C8349989F818717F48F0494@china.huawei.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 Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 24 May 2010 20:34:08 -0000 I'll defer to the terminology used in the WG charter, and change GIN to read "SIP-PBX" in the next iteration. /a On 5/24/10 3:08 PM, Spencer Dawkins wrote: > Speaking as chair, that would be lovely :D > > Spencer > > >> Hi, >> >> The requirements talk about SIP-PBXs, GIN talks about PBXs, and >> VERMOUTH talks about IP-PBXs :) >> >> I think we should try to use common terminology, because I assume we >> are talking about the same thing in all cases, aren't we?. >> >> Regards, >> >> Christer > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Mon May 24 15:49:26 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 195F83A6CF4 for ; Mon, 24 May 2010 15:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[AWL=0.348, 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 X-n7LnuPkw8x for ; Mon, 24 May 2010 15:49:24 -0700 (PDT) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by core3.amsl.com (Postfix) with ESMTP id B27263A6A5A for ; Mon, 24 May 2010 15:49:24 -0700 (PDT) Received: from BLU137-W28 ([65.55.111.73]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 May 2010 15:49:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a4fc6984-2557-42b2-8530-bc3c5b5372c4_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Mon, 24 May 2010 15:49:16 -0700 Importance: Normal In-Reply-To: <4BFAD37E.6040000@nostrum.com> References: , <4BFAD37E.6040000@nostrum.com> MIME-Version: 1.0 X-OriginalArrivalTime: 24 May 2010 22:49:17.0253 (UTC) FILETIME=[570A2F50:01CAFB93] Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 24 May 2010 22:49:26 -0000 --_a4fc6984-2557-42b2-8530-bc3c5b5372c4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks to Paul and Adam for the explanation. Adding a paragraph or two exp= laining the reasoning might be helpful.=20 Paul Kyzivat said: "They are *owned* by the SSP=2C but *delegated* to the PBX. The SSP doesn't know very much about those AORs - only that=20 they are=20 delegated to the PBX. The PBX has much more information - e.g.=20 about=20 registered UAs. You could think of this like a symbolic link in a file system=2C to a=20 directory. Sometimes you want info about the link=2C sometimes=20 about the=20 target of the link. I guess you could have a subscription to sip:+12125551234 at=20 SSP.net just=20 return the info that there is one registered contact:=20 sip:+12125551234@. But then the=20 subscriber would=20 need to subscribe to that contact to get the interesting=20 information.=20 And we don't have a way to get a subscription there. Thanks=2C Paul" Date: Mon=2C 24 May 2010 14:29:02 -0500 From: adam@nostrum.com To: bernard_aboba@hotmail.com CC: martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg"= event package =20 =20 On 5/24/10 11:37 AM=2C Bernard Aboba wrote: I agree with Hadriel's argument that the SSP should service the subscriptions=2C since it "owns" the URIs.=20 =20 I also agree that we should not add a dependency on VERMOUTH.=20 =20 What I'm not sure about is why servicing subscriptions at the SSP or PBX is a matter of policy. Are there situations in which servicing the subscriptions at the PBX would make sense? Definitely. For reg-event=2C the PBX is the only entity that will know stuff like "this extension has three terminals registered." It's the only one that can say stuff like "the terminal for +12143290491 has registered a callee capability of 'video'". The SSP won't have the first foggy clue that these kinds of things are true. All that said=2C I *understand* the position that you and Hadriel have put forth=2C and can see that it makes sense in certain architectures. Emphasis on the last three words of that sentence. Which is why I've proposed the third way of putting in a discussion about the properties of servicing at the SSP versus the properties of servicing at the PBX=2C and leaving the actual decision -- which comes down to network architecture -- to SDOs who claim to do network architecture. /a = --_a4fc6984-2557-42b2-8530-bc3c5b5372c4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks to Paul and Adam for the explanation. =3B Adding a paragraph or = two explaining the reasoning might be helpful.

Paul Kyzivat said:
"They are *owned* by the SSP=2C but *delegated* to the PBX.
Th= e SSP doesn't know very much about those AORs - only that=20 they are=20 delegated to the PBX. The PBX has much more information - e.g.=20 about=20 registered UAs. You could think of this like a symbolic link in a file system=2C to a=20 directory. Sometimes you want info about the link=2C sometimes=20 about the=20 target of the link. I guess you could have a subscription to sip:+12125551234 at=20 SSP.net just=20 return the info that there is one registered contact:=20 sip:+12125551234@<=3Bpbx-contact-address>=3B. But then the=20 subscriber would=20 need to subscribe to that contact to get the interesting=20 information.=20 And we don't have a way to get a subscription there.

<= pre style=3D"margin: 0em=3B"> Thanks=2C
Paul"

Date: Mon=2C 24 May 2010 14:29:02 -0500
From: adam@nostrum.c= om
To: bernard_aboba@hotmail.com
CC: martini@ietf.org
Subject: Re:= [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event packa= ge

=20 On 5/24/10 11:37 AM=2C Bernard Aboba wrote:
I agree with Hadriel's argument that the SSP should service the subscriptions=2C since it "owns" the URIs.

I also agree that we should not add a dependency on VERMOUTH.

What I'm not sure about is why servicing subscriptions at the SSP or PBX is a matter of policy. =3B Are there situations in which servicing = the subscriptions at the PBX would make sense?

Definitely. For reg-event=2C the PBX is the only entity that will know stuff like "this extension has three terminals registered." It's the only one that can say stuff like "the terminal for +12143290491 has registered a callee capability of 'video'". The SSP won't have the first foggy clue that these kinds of things are true.

All that said=2C I *understand* the position that you and Hadriel have put forth=2C and can see that it makes sense in certain architectures. Emphasis on the last three words of that sentence.

Which is why I've proposed the third way of putting in a discussion about the properties of servicing at the SSP versus the properties of servicing at the PBX=2C and leaving the actual decision -- which comes down to network architecture -- to SDOs who claim to do network architecture.

/a
= --_a4fc6984-2557-42b2-8530-bc3c5b5372c4_-- From john.elwell@siemens-enterprise.com Tue May 25 00:11:29 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 D38F23A6A44 for ; Tue, 25 May 2010 00:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_50=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 6-RtnNw6Lj4m for ; Tue, 25 May 2010 00:11:27 -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 0C56E3A6A34 for ; Tue, 25 May 2010 00:11:26 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-274486; Tue, 25 May 2010 09:11:17 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id E087823F028E; Tue, 25 May 2010 09:11:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 25 May 2010 09:11:17 +0200 From: "Elwell, John" To: Bernard Aboba , "martini@ietf.org" Date: Tue, 25 May 2010 09:11:16 +0200 Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr7X+0gMNaAHtk5SrSMBH0g/KMYtwAeJzow 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] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 25 May 2010 07:11:30 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: 24 May 2010 17:38 > To: martini@ietf.org > Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36:=20 > GIN and "reg" event package >=20 > I agree with Hadriel's argument that the SSP should service=20 > the subscriptions, since it "owns" the URIs.=20 >=20 > I also agree that we should not add a dependency on VERMOUTH.=20 >=20 > What I'm not sure about is why servicing subscriptions at the=20 > SSP or PBX is a matter of policy. Are there situations in=20 > which servicing the subscriptions at the PBX would make=20 > sense? We're always talking about URIs owned by the SSP, correct? [JRE] Let's consider other event packages, presence say. Ignoring MARTINI f= or now, if a SUBSCRIBE request for presence is targeted at alice@example.co= m, the example.com domain proxy has to use policy to know whether to route = it to a presence server in that domain or simply to route to Alice's regist= ered UA(s). Now extending this to the MARTINI situation, if a SUBSCRIBE request for pre= sence is targeted at alice@ssp.com, the ssp.com domain proxy has to use pol= icy to know whether to route it to a presence server within the SSP domain = or route to the PBX. In the latter case the PBX has to use policy to know w= hether to route to a presence server associated with the PBX or simply to r= oute to Alice's registered UA(s). John >=20 > On 5/18/10 5:12 PM, Adam Roach wrote: >=20 > We're down to a fairly small number of open issues on GIN. >=20 > Currently, section 7.2.2 of the GIN document describes=20 > some fairly specific behavior for "reg" event handling. In=20 > particular, it says that subscriptions to the state of a=20 > single phone number are forwarded by the SSP to the PBX.=20 > There's some logic in the document about why I thought this=20 > was a Good Idea, and even "important." >=20 > At the most recent interim, we had a fairly long=20 > discussion about whether this was actually the "right" thing=20 > to do. Hadriel made some convincing arguments that the SSP=20 > should service the subscriptions, since it really "owns" the=20 > URIs in question. >=20 > The "vermouth" draft delves a bit deeper into some=20 > related issues, but it's somewhat less developed than GIN at=20 > this point. We don't want to make GIN dependent on vermouth,=20 > and we really can't leave a treatment of the "reg" event=20 > package out of GIN: GIN deals intimately with registration.=20 > Under any reasonable "you break it you buy it" principle,=20 > we're on the hook for coming up with a sane treatment of the=20 > "reg" event package. >=20 > After an off-list exchange with Hadriel, I *think* we're=20 > both okay if that treatment is as simple as "here are the=20 > properties if you handle it at the SSP, here are the=20 > properties if you handle it at the PBX, and which you choose=20 > is a matter of policy." (I don't mean to put words in=20 > Hadriel's mouth, and I'm sure he'll correct me if my summary=20 > isn't consistent with his position). >=20 > This approach is actually pretty well in line with the=20 > way that event packages are handled in general. It also=20 > allows for some clever (if complicated) solutions to the=20 > problem in which the SSP services the subscription, but=20 > incorporates information it has learned from the PBX (say,=20 > through back-end subscriptions). Basically, it gets us back=20 > to what the IETF does well -- defining protocol mechanisms --=20 > while leaving concrete architectures up to other organizations. >=20 > Please comment on whether you think this is a reasonable=20 > way to address this open issue. If there is enough support,=20 > I'll craft some formal text and put it in GIN.=20 > = From keith.drage@alcatel-lucent.com Tue May 25 02:48:45 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 7078F3A6A7A for ; Tue, 25 May 2010 02:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=-2.229, BAYES_50=0.001, 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 LPyun5A-NwGR for ; Tue, 25 May 2010 02:48:44 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 4ED603A691D for ; Tue, 25 May 2010 02:48:43 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4P9h6sQ014233 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 May 2010 11:48:28 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 25 May 2010 11:47:42 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , Spencer Dawkins Date: Tue, 25 May 2010 11:47:41 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr7gHUKSwkklOz2QlW1GcpYxR6BvwAbkHAw Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> In-Reply-To: <4BFAE2B3.6070602@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-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 25 May 2010 09:48:45 -0000 I suspect in most cases you should not be using xxx-PBX at all, unless it i= s a restriction of MARTINI that the attached PBX cannot take traffic from o= ther PBXs in the same network. I would also point out that in using MARTINI= , what happens in the rest of the PBX should not necessarily be constrained= to be SIP. ETSI and ECMA agreed on a common terminology that started from the original= ISO root definition. "Corporate telecommunication Network (CN): sets of enterprise premises equi= pment, owned by or managed on behalf of an enterprise that are located at g= eographically dispersed locations and are interconnected to provide telecom= munication services to a defined group of users belonging to that enterpris= e enterprise: unit of economic organization or activity, especially a busines= s organization Next Generation CN (NGCN): self-contained corporate network designed to tak= e advantage of emerging IP-based communications solutions and that can have= its own applications and service provisioning NOTE 1: For the purpose of the present document it is a corporate network t= hat provides an IP-based interface to an NGN. NOTE 2: TR 102 478 [10] uses NGCN to collectively refer to IP-PBXs. NGCN site: separate part of an NGCN" regards Keith =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Monday, May 24, 2010 9:34 PM > To: Spencer Dawkins > Cc: martini@ietf.org > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX >=20 > I'll defer to the terminology used in the WG charter, and=20 > change GIN to read "SIP-PBX" in the next iteration. >=20 > /a >=20 > On 5/24/10 3:08 PM, Spencer Dawkins wrote: > > Speaking as chair, that would be lovely :D > > > > Spencer > > > > > >> Hi, > >> > >> The requirements talk about SIP-PBXs, GIN talks about PBXs, and=20 > >> VERMOUTH talks about IP-PBXs :) > >> > >> I think we should try to use common terminology, because I=20 > assume we=20 > >> are talking about the same thing in all cases, aren't we?. > >> > >> Regards, > >> > >> Christer > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From martien.huysmans@ericsson.com Tue May 25 03:52:19 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 130213A67E6 for ; Tue, 25 May 2010 03:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 5mGS3WJ8z+J0 for ; Tue, 25 May 2010 03:52:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 853923A6D6D for ; Tue, 25 May 2010 03:52:16 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-76-4bfbabd689cc Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.C6.08537.6DBABFB4; Tue, 25 May 2010 12:52:07 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 25 May 2010 12:52:06 +0200 From: Martien Huysmans To: Adam Roach Date: Tue, 25 May 2010 12:52:05 +0200 Thread-Topic: [martini] martini-gin-02: explicit registration & Reg Event Thread-Index: Acr46PzcMGF5Db2eQ5WHB5Ee0E/iPADDAIFw Message-ID: References: <4BF68996.2080900@nostrum.com> In-Reply-To: <4BF68996.2080900@nostrum.com> 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_B5CE2B521539624E8364D395B6F76B5C1DD66C6503ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: explicit registration & Reg Event 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, 25 May 2010 10:52:19 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C1DD66C6503ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam Ok, so for such an "individual extension" always normal processing applies. I am still somewhat confused by the existing text. GIN, chapter 5.2 says that an "individual extension that is implicitly regi= stered" may ALSO be explicitly registered. This text suggests that an such an individual extension has 2 Contacts, one= from bulk registration and one from the normal registration. A related question: what if such an individual extension has no active normal registrations, e.= g. because the device is turned of. I guess that normal processing shall apply. Agree? Perhaps it would be better if the text talks about "an individual extension= for which through provisioning it has been defined that normal registration/processing" applies. /Martiem ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Friday, May 21, 2010 3:25 PM To: Martien Huysmans Cc: martini@ietf.org Subject: Re: [martini] martini-gin-02: explicit registration & Reg Event On 5/21/10 01:09, May 21, Martien Huysmans wrote: Hi martini-gin-02 states in chapter 5.2: 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). Assume that an individual extension does a "normal, non-bulk" registratrati= on in additional to it's implcit registration. Question: How is a "reg" event SUBSCRIBE in such a case handled? Is it forwarded to t= he PBX? If so, does that PBX have knowledge of the "normal, non-bulk" registration? I don't think so. It's not a GIN registration, so normal processing applies= . /a --_000_B5CE2B521539624E8364D395B6F76B5C1DD66C6503ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adam
 
Ok, so for such an "individual extension" always n= ormal=20 processing applies.
I am= still=20 somewhat confused by the existing text.
 
GIN, chapter 5.2 says that an "individual extension that is implicitly registered" = may=20 ALSO be explicitly registered.
This text suggests that an such an individual exte= nsion has=20 2 Contacts, one from bulk registration and one from the normal=20 registration.
 
A related question:
what if such an individual= =20 extension has no active normal registrations, e.g. because the device is tu= rned=20 of.
I guess that normal processing shall apply.=20 Agree?
 
Perhaps it would be better if the text talks = about "an=20 individual extension for which through provisioning it
has been defined that norm= al=20 registration/processing" applies.
 
/Martiem

From: Adam Roach [mailto:adam@nostrum.c= om]=20
Sent: Friday, May 21, 2010 3:25 PM
To: Martien=20 Huysmans
Cc: martini@ietf.org
Subject: Re: [martini]=20 martini-gin-02: explicit registration & Reg Event

On 5/21/10 01:09, May 21, Martien Huysmans wrote:=20
Hi
 
martini-gin-02 states in chapter 5.2:
 
A further implication of this property is that an
   individual extension that is implicitly registered may = also=20 be
   explicitly registered using a normal, non-bulk registra= tion=20 (subject
   to SSP policy).
 
Assume that an individual extension does a "normal, non-bulk"=20 registratration
in additional to it's implcit registration.
 
Question:
How is a "reg" event SUBSCRIBE in such a case handled? Is it forward= ed to=20 the PBX?
If so, does that PBX have knowledge of the "normal, non-bulk"=20 registration?

 

I=20 don't think so. It's not a GIN registration, so normal processing=20 applies.

/a
--_000_B5CE2B521539624E8364D395B6F76B5C1DD66C6503ESESSCMS0356e_-- From martien.huysmans@ericsson.com Tue May 25 04:55: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 C3BBB3A6DF2 for ; Tue, 25 May 2010 04:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_50=0.001, 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 crBKr8EjdScN for ; Tue, 25 May 2010 04:55:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 84C833A6B37 for ; Tue, 25 May 2010 04:55:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-91-4bfbbac121f1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 67.6F.08537.1CABBFB4; Tue, 25 May 2010 13:55:46 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 25 May 2010 13:55:45 +0200 From: Martien Huysmans To: Adam Roach Date: Tue, 25 May 2010 13:55:44 +0200 Thread-Topic: [martini] martini-gin-02: profound impact Thread-Index: Acr47aCCudLHh1cMSOWHCu2ZrvWViQDE1BBA Message-ID: References: <4BF69162.8050802@nostrum.com> In-Reply-To: <4BF69162.8050802@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-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: profound impact 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, 25 May 2010 11:55:56 -0000 Adam I appreciate your effort. I do not want to change the text in section 2. I just want to understand it= 's message. So perhaps I do not really understand SIP, but this is a good time to learn= . What I fail to understand (from section 2) is how this (the PBX properties (1) and (2)) is different compared to a regula= r user signing up with a SSP which doesn't have (1) and (2) either. To me these (1) and (2) feel like no= rmal properties, nothing unique for a PBX. /Martien =20 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Friday, May 21, 2010 3:58 PM To: Martien Huysmans Cc: martini@ietf.org Subject: Re: [martini] martini-gin-02: profound impact On 5/21/10 01:42, May 21, Martien Huysmans wrote: > martini-gin-02, chapter 2 contains the following text > The following p= aragraph is perhaps the most important in > understanding the solution def= ined in this document. That can probably be tightened up. One can actually implement the solution = without understanding these constraints, but such a person may be left bogg= led by why things are done the way they are. So I'll revise to read "...in = understanding the reasons for the design decisions made in this document." > ... > In terms of impact to the solution at hand, > the following two constra= ints have the most profound effect: .... > ... > > These are some heavy words: "most important" and "profound ". > So I know that I really need understand this chapter. > But I do not. Can somebody explain? Wow. I thought the two highlighted constraints were written in clear, conci= se, unambiguous, and easy-to-understand language. Perhaps I presume too muc= h knowledge on behalf of my audience. For your benefit, I'll try to explain= these two constraints more explicitly below. Let me know if there's someth= ing regarding which you need further explanation. "(1) The PBX cannot be assumed to be assigned a static IP address" This means that the PBX may or may not have a static (unchanging) IP Addres= s (the unique identifier used to indicate end-points on the Internet), and = that we, as designers of the GIN solution, cannot make any assumptions one = way or the other about whether this is true. "(2) No DNS entry can be relied upon to consistently resolve to the IP addr= ess of the PBX." This means that there may or may not be an entry in the global Domain Name = Service database (the distributed database used on the internet to convert = human-readable names into IP addresses) that, when resolved, produces that = IP address of the PBX, and that we, as designers of the GIN solution, canno= t make any assumptions one way or another about whether this is true. If your confusion was in relation to any of the other three sentences in th= e section, let me know, and I can try to clear up their intended meaning. T= hey're less central to the thesis of this section, but I don't want them to= leave you confused. And, if your confusion isn't regarding any single sentence, but rather the = gestalt of the whole section, the short summary is: "This document proposes= doing some things that seem pretty stupid to anyone who really understands= SIP, but we have some good reasons for doing so. These reasons are explain= ed by the requirements document, and here are the two that make the biggest= difference." Does any of that help? /a From HKaplan@acmepacket.com Tue May 25 06:55: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 D07B73A6B31 for ; Tue, 25 May 2010 06:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=-0.367, 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 47Qt2bO6R9M1 for ; Tue, 25 May 2010 06:55:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D47003A6CEB for ; Tue, 25 May 2010 06:54:59 -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, 25 May 2010 09:54:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 25 May 2010 09:54:50 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Bernard Aboba Date: Tue, 25 May 2010 09:54:49 -0400 Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr7ZO9r28wXwicfQBmlNFLWdhvXZQArEh+Q Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A02F@mail> References: <4BFAB424.2060309@cisco.com> In-Reply-To: <4BFAB424.2060309@cisco.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" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 25 May 2010 13:55:00 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Paul Kyzivat >=20 > Bernard Aboba wrote: > > I agree with Hadriel's argument that the SSP should service the > > subscriptions, since it "owns" the URIs. > > > > I also agree that we should not add a dependency on VERMOUTH. > > > > What I'm not sure about is why servicing subscriptions at the SSP or PB= X > > is a matter of policy. Are there situations in which servicing the > > subscriptions at the PBX would make sense? We're always talking about > > URIs owned by the SSP, correct? >=20 > They are *owned* by the SSP, but *delegated* to the PBX. > The SSP doesn't know very much about those AORs - only that they are > delegated to the PBX. The PBX has much more information - e.g. about > registered UAs. I don't think you can make that blanket statement. The SSP could have othe= r UA's registered for one or more of those same AoR's. Unless we're explic= itly saying it can't.(?) =20 > I guess you could have a subscription to sip:+12125551234@SSP.net just > return the info that there is one registered contact: > sip:+12125551234@. But then the subscriber would > need to subscribe to that contact to get the interesting information. > And we don't have a way to get a subscription there. Yes we do. Send the SUBSCRIBE to the contact (and path info as Routes) of = that initial subscribe's notified xml doc entries. -hadriel From HKaplan@acmepacket.com Tue May 25 07:00:25 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 2A4F83A6B8B for ; Tue, 25 May 2010 07:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=-0.365, 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 I7x63Prid3yW for ; Tue, 25 May 2010 07:00:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 07B103A6A16 for ; Tue, 25 May 2010 07:00:23 -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, 25 May 2010 10:00:15 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 25 May 2010 10:00:14 -0400 From: Hadriel Kaplan To: Adam Roach , Bernard Aboba Date: Tue, 25 May 2010 10:00:13 -0400 Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr7d3DCAFs+EH1NSq6m2x8851oeygAmo90Q Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A033@mail> References: <4BFAD37E.6040000@nostrum.com> In-Reply-To: <4BFAD37E.6040000@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: "martini@ietf.org" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 25 May 2010 14:00:25 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Adam Roach > Sent: Monday, May 24, 2010 3:29 PM >=20 >=20 > Definitely. For reg-event, the PBX is the only entity that will know stuf= f > like "this extension has three terminals registered." It's the only one > that can say stuff like "the terminal for +12143290491 has registered a > callee capability of 'video'". The SSP won't have the first foggy clue > that these kinds of things are true. I guess one implicit assumption here is that the phones off the PBX registe= r for an AoR of the SSP, but in the PBX. I mean, let's say we've got "sip:= 12345@ssp.com". Do the "terminals" off the PBX REGISTER for the literal Ao= R "sip:12345@ssp.com"? =20 Because if they don't, then I don't see how a PBX processes a SUBSCRIBE for= reg-event for "sip:12345@ssp.com" and shows registered contacts of those t= erminals with that as the aor. I mean it could obviously, but it's not wha= t 3680 says. -hadriel From pkyzivat@cisco.com Tue May 25 07:31:39 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 C6BB13A7503 for ; Tue, 25 May 2010 07:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.213 X-Spam-Level: X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 9Eo6nXrcrj2f for ; Tue, 25 May 2010 07:31:36 -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 50F913A7236 for ; Tue, 25 May 2010 07:27:27 -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: AvsEAJt6+0tAZnwM/2dsb2JhbACeA3GlEpoJhRME X-IronPort-AV: E=Sophos;i="4.53,298,1272844800"; d="scan'208";a="114499920" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 May 2010 14:27:14 +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 o4PEREJL021850; Tue, 25 May 2010 14:27:14 GMT Message-ID: <4BFBDE3D.7060906@cisco.com> Date: Tue, 25 May 2010 10:27:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BFAB424.2060309@cisco.com> <430FC6BDED356B4C8498F634416644A91C13B8A02F@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A02F@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 25 May 2010 14:31:39 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> >> Bernard Aboba wrote: >>> I agree with Hadriel's argument that the SSP should service the >>> subscriptions, since it "owns" the URIs. >>> >>> I also agree that we should not add a dependency on VERMOUTH. >>> >>> What I'm not sure about is why servicing subscriptions at the SSP or PBX >>> is a matter of policy. Are there situations in which servicing the >>> subscriptions at the PBX would make sense? We're always talking about >>> URIs owned by the SSP, correct? >> They are *owned* by the SSP, but *delegated* to the PBX. >> The SSP doesn't know very much about those AORs - only that they are >> delegated to the PBX. The PBX has much more information - e.g. about >> registered UAs. > > I don't think you can make that blanket statement. The SSP could have other UA's registered for one or more of those same AoR's. Unless we're explicitly saying it can't.(?) Yes, that is a potential, though outside the mainstream of the cases being considered. >> I guess you could have a subscription to sip:+12125551234@SSP.net just >> return the info that there is one registered contact: >> sip:+12125551234@. But then the subscriber would >> need to subscribe to that contact to get the interesting information. >> And we don't have a way to get a subscription there. > > Yes we do. Send the SUBSCRIBE to the contact (and path info as Routes) of that initial subscribe's notified xml doc entries. This could be made to work, and may be the best alternative. I think this would require that the published contact address either be a GRUU, or contain an embedded Route header that references the SSP in some way, or else depend on the notification containing the GRUU and the subscriber knowing enough to use that for the subsequent subscription. Perhaps the last of those is the cleanest. But its not entirely clear to me how clients, who may not even know Martini mechanisms are in use, would know they should do this. Thanks, Paul From pkyzivat@cisco.com Tue May 25 07:36:01 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 EC3053A7433 for ; Tue, 25 May 2010 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 XTnJ2ArmmNwC for ; Tue, 25 May 2010 07:36:01 -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 033E53A7509 for ; Tue, 25 May 2010 07:31:58 -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: AvsEANB7+0tAZnwM/2dsb2JhbACeA3GlJZoKhRME X-IronPort-AV: E=Sophos;i="4.53,298,1272844800"; d="scan'208";a="114502156" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 May 2010 14:31:50 +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 o4PEVoIn024035; Tue, 25 May 2010 14:31:50 GMT Message-ID: <4BFBDF52.2020800@cisco.com> Date: Tue, 25 May 2010 10:31:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BFAD37E.6040000@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A033@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A033@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 25 May 2010 14:36:02 -0000 IIUC its most likely that we have "sip:12345@ssp.com" defined on the ssp, but the terminals are registering with "sip:12345@pbx.com". I don't see that as a fundamental problem. If the ssp receives a subscribe for "sip:12345@ssp.com" and retargets it to "sip:12345@ssp.com" then the pbx processes the subscription based on the R-URI. But note I just replied to your other mail in way that may make this moot. Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of Adam Roach >> Sent: Monday, May 24, 2010 3:29 PM >> >> >> Definitely. For reg-event, the PBX is the only entity that will know stuff >> like "this extension has three terminals registered." It's the only one >> that can say stuff like "the terminal for +12143290491 has registered a >> callee capability of 'video'". The SSP won't have the first foggy clue >> that these kinds of things are true. > > I guess one implicit assumption here is that the phones off the PBX register for an AoR of the SSP, but in the PBX. I mean, let's say we've got "sip:12345@ssp.com". Do the "terminals" off the PBX REGISTER for the literal AoR "sip:12345@ssp.com"? > > Because if they don't, then I don't see how a PBX processes a SUBSCRIBE for reg-event for "sip:12345@ssp.com" and shows registered contacts of those terminals with that as the aor. I mean it could obviously, but it's not what 3680 says. > > -hadriel > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From HKaplan@acmepacket.com Tue May 25 07:55:40 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 48D783A6C10 for ; Tue, 25 May 2010 07:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_50=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 zTspYdVaoTPf for ; Tue, 25 May 2010 07:55:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3D9593A6AC1 for ; Tue, 25 May 2010 07:55:39 -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, 25 May 2010 10:55:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 25 May 2010 10:55:30 -0400 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , Adam Roach , Spencer Dawkins Date: Tue, 25 May 2010 10:55:29 -0400 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr7gHUKSwkklOz2QlW1GcpYxR6BvwAbkHAwAAk4urA= Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> 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 Cc: "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 25 May 2010 14:55:40 -0000 That's ok, we can put this in the definitions section: SIP-PBX: SIP Provisioned Bulk-user eXternalizer > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: Tuesday, May 25, 2010 5:48 AM >=20 > I suspect in most cases you should not be using xxx-PBX at all, unless it > is a restriction of MARTINI that the attached PBX cannot take traffic fro= m > other PBXs in the same network. I would also point out that in using > MARTINI, what happens in the rest of the PBX should not necessarily be > constrained to be SIP. >=20 > ETSI and ECMA agreed on a common terminology that started from the > original ISO root definition. >=20 > "Corporate telecommunication Network (CN): sets of enterprise premises > equipment, owned by or managed on behalf of an enterprise that are locate= d > at geographically dispersed locations and are interconnected to provide > telecommunication services to a defined group of users belonging to that > enterprise >=20 > enterprise: unit of economic organization or activity, especially a > business organization >=20 > Next Generation CN (NGCN): self-contained corporate network designed to > take advantage of emerging IP-based communications solutions and that can > have its own applications and service provisioning >=20 > NOTE 1: For the purpose of the present document it is a corporate > network that provides an IP-based interface to an NGN. >=20 > NOTE 2: TR 102 478 [10] uses NGCN to collectively refer to IP-PBXs. >=20 > NGCN site: separate part of an NGCN" >=20 > regards >=20 > Keith >=20 From keith.drage@alcatel-lucent.com Tue May 25 08:08:47 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 918C23A6944 for ; Tue, 25 May 2010 08:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=-2.190, BAYES_50=0.001, 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 w7RLWlZdgo0J for ; Tue, 25 May 2010 08:08:46 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 70F563A68CD for ; Tue, 25 May 2010 08:08:45 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4PEitq7012515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 May 2010 17:08:28 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 25 May 2010 17:06:56 +0200 From: "DRAGE, Keith (Keith)" To: Hadriel Kaplan , Adam Roach , Spencer Dawkins Date: Tue, 25 May 2010 17:06:55 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr7gHUKSwkklOz2QlW1GcpYxR6BvwAbkHAwAAk4urAAAgmK0A== Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A06F@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 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 25 May 2010 15:08:47 -0000 Apart from any other issues, all that tells you is it runs SIP (or somethin= g nearly but not quite SIP) and is a separate box. That covers about 10% of= what it is and needs to be. Keith=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, May 25, 2010 3:55 PM > To: DRAGE, Keith (Keith); Adam Roach; Spencer Dawkins > Cc: martini@ietf.org > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX >=20 >=20 > That's ok, we can put this in the definitions section: >=20 > SIP-PBX: SIP Provisioned Bulk-user eXternalizer >=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of DRAGE, Keith (Keith) > > Sent: Tuesday, May 25, 2010 5:48 AM > >=20 > > I suspect in most cases you should not be using xxx-PBX at=20 > all, unless=20 > > it is a restriction of MARTINI that the attached PBX cannot take=20 > > traffic from other PBXs in the same network. I would also point out=20 > > that in using MARTINI, what happens in the rest of the PBX=20 > should not=20 > > necessarily be constrained to be SIP. > >=20 > > ETSI and ECMA agreed on a common terminology that started from the=20 > > original ISO root definition. > >=20 > > "Corporate telecommunication Network (CN): sets of=20 > enterprise premises=20 > > equipment, owned by or managed on behalf of an enterprise that are=20 > > located at geographically dispersed locations and are=20 > interconnected=20 > > to provide telecommunication services to a defined group of users=20 > > belonging to that enterprise > >=20 > > enterprise: unit of economic organization or activity, especially a=20 > > business organization > >=20 > > Next Generation CN (NGCN): self-contained corporate network=20 > designed=20 > > to take advantage of emerging IP-based communications solutions and=20 > > that can have its own applications and service provisioning > >=20 > > NOTE 1: For the purpose of the present document it is a=20 > corporate > > network that provides an IP-based interface to an NGN. > >=20 > > NOTE 2: TR 102 478 [10] uses NGCN to collectively refer=20 > to IP-PBXs. > >=20 > > NGCN site: separate part of an NGCN" > >=20 > > regards > >=20 > > Keith > >=20 > = From HKaplan@acmepacket.com Tue May 25 10:50:13 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 B3BC23A6949 for ; Tue, 25 May 2010 10:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_50=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 6QRnKHWYSTvr for ; Tue, 25 May 2010 10:50:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EAFEF3A6948 for ; Tue, 25 May 2010 10:50:11 -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, 25 May 2010 13:50:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 25 May 2010 13:50:03 -0400 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , Adam Roach , Spencer Dawkins Date: Tue, 25 May 2010 13:49:26 -0400 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr7gHUKSwkklOz2QlW1GcpYxR6BvwAbkHAwAAk4urAAAgmK0AAFNeNQ Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> 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 Cc: "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 25 May 2010 17:50:13 -0000 OK... how about SIP-PBX: SIP Proxy or B2bua for eXternal-address-of-records= ? > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Tuesday, May 25, 2010 11:07 AM > To: Hadriel Kaplan; Adam Roach; Spencer Dawkins > Cc: martini@ietf.org > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX >=20 > Apart from any other issues, all that tells you is it runs SIP (or > something nearly but not quite SIP) and is a separate box. That covers > about 10% of what it is and needs to be. >=20 > Keith >=20 > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Tuesday, May 25, 2010 3:55 PM > > To: DRAGE, Keith (Keith); Adam Roach; Spencer Dawkins > > Cc: martini@ietf.org > > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX > > > > > > That's ok, we can put this in the definitions section: > > > > SIP-PBX: SIP Provisioned Bulk-user eXternalizer > > > > > > > -----Original Message----- > > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > > > Behalf Of DRAGE, Keith (Keith) > > > Sent: Tuesday, May 25, 2010 5:48 AM > > > > > > I suspect in most cases you should not be using xxx-PBX at > > all, unless > > > it is a restriction of MARTINI that the attached PBX cannot take > > > traffic from other PBXs in the same network. I would also point out > > > that in using MARTINI, what happens in the rest of the PBX > > should not > > > necessarily be constrained to be SIP. > > > > > > ETSI and ECMA agreed on a common terminology that started from the > > > original ISO root definition. > > > > > > "Corporate telecommunication Network (CN): sets of > > enterprise premises > > > equipment, owned by or managed on behalf of an enterprise that are > > > located at geographically dispersed locations and are > > interconnected > > > to provide telecommunication services to a defined group of users > > > belonging to that enterprise > > > > > > enterprise: unit of economic organization or activity, especially a > > > business organization > > > > > > Next Generation CN (NGCN): self-contained corporate network > > designed > > > to take advantage of emerging IP-based communications solutions and > > > that can have its own applications and service provisioning > > > > > > NOTE 1: For the purpose of the present document it is a > > corporate > > > network that provides an IP-based interface to an NGN. > > > > > > NOTE 2: TR 102 478 [10] uses NGCN to collectively refer > > to IP-PBXs. > > > > > > NGCN site: separate part of an NGCN" > > > > > > regards > > > > > > Keith > > > > > From christer.holmberg@ericsson.com Tue May 25 10:59: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 B131E3A6918 for ; Tue, 25 May 2010 10:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.599, 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 jKLHfwvJstvp for ; Tue, 25 May 2010 10:59: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 811BA3A695E for ; Tue, 25 May 2010 10:59:48 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-02-4bfc100a0ff4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EE.40.21861.A001CFB4; Tue, 25 May 2010 19:59:38 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 25 May 2010 19:59:38 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 25 May 2010 19:59:37 +0200 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Tue, 25 May 2010 19:59:37 +0200 Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr8F5ji6TugXypLQzGxUjy/A2P2mQAGy8l2 Message-ID: References: <4BFAD37E.6040000@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A033@mail>, <4BFBDF52.2020800@cisco.com> In-Reply-To: <4BFBDF52.2020800@cisco.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-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 25 May 2010 17:59:49 -0000 Hi, IF the SUBSCRIBE was to be forwarded to the PBX, there are a few things tha= t need to be considered. Q1. How does the SSP know whether the PBX will be able to process the SUBSC= RIBE in the first place?=20 Yes, the SSP may have sent Allow: SUBSCRIBE, and it may have indicated supp= ort of the reg-event package, but that still doesn't mean it will support R= ECEIVING a subscription. And, this again comes down to the question: what SIP role does the PBX repr= esent in the first place? I think that is something that needs to be descri= bed in the draft.=20 For example, there is a section called "PBX behavior". But, there is no SIP= role called "PBX", as little as there is a SIP role called "B2BUA" etc. Q2. Is there a trust issue? The notification sent from the PBX will most li= kely not be asserted by the SSP, or anyone else. Regards, Christer ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Tuesday, May 25, 2010 5:31 PM To: Hadriel Kaplan Cc: Bernard Aboba; martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg"= event package IIUC its most likely that we have "sip:12345@ssp.com" defined on the ssp, but the terminals are registering with "sip:12345@pbx.com". I don't see that as a fundamental problem. If the ssp receives a subscribe for "sip:12345@ssp.com" and retargets it to "sip:12345@ssp.com" then the pbx processes the subscription based on the R-URI. But note I just replied to your other mail in way that may make this moot. Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Beha= lf >> Of Adam Roach >> Sent: Monday, May 24, 2010 3:29 PM >> >> >> Definitely. For reg-event, the PBX is the only entity that will know stu= ff >> like "this extension has three terminals registered." It's the only one >> that can say stuff like "the terminal for +12143290491 has registered a >> callee capability of 'video'". The SSP won't have the first foggy clue >> that these kinds of things are true. > > I guess one implicit assumption here is that the phones off the PBX regis= ter for an AoR of the SSP, but in the PBX. I mean, let's say we've got "si= p:12345@ssp.com". Do the "terminals" off the PBX REGISTER for the literal = AoR "sip:12345@ssp.com"? > > Because if they don't, then I don't see how a PBX processes a SUBSCRIBE f= or reg-event for "sip:12345@ssp.com" and shows registered contacts of those= terminals with that as the aor. I mean it could obviously, but it's not w= hat 3680 says. > > -hadriel > _______________________________________________ > 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 christer.holmberg@ericsson.com Tue May 25 11:00:34 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 8DE8B3A696B for ; Tue, 25 May 2010 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.195 X-Spam-Level: X-Spam-Status: No, score=-5.195 tagged_above=-999 required=5 tests=[AWL=1.404, 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 ywDw1sZieSdL for ; Tue, 25 May 2010 11:00:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 129003A6918 for ; Tue, 25 May 2010 11:00:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-bc-4bfc1037ef43 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.44.08537.7301CFB4; Tue, 25 May 2010 20:00:23 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 25 May 2010 20:00:22 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 25 May 2010 20:00:22 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , Hadriel Kaplan Date: Tue, 25 May 2010 20:00:08 +0200 Thread-Topic: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package Thread-Index: Acr8F5ji6TugXypLQzGxUjy/A2P2mQAGy8l2AABVTuA= Message-ID: References: <4BFAD37E.6040000@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A033@mail>, <4BFBDF52.2020800@cisco.com>, 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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 25 May 2010 18:00:34 -0000 The PBX may have sent Allow: SUBSCRIBE, that is... ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] Sent: Tuesday, May 25, 2010 8:59 PM To: Paul Kyzivat; Hadriel Kaplan Cc: Bernard Aboba; martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg"= event package Hi, IF the SUBSCRIBE was to be forwarded to the PBX, there are a few things tha= t need to be considered. Q1. How does the SSP know whether the PBX will be able to process the SUBSC= RIBE in the first place? Yes, the SSP may have sent Allow: SUBSCRIBE, and it may have indicated supp= ort of the reg-event package, but that still doesn't mean it will support R= ECEIVING a subscription. And, this again comes down to the question: what SIP role does the PBX repr= esent in the first place? I think that is something that needs to be descri= bed in the draft. For example, there is a section called "PBX behavior". But, there is no SIP= role called "PBX", as little as there is a SIP role called "B2BUA" etc. Q2. Is there a trust issue? The notification sent from the PBX will most li= kely not be asserted by the SSP, or anyone else. Regards, Christer ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Tuesday, May 25, 2010 5:31 PM To: Hadriel Kaplan Cc: Bernard Aboba; martini@ietf.org Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg"= event package IIUC its most likely that we have "sip:12345@ssp.com" defined on the ssp, but the terminals are registering with "sip:12345@pbx.com". I don't see that as a fundamental problem. If the ssp receives a subscribe for "sip:12345@ssp.com" and retargets it to "sip:12345@ssp.com" then the pbx processes the subscription based on the R-URI. But note I just replied to your other mail in way that may make this moot. Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Beha= lf >> Of Adam Roach >> Sent: Monday, May 24, 2010 3:29 PM >> >> >> Definitely. For reg-event, the PBX is the only entity that will know stu= ff >> like "this extension has three terminals registered." It's the only one >> that can say stuff like "the terminal for +12143290491 has registered a >> callee capability of 'video'". The SSP won't have the first foggy clue >> that these kinds of things are true. > > I guess one implicit assumption here is that the phones off the PBX regis= ter for an AoR of the SSP, but in the PBX. I mean, let's say we've got "si= p:12345@ssp.com". Do the "terminals" off the PBX REGISTER for the literal = AoR "sip:12345@ssp.com"? > > Because if they don't, then I don't see how a PBX processes a SUBSCRIBE f= or reg-event for "sip:12345@ssp.com" and shows registered contacts of those= terminals with that as the aor. I mean it could obviously, but it's not w= hat 3680 says. > > -hadriel > _______________________________________________ > 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 christer.holmberg@ericsson.com Tue May 25 11:17:37 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 9C3083A6987 for ; Tue, 25 May 2010 11:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 wetwqPcNNCzx for ; Tue, 25 May 2010 11:17:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1837B3A6998 for ; Tue, 25 May 2010 11:17:32 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-e6-4bfc14339aad Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3F.71.21861.3341CFB4; Tue, 25 May 2010 20:17:23 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 25 May 2010 20:17:23 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 25 May 2010 20:17:22 +0200 From: Christer Holmberg To: Martien Huysmans , Adam Roach Date: Tue, 25 May 2010 20:17:22 +0200 Thread-Topic: [martini] martini-gin-02: explicit registration & Reg Event Thread-Index: Acr46PzcMGF5Db2eQ5WHB5Ee0E/iPADDAIFwAA/MZps= Message-ID: References: <4BF68996.2080900@nostrum.com>, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: explicit registration & Reg Event 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, 25 May 2010 18:17:37 -0000 Hi, I also have more or less the same question/issue as Martien, but my questio= n is more from a core 3261 perspective. So, since the explicit registration of an individual extension (AOR), that = IS also part of the bulk registration, is described as a "non-bulk registra= tion" (I assume that means a vanilla 3261 registration), does that mean that we are talking about an addition of a binding for an existing extensio= n, as described in section 10.2.1 of 3261? If so, shouldn't the registration responses (both for the bulk REGISTER and= the individual REGISTER) then also contain BOTH contacts (the bulk and the= individual), since there now exists two contacts for the same extension? Second, where is the requirement for being able to perform the individual e= xtension registration in the first place? Regards, Christer ________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Mart= ien Huysmans [martien.huysmans@ericsson.com] Sent: Tuesday, May 25, 2010 1:52 PM To: Adam Roach Cc: martini@ietf.org Subject: Re: [martini] martini-gin-02: explicit registration & Reg Event Adam Ok, so for such an "individual extension" always normal processing applies. I am still somewhat confused by the existing text. GIN, chapter 5.2 says that an "individual extension that is implicitly regi= stered" may ALSO be explicitly registered. This text suggests that an such an individual extension has 2 Contacts, one= from bulk registration and one from the normal registration. A related question: what if such an individual extension has no active normal registrations, e.= g. because the device is turned of. I guess that normal processing shall apply. Agree? Perhaps it would be better if the text talks about "an individual extension= for which through provisioning it has been defined that normal registration/processing" applies. /Martiem ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Friday, May 21, 2010 3:25 PM To: Martien Huysmans Cc: martini@ietf.org Subject: Re: [martini] martini-gin-02: explicit registration & Reg Event On 5/21/10 01:09, May 21, Martien Huysmans wrote: Hi martini-gin-02 states in chapter 5.2: 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). Assume that an individual extension does a "normal, non-bulk" registratrati= on in additional to it's implcit registration. Question: How is a "reg" event SUBSCRIBE in such a case handled? Is it forwarded to t= he PBX? If so, does that PBX have knowledge of the "normal, non-bulk" registration? I don't think so. It's not a GIN registration, so normal processing applies= . /a From adam@nostrum.com Tue May 25 11:30:34 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 5C3923A69A8 for ; Tue, 25 May 2010 11:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 eFsaTqiN13OS for ; Tue, 25 May 2010 11:30:33 -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 2C3253A68D7 for ; Tue, 25 May 2010 11:30:32 -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 o4PIUI9l078962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 13:30:19 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BFC173A.1010900@nostrum.com> Date: Tue, 25 May 2010 13:30:18 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <4BF68996.2080900@nostrum.com>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------040606040501060101030905" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: [martini] Proscriptive vs. Permissive Behaviors (was Re: martini-gin-02: explicit registration & Reg Event) 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, 25 May 2010 18:30:34 -0000 This is a multi-part message in MIME format. --------------040606040501060101030905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/25/10 1:17 PM, Christer Holmberg wrote: > [W]here is the requirement for being able to perform the individual extension registration in the first place? > It's not an additional behavior that we're specifying -- it's an observation. We would need to go out of our way to normatively prohibit it if we don't want it to happen. So far, there has been no reason to normatively prohibit it. I guess whether we go out of our way to prohibit it comes down to where we want to take things philosophically. Do we: 1. Prohibit only those things that harm interoperability? 2. Prohibit everything that we can't imagine a use case for right now? My reading of most IETF-developed protocols is that we lean towards the first behavior, not the second. It allows people to come up with new and useful use cases that we may lack the ability to invent at the moment. /a --------------040606040501060101030905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/25/10 1:17 PM, Christer Holmberg wrote: 
[W]here is the requirement for being able to perform the individual extension registration in the first place?

It's not an additional behavior that we're specifying -- it's an observation. We would need to go out of our way to normatively prohibit it if we don't want it to happen. So far, there has been no reason to normatively prohibit it.

I guess whether we go out of our way to prohibit it comes down to where we want to take things philosophically. Do we:
  1. Prohibit only those things that harm interoperability?
  2. Prohibit everything that we can't imagine a use case for right now?
My reading of most IETF-developed protocols is that we lean towards the first behavior, not the second. It allows people to come up with new and useful use cases that we may lack the ability to invent at the moment.

/a
--------------040606040501060101030905-- From christer.holmberg@ericsson.com Tue May 25 11:32:28 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 EC7E03A698F for ; Tue, 25 May 2010 11:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=2.000, 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 9O6bv1KMeN8R for ; Tue, 25 May 2010 11:32:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8EEF63A68D7 for ; Tue, 25 May 2010 11:32:25 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-22-4bfc17af264f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 97.26.08537.FA71CFB4; Tue, 25 May 2010 20:32:15 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 25 May 2010 20:32:15 +0200 From: Christer Holmberg To: "martini@ietf.org" Date: Tue, 25 May 2010 20:32:14 +0200 Thread-Topic: Usage of "gin" option-tag Thread-Index: AQHK/DiYFPYpbD8FiE+VCFAcYY6HWw== Message-ID: 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-Brightmail-Tracker: AAAAAA== Subject: [martini] GIN: Usage of "gin" option-tag 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, 25 May 2010 18:32:28 -0000 Hi, Q1. The GIN draft currently says, that when a PBX sends a bulk REGISTER, it inc= ludeds the "gin" option-tag in the Require and Proxy-Require header fields. But, based on our what-does-require-really-mean discussions in SIPCORE, sho= uldn't it also include the option-tag in the Supported header field, indica= ting to the SSP that it supports GIN? Q2. Unless I've missed something, GIN only specifies the usage of the "gin" opt= ion-tag for REGISTER requests. What about other requests, e.g. inbound INVI= TEs and other requests where the SSP does the number mapping according to G= IN? Because, again based on the previous discussions, people have said that an = option-tag is only applicable for the request where it is included - not fo= r a registration or dialog that may be established based on that request. Regards, Christer From christer.holmberg@ericsson.com Tue May 25 11:38:16 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 DF3CF3A6980 for ; Tue, 25 May 2010 11:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=-1.000] 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 211FV4H7U9D0 for ; Tue, 25 May 2010 11:38:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E6FFA3A6966 for ; Tue, 25 May 2010 11:38:07 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-ae-4bfc19064172 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 19.72.21861.6091CFB4; Tue, 25 May 2010 20:37:58 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 25 May 2010 20:37:58 +0200 From: Christer Holmberg To: Adam Roach Date: Tue, 25 May 2010 20:37:56 +0200 Thread-Topic: Proscriptive vs. Permissive Behaviors (was Re: [martini] martini-gin-02: explicit registration & Reg Event) Thread-Index: Acr8OFb1IUEOYQglTYOtpHCDoBvhfgAAFYG/ Message-ID: References: <4BF68996.2080900@nostrum.com>, , <4BFC173A.1010900@nostrum.com> In-Reply-To: <4BFC173A.1010900@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-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] Proscriptive vs. Permissive Behaviors (was Re: martini-gin-02: explicit registration & Reg Event) 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, 25 May 2010 18:38:16 -0000 Hi, >[W]here is the requirement for being able to perform the individual extens= ion registration in the first place? > =20 >It's not an additional behavior that we're specifying -- it's an observati= on. We would need to go out of our way to normatively prohibit it if we don= 't want it to happen. So far, there has been no reason to normatively prohi= bit it. IF it is just an addition of contact/binding (see my comment), then one cou= ld say that it is just an observation of existing 3261 behavior. If it is s= omething else, then I think it is new functionality. >I guess whether we go out of our way to prohibit it comes down to where we= want to take things philosophically. Do we:=20 > >Prohibit only those things that harm interoperability? > >Prohibit everything that we can't imagine a use case for right now?=20 >My reading of most IETF-developed protocols is that we lean towards the fi= rst behavior, not the second. It allows people to come up with new and usef= ul use cases that we may lack the ability to invent at the moment. My experience is that we, unfortunately, sometimes have prohibited things j= ust because we haven't seen a use-case at the moment - without any real tec= hnical reason. Regards, Christer= From christer.holmberg@ericsson.com Tue May 25 12:07: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 C83813A696A; Tue, 25 May 2010 12:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=1.170, BAYES_20=-0.74, 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 nxwtgg+QQJ7c; Tue, 25 May 2010 12:07:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 579A13A69A0; Tue, 25 May 2010 12:07:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-33-4bfc1fe17fee Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8A.A7.08537.1EF1CFB4; Tue, 25 May 2010 21:07:13 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 25 May 2010 21:07:13 +0200 From: Christer Holmberg To: 'IESG Secretary' , "ietf-announce@ietf.org" Date: Tue, 25 May 2010 21:07:11 +0200 Thread-Topic: [martini] MARTINI WG Virtual Interim Meeting, June 16, 2010 Thread-Index: AcryvcN4z0wAESvDRLeecpRfregTsAJf06Kw Message-ID: References: <20100513170001.EBDB83A6B12@core3.amsl.com> In-Reply-To: <20100513170001.EBDB83A6B12@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 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] MARTINI WG Virtual Interim Meeting, June 16, 2010 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, 25 May 2010 19:07:24 -0000 Hi, Since I have not been able to participate in the virtual meetings I have no= t raised this issue before. But, is there a reason that 11 AM pacific is the earliest suggested time in= the pole? That is very late in this part of the world. So, what is the reason for not e.g. also suggesting 8 AM pacific? Regards, Christer=20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of IESG Secretary Sent: 13. toukokuuta 2010 20:00 To: ietf-announce@ietf.org Cc: martini@ietf.org Subject: [martini] MARTINI WG Virtual Interim Meeting, June 16, 2010 The MARTINI WG will be having a Virtual Interim meeting on June 16, 2010 fr= om 11 AM - 1 PM Pacific Time. Conference parameters for the meeting will be= announced on the MARTINI WG mailing list: http://www.ietf.org/mail-archive/web/martini/current/maillist.html _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Tue May 25 12:20:21 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 A77C93A69EA for ; Tue, 25 May 2010 12:20:21 -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 Fqpba6arawnM for ; Tue, 25 May 2010 12:20:20 -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 975C03A69E2 for ; Tue, 25 May 2010 12:20:19 -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-286247; Tue, 25 May 2010 21:20:10 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 869E723F0278; Tue, 25 May 2010 21:20:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 25 May 2010 21:20:10 +0200 From: "Elwell, John" To: Christer Holmberg , "martini@ietf.org" Date: Tue, 25 May 2010 21:20:09 +0200 Thread-Topic: Usage of "gin" option-tag Thread-Index: AQHK/DiYFPYpbD8FiE+VCFAcYY6HW5JihWOA 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] Usage of "gin" option-tag 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, 25 May 2010 19:20:21 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 25 May 2010 19:32 > To: martini@ietf.org > Subject: [martini] GIN: Usage of "gin" option-tag >=20 > Hi, >=20 > Q1. >=20 > The GIN draft currently says, that when a PBX sends a bulk=20 > REGISTER, it includeds the "gin" option-tag in the Require=20 > and Proxy-Require header fields. >=20 > But, based on our what-does-require-really-mean discussions=20 > in SIPCORE, shouldn't it also include the option-tag in the=20 > Supported header field, indicating to the SSP that it supports GIN? [JRE] I don't recollect other cases where we put the same option tag in bot= h Supported and Require header fields in the same message. >=20 >=20 > Q2. >=20 > Unless I've missed something, GIN only specifies the usage of=20 > the "gin" option-tag for REGISTER requests. What about other=20 > requests, e.g. inbound INVITEs and other requests where the=20 > SSP does the number mapping according to GIN? [JRE] No it doesn't. The gin-specific behaviour occurs when processing the = REGISTER request. That results in something being placed in the location se= rvice that allows INVITE and other inbound requests to be processed accordi= ng to RFC 3261. John >=20 > Because, again based on the previous discussions, people have=20 > said that an option-tag is only applicable for the request=20 > where it is included - not for a registration or dialog that=20 > may be established based on that request. >=20 >=20 > Regards, >=20 > Christer > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Tue May 25 12:23:28 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 CE7003A6A12; Tue, 25 May 2010 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, 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 XY6VL6AGOnrP; Tue, 25 May 2010 12:23:23 -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 149D23A69F5; Tue, 25 May 2010 12:23:20 -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-286282; Tue, 25 May 2010 21:23:09 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 894701EB82AB; Tue, 25 May 2010 21:23:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 25 May 2010 21:23:09 +0200 From: "Elwell, John" To: Christer Holmberg , 'IESG Secretary' , "ietf-announce@ietf.org" Date: Tue, 25 May 2010 21:23:08 +0200 Thread-Topic: [martini] MARTINI WG Virtual Interim Meeting, June 16, 2010 Thread-Index: AcryvcN4z0wAESvDRLeecpRfregTsAJf06KwAACaO3A= Message-ID: References: <20100513170001.EBDB83A6B12@core3.amsl.com> 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 Cc: "martini@ietf.org" Subject: Re: [martini] MARTINI WG Virtual Interim Meeting, June 16, 2010 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, 25 May 2010 19:23:28 -0000 Earlier times were offered in the Doodle poll but, alas, presumably this ti= me was the best fit from the responses received. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 25 May 2010 20:07 > To: 'IESG Secretary'; ietf-announce@ietf.org > Cc: martini@ietf.org > Subject: Re: [martini] MARTINI WG Virtual Interim Meeting,=20 > June 16, 2010 >=20 >=20 > Hi, >=20 > Since I have not been able to participate in the virtual=20 > meetings I have not raised this issue before. >=20 > But, is there a reason that 11 AM pacific is the earliest=20 > suggested time in the pole? That is very late in this part of=20 > the world. >=20 > So, what is the reason for not e.g. also suggesting 8 AM pacific? >=20 > Regards, >=20 > Christer=20 >=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: 13. toukokuuta 2010 20:00 > To: ietf-announce@ietf.org > Cc: martini@ietf.org > Subject: [martini] MARTINI WG Virtual Interim Meeting, June 16, 2010 >=20 > The MARTINI WG will be having a Virtual Interim meeting on=20 > June 16, 2010 from 11 AM - 1 PM Pacific Time. Conference=20 > parameters for the meeting will be announced on the MARTINI=20 > WG mailing list: >=20 > http://www.ietf.org/mail-archive/web/martini/current/maillist.html > _______________________________________________ > 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 Tue May 25 12:24: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 6B6DF3A69F5 for ; Tue, 25 May 2010 12:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 aDbfo8ZGtU4u for ; Tue, 25 May 2010 12:23:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 052673A6A3C for ; Tue, 25 May 2010 12:23:46 -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, 25 May 2010 15:23:37 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 25 May 2010 15:23:37 -0400 From: Hadriel Kaplan To: Christer Holmberg , "martini@ietf.org" Date: Tue, 25 May 2010 15:23:31 -0400 Thread-Topic: Usage of "gin" option-tag Thread-Index: AQHK/DiYFPYpbD8FiE+VCFAcYY6HW5JihjOg Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A160@mail> 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] Usage of "gin" option-tag 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, 25 May 2010 19:24:00 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Christer Holmberg > Sent: Tuesday, May 25, 2010 2:32 PM >=20 > Q1. >=20 > The GIN draft currently says, that when a PBX sends a bulk REGISTER, it > includeds the "gin" option-tag in the Require and Proxy-Require header > fields. >=20 > But, based on our what-does-require-really-mean discussions in SIPCORE, > shouldn't it also include the option-tag in the Supported header field, > indicating to the SSP that it supports GIN? I don't recall the SIPCORE discussion indicating that - the discussion I re= call was more that putting it in Require or Supported doesn't mean the exte= nsion is being actually used for the request it's in. But since we have th= e bnc contact param, that is the indication. > Q2. >=20 > Unless I've missed something, GIN only specifies the usage of the "gin" > option-tag for REGISTER requests. What about other requests, e.g. inbound > INVITEs and other requests where the SSP does the number mapping accordin= g > to GIN? The "number mapping" of the INVITE is not "according to gin". It's just 32= 61 registration resolution. The mapping (or really "expansion") occurred i= n the REGISTER transaction. -hadriel From christer.holmberg@ericsson.com Tue May 25 12:32:27 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 9BFF13A6A01 for ; Tue, 25 May 2010 12:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 C5Fr-oz7I0zw for ; Tue, 25 May 2010 12:32:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 51BC43A69CC for ; Tue, 25 May 2010 12:32:26 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-3f-4bfc25c01e58 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AC.D4.21861.0C52CFB4; Tue, 25 May 2010 21:32:16 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 25 May 2010 21:32:15 +0200 From: Christer Holmberg To: 'Hadriel Kaplan' , "martini@ietf.org" Date: Tue, 25 May 2010 21:32:15 +0200 Thread-Topic: Usage of "gin" option-tag Thread-Index: AQHK/DiYFPYpbD8FiE+VCFAcYY6HW5JihjOggAACW2A= Message-ID: References: <430FC6BDED356B4C8498F634416644A91C13B8A160@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A160@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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] Usage of "gin" option-tag 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, 25 May 2010 19:32:27 -0000 Hi,=20 >>Q1. >>=20 >>The GIN draft currently says, that when a PBX sends a bulk REGISTER,=20 >>it includeds the "gin" option-tag in the Require and Proxy-Require=20 >>header fields. >>=20 >>But, based on our what-does-require-really-mean discussions in=20 >>SIPCORE, shouldn't it also include the option-tag in the Supported=20 >>header field, indicating to the SSP that it supports GIN? > >I don't recall the SIPCORE discussion indicating that - the discussion I r= ecall was more that putting it in Require or Supported doesn't mean the ext= ension is being actually used for the request it's in. But since we have t= he bnc=20 >contact param, that is the indication. That is true - that is telling the SSP to use it. But, according to my understanind, it is still not an indication that the P= BX supports the extension - only that the PBX requires the SSP to use it. >>Q2. >>=20 >>Unless I've missed something, GIN only specifies the usage of the "gin" >>option-tag for REGISTER requests. What about other requests, e.g.=20 >>inbound INVITEs and other requests where the SSP does the number=20 >>mapping according to GIN? > >The "number mapping" of the INVITE is not "according to gin". It's just 3= 261 registration resolution. The mapping (or really "expansion") occurred = in the REGISTER transaction. Ok, that might be correct. Regards, Christer From christer.holmberg@ericsson.com Tue May 25 12:34:47 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 DF34D3A6A0B for ; Tue, 25 May 2010 12:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 uM8XIRy8mj2H for ; Tue, 25 May 2010 12:34:47 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DE6C53A69ED for ; Tue, 25 May 2010 12:34:46 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-35-4bfc264d2f54 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4A.F4.21861.D462CFB4; Tue, 25 May 2010 21:34:37 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 25 May 2010 21:34:37 +0200 From: Christer Holmberg To: "'Elwell, John'" , "martini@ietf.org" Date: Tue, 25 May 2010 21:34:36 +0200 Thread-Topic: Usage of "gin" option-tag Thread-Index: AQHK/DiYFPYpbD8FiE+VCFAcYY6HW5JihWOAgAAEg6A= 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] Usage of "gin" option-tag 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, 25 May 2010 19:34:48 -0000 Hi,=20 >>Q1. >>=20 >>The GIN draft currently says, that when a PBX sends a bulk REGISTER,=20 >>it includeds the "gin" option-tag in the Require and Proxy-Require=20 >>header fields. >>=20 >>But, based on our what-does-require-really-mean discussions in=20 >>SIPCORE, shouldn't it also include the option-tag in the Supported=20 >>header field, indicating to the SSP that it supports GIN? >[JRE] I don't recollect other cases where we put the same option tag in bo= th Supported and Require header fields in the same message. That's because so far we have done it wrong :) Regards, Christer From ietf.hanserik@gmail.com Tue May 25 17:31: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 3D0CC3A6CF3 for ; Tue, 25 May 2010 17:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[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 KdSLlRDJa7Vu for ; Tue, 25 May 2010 17:31:10 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id DFB663A75C3 for ; Tue, 25 May 2010 15:36:24 -0700 (PDT) Received: by ewy8 with SMTP id 8so688725ewy.28 for ; Tue, 25 May 2010 15:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sTqdhiXkgLSWJWefG7nTEcofn9GelqQsp86qMarnnCs=; b=BRbn1k8fadYB9mO/kRS1X4nPZdhapEFc+J0ETzhh6T+BFOjGuf4ajvTU8ktTA8s09a jLDB3IL8Ir3BkdJrZ/5u+X82WzdwSqI7rWl4g8ukqTwDrQ/zG0b7Ku0EPIcJcvH1afKX 5cuu+75CzMxBPNodc4yBwaasrUU0hy2QKAhS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B3mcu52jqCyoYooh4zvVfYEEIaouTZo7+Kr6/yJV9doUzXIxBjWnTYxbIen4MG1KeD l7qRtbyhh0hZ9QKhQ5uNzJPOWLQQ14JpvIW+8xaINqH386o1pU3O55M2Xw99H9edEoKY 8u+CG0ttXH1pTAUgTYWfJHjvVkjJ6NYpCLiSA= MIME-Version: 1.0 Received: by 10.213.21.204 with SMTP id k12mr784167ebb.42.1274826973446; Tue, 25 May 2010 15:36:13 -0700 (PDT) Received: by 10.213.14.84 with HTTP; Tue, 25 May 2010 15:36:13 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A160@mail> References: <430FC6BDED356B4C8498F634416644A91C13B8A160@mail> Date: Wed, 26 May 2010 00:36:13 +0200 Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] Usage of "gin" option-tag 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, 26 May 2010 00:31:14 -0000 On Tue, May 25, 2010 at 9:23 PM, Hadriel Kaplan wr= ote: > The "number mapping" of the INVITE is not "according to gin". =A0It's jus= t 3261 registration resolution. =A0The mapping (or really "expansion") occu= rred in the REGISTER transaction. [HE] The option tag in the REGISTER modifies 3261 behaviour for INVITE. And that is OK. /Hans Erik van Elburg From ietf.hanserik@gmail.com Tue May 25 17:39:06 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 DF0443A67FD for ; Tue, 25 May 2010 17:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=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 0V6zlKoPmZ-f for ; Tue, 25 May 2010 17:39:06 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 08F8B3A67A2 for ; Tue, 25 May 2010 16:00:34 -0700 (PDT) Received: by ewy8 with SMTP id 8so691978ewy.28 for ; Tue, 25 May 2010 16:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WMq2u+QfR5UNfJ1QQgcUJHT6ESweCCZrHbERkGkOJ+c=; b=oOMf5AoAOWRL3ELLThQo6Kpl8+USGQp2oI1WpVF63odkBNOaS+X2DflaTeroC+Sde/ cSICso5Gg1HZ6OtEcdC5PigQhU8KAfRAibNzotLyOB95KsEsD0OempZTuifYiFOK1/ZS i//aH2b+jYmZ28SJNatpfJ4pbE8kU7v8MXGcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mVn1gjYABxn/AoNPWPCarjvpUEcLqcZpIrA6deDmNhLZwQckDYqQVZFR9eiL0NjAZy rzF5roHQYMFwKmxHcc7mlj2AA50+49bVXFcujn2u6nP6DOL6ED4PkzUl5bcO8FIyMrYx jHCFABfnDRBg07ulSvTmqCnxbnjxcCvEb8Gs4= MIME-Version: 1.0 Received: by 10.213.33.148 with SMTP id h20mr158085ebd.10.1274828419641; Tue, 25 May 2010 16:00:19 -0700 (PDT) Received: by 10.213.14.84 with HTTP; Tue, 25 May 2010 16:00:19 -0700 (PDT) In-Reply-To: <4BF69162.8050802@nostrum.com> References: <4BF69162.8050802@nostrum.com> Date: Wed, 26 May 2010 01:00:19 +0200 Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: profound impact 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, 26 May 2010 00:39:07 -0000 I think only the following sentences in this chapter provides useful information: "Within the problem space that has been established for this work, several constraints shape our solution. These are being defined in the MARTINI requirements document [8]." The rest seems very subjective, because other readers can easily argue that other aspects are far more profound. Suggest to remove the other sentences. /Hans Erik van Elburg On Fri, May 21, 2010 at 3:57 PM, Adam Roach wrote: > On 5/21/10 01:42, May 21, Martien Huysmans wrote: >> martini-gin-02, chapter 2 contains the following text >> The following paragraph is perhaps the most important in >> understanding the solution defined in this document. > > That can probably be tightened up. One can actually implement the solutio= n > without understanding these constraints, but such a person may be left > boggled by why things are done the way they are. So I'll revise to read > "...in understanding the reasons for the design decisions made in this > document." > >> ... >> In terms of impact to the solution at hand, >> the following two constraints have the most profound effect: =85. >> ... >> >> These are some heavy words: "most important" and "profound ". >> So I know that I really need understand this chapter. >> But I do not. Can somebody explain? > > > Wow. I thought the two highlighted constraints were written in clear, > concise, unambiguous, and easy-to-understand language. Perhaps I presume = too > much knowledge on behalf of my audience. For your benefit, I'll try to > explain these two constraints more explicitly below. Let me know if there= 's > something regarding which you need further explanation. > > "(1) The PBX cannot be assumed to be assigned a static IP address" > > This means that the PBX may or may not have a static (unchanging) IP Addr= ess > (the unique identifier used to indicate end-points on the Internet), and > that we, as designers of the GIN solution, cannot make any assumptions on= e > way or the other about whether this is true. > > > "(2) No DNS entry can be relied upon to consistently resolve to the IP > address of the PBX." > > This means that there may or may not be an entry in the global Domain Nam= e > Service database (the distributed database used on the internet to conver= t > human-readable names into IP addresses) that, when resolved, produces tha= t > IP address of the PBX, and that we, as designers of the GIN solution, can= not > make any assumptions one way or another about whether this is true. > > If your confusion was in relation to any of the other three sentences in = the > section, let me know, and I can try to clear up their intended meaning. > They're less central to the thesis of this section, but I don't want them= to > leave you confused. > > And, if your confusion isn't regarding any single sentence, but rather th= e > gestalt of the whole section, the short summary is: "This document propos= es > doing some things that seem pretty stupid to anyone who really understand= s > SIP, but we have some good reasons for doing so. These reasons are explai= ned > by the requirements document, and here are the two that make the biggest > difference." > > Does any of that help? > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From ietf.hanserik@gmail.com Tue May 25 17:41:34 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 341013A681B for ; Tue, 25 May 2010 17:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6] 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 yTN2agQH+lGT for ; Tue, 25 May 2010 17:41:33 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 6E01F3A6E11 for ; Tue, 25 May 2010 16:18:28 -0700 (PDT) Received: by ewy8 with SMTP id 8so694109ewy.28 for ; Tue, 25 May 2010 16:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=iQ9EPFvn2vphPHEkfEjM27xvQlYZNBV1ALpDVKtoqBA=; b=l1BPWf/Wv90mxzD5jlab4GpjAps3rD2VAJwcdRp0AsFtrKHt9Psx5WjsXR8fbXhxE2 HEBXtXxYkUJnkzMP2m8iyJKGqnatqAndf29sYg7Ab3d2HFJK5oH7DRVl6IbV/kzJm1it ixDGxRTEwAw0XPnzyXFKdhuoqVJgZmMycJjwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SLPmZrXQ59yreQogZW29WYf2fdIyd6v44Lc5JGRd/vfX3Rq7XVGkHH8TtV5KZpOjn3 U7ma7+/5o8cJp8GpZBTLvuptgYBh3OweeYZ0JW63yxGvEzSRok0C6MJ9bEmgsRXD+OM6 /m/++IeJjxJSRQiHVJeMrXlGoGC2LQ5WNWr4s= MIME-Version: 1.0 Received: by 10.213.33.137 with SMTP id h9mr892463ebd.54.1274829485640; Tue, 25 May 2010 16:18:05 -0700 (PDT) Received: by 10.213.14.84 with HTTP; Tue, 25 May 2010 16:18:05 -0700 (PDT) In-Reply-To: <4BF3F0E6.8090603@nostrum.com> References: <4BF308BF.5030709@nostrum.com> <4BF3F0E6.8090603@nostrum.com> Date: Wed, 26 May 2010 01:18:05 +0200 Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Cc: "martini@ietf.org" Subject: Re: [martini] New GIN Draft 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, 26 May 2010 00:41:34 -0000 On Wed, May 19, 2010 at 4:08 PM, Adam Roach wrote: > On 5/19/10 2:45 AM, Elwell, John wrote: >> >> Although this might work, I view the autouser addition as probably going >> beyond what is necessary. >> >> As I think I mentioned on the call, I tend to view the user= parameter as >> an extension of the user part. So it should not be included in the Contact >> URI of the REGISTER request, but should be included in the Request-URI of >> inbound requests if the user-part requires it (e.g., user=phone if the user >> part is a telephone-subscriber string) - this would be a matter for >> provisioning. I don't think this requires the autouser parameter. > > I'm happy to take things that way also, but it's not what I heard people > supporting on the call. > > As I said in my slides, I think this issue is bike-shed painting of the > worst kind. I really, *really* don't think it matters which of the six or > seven options we discussed are selected -- they all work -- but we *need* to > choose one and move forward. A simpler option not requiring automagic behaviour on the SSP's side, would be to copy the user=phone to the contact when received by the SSP. During the discussion this is what I understood that the new parameter should control. i.e. true=copy user parameter if present, false=do not copy user parameter. /Hans Erik From ietf.hanserik@gmail.com Wed May 26 14:41:10 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 3EA9D3A6A26 for ; Wed, 26 May 2010 14:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_50=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 Ewb0CHYkxnl1 for ; Wed, 26 May 2010 14:41:09 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 3538F3A6A20 for ; Wed, 26 May 2010 14:41:06 -0700 (PDT) Received: by ewy8 with SMTP id 8so265813ewy.28 for ; Wed, 26 May 2010 14:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m/u5OyD0H4G5MI4t277tGwQIfcjXQQMf7Do4GFHRLbo=; b=e1gf9aazwfiIsRKCupPdOvMv2/rmqk8yymAQMVCFpXmx/eMoSlZvYnSEofx9np4nRb Z/PYzrOXFbOL1M0KS2I05YrUryfgBXMsl1ZM85c+PRZ6LGOXPyAu0ocRELtQrRFY7cNq kr9+zWM2bav63lGVtqHiu+AAeZ2pcB1ZGdNlg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qsuBu9htlyw98cNDAubm+3wbc4tejSZ+iK5q+rVt4C5Ucf3vMOdvex6MzhEiJEh9UI LGu/wMH+6mtK5JDJU2z7nR8BhTlt99r4JEyfSKD+dBFF4RWrZKwMFdnId6xs7k2dqprp TOUMcsCzO+RVGebJfvRZdZa2PvuiV13euw6jY= MIME-Version: 1.0 Received: by 10.213.109.9 with SMTP id h9mr1580091ebp.12.1274910053764; Wed, 26 May 2010 14:40:53 -0700 (PDT) Received: by 10.213.14.84 with HTTP; Wed, 26 May 2010 14:40:53 -0700 (PDT) In-Reply-To: <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> Date: Wed, 26 May 2010 23:40:53 +0200 Message-ID: From: Hans Erik van Elburg To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 26 May 2010 21:41:10 -0000 On Thu, May 20, 2010 at 4:04 PM, Cullen Jennings wrote: > There's a ton of way to skin this cat but I am strongly against depreciat= ing anonymous call support of 3261 when using the GIN draft - I view that a= s GIN breaking SIP. It's a critical feature when using SIP for PSTN replace= ment and I believe it has very important value many types of SIP communicat= ion. [HE] I agree that anonymity is an important feature, but how would this break anonymous call support in RFC3261? Does it not have a similar weakness as RFC3261 that the goat shelter could be revealed by the IP address in the contact header of messages coming out of the shelter's pbx? Or did you mean to refer to RFC3323? Which delegates the anonymization of the Contact header to an intermediary providing a privacy service (section 4.1). /Hans Erik From ietf.hanserik@gmail.com Wed May 26 15:03:54 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 563613A6A2F for ; Wed, 26 May 2010 15:03:54 -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 NWj9u6Yk+hz2 for ; Wed, 26 May 2010 15:03:53 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id EEDAA3A6A29 for ; Wed, 26 May 2010 15:03:52 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so230750eyf.51 for ; Wed, 26 May 2010 15:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=umDrKIZKoyLon7fTP0eqhdy6yf0lGPSbCVDBN6laTwA=; b=G0l9GF8qtKGlYmMtYLShQtUobkH/2Qzge8yvzkVRhFiuBkE9DrlokyGJ/NWIJXjOXl WlndmF1Y5YCeUrC+L2sASQEiMiHkkcDIh6cGHSZqWkKE48ZJecpaNrLuyt4QOL0TmAwC ekyxMxJ02wzO586U+ITR+FkNGRtWkESSTmpak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tTSuIVMYDhjADZeRvu8zbXazFvXESW0FoLXGWtrgXJ4XKwKfsfEoUqNxDVH438s5t6 wbZ6Q/idYsrVDKBqutObJjt6gRx1ojlf0n8kZUWypnSMUKUuFWNJLFsgrp27lq5jqoo3 RShZbLFUPPFZZ5tibgVJM519zChLt/N3CrQAY= MIME-Version: 1.0 Received: by 10.213.32.135 with SMTP id c7mr1757941ebd.49.1274911416098; Wed, 26 May 2010 15:03:36 -0700 (PDT) Received: by 10.213.14.84 with HTTP; Wed, 26 May 2010 15:03:36 -0700 (PDT) In-Reply-To: <4BF7010A.1000103@nostrum.com> References: <4BF7010A.1000103@nostrum.com> Date: Thu, 27 May 2010 00:03:36 +0200 Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] martini-gin-02: multiple contacts 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, 26 May 2010 22:03:54 -0000 On Fri, May 21, 2010 at 11:54 PM, Adam Roach wrote: > On 5/21/10 1:29 AM, Martien Huysmans wrote: > > Martini-gin-02, chapter 5.1 contains the following text > =A0 Second, in at least one "Contact" header field, it must include a > =A0=A0 Contact URI that contains the URI parameter "bnc", and no user > =A0=A0 portion (hence no "@" symbol). > > Assume that 2 Contact header fields are present, one with bnc and one > without. > This implies that for inbound SIP Request, forking would take place at th= e > SSP. > > Not "would." "Might." What a proxy does with registration data when a cal= l > arrives is always subject to local policy. So qsking about whether forkin= g > is "the right thing to do" doesn't make much sense. Proxies will do it if > it's the right thing to do according to their local policy, and they won'= t > if it isn't. > [HE] The text in 5.2 implies that if there is one contact header with the bnc parameter then for all the contacts listed in the REGISTER the GIN behaviour applies. Is that intended? > > > 2) What is the use case that people had in mind, when adding this > possibility? > > We didn't add it -- it is implict in the use of the REGISTER method -- we > simply don't prohibit it. > [HE] It is explictly mentioned (indicated) in the text. Hence the question. I think we would need to explain what it means in this particular case. Does it make sense at all? Ca it be used for redundant connections? etc. From ietf.hanserik@gmail.com Wed May 26 15:17:58 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 001A33A6A39 for ; Wed, 26 May 2010 15:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.122 X-Spam-Level: X-Spam-Status: No, score=-0.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_50=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 gtMOJalQzqCA for ; Wed, 26 May 2010 15:17:56 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 260143A6A29 for ; Wed, 26 May 2010 15:17:55 -0700 (PDT) Received: by ewy8 with SMTP id 8so272160ewy.28 for ; Wed, 26 May 2010 15:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=twuMAWpPlYTDybsWRLcwTTpsGST2S3O3sYARIN2uJCg=; b=b71IoRyWdckd6ETtLE1eM2mDclCafapnQ4PgId5mhFvbd1q/l6nYX91lpWP5SVXEmD 17R+FPi1eQcWpmXEiSD7L+q6Im1B4h41Js3Hs4/N6oGnbTVXkj5wKP+J+tDVwTk/pjqy pPvFRJx6AcywwLLrEOgj1fIzYyONRECb9f3Dc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=epq44mIU6hOOlSjgSi83qImTcxETE5F0Y9Ygsqar9Q4z06GL7XeCnKOXUUiWHMPoSx pYsG/Se2ysg+2H0MgK2WvJWrpe6SnNuXWP4cUJQ48ptUcvtr7BXXNtd0gnROinIOS0y/ Gfj2DWEy41jlPHjQOMhhWGC3qIuOMrgvRA3iY= MIME-Version: 1.0 Received: by 10.213.27.201 with SMTP id j9mr1576632ebc.9.1274912262737; Wed, 26 May 2010 15:17:42 -0700 (PDT) Received: by 10.213.14.84 with HTTP; Wed, 26 May 2010 15:17:42 -0700 (PDT) In-Reply-To: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> <4BF40A96.3040600@nostrum.com> <1274407304.1374.2.camel@damnableubu> <57FFB2AC-118F-4D02-B446-F4808C768D70@cisco.com> Date: Thu, 27 May 2010 00:17:42 +0200 Message-ID: From: Hans Erik van Elburg To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 26 May 2010 22:17:58 -0000 I propose to move the requirements analysis into an appendix. Don't think it is needed in the main body of the document. But I agree the information is usefull. /Hans Erik van Elburg On Mon, May 24, 2010 at 2:03 PM, Christer Holmberg wrote: > > Hi, > > One reason why I think it is important to have some kind of reference and= tracking of the requirements is because, as we know, GIN does not solve al= l the requirements that some people need, and that MARTINI later might work= on. We have accepted some limitations and restrictions for GIN. > > So, if we later work with another solution, which solves requirements tha= t we have chosen to not include for GIN, it is very useful to see what requ= irements the solutions solve, in order to evaluate them etc. > > I think the simplest solution is to simply list the requirements in the G= IN draft, but I have no strong preference how it's done. > > Regards, > > Christer > > > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f Of Elwell, John > Sent: 21. toukokuuta 2010 17:52 > To: Cullen Jennings; Dean Willis > Cc: martini@ietf.org > Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? > > Cullen, > > I agree with what you say, but the IETF (certainly RAI) has a history of = producing requirements RFCs, e.g., SPEERMINT, identification (RFC 3324), e2= m security (RFC 4189), trait-based authorisation (RFC 4484), overload (RFC = 5390), media security (5479), floor control (RFC 4376), media control (RFC = 5167), geopriv (RFC 3693), ecrit (RFC 5012)... In some cases the charter ev= en calls for this, although that is not true for MARTINI. I think the decis= ion was made at the start of the work to produce a requirements document. I= f we want to use a less formal means of publishing this, and include the wr= ite-up on how gin meets the requirements, I don't mind. I just thought the = WG was expecting an RFC. > > And by the way, I could probably cite a bunch more where requirements and= motivation are included in the solution RFC, but that is another matter. > > John > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 21 May 2010 15:20 >> To: Dean Willis >> Cc: Elwell, John; Spencer Dawkins; martini@ietf.org >> Subject: Re: [martini] GIN: Removing Section 9 (Requirements >> Analysis)? >> >> >> So, I should start with I really don't feel strongly about this and I >> can live with whatever happens .... >> >> Few points about Requirements - people always say they are written >> before the solutions. In all the examples I have seen at IETF this is >> farm more often not the case - certainly not true in this case. The >> requirements and solutions were evolved along in parallel over months >> or years starting in SIP Forum and eventually ending up where - I will >> point the requirements are still not done in the sense that they are >> not an RFC and are still changing and the solution is very close to >> WGLC. >> >> Next, I don't think there is any rule that the solution MUST meet the >> requirements. The question I think the WG should ask when it goes to >> publish the solution is basically "Are we happy enough with this that >> we have rough consensus to publish it". I very important piece of >> information for everyone to try and decide if they can say yes to that >> is the analysis of how well the solution meets the requirements but >> from a procedural point of view, if the solution does not meet all the >> requirements, the WG could still decide to pub request the doc. >> >> So from my point of view, it's nice to have a draft that has the >> requirements (could be same or different draft as the solution), it's >> nice to have a draft with the analysis of how well the solution meets >> the requirements. But once the work is done, none of this text has >> much value as an RFC. It's useful to have a pornier in the RFC to find >> this. The easiest way to do that is the names of the draft and just >> use google to find them. They really do last forever on the internet >> unlike whatever the front of them says about 6 months. The fundamental >> reasons we publish them as RFC is that people put a bunch of work into >> them and publishing it as a RFC with the person name on it is a way to >> say thanks for that work. >> >> But I do have a preference for moving text that is of no use out of >> RFC implementors need to read. It can move to another RFC, a draft, an >> email thread that is archived, whatever. >> When considering moving it to an RFC, keep in mind that even a simple >> information RFC takes a ton of time for the AD so that means something >> else is getting dropped. Well worth considering the load level on your >> AD based on reassured response time and task drop rate before asking >> them to publish something that would not have much more value as an >> RFC than as a draft. >> >> Oh yah, and +1 to Deans comments below and John I agree with your >> point we want to be able to put finished stuff to bead and not have it >> wait on some future doc. >> >> >> On May 20, 2010, at 8:01 PM, Dean Willis wrote: >> >> > On Thu, 2010-05-20 at 15:50 +0200, Elwell, John wrote: >> >> Cullen, >> >> >> >> I think that is the wrong way round. A requirements >> document is generally written before solution documents. And suppose >> some requirements are not met until a later solutions document, e.g., >> olive. Does that mean we can't put the requirements document to bed >> before olive is finished? >> >> >> >> On the other hand, I tend to agree with you that >> implementers don't like too much useless material. We had a pretty >> good evaluation of gin against requirements at IETF#77 on slides, and >> it is that that is captured in the latest gin draft. The analysis has >> changed very little, except that a couple of new requirements have >> been added. The IETF#77 MARTINI minutes, with pointer to the slides, >> goes a long way to showing that we have done due diligence in ensuring >> the solution meets the requirements. OR we could post updated text on >> the mailing list, so that it appears in the archive. >> Do we really need to encumber either draft with this lengthy text? >> >> >> > >> > Easy solution. >> > >> > Publish the requirements, informational track. >> > >> > Publish gin, standards track, containing only that which is >> required to >> > implement the spec, tight and testable. >> > >> > Make yet another draft, informational track, that shows how >> gin or gin >> > +olive meet the requirements, and that revises the requirements if >> > necessary. >> > >> > -- >> > Dean >> > >> > >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> > _______________________________________________ > 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 ietf.hanserik@gmail.com Wed May 26 15:49:13 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 999073A67B3 for ; Wed, 26 May 2010 15:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, 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 wh7wweTHoZYk for ; Wed, 26 May 2010 15:49:13 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id AFD903A6A3E for ; Wed, 26 May 2010 15:49:12 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so231907eyf.51 for ; Wed, 26 May 2010 15:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=lSJWGvO31t2suWNqOVfs3E+EsZLmQ/VqS3hli4PDsU0=; b=sAqL+iI4QASXHjOvz4FLIJSln7OqbjcoAAGSkr9Ue+f0RfMjP6FR/oy1ziHyl9zdJ0 +mHySVmeEkdMBHj/OAGJqdqjrGs+657yHIl+gRw4opmxSaEgp7AHByodBQqgrKpuvzaF GbfrNj4oVBSy3L7zIdN63qvRk2X++w0kk11AE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mjKP55Y56VFkI0XPNtyu6H+RKd787ktSMnUCNfTZiYMgk7aZHS9PpKq/8bRGi5XSn5 QhjuHfe2X7XmSd5k4f5CG5dxBHhSwvmBHX4EV2BSSxWuQixdn0hSDy+r7a267G90zOrX RFNCMoX1zmE7aL1POjpvaTX/rwY5cT49keXN4= MIME-Version: 1.0 Received: by 10.213.10.147 with SMTP id p19mr1595912ebp.4.1274914140374; Wed, 26 May 2010 15:49:00 -0700 (PDT) Received: by 10.213.14.84 with HTTP; Wed, 26 May 2010 15:49:00 -0700 (PDT) In-Reply-To: <4BFBDF52.2020800@cisco.com> References: <4BFAD37E.6040000@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A033@mail> <4BFBDF52.2020800@cisco.com> Date: Thu, 27 May 2010 00:49:00 +0200 Message-ID: From: Hans Erik van Elburg To: "martini@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [martini] RESPONSE REQUESTED Re: Open Issue #36: GIN and "reg" event package 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, 26 May 2010 22:49:13 -0000 On Tue, May 25, 2010 at 4:31 PM, Paul Kyzivat wrote: > IIUC its most likely that we have "sip:12345@ssp.com" defined on the ssp, > but the terminals are registering with "sip:12345@pbx.com". > Yes, the consequence of taking GIN. End users register with another AOR then they have to give their relations to be reached by. /Hans Erik van Elburg From john.elwell@siemens-enterprise.com Wed May 26 23:59:03 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 B59983A68A0 for ; Wed, 26 May 2010 23:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 0WWIZHD5WhKX for ; Wed, 26 May 2010 23:59:02 -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 B40693A6818 for ; Wed, 26 May 2010 23:59:01 -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-305087; Thu, 27 May 2010 08:58:51 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C5B681EB82AE; Thu, 27 May 2010 08:58:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 27 May 2010 08:58:51 +0200 From: "Elwell, John" To: Hans Erik van Elburg , Christer Holmberg Date: Thu, 27 May 2010 08:58:49 +0200 Thread-Topic: [martini] GIN: Removing Section 9 (Requirements Analysis)? Thread-Index: Acr9IULm1ikElp/fRECHO45ENvGUbAASMThg Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF40757.1040009@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA06928CC2@gaalpa1msgusr7e.ugd.att.com> <4BF40A96.3040600@nostrum.com> <1274407304.1374.2.camel@damnableubu> <57FFB2AC-118F-4D02-B446-F4808C768D70@cisco.com> 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 Cc: "martini@ietf.org" Subject: Re: [martini] GIN: Removing Section 9 (Requirements Analysis)? 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, 27 May 2010 06:59:03 -0000 Works for me. John=20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 26 May 2010 23:18 > To: Christer Holmberg > Cc: Elwell, John; Cullen Jennings; Dean Willis; martini@ietf.org > Subject: Re: [martini] GIN: Removing Section 9 (Requirements=20 > Analysis)? >=20 > I propose to move the requirements analysis into an appendix. Don't > think it is needed in the main body of the document. But I agree the > information is usefull. >=20 > /Hans Erik van Elburg >=20 > On Mon, May 24, 2010 at 2:03 PM, Christer Holmberg > wrote: > > > > Hi, > > > > One reason why I think it is important to have some kind of=20 > reference and tracking of the requirements is because, as we=20 > know, GIN does not solve all the requirements that some=20 > people need, and that MARTINI later might work on. We have=20 > accepted some limitations and restrictions for GIN. > > > > So, if we later work with another solution, which solves=20 > requirements that we have chosen to not include for GIN, it=20 > is very useful to see what requirements the solutions solve,=20 > in order to evaluate them etc. > > > > I think the simplest solution is to simply list the=20 > requirements in the GIN draft, but I have no strong=20 > preference how it's done. > > > > Regards, > > > > Christer > > > > > > > > -----Original Message----- > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 21. toukokuuta 2010 17:52 > > To: Cullen Jennings; Dean Willis > > Cc: martini@ietf.org > > Subject: Re: [martini] GIN: Removing Section 9=20 > (Requirements Analysis)? > > > > Cullen, > > > > I agree with what you say, but the IETF (certainly RAI) has=20 > a history of producing requirements RFCs, e.g., SPEERMINT,=20 > identification (RFC 3324), e2m security (RFC 4189),=20 > trait-based authorisation (RFC 4484), overload (RFC 5390),=20 > media security (5479), floor control (RFC 4376), media=20 > control (RFC 5167), geopriv (RFC 3693), ecrit (RFC 5012)...=20 > In some cases the charter even calls for this, although that=20 > is not true for MARTINI. I think the decision was made at the=20 > start of the work to produce a requirements document. If we=20 > want to use a less formal means of publishing this, and=20 > include the write-up on how gin meets the requirements, I=20 > don't mind. I just thought the WG was expecting an RFC. > > > > And by the way, I could probably cite a bunch more where=20 > requirements and motivation are included in the solution RFC,=20 > but that is another matter. > > > > John > > > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: 21 May 2010 15:20 > >> To: Dean Willis > >> Cc: Elwell, John; Spencer Dawkins; martini@ietf.org > >> Subject: Re: [martini] GIN: Removing Section 9 (Requirements > >> Analysis)? > >> > >> > >> So, I should start with I really don't feel strongly about=20 > this and I > >> can live with whatever happens .... > >> > >> Few points about Requirements - people always say they are written > >> before the solutions. In all the examples I have seen at=20 > IETF this is > >> farm more often not the case - certainly not true in this case. The > >> requirements and solutions were evolved along in parallel=20 > over months > >> or years starting in SIP Forum and eventually ending up=20 > where - I will > >> point the requirements are still not done in the sense=20 > that they are > >> not an RFC and are still changing and the solution is very close to > >> WGLC. > >> > >> Next, I don't think there is any rule that the solution=20 > MUST meet the > >> requirements. The question I think the WG should ask when=20 > it goes to > >> publish the solution is basically "Are we happy enough=20 > with this that > >> we have rough consensus to publish it". I very important piece of > >> information for everyone to try and decide if they can say=20 > yes to that > >> is the analysis of how well the solution meets the requirements but > >> from a procedural point of view, if the solution does not=20 > meet all the > >> requirements, the WG could still decide to pub request the doc. > >> > >> So from my point of view, it's nice to have a draft that has the > >> requirements (could be same or different draft as the=20 > solution), it's > >> nice to have a draft with the analysis of how well the=20 > solution meets > >> the requirements. But once the work is done, none of this text has > >> much value as an RFC. It's useful to have a pornier in the=20 > RFC to find > >> this. The easiest way to do that is the names of the draft and just > >> use google to find them. They really do last forever on=20 > the internet > >> unlike whatever the front of them says about 6 months. The=20 > fundamental > >> reasons we publish them as RFC is that people put a bunch=20 > of work into > >> them and publishing it as a RFC with the person name on it=20 > is a way to > >> say thanks for that work. > >> > >> But I do have a preference for moving text that is of no use out of > >> RFC implementors need to read. It can move to another RFC,=20 > a draft, an > >> email thread that is archived, whatever. > >> When considering moving it to an RFC, keep in mind that=20 > even a simple > >> information RFC takes a ton of time for the AD so that=20 > means something > >> else is getting dropped. Well worth considering the load=20 > level on your > >> AD based on reassured response time and task drop rate=20 > before asking > >> them to publish something that would not have much more value as an > >> RFC than as a draft. > >> > >> Oh yah, and +1 to Deans comments below and John I agree with your > >> point we want to be able to put finished stuff to bead and=20 > not have it > >> wait on some future doc. > >> > >> > >> On May 20, 2010, at 8:01 PM, Dean Willis wrote: > >> > >> > On Thu, 2010-05-20 at 15:50 +0200, Elwell, John wrote: > >> >> Cullen, > >> >> > >> >> I think that is the wrong way round. A requirements > >> document is generally written before solution documents.=20 > And suppose > >> some requirements are not met until a later solutions=20 > document, e.g., > >> olive. Does that mean we can't put the requirements document to bed > >> before olive is finished? > >> >> > >> >> On the other hand, I tend to agree with you that > >> implementers don't like too much useless material. We had a pretty > >> good evaluation of gin against requirements at IETF#77 on=20 > slides, and > >> it is that that is captured in the latest gin draft. The=20 > analysis has > >> changed very little, except that a couple of new requirements have > >> been added. The IETF#77 MARTINI minutes, with pointer to=20 > the slides, > >> goes a long way to showing that we have done due diligence=20 > in ensuring > >> the solution meets the requirements. OR we could post=20 > updated text on > >> the mailing list, so that it appears in the archive. > >> Do we really need to encumber either draft with this lengthy text? > >> >> > >> > > >> > Easy solution. > >> > > >> > Publish the requirements, informational track. > >> > > >> > Publish gin, standards track, containing only that which is > >> required to > >> > implement the spec, tight and testable. > >> > > >> > Make yet another draft, informational track, that shows how > >> gin or gin > >> > +olive meet the requirements, and that revises the=20 > requirements if > >> > necessary. > >> > > >> > -- > >> > Dean > >> > > >> > > >> > >> > >> Cullen Jennings > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > >> > >> > >> > > _______________________________________________ > > 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 martien.huysmans@ericsson.com Thu May 27 01:07:29 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 76CA83A6988 for ; Thu, 27 May 2010 01:07:29 -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 nBmgrgaN3akq for ; Thu, 27 May 2010 01:07:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2FC423A6A3B for ; Thu, 27 May 2010 01:07:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7b73ae00000711c-3f-4bfe2835e6c7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 87.C7.28956.5382EFB4; Thu, 27 May 2010 10:07:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 27 May 2010 10:07:17 +0200 From: Martien Huysmans To: Hans Erik van Elburg , Cullen Jennings Date: Thu, 27 May 2010 10:07:15 +0200 Thread-Topic: [martini] GIN and anonymous GRUUS Thread-Index: Acr9HCVTooLPBf3pSTWExP1D7RfOfgATln9g Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 27 May 2010 08:07:29 -0000 Hi If I understand you correctly, you are saying that RFC3323 provides an alte= rnative for the "goat shelter" problem. That problem resulted in the temp-gruu chapters that are now described in m= artini-gin-03. In this alternative the SSP would provide a Privacy service, which ensures = that caller remains anonymous.=20 Sound good. Side question: If there is a B2BUA in the network of the SSP, then my under= standing is that the contact of the caller will never reach the caller. I guess the Privacy serv= ice would be implemented as a B2BUA. /Martien=20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Hans Erik van Elburg Sent: Wednesday, May 26, 2010 11:41 PM To: Cullen Jennings Cc: martini@ietf.org Subject: Re: [martini] GIN and anonymous GRUUS On Thu, May 20, 2010 at 4:04 PM, Cullen Jennings wrote: > There's a ton of way to skin this cat but I am strongly against depreciat= ing anonymous call support of 3261 when using the GIN draft - I view that a= s GIN breaking SIP. It's a critical feature when using SIP for PSTN replace= ment and I believe it has very important value many types of SIP communicat= ion. [HE] I agree that anonymity is an important feature, but how would this bre= ak anonymous call support in RFC3261? Does it not have a similar weakness a= s RFC3261 that the goat shelter could be revealed by the IP address in the = contact header of messages coming out of the shelter's pbx? Or did you mean to refer to RFC3323? Which delegates the anonymization of t= he Contact header to an intermediary providing a privacy service (section 4= .1). /Hans Erik _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From ietf.hanserik@gmail.com Thu May 27 06:00:08 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 3DC553A6847 for ; Thu, 27 May 2010 06:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 FEQnKGFDWdTj for ; Thu, 27 May 2010 06:00:07 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 3291E3A6A97 for ; Thu, 27 May 2010 06:00:07 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so257046eyf.51 for ; Thu, 27 May 2010 05:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LCXQAU51y6cE8WybJLPGFqKbh77IIvINJvWTFari+m4=; b=d/1qUZad/xDhLCbhLdo1K/qLj+M6LWmJtbIKdK9V/VPqKFmfKNawtwS16JC3jFgbpA nmEwI8T2Ikg1lOXFfXpoXu1R0LKD9dkK9fzifOFCECIR6MN/g/xhSvSIHy98Voo/Q5J6 D+egcI1/MvRwzatOigq/gAw247ygBCGr3kW4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=djU1aSfAZKYEMgqZc9365seR90U0bCK54/+1sxU1FuYoi1winwzaHD1gezH5lRtI5S wQ6QiarUzoaZWCJg/eHvBvzqmFInc4HbCcxqdt6+ijDlMWE5F77r95avmBXwCNAmlj+W 3auR7b8ilIAZq3A0tPy20myWJOLCll+6dMspw= MIME-Version: 1.0 Received: by 10.213.10.147 with SMTP id p19mr2040895ebp.4.1274965193373; Thu, 27 May 2010 05:59:53 -0700 (PDT) Received: by 10.213.14.84 with HTTP; Thu, 27 May 2010 05:59:53 -0700 (PDT) In-Reply-To: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> Date: Thu, 27 May 2010 14:59:53 +0200 Message-ID: From: Hans Erik van Elburg To: Martien Huysmans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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, 27 May 2010 13:00:08 -0000 I did not ment to state anything I was just raising questions for my understanding to Cullen. /Hans Erik van Elburg On Thu, May 27, 2010 at 10:07 AM, Martien Huysmans wrote: > Hi > > If I understand you correctly, you are saying that RFC3323 provides an al= ternative for the "goat shelter" problem. > That problem resulted in the temp-gruu chapters that are now described in= martini-gin-03. > In this alternative the SSP would provide a Privacy service, which ensure= s that caller remains anonymous. > Sound good. > > Side question: If there is a B2BUA in the network of the SSP, then my und= erstanding is that the > contact of the caller will never reach the caller. I guess the Privacy se= rvice would be implemented as a B2BUA. > > /Martien > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f Of Hans Erik van Elburg > Sent: Wednesday, May 26, 2010 11:41 PM > To: Cullen Jennings > Cc: martini@ietf.org > Subject: Re: [martini] GIN and anonymous GRUUS > > On Thu, May 20, 2010 at 4:04 PM, Cullen Jennings wrote= : >> There's a ton of way to skin this cat but I am strongly against deprecia= ting anonymous call support of 3261 when using the GIN draft - I view that = as GIN breaking SIP. It's a critical feature when using SIP for PSTN replac= ement and I believe it has very important value many types of SIP communica= tion. > > [HE] I agree that anonymity is an important feature, but how would this b= reak anonymous call support in RFC3261? Does it not have a similar weakness= as RFC3261 that the goat shelter could be revealed by the IP address in th= e contact header of messages coming out of the shelter's pbx? > > Or did you mean to refer to RFC3323? Which delegates the anonymization of= the Contact header to an intermediary providing a privacy service (section= 4.1). > > /Hans Erik > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From keith.drage@alcatel-lucent.com Thu May 27 10:08:35 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 317DB3A6B0B for ; Thu, 27 May 2010 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, HELO_EQ_FR=0.35, 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 9AhNDcthywP1 for ; Thu, 27 May 2010 10:08:34 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 8AA003A6B50 for ; Thu, 27 May 2010 10:08:32 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4RH8Kic004938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 May 2010 19:08:20 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 27 May 2010 19:08:20 +0200 From: "DRAGE, Keith (Keith)" To: Hadriel Kaplan , Adam Roach , Spencer Dawkins Date: Thu, 27 May 2010 19:08:19 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr7gHUKSwkklOz2QlW1GcpYxR6BvwAbkHAwAAk4urAAAgmK0AAFNeNQAF2wDAA= Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A0FB@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 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 27 May 2010 17:08:35 -0000 You are missing the point. You are 1) trying to define a term which in many= cases is the incorrect term; 2) create a definition that does not encompas= s an essential characteristic. 1) What we are working with is not restricted to a single entity. The attac= hed device may be an entire network of PBXs, and the incoming calls could b= e delivered to, or forwarded to, a large number of devices outside the spec= ific attached physical box. Therefore it is much more appropriate to refer = to an attached network, and not to an attached PBX. That, according to the = ISO definition, is a corporate network, and to distinguish the IP character= istics, a Next Generation Corporate Network (NGCN) which is the term ECMA, = TISPAN and now 3GPP are using. 2) We need to distinguish traffic concentrators from corporate networks. It= is possible to build a box which provides a proxy, but all the end registr= ations are still between UA and the service providers network. That falls w= ithin your definition. However the MARTINI solution is still that the end U= As register with the corporate network, and the corporate network (or its g= ateway to the outside world) independently registers with the service provi= ders network. Beyond what we are talking about in MARTINI (and assuming ser= vice-route is tied into the registration, the the corporate network would p= rovide (or source) the services to its end terminals, whereas in the proxy = acting as a concentrator type implementation, these would be a means of acc= ess to Centrex type services from the service provider. regards Keith > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, May 25, 2010 6:49 PM > To: DRAGE, Keith (Keith); Adam Roach; Spencer Dawkins > Cc: martini@ietf.org > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX >=20 >=20 > OK... how about SIP-PBX: SIP Proxy or B2bua for=20 > eXternal-address-of-records? >=20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: Tuesday, May 25, 2010 11:07 AM > > To: Hadriel Kaplan; Adam Roach; Spencer Dawkins > > Cc: martini@ietf.org > > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX > >=20 > > Apart from any other issues, all that tells you is it runs SIP (or=20 > > something nearly but not quite SIP) and is a separate box.=20 > That covers=20 > > about 10% of what it is and needs to be. > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Tuesday, May 25, 2010 3:55 PM > > > To: DRAGE, Keith (Keith); Adam Roach; Spencer Dawkins > > > Cc: martini@ietf.org > > > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX > > > > > > > > > That's ok, we can put this in the definitions section: > > > > > > SIP-PBX: SIP Provisioned Bulk-user eXternalizer > > > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org]=20 > > > > On Behalf Of DRAGE, Keith (Keith) > > > > Sent: Tuesday, May 25, 2010 5:48 AM > > > > > > > > I suspect in most cases you should not be using xxx-PBX at > > > all, unless > > > > it is a restriction of MARTINI that the attached PBX=20 > cannot take=20 > > > > traffic from other PBXs in the same network. I would also point=20 > > > > out that in using MARTINI, what happens in the rest of the PBX > > > should not > > > > necessarily be constrained to be SIP. > > > > > > > > ETSI and ECMA agreed on a common terminology that=20 > started from the=20 > > > > original ISO root definition. > > > > > > > > "Corporate telecommunication Network (CN): sets of > > > enterprise premises > > > > equipment, owned by or managed on behalf of an=20 > enterprise that are=20 > > > > located at geographically dispersed locations and are > > > interconnected > > > > to provide telecommunication services to a defined=20 > group of users=20 > > > > belonging to that enterprise > > > > > > > > enterprise: unit of economic organization or activity,=20 > especially=20 > > > > a business organization > > > > > > > > Next Generation CN (NGCN): self-contained corporate network > > > designed > > > > to take advantage of emerging IP-based communications solutions=20 > > > > and that can have its own applications and service provisioning > > > > > > > > NOTE 1: For the purpose of the present document it is a > > > corporate > > > > network that provides an IP-based interface to an NGN. > > > > > > > > NOTE 2: TR 102 478 [10] uses NGCN to collectively refer > > > to IP-PBXs. > > > > > > > > NGCN site: separate part of an NGCN" > > > > > > > > regards > > > > > > > > Keith > > > > > > > > = From pkyzivat@cisco.com Thu May 27 10:47:58 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 9B8C43A6942 for ; Thu, 27 May 2010 10:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.988 X-Spam-Level: X-Spam-Status: No, score=-8.988 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_05=-1.11, 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 EOJ1scor5qCv for ; Thu, 27 May 2010 10:47:57 -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 68C383A6845 for ; Thu, 27 May 2010 10:47:57 -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: AvsEALdM/ktAZnwN/2dsb2JhbACeInGoHJozgmCCMwQ X-IronPort-AV: E=Sophos;i="4.53,312,1272844800"; d="scan'208";a="115304142" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 May 2010 17:47:47 +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 o4RHllKC000461; Thu, 27 May 2010 17:47:47 GMT Message-ID: <4BFEB043.1080304@cisco.com> Date: Thu, 27 May 2010 13:47:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 27 May 2010 17:47:58 -0000 DRAGE, Keith (Keith) wrote: > 2) We need to distinguish traffic concentrators from corporate networks. It is possible to build a box which provides a proxy, but all the end registrations are still between UA and the service providers network. That falls within your definition. However the MARTINI solution is still that the end UAs register with the corporate network, and the corporate network (or its gateway to the outside world) independently registers with the service providers network. Beyond what we are talking about in MARTINI (and assuming service-route is tied into the registration, the the corporate network would provide (or source) the services to its end terminals, whereas in the proxy acting as a concentrator type implementation, these would be a means of access to Centrex type services from the service provider. What does the above have to do with Martini??? That can already be done without Martini, using normal REGISTER, Route, Service-Route, etc. Thanks, Paul From christer.holmberg@ericsson.com Thu May 27 11:06:04 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 D81913A6BBF for ; Thu, 27 May 2010 11:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[AWL=1.797, 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 8w14duQ9Wlhz for ; Thu, 27 May 2010 11:06:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D4E0B3A6878 for ; Thu, 27 May 2010 11:05:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7b73ae00000711c-b5-4bfeb4772b04 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F8.EE.28956.774BEFB4; Thu, 27 May 2010 20:05:44 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 27 May 2010 20:05:43 +0200 From: Christer Holmberg To: Paul Kyzivat , "DRAGE, Keith (Keith)" Date: Thu, 27 May 2010 20:04:01 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr9xLtVK/sP9p0JSaaJs/VlancBLAAAkGFt Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> , <4BFEB043.1080304@cisco.com> In-Reply-To: <4BFEB043.1080304@cisco.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-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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, 27 May 2010 18:06:05 -0000 Hi, Maybe we should simply talk about "behavior of a SIP entity that performs b= ulk registration", or something like that. A SIP-PBX (or whatever we want to call it) can then be used as an example. Regards, Christer ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Thursday, May 27, 2010 8:47 PM To: DRAGE, Keith (Keith) Cc: Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] SIP-PBX, PBX and IP-PBX DRAGE, Keith (Keith) wrote: > 2) We need to distinguish traffic concentrators from corporate network= s. It is possible to build a box which provides a proxy, but all the end re= gistrations are still between UA and the service providers network. That fa= lls within your definition. However the MARTINI solution is still that the = end UAs register with the corporate network, and the corporate network (or = its gateway to the outside world) independently registers with the service = providers network. Beyond what we are talking about in MARTINI (and assumin= g service-route is tied into the registration, the the corporate network wo= uld provide (or source) the services to its end terminals, whereas in the p= roxy acting as a concentrator type implementation, these would be a means o= f access to Centrex type services from the service provider. What does the above have to do with Martini??? That can already be done without Martini, using normal REGISTER, Route, Service-Route, etc. Thanks, Paul _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini= From john.elwell@siemens-enterprise.com Thu May 27 23:53:48 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 C95213A679C for ; Thu, 27 May 2010 23:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_50=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 92ageNTkKKS5 for ; Thu, 27 May 2010 23:53:47 -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 1C3A13A67AD for ; Thu, 27 May 2010 23:53:46 -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-320243; Fri, 28 May 2010 08:53:34 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id DFE131EB82AB; Fri, 28 May 2010 08:53:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 28 May 2010 08:53:34 +0200 From: "Elwell, John" To: Christer Holmberg , Paul Kyzivat , "DRAGE, Keith (Keith)" Date: Fri, 28 May 2010 08:53:33 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr9xLtVK/sP9p0JSaaJs/VlancBLAAAkGFtABrSQtA= Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> , <4BFEB043.1080304@cisco.com> 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 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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: Fri, 28 May 2010 06:53:48 -0000 Yes, we could define a term Bulk Registrant (BR) and give SIP-PBXs and NGCN= s as examples. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 27 May 2010 19:04 > To: Paul Kyzivat; DRAGE, Keith (Keith) > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX >=20 > Hi, >=20 > Maybe we should simply talk about "behavior of a SIP entity=20 > that performs bulk registration", or something like that. >=20 > A SIP-PBX (or whatever we want to call it) can then be used=20 > as an example. >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: martini-bounces@ietf.org [martini-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > Sent: Thursday, May 27, 2010 8:47 PM > To: DRAGE, Keith (Keith) > Cc: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX >=20 > DRAGE, Keith (Keith) wrote: >=20 > > 2) We need to distinguish traffic concentrators from=20 > corporate networks. It is possible to build a box which=20 > provides a proxy, but all the end registrations are still=20 > between UA and the service providers network. That falls=20 > within your definition. However the MARTINI solution is still=20 > that the end UAs register with the corporate network, and the=20 > corporate network (or its gateway to the outside world)=20 > independently registers with the service providers network.=20 > Beyond what we are talking about in MARTINI (and assuming=20 > service-route is tied into the registration, the the=20 > corporate network would provide (or source) the services to=20 > its end terminals, whereas in the proxy acting as a=20 > concentrator type implementation, these would be a means of=20 > access to Centrex type services from the service provider. >=20 > What does the above have to do with Martini??? >=20 > That can already be done without Martini, using normal=20 > REGISTER, Route, > Service-Route, etc. >=20 > Thanks, > Paul > _______________________________________________ > 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 martien.huysmans@ericsson.com Fri May 28 04:37:02 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 D474D3A68C1 for ; Fri, 28 May 2010 04:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-2.929, 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 oEKMd0WYWTC6 for ; Fri, 28 May 2010 04:37:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B8DDE3A6781 for ; Fri, 28 May 2010 04:37:01 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-ff-4bffaad2c986 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3E.00.06817.2DAAFFB4; Fri, 28 May 2010 13:36:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.112]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 28 May 2010 13:36:50 +0200 From: Martien Huysmans To: Hans Erik van Elburg Date: Fri, 28 May 2010 13:36:49 +0200 Thread-Topic: [martini] GIN and anonymous GRUUS Thread-Index: Acr9niaUfFdPtUH3RvyA+L1u8LEaMwAu5oOw Message-ID: References: <94280B93-31C5-49A6-A086-7297F14DE00A@cisco.com> <4BF3F2FC.8090609@nostrum.com> <4BF40068.3020502@nostrum.com> <4BF41BDC.7050902@cisco.com> <44DE5C45-48D5-4BA7-AE3E-92497A26D3A1@cisco.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] GIN and anonymous GRUUS 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: Fri, 28 May 2010 11:37:02 -0000 Then the statement is from my side. /Martien -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, May 27, 2010 3:00 PM To: Martien Huysmans Cc: Cullen Jennings; martini@ietf.org Subject: Re: [martini] GIN and anonymous GRUUS I did not ment to state anything I was just raising questions for my unders= tanding to Cullen. /Hans Erik van Elburg On Thu, May 27, 2010 at 10:07 AM, Martien Huysmans wrote: > Hi > > If I understand you correctly, you are saying that RFC3323 provides an al= ternative for the "goat shelter" problem. > That problem resulted in the temp-gruu chapters that are now described in= martini-gin-03. > In this alternative the SSP would provide a Privacy service, which ensure= s that caller remains anonymous. > Sound good. > > Side question: If there is a B2BUA in the network of the SSP, then my=20 > understanding is that the contact of the caller will never reach the call= er. I guess the Privacy service would be implemented as a B2BUA. > > /Martien > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > Behalf Of Hans Erik van Elburg > Sent: Wednesday, May 26, 2010 11:41 PM > To: Cullen Jennings > Cc: martini@ietf.org > Subject: Re: [martini] GIN and anonymous GRUUS > > On Thu, May 20, 2010 at 4:04 PM, Cullen Jennings wrote= : >> There's a ton of way to skin this cat but I am strongly against deprecia= ting anonymous call support of 3261 when using the GIN draft - I view that = as GIN breaking SIP. It's a critical feature when using SIP for PSTN replac= ement and I believe it has very important value many types of SIP communica= tion. > > [HE] I agree that anonymity is an important feature, but how would this b= reak anonymous call support in RFC3261? Does it not have a similar weakness= as RFC3261 that the goat shelter could be revealed by the IP address in th= e contact header of messages coming out of the shelter's pbx? > > Or did you mean to refer to RFC3323? Which delegates the anonymization of= the Contact header to an intermediary providing a privacy service (section= 4.1). > > /Hans Erik > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From christer.holmberg@ericsson.com Fri May 28 04:52:17 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 DB65B3A6836 for ; Fri, 28 May 2010 04:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=-0.437, 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 ujNwceLc3U1H for ; Fri, 28 May 2010 04:52:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7D6913A6822 for ; Fri, 28 May 2010 04:52:16 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-a5-4bffae644b2b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A0.B1.06817.46EAFFB4; Fri, 28 May 2010 13:52:05 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 28 May 2010 13:52:04 +0200 From: Christer Holmberg To: "Elwell, John" , Paul Kyzivat , "DRAGE, Keith (Keith)" Date: Fri, 28 May 2010 13:52:03 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr9xLtVK/sP9p0JSaaJs/VlancBLAAAkGFtABrSQtAACmwJcA== Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> , <4BFEB043.1080304@cisco.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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: Fri, 28 May 2010 11:52:18 -0000 Hi,=20 >Yes, we could define a term Bulk Registrant (BR) and give SIP-PBXs and NGC= Ns as examples. Yes.=20 And, I also believe that the text should say that, from the SSP perspective= , the BR implements a SIP UA role. Because, as far as I know, proxies do no= t register. Regards, Christer > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 27 May 2010 19:04 > > To: Paul Kyzivat; DRAGE, Keith (Keith) > > Cc: martini@ietf.org; Hadriel Kaplan > > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX > >=20 > > Hi, > >=20 > > Maybe we should simply talk about "behavior of a SIP entity that=20 > > performs bulk registration", or something like that. > >=20 > > A SIP-PBX (or whatever we want to call it) can then be used as an=20 > > example. > >=20 > > Regards, > >=20 > > Christer > >=20 > > ________________________________________ > > From: martini-bounces@ietf.org [martini-bounces@ietf.org]=20 > On Behalf Of=20 > > Paul Kyzivat [pkyzivat@cisco.com] > > Sent: Thursday, May 27, 2010 8:47 PM > > To: DRAGE, Keith (Keith) > > Cc: Hadriel Kaplan; martini@ietf.org > > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX > >=20 > > DRAGE, Keith (Keith) wrote: > >=20 > > > 2) We need to distinguish traffic concentrators from=20 > > corporate networks. It is possible to build a box which provides a=20 > > proxy, but all the end registrations are still between UA and the=20 > > service providers network. That falls within your=20 > definition. However=20 > > the MARTINI solution is still that the end UAs register with the=20 > > corporate network, and the corporate network (or its gateway to the=20 > > outside world) independently registers with the service providers=20 > > network. > > Beyond what we are talking about in MARTINI (and assuming=20 > > service-route is tied into the registration, the the=20 > corporate network=20 > > would provide (or source) the services to its end=20 > terminals, whereas=20 > > in the proxy acting as a concentrator type implementation,=20 > these would=20 > > be a means of access to Centrex type services from the service=20 > > provider. > >=20 > > What does the above have to do with Martini??? > >=20 > > That can already be done without Martini, using normal REGISTER,=20 > > Route, Service-Route, etc. > >=20 > > Thanks, > > Paul > > _______________________________________________ > > 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 john.elwell@siemens-enterprise.com Fri May 28 05:41: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 2B8223A68D1 for ; Fri, 28 May 2010 05:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 1cWxjoAA6RPz for ; Fri, 28 May 2010 05:41:23 -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 DE1343A6820 for ; Fri, 28 May 2010 05:41:22 -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-326331; Fri, 28 May 2010 14:41:12 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id F00DD1EB82AB; Fri, 28 May 2010 14:41:11 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 28 May 2010 14:41:11 +0200 From: "Elwell, John" To: Christer Holmberg , Paul Kyzivat , "DRAGE, Keith (Keith)" Date: Fri, 28 May 2010 14:41:09 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr9xLtVK/sP9p0JSaaJs/VlancBLAAAkGFtABrSQtAACmwJcAABkS8g Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> , <4BFEB043.1080304@cisco.com> 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 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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: Fri, 28 May 2010 12:41:24 -0000 Yes. Even a PBX that acts as a proxy on non-REGISTER inbound and outbound r= equests would be a UA from the perspective of REGISTER, i.e., the BR would = be a UA. John=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 28 May 2010 12:52 > To: Elwell, John; Paul Kyzivat; DRAGE, Keith (Keith) > Cc: martini@ietf.org; Hadriel Kaplan > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX >=20 >=20 > Hi,=20 >=20 > >Yes, we could define a term Bulk Registrant (BR) and give=20 > SIP-PBXs and NGCNs as examples. >=20 > Yes.=20 >=20 > And, I also believe that the text should say that, from the=20 > SSP perspective, the BR implements a SIP UA role. Because, as=20 > far as I know, proxies do not register. >=20 > Regards, >=20 > Christer >=20 >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 27 May 2010 19:04 > > > To: Paul Kyzivat; DRAGE, Keith (Keith) > > > Cc: martini@ietf.org; Hadriel Kaplan > > > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX > > >=20 > > > Hi, > > >=20 > > > Maybe we should simply talk about "behavior of a SIP entity that=20 > > > performs bulk registration", or something like that. > > >=20 > > > A SIP-PBX (or whatever we want to call it) can then be used as an=20 > > > example. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > ________________________________________ > > > From: martini-bounces@ietf.org [martini-bounces@ietf.org]=20 > > On Behalf Of=20 > > > Paul Kyzivat [pkyzivat@cisco.com] > > > Sent: Thursday, May 27, 2010 8:47 PM > > > To: DRAGE, Keith (Keith) > > > Cc: Hadriel Kaplan; martini@ietf.org > > > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX > > >=20 > > > DRAGE, Keith (Keith) wrote: > > >=20 > > > > 2) We need to distinguish traffic concentrators from=20 > > > corporate networks. It is possible to build a box which=20 > provides a=20 > > > proxy, but all the end registrations are still between UA and the=20 > > > service providers network. That falls within your=20 > > definition. However=20 > > > the MARTINI solution is still that the end UAs register with the=20 > > > corporate network, and the corporate network (or its=20 > gateway to the=20 > > > outside world) independently registers with the service providers=20 > > > network. > > > Beyond what we are talking about in MARTINI (and assuming=20 > > > service-route is tied into the registration, the the=20 > > corporate network=20 > > > would provide (or source) the services to its end=20 > > terminals, whereas=20 > > > in the proxy acting as a concentrator type implementation,=20 > > these would=20 > > > be a means of access to Centrex type services from the service=20 > > > provider. > > >=20 > > > What does the above have to do with Martini??? > > >=20 > > > That can already be done without Martini, using normal REGISTER,=20 > > > Route, Service-Route, etc. > > >=20 > > > Thanks, > > > Paul > > > _______________________________________________ > > > 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 keith.drage@alcatel-lucent.com Fri May 28 05:46:01 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 35B463A6836 for ; Fri, 28 May 2010 05:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.069 X-Spam-Level: X-Spam-Status: No, score=-5.069 tagged_above=-999 required=5 tests=[AWL=1.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Va7bEpnwTvtn for ; Fri, 28 May 2010 05:46:00 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id DDA283A6802 for ; Fri, 28 May 2010 05:45:59 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4SCdoAR004142 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 May 2010 14:45:17 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 28 May 2010 14:44:53 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "Elwell, John" , Paul Kyzivat Date: Fri, 28 May 2010 14:44:50 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr9xLtVK/sP9p0JSaaJs/VlancBLAAAkGFtABrSQtAACmwJcAAB1vjw Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> , <4BFEB043.1080304@cisco.com> 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 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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: Fri, 28 May 2010 12:46:01 -0000 > And, I also believe that the text should say that, from the=20 > SSP perspective, the BR implements a SIP UA role. Because, as=20 > far as I know, proxies do not register. >From the perspective of the REGISTER method, yes. What the gateway function= ality on the corporate network side does for other methods is entirely up t= o it (providing it is conformant with appropriate SIP RFCs). Keith > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, May 28, 2010 12:52 PM > To: Elwell, John; Paul Kyzivat; DRAGE, Keith (Keith) > Cc: martini@ietf.org; Hadriel Kaplan > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX >=20 >=20 > Hi,=20 >=20 > >Yes, we could define a term Bulk Registrant (BR) and give=20 > SIP-PBXs and NGCNs as examples. >=20 > Yes.=20 >=20 > And, I also believe that the text should say that, from the=20 > SSP perspective, the BR implements a SIP UA role. Because, as=20 > far as I know, proxies do not register. >=20 > Regards, >=20 > Christer >=20 >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 27 May 2010 19:04 > > > To: Paul Kyzivat; DRAGE, Keith (Keith) > > > Cc: martini@ietf.org; Hadriel Kaplan > > > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX > > >=20 > > > Hi, > > >=20 > > > Maybe we should simply talk about "behavior of a SIP entity that=20 > > > performs bulk registration", or something like that. > > >=20 > > > A SIP-PBX (or whatever we want to call it) can then be used as an=20 > > > example. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > ________________________________________ > > > From: martini-bounces@ietf.org [martini-bounces@ietf.org] > > On Behalf Of > > > Paul Kyzivat [pkyzivat@cisco.com] > > > Sent: Thursday, May 27, 2010 8:47 PM > > > To: DRAGE, Keith (Keith) > > > Cc: Hadriel Kaplan; martini@ietf.org > > > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX > > >=20 > > > DRAGE, Keith (Keith) wrote: > > >=20 > > > > 2) We need to distinguish traffic concentrators from=20 > > > corporate networks. It is possible to build a box which=20 > provides a=20 > > > proxy, but all the end registrations are still between UA and the=20 > > > service providers network. That falls within your > > definition. However > > > the MARTINI solution is still that the end UAs register with the=20 > > > corporate network, and the corporate network (or its=20 > gateway to the=20 > > > outside world) independently registers with the service providers=20 > > > network. > > > Beyond what we are talking about in MARTINI (and assuming=20 > > > service-route is tied into the registration, the the > > corporate network > > > would provide (or source) the services to its end > > terminals, whereas > > > in the proxy acting as a concentrator type implementation, > > these would > > > be a means of access to Centrex type services from the service=20 > > > provider. > > >=20 > > > What does the above have to do with Martini??? > > >=20 > > > That can already be done without Martini, using normal REGISTER,=20 > > > Route, Service-Route, etc. > > >=20 > > > Thanks, > > > Paul > > > _______________________________________________ > > > 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 christer.holmberg@ericsson.com Fri May 28 05:57:26 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 4BDEF3A6802 for ; Fri, 28 May 2010 05:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=-0.419, 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 f5Z9nH443paf for ; Fri, 28 May 2010 05:57:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E31D13A6781 for ; Fri, 28 May 2010 05:57:24 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-6d-4bffbda99d0b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F8.19.06817.9ADBFFB4; Fri, 28 May 2010 14:57:13 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 28 May 2010 14:57:12 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , "Elwell, John" , Paul Kyzivat Date: Fri, 28 May 2010 14:57:12 +0200 Thread-Topic: [martini] SIP-PBX, PBX and IP-PBX Thread-Index: Acr9xLtVK/sP9p0JSaaJs/VlancBLAAAkGFtABrSQtAACmwJcAAB1vjwAABkXWA= Message-ID: References: <98F231212C8349989F818717F48F0494@china.huawei.com> <4BFAE2B3.6070602@nostrum.com> <430FC6BDED356B4C8498F634416644A91C13B8A06F@mail> <430FC6BDED356B4C8498F634416644A91C13B8A0FB@mail> , <4BFEB043.1080304@cisco.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] SIP-PBX, PBX and IP-PBX 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: Fri, 28 May 2010 12:57:26 -0000 Hi,=20 >>And, I also believe that the text should say that, from the SSP=20 >>perspective, the BR implements a SIP UA role. Because, as far as I=20 >>know, proxies do not register. >=20 >From the perspective of the REGISTER method, yes. What the=20 >gateway functionality on the corporate network side does for=20 >other methods is entirely up to it (providing it is=20 >conformant with appropriate SIP RFCs). Correct, and there can for sure be some wording about that when describing = different usage examples. But, other than that I believe that what it does on the "other side" is out= side the scope of MARTINI. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, May 28, 2010 12:52 PM > > To: Elwell, John; Paul Kyzivat; DRAGE, Keith (Keith) > > Cc: martini@ietf.org; Hadriel Kaplan > > Subject: RE: [martini] SIP-PBX, PBX and IP-PBX > >=20 > >=20 > > Hi, > >=20 > > >Yes, we could define a term Bulk Registrant (BR) and give > > SIP-PBXs and NGCNs as examples. > >=20 > > Yes.=20 > >=20 > > And, I also believe that the text should say that, from the SSP=20 > > perspective, the BR implements a SIP UA role. Because, as far as I=20 > > know, proxies do not register. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg > > > > Sent: 27 May 2010 19:04 > > > > To: Paul Kyzivat; DRAGE, Keith (Keith) > > > > Cc: martini@ietf.org; Hadriel Kaplan > > > > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX > > > >=20 > > > > Hi, > > > >=20 > > > > Maybe we should simply talk about "behavior of a SIP=20 > entity that=20 > > > > performs bulk registration", or something like that. > > > >=20 > > > > A SIP-PBX (or whatever we want to call it) can then be=20 > used as an=20 > > > > example. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > > ________________________________________ > > > > From: martini-bounces@ietf.org [martini-bounces@ietf.org] > > > On Behalf Of > > > > Paul Kyzivat [pkyzivat@cisco.com] > > > > Sent: Thursday, May 27, 2010 8:47 PM > > > > To: DRAGE, Keith (Keith) > > > > Cc: Hadriel Kaplan; martini@ietf.org > > > > Subject: Re: [martini] SIP-PBX, PBX and IP-PBX > > > >=20 > > > > DRAGE, Keith (Keith) wrote: > > > >=20 > > > > > 2) We need to distinguish traffic concentrators from=20 > > > > corporate networks. It is possible to build a box which > > provides a > > > > proxy, but all the end registrations are still between=20 > UA and the=20 > > > > service providers network. That falls within your > > > definition. However > > > > the MARTINI solution is still that the end UAs register=20 > with the=20 > > > > corporate network, and the corporate network (or its > > gateway to the > > > > outside world) independently registers with the service=20 > providers=20 > > > > network. > > > > Beyond what we are talking about in MARTINI (and assuming=20 > > > > service-route is tied into the registration, the the > > > corporate network > > > > would provide (or source) the services to its end > > > terminals, whereas > > > > in the proxy acting as a concentrator type implementation, > > > these would > > > > be a means of access to Centrex type services from the service=20 > > > > provider. > > > >=20 > > > > What does the above have to do with Martini??? > > > >=20 > > > > That can already be done without Martini, using normal=20 > REGISTER,=20 > > > > Route, Service-Route, etc. > > > >=20 > > > > Thanks, > > > > Paul > > > > _______________________________________________ > > > > 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 > > > > =