From pkyzivat@alum.mit.edu Sun Oct 2 14:54:46 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B305221F8586 for ; Sun, 2 Oct 2011 14:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwkcf3urVUO2 for ; Sun, 2 Oct 2011 14:54:45 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9E66021F8560 for ; Sun, 2 Oct 2011 14:54:45 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id fuLL1h0031c6gX851xxmNs; Sun, 02 Oct 2011 21:57:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id fxxl1h00y0tdiYw3jxxmj7; Sun, 02 Oct 2011 21:57:46 +0000 Message-ID: <4E88DE57.3070909@alum.mit.edu> Date: Sun, 02 Oct 2011 17:57:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com> <6369CB70BFD88942B9705AC1E639A33822D1EBF8C6@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822D1EBF8C6@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 21:54:46 -0000 On 9/27/11 8:34 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Our intention with the original SIP Action Referral proposal and later on with the INVOKE method proposal was to extend the Remote *Call* Control mechanism defined by the REFER method. > During the discussion of these proposals some people showed interest in a Remote *Device* Control, but it was clear that the line between Remote Call Control and Remote Device Control is blurry. > Different people have different ideas on how to address these needs: > * One mechanism over SIP should address both Call and Device control > * SIP should be used for Call control and a non-SIP mechanism for Device control > * non-SIP mechanism should be used for both Call and Device control > > That is the reason for the questions stated below. I agree here. As it started out, it was a mechanism to do "stuff", which seemed too loosy-goosey to me. I do want to see a bounded scope to what can be controlled. But it also seemed to be the case that some aspects of device control are encompassed. In fact it may turn out to be all about device control, since there are existing solutions for a lot of call control. I agree that there are serious security concerns for device control, but that doesn't mean it shouldn't be addressed. Security concerns may limit what device features are in scope. (E.g. declare the "explode device" feature out of scope.) Clearly there will have to be some limitations that prevent using this to turn a phone into a bugging device. So I'm fine with including investigation of both call control and device control while narrowing down what we mean by those. Thanks, Paul > In any case, I would welcome any suggestions on how to improve the text of this charter proposal. > Regards, > Rifaat > > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: Friday, September 23, 2011 7:40 PM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG >> >> >> I don't mean to argue for or against this work in any way, but the charter >> seems very odd to me. >> I could be totally wrong, but I don't think WG charters usually have goals >> like the first two you have listed: >>> * Clearly answer the following questions: >>> a. What is "call control"? >>> b. What is "device control"? >>> * Will the new mechanism address "call control", "device control" or both? >> >> Those types of questions are usually answered *before* a WG is chartered, as >> far as I can recall. Otherwise it's like saying one of the goals of the >> Working Group is to define it's own scope. Well... usually the IETF wants to >> know the scope before creating a WG. >> >> Also, for some topics DISPATCH needs a "mini-BOF" at a face-to-face IETF >> meeting, with a presentation(s) on the problem and possible solutions, and the >> chairs ask for hands on who's interested in the work and would be willing to >> contribute and such. Are you planning on doing that for the Taipei meeting? >> >> -hadriel >> >> >> >> On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> >>> Hi, >>> >>> The following is a charter proposal for a Remote Call/Device Control WG. >>> We would appreciate it if you review it and provide us with your feedback. >>> >>> Thanks, >>> Rifaat >>> >>> ------- >>> >>> Remote Call/Device Control WG >>> >>> The Session Initiation Protocol (SIP) [RFC3261] provides users with the >> ability to initiate, manage, and terminate multimedia sessions. >>> A SIP application is a program running on a SIP network element that >> provides some value-added function to a user. >>> Many deployments have SIP applications in the SIP signaling path that get >> involved in the setup and management of these multimedia sessions. >>> Third-Party Application might also be interested in interacting with User >> Agents and the setup of multimedia sessions. >>> Some of these applications need a mechanism to remotely invoke some actions >> or/and monitor the invocation of actions on a SIP User Agent. >>> SIP allows for the invocation of actions on a remote User Agent using the >> REFER method. >>> The actions that can be invoked by the REFER method are limited, and there >> is a need for more actions by some SIP applications. >>> The purpose of this WG is to evaluate the various available mechanisms or >> proposed mechanism and recommend one or more of them, >>> or define a new mechanism if none of the available are good enough to >> address this need. >>> >>> The work group will need to address the following: >>> * Clearly answer the following questions: >>> a. What is "call control"? >>> b. What is "device control"? >>> * Will the new mechanism address "call control", "device control" or both? >>> * Will the new mechanism be a SIP or a non-SIP based mechanism? >>> * If a non-SIP mechanism is used, how to deal with the fact that some of >> these >>> actions already covered by the SIP REFER method and widely used in the >> industry >>> * Define a model for the actions >>> * Define a scope for the actions >>> * Define a set of initial actions that can be later extended, if needed. >>> * Others? >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Sun Oct 2 16:34:35 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DAE21F8532 for ; Sun, 2 Oct 2011 16:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI8MYaVfCw3V for ; Sun, 2 Oct 2011 16:34:34 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0A121F851F for ; Sun, 2 Oct 2011 16:34:33 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id fx8y1h0081ei1Bg51zdaAf; Sun, 02 Oct 2011 23:37:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id fzdZ1h00r0tdiYw3kzdZEJ; Sun, 02 Oct 2011 23:37:34 +0000 Message-ID: <4E88F5BC.6010904@alum.mit.edu> Date: Sun, 02 Oct 2011 19:37:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080307@alum.mit.edu> <4E7CB229.2050207@digium.com> In-Reply-To: <4E7CB229.2050207@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 23:34:35 -0000 On 9/23/11 12:22 PM, Kevin P. Fleming wrote: > On 09/23/2011 10:46 AM, Worley, Dale R (Dale) wrote: >>> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >>> >>> You can just configure the phone as you say, IF: >>> >>> - the phone has a configurable light >>> - the light can be configured with a URI >>> - the phone determines the light status by using the URI >>> in the way intended by the target of that URI >>> >>> AFAIK all of those are unusual properties, except for the specific >>> equipment that currently supports it. If I have some "other" phone I am >>> out of luck unless I am in a position to modify it in that way. >> >> I may be completely misunderstanding you, but I know of no SIP phone >> which is claimed to "have BLF lights" that does *not* implement the >> points you've listed. > > Yeah... I was going to post the same thing, but wasn't quite sure if I > was missing something obvious :-) I've been living in the sheltered world of Cisco phones. AFAIK there aren't any real standards for this, so it will work for those things that happen to follow this defacto standard. Thanks, Paul From pravindran@sonusnet.com Sun Oct 2 23:28:16 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B5821F88B6 for ; Sun, 2 Oct 2011 23:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASIfGxHNHhKB for ; Sun, 2 Oct 2011 23:28:15 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 257CE21F889A for ; Sun, 2 Oct 2011 23:28:15 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p936VmwF022862; Mon, 3 Oct 2011 02:31:48 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 02:31:15 -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: Mon, 3 Oct 2011 12:01:11 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F12FE@sonusinmail02.sonusnet.com> In-Reply-To: <4E88DE57.3070909@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: AcyBTlatwgVe28zXSiqHiZ7hnhpgsQAR5Tlg References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com><5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com><6369CB70BFD88942B9705AC1E639A33822D1EBF8C6@DC-US1MBEX4.global.avaya.com> <4E88DE57.3070909@alum.mit.edu> From: "Ravindran Parthasarathi" To: "Paul Kyzivat" , X-OriginalArrivalTime: 03 Oct 2011 06:31:15.0837 (UTC) FILETIME=[0D7E72D0:01CC8196] Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 06:28:16 -0000 I agree with Paul and interested in the progress of this work in the correct WG this time :-) Thanks Partha >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of Paul Kyzivat >Sent: Monday, October 03, 2011 3:28 AM >To: dispatch@ietf.org >Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG > >On 9/27/11 8:34 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> Our intention with the original SIP Action Referral proposal and later >on with the INVOKE method proposal was to extend the Remote *Call* >Control mechanism defined by the REFER method. >> During the discussion of these proposals some people showed interest >in a Remote *Device* Control, but it was clear that the line between >Remote Call Control and Remote Device Control is blurry. >> Different people have different ideas on how to address these needs: >> * One mechanism over SIP should address both Call and Device >control >> * SIP should be used for Call control and a non-SIP mechanism for >Device control >> * non-SIP mechanism should be used for both Call and Device control >> >> That is the reason for the questions stated below. > >I agree here. As it started out, it was a mechanism to do "stuff", which >seemed too loosy-goosey to me. I do want to see a bounded scope to what >can be controlled. But it also seemed to be the case that some aspects >of device control are encompassed. In fact it may turn out to be all >about device control, since there are existing solutions for a lot of >call control. > >I agree that there are serious security concerns for device control, but >that doesn't mean it shouldn't be addressed. Security concerns may limit >what device features are in scope. (E.g. declare the "explode device" >feature out of scope.) Clearly there will have to be some limitations >that prevent using this to turn a phone into a bugging device. > >So I'm fine with including investigation of both call control and device >control while narrowing down what we mean by those. > > Thanks, > Paul > >> In any case, I would welcome any suggestions on how to improve the >text of this charter proposal. > > > >> Regards, >> Rifaat >> >> >>> -----Original Message----- >>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>> Sent: Friday, September 23, 2011 7:40 PM >>> To: Shekh-Yusef, Rifaat (Rifaat) >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control >WG >>> >>> >>> I don't mean to argue for or against this work in any way, but the >charter >>> seems very odd to me. >>> I could be totally wrong, but I don't think WG charters usually have >goals >>> like the first two you have listed: >>>> * Clearly answer the following questions: >>>> a. What is "call control"? >>>> b. What is "device control"? >>>> * Will the new mechanism address "call control", "device control" or >both? >>> >>> Those types of questions are usually answered *before* a WG is >chartered, as >>> far as I can recall. Otherwise it's like saying one of the goals of >the >>> Working Group is to define it's own scope. Well... usually the IETF >wants to >>> know the scope before creating a WG. >>> >>> Also, for some topics DISPATCH needs a "mini-BOF" at a face-to-face >IETF >>> meeting, with a presentation(s) on the problem and possible >solutions, and the >>> chairs ask for hands on who's interested in the work and would be >willing to >>> contribute and such. Are you planning on doing that for the Taipei >meeting? >>> >>> -hadriel >>> >>> >>> >>> On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>> >>>> Hi, >>>> >>>> The following is a charter proposal for a Remote Call/Device Control >WG. >>>> We would appreciate it if you review it and provide us with your >feedback. >>>> >>>> Thanks, >>>> Rifaat >>>> >>>> ------- >>>> >>>> Remote Call/Device Control WG >>>> >>>> The Session Initiation Protocol (SIP) [RFC3261] provides users with >the >>> ability to initiate, manage, and terminate multimedia sessions. >>>> A SIP application is a program running on a SIP network element that >>> provides some value-added function to a user. >>>> Many deployments have SIP applications in the SIP signaling path >that get >>> involved in the setup and management of these multimedia sessions. >>>> Third-Party Application might also be interested in interacting with >User >>> Agents and the setup of multimedia sessions. >>>> Some of these applications need a mechanism to remotely invoke some >actions >>> or/and monitor the invocation of actions on a SIP User Agent. >>>> SIP allows for the invocation of actions on a remote User Agent >using the >>> REFER method. >>>> The actions that can be invoked by the REFER method are limited, and >there >>> is a need for more actions by some SIP applications. >>>> The purpose of this WG is to evaluate the various available >mechanisms or >>> proposed mechanism and recommend one or more of them, >>>> or define a new mechanism if none of the available are good enough >to >>> address this need. >>>> >>>> The work group will need to address the following: >>>> * Clearly answer the following questions: >>>> a. What is "call control"? >>>> b. What is "device control"? >>>> * Will the new mechanism address "call control", "device control" or >both? >>>> * Will the new mechanism be a SIP or a non-SIP based mechanism? >>>> * If a non-SIP mechanism is used, how to deal with the fact that >some of >>> these >>>> actions already covered by the SIP REFER method and widely used >in the >>> industry >>>> * Define a model for the actions >>>> * Define a scope for the actions >>>> * Define a set of initial actions that can be later extended, if >needed. >>>> * Others? >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Mon Oct 3 12:31:17 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774F121F8E10 for ; Mon, 3 Oct 2011 12:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K37Ow+qUvkoC for ; Mon, 3 Oct 2011 12:31:17 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5D921F8DF3 for ; Mon, 3 Oct 2011 12:31:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHINik6HCzI1/2dsb2JhbABDDqd1gQWBUwEBAQECARIoRAsCAQgNAQchEDIlAQEEARIIGodZnXQCmwmGQGEEmSSLQ1M X-IronPort-AV: E=Sophos;i="4.68,481,1312171200"; d="scan'208";a="210798296" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Oct 2011 15:34:07 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Oct 2011 15:24:16 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 3 Oct 2011 15:34:07 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "dispatch@ietf.org" Date: Mon, 3 Oct 2011 15:34:07 -0400 Thread-Topic: [dispatch] Deriving URI from MAC-based URN ??? Thread-Index: AcyBXFM71AMs+uXDSIGRHr6A+RwnAwApksti Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080307@alum.mit.edu> <4E7CB229.2050207@digium.com>,<4E88F5BC.6010904@alum.mit.edu> In-Reply-To: <4E88F5BC.6010904@alum.mit.edu> 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: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 19:31:17 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > I've been living in the sheltered world of Cisco phones. And conversely, Cisco phones have never implemented enough of SIP to be usable in our pure-proxy system. What we see in the market is that a phone is configured with a single URI for BLF. The phone subscribes to the URI for dialog events with the "resource list" extension (RFC 4662). Each resource in the resource list is mapped to one BLF light. The state of the light is driven by interpreting the status of the dialogs reported for the resource in the resource list events. Actually, the phones don't support RFC 4662 event values generally, but rather the subset of it that Broadworks can generate: Each resource must have only one resource instance, and in full-state events, each resource must have at least one dialog, whose local display name is used to label the BLF button. Or something like that; it's a horror story that I've started to forget. Dale From pkyzivat@alum.mit.edu Mon Oct 3 22:02:57 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CBE21F8E25 for ; Mon, 3 Oct 2011 22:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w27X3sCNKqW for ; Mon, 3 Oct 2011 22:02:57 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0387A21F8DC5 for ; Mon, 3 Oct 2011 22:02:55 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id gV231h0031YDfWL5DV5zL6; Tue, 04 Oct 2011 05:05:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([205.168.243.143]) by omta20.westchester.pa.mail.comcast.net with comcast id gV5n1h00236M3z93gV5pbj; Tue, 04 Oct 2011 05:05:56 +0000 Message-ID: <4E8A9429.1040408@alum.mit.edu> Date: Tue, 04 Oct 2011 01:05:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080307@alum.mit.edu> <4E7CB229.2050207@digium.com>, <4E88F5BC.6010904@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 05:02:57 -0000 On 10/3/11 3:34 PM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> I've been living in the sheltered world of Cisco phones. > > And conversely, Cisco phones have never implemented enough of SIP to > be usable in our pure-proxy system. > > What we see in the market is that a phone is configured with a single > URI for BLF. The phone subscribes to the URI for dialog events with > the "resource list" extension (RFC 4662). Each resource in the > resource list is mapped to one BLF light. The state of the light is > driven by interpreting the status of the dialogs reported for the > resource in the resource list events. > > Actually, the phones don't support RFC 4662 event values generally, > but rather the subset of it that Broadworks can generate: Each > resource must have only one resource instance, and in full-state > events, each resource must have at least one dialog, whose local > display name is used to label the BLF button. Or something like that; > it's a horror story that I've started to forget. OK. This has been a long digression from arguments about new URN formats. I guess the point is that some applications may utilize the URN in a sip.instance in unusual and proprietary ways, and changing the type of URN could break that usage. IMO that is not something we need be concerned with here. Thanks, Paul From dworley@avaya.com Tue Oct 4 08:17:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60D421F891D for ; Tue, 4 Oct 2011 08:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmWMet8yN6Qe for ; Tue, 4 Oct 2011 08:17:48 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5A421F8ADE for ; Tue, 4 Oct 2011 08:17:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADIji07GmAcF/2dsb2JhbAA8Bg6nbIEFgVMBAQEBAgESKD8FCwIBCA0BByEQMiUBAQQOBQgah1qdJAKbI4QBgkBhBJksi0VT X-IronPort-AV: E=Sophos;i="4.68,485,1312171200"; d="scan'208";a="211191857" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Oct 2011 11:20:53 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Oct 2011 11:20:00 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 4 Oct 2011 11:20:52 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat Date: Tue, 4 Oct 2011 11:18:12 -0400 Thread-Topic: [dispatch] Deriving URI from MAC-based URN ??? Thread-Index: AcyCU06jfyvJg5gdQZOb3CAM02c0rQAVYVRU Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080307@alum.mit.edu> <4E7CB229.2050207@digium.com>,<4E88F5BC.6010904@alum.mit.edu> , <4E8A9429.1040408@alum.mit.edu> In-Reply-To: <4E8A9429.1040408@alum.mit.edu> 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: "dispatch@ietf.org" Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:17:48 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > I guess the point is that some applications may utilize the URN in a > sip.instance in unusual and proprietary ways, and changing the type of > URN could break that usage. IMO that is not something we need be > concerned with here. The related point I was trying to make is that I've written code that uses sip.instance URNs in non-trivial ways, and since the beginning, the code was organized to be robust against non-UUID URNs, as there was no assurance that UAs would not use such URNs. Dale From spromano@unina.it Wed Oct 5 08:13:00 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533E421F8D43; Wed, 5 Oct 2011 08:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.341 X-Spam-Level: X-Spam-Status: No, score=-100.341 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqMAaCMoNsMX; Wed, 5 Oct 2011 08:12:59 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3701B21F8D44; Wed, 5 Oct 2011 08:12:59 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id p95FG3r2026236 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 5 Oct 2011 17:16:05 +0200 Message-ID: <4E8C74B0.1080505@unina.it> Date: Wed, 05 Oct 2011 17:16:00 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: dcon@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: DISPATCH Subject: [dispatch] DCON discussion material X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 15:13:00 -0000 Hi all, following the recent discussions about Distributed Conferencing (for which, as you might know, a BOF at IETF 82 has been proposed), I'm sending you three references to Internet Drafts we submitted some time ago and which should help position the proposed idea in the context of what has already been achieved within the IETF (XCON in particular). These I-Ds clearly represent just preliminary thoughts, which might be completely re-designed should the IETF decide to start working on this topic, but they nonetheless stand there as a first attempt at addressing the issues we identified so far. Here are the documents I'm referring to: 1. Requirements for Distributed Conferencing --> http://tools.ietf.org/html/draft-romano-dcon-requirements-09 2. A Framework for Distributed Conferencing --> http://tools.ietf.org/html/draft-romano-dcon-framework-09 3. Requirements for the XCON-DCON Synchronization Protocol --> http://tools.ietf.org/html/draft-romano-dcon-xdsp-reqs-09 I hope this can help foster discussion on the brand new non-WG list that has been recently created. I'm CC:ing DISPATCH, since this is where the DCON story comes from. Cheers, Simon -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From marshall.eubanks@gmail.com Wed Oct 5 09:13:15 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957BF11E8083; Wed, 5 Oct 2011 09:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scUD8mceccnW; Wed, 5 Oct 2011 09:13:14 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBE8121F8BEB; Wed, 5 Oct 2011 09:13:14 -0700 (PDT) Received: by gyd12 with SMTP id 12so2099285gyd.31 for ; Wed, 05 Oct 2011 09:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=B6nPq8xKoGq7mXUCn8hkXpAm4Gxw0qsd8vxf/B7pRRE=; b=sfPh5QyjsOYKRHz8vSs7bO/cBzbxAqnCjvU8kuPsVmmImwwhXoACNH/ai5uYuoEtlX IB8pu5JAaKV40hJszlRvL3y11A+ZEGiRDKxu3vlFVxFl4+AWpXbkgp8dZi3STWVjfVwI WV62txepBZ3CUY2E50gd1HfH8pZ9N7khxyeng= MIME-Version: 1.0 Received: by 10.150.164.16 with SMTP id m16mr2600922ybe.197.1317831382431; Wed, 05 Oct 2011 09:16:22 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Wed, 5 Oct 2011 09:16:22 -0700 (PDT) In-Reply-To: <4E8C74B0.1080505@unina.it> References: <4E8C74B0.1080505@unina.it> Date: Wed, 5 Oct 2011 12:16:22 -0400 Message-ID: From: Marshall Eubanks To: Simon Pietro Romano Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dcon@ietf.org, DISPATCH Subject: Re: [dispatch] [dcon] DCON discussion material X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:13:15 -0000 On Wed, Oct 5, 2011 at 11:16 AM, Simon Pietro Romano wr= ote: > Hi all, > > following the recent discussions about Distributed Conferencing (for whic= h, > as you might know, a BOF at IETF 82 has been proposed), According to this http://trac.tools.ietf.org/bof/trac/wiki it has been approved. Regards Marshall I'm sending you > three references to Internet Drafts we submitted some time ago and which > should help position the proposed idea in the context of what has already > been achieved within the IETF (XCON in particular). These I-Ds clearly > represent just preliminary thoughts, which might be completely re-designe= d > should the IETF decide to start working on this topic, but they nonethele= ss > stand there as a first attempt at addressing the issues we identified so > far. Here are the documents I'm referring to: > > 1. Requirements for Distributed Conferencing --> > http://tools.ietf.org/html/draft-romano-dcon-requirements-09 > 2. A Framework for Distributed Conferencing --> > http://tools.ietf.org/html/draft-romano-dcon-framework-09 > 3. =A0Requirements for the XCON-DCON Synchronization Protocol --> > http://tools.ietf.org/html/draft-romano-dcon-xdsp-reqs-09 > > I hope this can help foster discussion on the brand new non-WG list that = has > been recently created. I'm CC:ing DISPATCH, since this is where the DCON > story comes from. > > Cheers, > > Simon > > -- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_\\|//_ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0( O-O ) > =A0 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Simon Pietro Romano > =A0 =A0 =A0 =A0 =A0 =A0 =A0Universita' di Napoli Federico II > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Computer Science Department > =A0 =A0 =A0 =A0Phone: +39 081 7683823 -- Fax: +39 081 7684219 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0e-mail: spromano@unina.it > =A0 =A0 =A0 =A0 =A0http://www.comics.unina.it/simonpietro.romano > > =A0 =A0< =A0 idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 oooO > =A0 ~~~~~~~~~~~~~~~~~~~~~~( =A0 )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ ( =A0 =A0( =A0 ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \_) =A0 =A0) / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (_/ > > > _______________________________________________ > dcon mailing list > dcon@ietf.org > https://www.ietf.org/mailman/listinfo/dcon > From salvatore.loreto@ericsson.com Fri Oct 7 05:47:04 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B6921F84C2 for ; Fri, 7 Oct 2011 05:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDFjaT+3S60S for ; Fri, 7 Oct 2011 05:47:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B9C6E21F84BB for ; Fri, 7 Oct 2011 05:46:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-4e-4e8ef584a2ac Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3C.81.13753.485FE8E4; Fri, 7 Oct 2011 14:50:12 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 14:50:12 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E4207254B; Fri, 7 Oct 2011 15:50:11 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A8B19517F4; Fri, 7 Oct 2011 15:50:11 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2E82451614; Fri, 7 Oct 2011 15:50:11 +0300 (EEST) Message-ID: <4E8EF582.6050403@ericsson.com> Date: Fri, 7 Oct 2011 15:50:10 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="------------050006020701060209080400" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] new charter version for Session-id X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 12:47:04 -0000 --------------050006020701060209080400 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi, in Quebec we got a strong consensus on moving the Session-ID work forward, but in order to do so we have been asked to work on improving the charter so to make more clear and focused the aim of the mini-working group. Together with all the proponents of the initial charter [1] we have worked on it and we hope it now satisfy all the concerns we listened as well as all the questions/feedback we got during the Quebec presentation. (the charter is below) comments and feedback are really welcome cheers /Sal -- Salvatore Loreto www.sloreto.com [1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html _ End-to-end Session Identifier in SIP (NEW charter proposal)_ The end-to-end Session Identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediary devices, management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices and hops. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification.Perhaps the most important factor worth describing is that in real-world deployments devices like Back-to-Back User Agents (B2BUAs) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end Session Identifier aims to identify a Dialog (as defined in RFC 3261 Section 5), but does so in such a way as to overcome the limitations of the present means of Dialog identification.The Session Identifier allows for the possibility of uniquely identifying the communication session from the originating endpoint, passing through any number of intermediaries, to the terminating endpoint. The Session Identifier will address issues related to transferring or forwarding of sessions, as well as changes during mid-call of either of the endpoints by an intermediary (e.g., "joining" two calls at a B2BUA). As for Dialogs, an end-to-end Session Identifier should be "created through the generation of non-failure responses to requests with specific methods" (RFC 3261 Section 12.1).That said, the end-to-end Session Identifier may change if an endpoint receives an INVITE or other request indicating through some means that the remote endpoint has changed.This may occur, for example, when a B2BUA performs a call "join" or otherwise re-routes one end of the communication session.Taking note of such changes is important to ensure a new end-to-end Session Identifier can be constructed. Further, the Session Identifier must be constructed so that it may be used by other session control protocols, such as H.323 or XMPP, to improve interworking between protocols.The ITU-T has identified a need for an end-to-end session Identifier and is progressing work to be aligned with the output of this Working Group. The end-to-end Session Identifier has been considered as possible solution to different use cases like media and signaling correlation, session tracking, troubleshooting, billing, session recording, and so forth. Some of these requirements have also been identified and come directly from other existing working group within the RAI area (e.g., SIPRec and Splices). The requirements document shall deliver the possible scenarios where the Session Identifier would be used. This group will first focus on a document that will identify, collect and discuss all the requirements and use cases. Once the needs are clear and identified, the working group will specify the end-to-end Session Identifier mechanism. The working group will produce the following deliverables: 1. A requirement and use case document with key consideration for SIP Session End-to-End Identification 2. Specification of new end-to-end Session Identifier mechanism Goal and Milestone: March 2012 - Requirement and use case document sent to the IESG (Information) November 2012 -- Specification of the new mechanism sent to the IESG --------------050006020701060209080400 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi,

in Quebec we got a strong consensus on moving the Session-ID work forward,
but in order to do so we have been asked
to work on improving the charter so to make more clear and focused the aim of the mini-working group.

Together with all the proponents of the initial charter [1] we have worked on it
and we hope it now satisfy all the concerns we listened as well as all the questions/feedback we got
during the Quebec presentation.
(the charter is below)

comments and feedback are really welcome

cheers
/Sal
-- 
Salvatore Loreto
www.sloreto.com
[1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html



End-to-end Session Identifier in SIP (NEW charter proposal)

The end-to-end Session Identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediary devices, management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices and hops.

Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification.  Perhaps the most important factor worth describing is that in real-world deployments devices like Back-to-Back User Agents (B2BUAs) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through.

An end-to-end Session Identifier aims to identify a Dialog (as defined in RFC 3261 Section 5), but does so in such a way as to overcome the limitations of the present means of Dialog identification.  The Session Identifier allows for the possibility of uniquely identifying the communication session from the originating endpoint, passing through any number of intermediaries, to the terminating endpoint.  The Session Identifier will address issues related to transferring or forwarding of sessions, as well as changes during mid-call of either of the endpoints by an intermediary (e.g., “joining” two calls at a B2BUA).

As for Dialogs, an end-to-end Session Identifier should be “created through the generation of non-failure responses to requests with specific methods” (RFC 3261 Section 12.1).  That said, the end-to-end Session Identifier may change if an endpoint receives an INVITE or other request indicating through some means that the remote endpoint has changed.  This may occur, for example, when a B2BUA performs a call “join” or otherwise re-routes one end of the communication session.  Taking note of such changes is important to ensure a new end-to-end Session Identifier can be constructed.

Further, the Session Identifier must be constructed so that it may be used by other session control protocols, such as H.323 or XMPP, to improve interworking between protocols.  The ITU-T has identified a need for an end-to-end session Identifier and is progressing work to be aligned with the output of this Working Group.

The end-to-end Session Identifier has been considered as possible solution to different use cases like media and signaling correlation, session tracking, troubleshooting, billing, session recording, and so forth. Some of these requirements have also been identified and come directly from other existing working group within the RAI area (e.g., SIPRec and Splices).  The requirements document shall deliver the possible scenarios where the Session Identifier would be used.

This group will first focus on a document that will identify, collect and discuss all the requirements and use cases. Once the needs are clear and identified, the working group will specify the end-to-end Session Identifier mechanism.

The working group will produce the following deliverables:

1. A requirement and use case document with key consideration for SIP Session End-to-End Identification

2. Specification of new end-to-end Session Identifier mechanism

Goal and Milestone:

March 2012 - Requirement and use case document sent to the IESG (Information)

November 2012 – Specification of the new mechanism sent to the IESG

  

  


--------------050006020701060209080400--

From vkg@bell-labs.com  Fri Oct  7 06:21:59 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E776721F84BB for ; Fri,  7 Oct 2011 06:21:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.622
X-Spam-Level: 
X-Spam-Status: No, score=-106.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSGCFivlSjQU for ; Fri,  7 Oct 2011 06:21:55 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 62EFC21F84AE for ; Fri,  7 Oct 2011 06:21:55 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p97DP8Mx003490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Oct 2011 08:25:08 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p97DP7k5009146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Oct 2011 08:25:08 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p97DP7IA017416 for ; Fri, 7 Oct 2011 08:25:07 -0500 (CDT)
Message-ID: <4E8EFE52.1020402@bell-labs.com>
Date: Fri, 07 Oct 2011 08:27:46 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4E8EF582.6050403@ericsson.com>
In-Reply-To: <4E8EF582.6050403@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [dispatch] new charter version for Session-id
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 13:22:00 -0000

On 10/07/2011 07:50 AM, Salvatore Loreto wrote:
> in Quebec we got a strong consensus on moving the Session-ID work
> forward, but in order to do so we have been asked to work on
> improving the charter so to make more clear and focused the aim of
> the mini-working group.
>
> Together with all the proponents of the initial charter [1] we have
> worked on it and we hope it now satisfy all the concerns we listened
> as well as all the questions/feedback we got during the Quebec
> presentation. (the charter is below)
>
> comments and feedback are really welcome

Sal: Charter reads good.

One minor question --- in the first paragraph it is stated that the e2e
session identifier can be used to "identify and correlate SIP messages
and dialogs of the same higher-level end-to-end "communication session"
across multiple SIP devices and hops."

Any specific reason why the latter part of the sentence does not read
as "... across multiple SIP devices, hops, and administrative domains."?

IIRC, when we were having the session identifier discussions in SIPCLF,
one of the motivating factors that came up was the continued tracing
of a SIP call based on such an identifier when the session leaves
one administrative domain and enters another.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From salvatore.loreto@ericsson.com  Fri Oct  7 06:31:27 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEA821F8B83 for ; Fri,  7 Oct 2011 06:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.571
X-Spam-Level: 
X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prFm2af5A209 for ; Fri,  7 Oct 2011 06:31:23 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB1B21F8B7F for ; Fri,  7 Oct 2011 06:31:23 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-4f-4e8effec39f8
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D0.83.20773.CEFFE8E4; Fri,  7 Oct 2011 15:34:36 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 15:34:36 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id B8F67245F	for ; Fri,  7 Oct 2011 16:34:35 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 84650517F7	for ; Fri,  7 Oct 2011 16:34:35 +0300 (EEST)
Received: from n211.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3B6D0517F6	for ; Fri,  7 Oct 2011 16:34:35 +0300 (EEST)
Message-ID: <4E8EFFEA.5070605@ericsson.com>
Date: Fri, 7 Oct 2011 16:34:34 +0300
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4E8EF582.6050403@ericsson.com> <4E8EFE52.1020402@bell-labs.com>
In-Reply-To: <4E8EFE52.1020402@bell-labs.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] new charter version for Session-id
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 13:31:27 -0000

On 10/7/11 4:27 PM, Vijay K. Gurbani wrote:
> On 10/07/2011 07:50 AM, Salvatore Loreto wrote:
>> in Quebec we got a strong consensus on moving the Session-ID work
>> forward, but in order to do so we have been asked to work on
>> improving the charter so to make more clear and focused the aim of
>> the mini-working group.
>>
>> Together with all the proponents of the initial charter [1] we have
>> worked on it and we hope it now satisfy all the concerns we listened
>> as well as all the questions/feedback we got during the Quebec
>> presentation. (the charter is below)
>>
>> comments and feedback are really welcome
> Sal: Charter reads good.
>
> One minor question --- in the first paragraph it is stated that the e2e
> session identifier can be used to "identify and correlate SIP messages
> and dialogs of the same higher-level end-to-end "communication session"
> across multiple SIP devices and hops."
>
> Any specific reason why the latter part of the sentence does not read
> as "... across multiple SIP devices, hops, and administrative domains."?

that is a good point, I thought was implicit
but you are right that should be stated clearly in that sentence.
I am be happy to include explicitly "and administrative domains" in the 
next update

cheers
/Sal
>
> IIRC, when we were having the session identifier discussions in SIPCLF,
> one of the motivating factors that came up was the continued tracing
> of a SIP call based on such an identifier when the session leaves
> one administrative domain and enters another.
>
> Thanks,
>
> - vijay


-- 
Salvatore Loreto
www.sloreto.com


From gonzalo.camarillo@ericsson.com  Fri Oct  7 06:52:15 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531C321F84D7 for ; Fri,  7 Oct 2011 06:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.694
X-Spam-Level: 
X-Spam-Status: No, score=-105.694 tagged_above=-999 required=5 tests=[AWL=0.905, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7Qtixde5nov for ; Fri,  7 Oct 2011 06:52:14 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0D15021F851F for ; Fri,  7 Oct 2011 06:52:06 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-05-4e8f04c7b004
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BD.B6.20773.7C40F8E4; Fri,  7 Oct 2011 15:55:20 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 15:55:19 +0200
Received: from [131.160.126.191] (rvi2-126-191.lmf.ericsson.se [131.160.126.191])	by mail.lmf.ericsson.se (Postfix) with ESMTP id B4B91245F for ; Fri,  7 Oct 2011 16:55:19 +0300 (EEST)
Message-ID: <4E8F04C6.4020602@ericsson.com>
Date: Fri, 7 Oct 2011 16:55:18 +0300
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: DISPATCH 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: [dispatch] DCON BOF
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 13:52:15 -0000

Folks,

if you have been following the DISPATCH list, you should already know
this... but anyway, there is going to be a BOF on distributed
conferencing (DCON) in Taipei. We have created a mailing list for it:

https://www.ietf.org/mailman/listinfo/dcon

Please, join if you are interested in this work.

Cheers,

Gonzalo

From fluffy@cisco.com  Fri Oct  7 07:48:45 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED0721F8997 for ; Fri,  7 Oct 2011 07:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.018
X-Spam-Level: 
X-Spam-Status: No, score=-103.018 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj7q-6DynoNE for ; Fri,  7 Oct 2011 07:48:41 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B25B021F8538 for ; Fri,  7 Oct 2011 07:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5219; q=dns/txt; s=iport; t=1317999115; x=1319208715; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=o0gB9yZBCyc5h2nHISMyHgASIwCgnLrJwTxiC7V9tgs=; b=hrgPrjUa5S3PVvFBNaslVx/8qUvDg/BKT1m3L2P6alES0XhM9rC6Zz0b NHhpHvjMwsXbjfB+G9PbHANIpxf6rkHBwKWK/xJlHIxLmiv9/gIAA40iY XSeEoZj8GHjOyq3QRZiScgUxvBpVcfcEVecl37IEmj/zrifJXpqJ8il9B Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAM8Rj06rRDoH/2dsb2JhbAA6Cqg9gQWBUwEBAQECARIBNjAFCwtGVwYKEhIHh1wHmhEBni+EBIJMYQSHfYtyhSiMPw
X-IronPort-AV: E=Sophos;i="4.68,502,1312156800";  d="scan'208";a="6507278"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 07 Oct 2011 14:51:53 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97EprZD002623; Fri, 7 Oct 2011 14:51:53 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Cullen Jennings 
In-Reply-To: <4E8EF582.6050403@ericsson.com>
Date: Fri, 7 Oct 2011 08:51:52 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4E8EF582.6050403@ericsson.com>
To: Salvatore Loreto 
X-Mailer: Apple Mail (2.1084)
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] new charter version for Session-id
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 14:48:45 -0000

With my chair hat on.=20

This charter is completely out of line with what we had consensus on at =
the last meeting - I am shocked to see it go and add in so many of the =
things which people clearly objected to on provisos discussions of this.=20=


I encourage you to read the charter you proposed in your slides at IETF =
81, read the minutes from the meetings, then give some thought to how =
you like to move this work forward.=20

As chair, I would like to formally state there is no consensus for a =
charter such as the one below. There was consensus for a the charter =
presented at IETF 81.=20

Cullen 

On Oct 7, 2011, at 6:50 AM, Salvatore Loreto wrote:

> Hi,
>=20
> in Quebec we got a strong consensus on moving the Session-ID work =
forward,
> but in order to do so we have been asked
> to work on improving the charter so to make more clear and focused the =
aim of the mini-working group.
>=20
> Together with all the proponents of the initial charter [1] we have =
worked on it
> and we hope it now satisfy all the concerns we listened as well as all =
the questions/feedback we got
> during the Quebec presentation.
> (the charter is below)
>=20
> comments and feedback are really welcome
>=20
> cheers
> /Sal
> --=20
> Salvatore Loreto
>=20
> www.sloreto.com
> [1] =
http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html
>=20
>=20
>=20
> End-to-end Session Identifier in SIP (NEW charter proposal)
> The end-to-end Session Identifier in SIP-based multimedia =
communication networks refers to the ability for endpoints, intermediary =
devices, management and monitoring system to identify and correlate SIP =
messages and dialogs of the same higher-level end-to-end "communication =
session" across multiple SIP devices and hops.
>=20
> Unfortunately, there are a number of factors that contribute to the =
fact that the current dialog identifiers defined in SIP are not suitable =
for end-to-end session identification.  Perhaps the most important =
factor worth describing is that in real-world deployments devices like =
Back-to-Back User Agents (B2BUAs) often change the call identifiers =
(e.g., the From-tag and To-tag that are used in conjunction with the =
Call-ID header to make the dialog-id) as the session signaling passes =
through.
>=20
> An end-to-end Session Identifier aims to identify a Dialog (as defined =
in RFC 3261 Section 5), but does so in such a way as to overcome the =
limitations of the present means of Dialog identification.  The Session =
Identifier allows for the possibility of uniquely identifying the =
communication session from the originating endpoint, passing through any =
number of intermediaries, to the terminating endpoint.  The Session =
Identifier will address issues related to transferring or forwarding of =
sessions, as well as changes during mid-call of either of the endpoints =
by an intermediary (e.g., =93joining=94 two calls at a B2BUA).
>=20
> As for Dialogs, an end-to-end Session Identifier should be =93created =
through the generation of non-failure responses to requests with =
specific methods=94 (RFC 3261 Section 12.1).  That said, the end-to-end =
Session Identifier may change if an endpoint receives an INVITE or other =
request indicating through some means that the remote endpoint has =
changed.  This may occur, for example, when a B2BUA performs a call =
=93join=94 or otherwise re-routes one end of the communication session.  =
Taking note of such changes is important to ensure a new end-to-end =
Session Identifier can be constructed.
>=20
> Further, the Session Identifier must be constructed so that it may be =
used by other session control protocols, such as H.323 or XMPP, to =
improve interworking between protocols.  The ITU-T has identified a need =
for an end-to-end session Identifier and is progressing work to be =
aligned with the output of this Working Group.
>=20
> The end-to-end Session Identifier has been considered as possible =
solution to different use cases like media and signaling correlation, =
session tracking, troubleshooting, billing, session recording, and so =
forth. Some of these requirements have also been identified and come =
directly from other existing working group within the RAI area (e.g., =
SIPRec and Splices).  The requirements document shall deliver the =
possible scenarios where the Session Identifier would be used.
>=20
> This group will first focus on a document that will identify, collect =
and discuss all the requirements and use cases. Once the needs are clear =
and identified, the working group will specify the end-to-end Session =
Identifier mechanism.
>=20
> The working group will produce the following deliverables:
>=20
> 1. A requirement and use case document with key consideration for SIP =
Session End-to-End Identification
>=20
> 2. Specification of new end-to-end Session Identifier mechanism
>=20
> Goal and Milestone:
>=20
> March 2012 - Requirement and use case document sent to the IESG =
(Information)
>=20
> November 2012 =96 Specification of the new mechanism sent to the IESG
>=20
>  =20


From pkyzivat@alum.mit.edu  Fri Oct  7 08:02:12 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3659C21F8531 for ; Fri,  7 Oct 2011 08:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SP8Gp+PpPRc for ; Fri,  7 Oct 2011 08:02:11 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2610521F8548 for ; Fri,  7 Oct 2011 08:02:10 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta01.westchester.pa.mail.comcast.net with comcast id hmUR1h0021wpRvQ51r5Rml; Fri, 07 Oct 2011 15:05:25 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta18.westchester.pa.mail.comcast.net with comcast id hr5Q1h00D0tdiYw3er5QKh; Fri, 07 Oct 2011 15:05:25 +0000
Message-ID: <4E8F1532.8010908@alum.mit.edu>
Date: Fri, 07 Oct 2011 11:05:22 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4E8EF582.6050403@ericsson.com>
In-Reply-To: <4E8EF582.6050403@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [dispatch] new charter version for Session-id
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 15:02:12 -0000

I like this charter.

Given the diversity of aspirations, I fear it will be difficult to find 
a single solution. But neither am I fond of introducing multiple 
mechanisms. But I remain open minded that after digging in to this it 
will be possible to come up with something useful.

	Thanks,
	Paul

On 10/7/11 8:50 AM, Salvatore Loreto wrote:
> Hi,
>
> in Quebec we got a strong consensus on moving the Session-ID work forward,
> but in order to do so we have been asked
> to work on improving the charter so to make more clear and focused the
> aim of the mini-working group.
>
> Together with all the proponents of the initial charter [1] we have
> worked on it
> and we hope it now satisfy all the concerns we listened as well as all
> the questions/feedback we got
> during the Quebec presentation.
> (the charter is below)
>
> comments and feedback are really welcome

> cheers
> /Sal
>
> --
> Salvatore Loreto
> www.sloreto.com
>
> [1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html
> _
>
>
> End-to-end Session Identifier in SIP (NEW charter proposal)_
>
> The end-to-end Session Identifier in SIP-based multimedia communication
> networks refers to the ability for endpoints, intermediary devices,
> management and monitoring system to identify and correlate SIP messages
> and dialogs of the same higher-level end-to-end "communication session"
> across multiple SIP devices and hops.
>
> Unfortunately, there are a number of factors that contribute to the fact
> that the current dialog identifiers defined in SIP are not suitable for
> end-to-end session identification.Perhaps the most important factor
> worth describing is that in real-world deployments devices like
> Back-to-Back User Agents (B2BUAs) often change the call identifiers
> (e.g., the From-tag and To-tag that are used in conjunction with the
> Call-ID header to make the dialog-id) as the session signaling passes
> through.
>
> An end-to-end Session Identifier aims to identify a Dialog (as defined
> in RFC 3261 Section 5), but does so in such a way as to overcome the
> limitations of the present means of Dialog identification.The Session
> Identifier allows for the possibility of uniquely identifying the
> communication session from the originating endpoint, passing through any
> number of intermediaries, to the terminating endpoint. The Session
> Identifier will address issues related to transferring or forwarding of
> sessions, as well as changes during mid-call of either of the endpoints
> by an intermediary (e.g., “joining” two calls at a B2BUA).
>
> As for Dialogs, an end-to-end Session Identifier should be “created
> through the generation of non-failure responses to requests with
> specific methods” (RFC 3261 Section 12.1).That said, the end-to-end
> Session Identifier may change if an endpoint receives an INVITE or other
> request indicating through some means that the remote endpoint has
> changed.This may occur, for example, when a B2BUA performs a call “join”
> or otherwise re-routes one end of the communication session.Taking note
> of such changes is important to ensure a new end-to-end Session
> Identifier can be constructed.
>
> Further, the Session Identifier must be constructed so that it may be
> used by other session control protocols, such as H.323 or XMPP, to
> improve interworking between protocols.The ITU-T has identified a need
> for an end-to-end session Identifier and is progressing work to be
> aligned with the output of this Working Group.
>
> The end-to-end Session Identifier has been considered as possible
> solution to different use cases like media and signaling correlation,
> session tracking, troubleshooting, billing, session recording, and so
> forth. Some of these requirements have also been identified and come
> directly from other existing working group within the RAI area (e.g.,
> SIPRec and Splices). The requirements document shall deliver the
> possible scenarios where the Session Identifier would be used.
>
> This group will first focus on a document that will identify, collect
> and discuss all the requirements and use cases. Once the needs are clear
> and identified, the working group will specify the end-to-end Session
> Identifier mechanism.
>
> The working group will produce the following deliverables:
>
> 1. A requirement and use case document with key consideration for SIP
> Session End-to-End Identification
>
> 2. Specification of new end-to-end Session Identifier mechanism
>
> Goal and Milestone:
>
> March 2012 - Requirement and use case document sent to the IESG
> (Information)
>
> November 2012 – Specification of the new mechanism sent to the IESG
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From adam@nostrum.com  Fri Oct  7 08:32:26 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F58321F8AD2 for ; Fri,  7 Oct 2011 08:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.387
X-Spam-Level: 
X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFiMuB7-n7xe for ; Fri,  7 Oct 2011 08:32:21 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA221F84BB for ; Fri,  7 Oct 2011 08:32: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 p97FZUHU065483 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 7 Oct 2011 10:35:31 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4E8F1C42.3010803@nostrum.com>
Date: Fri, 07 Oct 2011 10:35:30 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Cullen Jennings 
References: <4E8EF582.6050403@ericsson.com> 
In-Reply-To: 
Content-Type: multipart/mixed; boundary="------------040904000006060207070401"
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] new charter version for Session-id
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 15:32:26 -0000

This is a multi-part message in MIME format.
--------------040904000006060207070401
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit


To aid in the discussion, I've attached a file that highlights the diffs 
between the charter we talked about in Quebec and the one Salvatore sent 
out today.

Cullen: can you point to the changes that you believe contravene the 
consensus in the room?

On a separate note, the charter remains silent on whether calls 
involving three or more parties are in scope. The current text is 
schizophrenic on the topic. In places, it strongly implies a model of 
one originating endpoint, multiple intermediaries, and one terminating 
endpoint. In others, it discusses the use of the "join" primitive, which 
implies conferencing.

Regardless of intention, whether conference calls are in scope need to 
be explicitly stated in the charter rather than merely being implied. 
What I heard in Quebec was as assertion that the work would be 
addressing the two-party situation, rather than the (possibly 
intractable) general problem of conferencing.

/a

On 10/7/11 9:51 AM, Cullen Jennings wrote:
> With my chair hat on.
>
> This charter is completely out of line with what we had consensus on at the last meeting - I am shocked to see it go and add in so many of the things which people clearly objected to on provisos discussions of this.
>
> I encourage you to read the charter you proposed in your slides at IETF 81, read the minutes from the meetings, then give some thought to how you like to move this work forward.
>
> As chair, I would like to formally state there is no consensus for a charter such as the one below. There was consensus for a the charter presented at IETF 81.
>
> Cullen
>
> On Oct 7, 2011, at 6:50 AM, Salvatore Loreto wrote:
>
>> Hi,
>>
>> in Quebec we got a strong consensus on moving the Session-ID work forward,
>> but in order to do so we have been asked
>> to work on improving the charter so to make more clear and focused the aim of the mini-working group.
>>
>> Together with all the proponents of the initial charter [1] we have worked on it
>> and we hope it now satisfy all the concerns we listened as well as all the questions/feedback we got
>> during the Quebec presentation.
>> (the charter is below)
>>
>> comments and feedback are really welcome
>>
>> cheers
>> /Sal
>> -- 
>> Salvatore Loreto
>>
>> www.sloreto.com
>> [1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html
>>
>>
>>
>> End-to-end Session Identifier in SIP (NEW charter proposal)
>> The end-to-end Session Identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediary devices, management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices and hops.
>>
>> Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification.  Perhaps the most important factor worth describing is that in real-world deployments devices like Back-to-Back User Agents (B2BUAs) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through.
>>
>> An end-to-end Session Identifier aims to identify a Dialog (as defined in RFC 3261 Section 5), but does so in such a way as to overcome the limitations of the present means of Dialog identification.  The Session Identifier allows for the possibility of uniquely identifying the communication session from the originating endpoint, passing through any number of intermediaries, to the terminating endpoint.  The Session Identifier will address issues related to transferring or forwarding of sessions, as well as changes during mid-call of either of the endpoints by an intermediary (e.g., “joining” two calls at a B2BUA).
>>
>> As for Dialogs, an end-to-end Session Identifier should be “created through the generation of non-failure responses to requests with specific methods” (RFC 3261 Section 12.1).  That said, the end-to-end Session Identifier may change if an endpoint receives an INVITE or other request indicating through some means that the remote endpoint has changed.  This may occur, for example, when a B2BUA performs a call “join” or otherwise re-routes one end of the communication session.  Taking note of such changes is important to ensure a new end-to-end Session Identifier can be constructed.
>>
>> Further, the Session Identifier must be constructed so that it may be used by other session control protocols, such as H.323 or XMPP, to improve interworking between protocols.  The ITU-T has identified a need for an end-to-end session Identifier and is progressing work to be aligned with the output of this Working Group.
>>
>> The end-to-end Session Identifier has been considered as possible solution to different use cases like media and signaling correlation, session tracking, troubleshooting, billing, session recording, and so forth. Some of these requirements have also been identified and come directly from other existing working group within the RAI area (e.g., SIPRec and Splices).  The requirements document shall deliver the possible scenarios where the Session Identifier would be used.
>>
>> This group will first focus on a document that will identify, collect and discuss all the requirements and use cases. Once the needs are clear and identified, the working group will specify the end-to-end Session Identifier mechanism.
>>
>> The working group will produce the following deliverables:
>>
>> 1. A requirement and use case document with key consideration for SIP Session End-to-End Identification
>>
>> 2. Specification of new end-to-end Session Identifier mechanism
>>
>> Goal and Milestone:
>>
>> March 2012 - Requirement and use case document sent to the IESG (Information)
>>
>> November 2012 – Specification of the new mechanism sent to the IESG
>>
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


--------------040904000006060207070401
Content-Type: text/html;
 name="session-id-charter-diff.html"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="session-id-charter-diff.html"

wdiff v1.txt v2.txt

End-to-endSession Identifier in SIP (charter proposal ) (NEW charter proposal)
----------------------------------------------

The end-to-end Session Identifier in an SIP-based multimedia communication
networks refers to the ability for endpoints, intermediate intermediary devices, and
management and monitoring system to identify and correlate SIP
messages and dialogs of the same higher-level end-to-end "communication
session" across multiple SIP devices and hops.

Unfortunately, there are a number of factors that contribute to the
fact that the current dialog identifiers as defined in SIP is are not
suitable for end-to-end session identification.  Perhaps the most
important factor worth describing is that in real-world deployments
devices like Session Border Controllers (SBC) Back-to-Back User Agents (B2BUAs) often change the
current
call identifiers (e.g., the From-tag and To-tag that are used in
conjunction with the Call-ID header to make the dialog-id) as the
session signaling passes through.

An end-to-end Session Identifier should allow the possibility aims to identify a Dialog (as
defined in RFC 3261 Section 5), but does so in such a way as to
overcome the limitations of the present means of Dialog identification.
The Session Identifier allows for the possibility of uniquely
identifying the communication session from the point of origin, originating endpoint,
passing through any number of intermediaries, to the ultimate point terminating
endpoint.  The Session Identifier will address issues related to
transferring or forwarding of
termination. It should have the same aim sessions, as well as changes during
mid-call of either of the From-tag, To-tag
and Call-ID conjunction, but endpoints by an intermediary (e.g.,
“joining†two calls at a B2BUA).

As for Dialogs, an end-to-end Session Identifier should not be mangled “created
through the generation of non-failure responses to requests with
specific methods†(RFC 3261 Section 12.1).  That said, the end-to-end
Session Identifier may change if an endpoint receives an INVITE or
other request indicating through some means that the remote endpoint
has changed.  This may occur, for example, when a B2BUA performs a
call “join†or otherwise re-routes one end of the communication
session.  Taking note of such changes is important to ensure a new
end-to-end Session Identifier can be constructed.

Further, the Session Identifier must be constructed so that it may
be used by intermediaries.


A SIP other session control protocols, such as H.323 or XMPP,
to improve interworking between protocols.  The ITU-T has identified
a need for an end-to-end session Identifier and is progressing work
to be aligned with the output of this Working Group.

The end-to-end Session Identifier has been considered as possible
solution of to different use cases like troubleshooting, billing,
session tracking, session recording, media and signaling correlation,
session tracking, troubleshooting, billing, session recording, and
so forth. Some of these requirements have also been identified and
come directly from other existing working group within the RAI area (e.g. SIPRec, Splices).


Moreover, other SDOs have identified the need for SIP
(e.g., SIPRec and H.323 to
carry Splices).  The requirements document shall deliver
the same "session ID" value(s) so that it is possible identify
a call end-to end even when performing inter working between
protocols. scenarios where the Session Identifier would be used.

This group will first focus on a document that will identify, collect
and discuss all the requirements and the use cases that have been
identified.  The document may identify the possibility to design a
general mechanism or the need to design multiple purpose built
identifiers. cases. Once the needs are
clear and identified, the working group will specify the mechanism(s).


Specifically, the proposed end-to-end
Session Identifier mechanism.

The working group will develop produce the following
deliverable: deliverables:

1. A requirement and use case document with key consideration for
SIP Session End-to-End identifier. The document will discuss
    the possibility of designing a general mechanism or the needs
    to design multiple purpose build identifier. Identification

2. Specification of new mechanism(s). end-to-end Session Identifier mechanism

Goal and Milestone:
    October 2011

March 2012 - Requirement and use case document sent to the IESG
(Information) November 2012 – Specification of the new mechanism
sent to the IESG




--------------040904000006060207070401--

From salvatore.loreto@ericsson.com  Fri Oct  7 09:27:04 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2A321F8560 for ; Fri,  7 Oct 2011 09:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.572
X-Spam-Level: 
X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BZ001-oosa7 for ; Fri,  7 Oct 2011 09:27:03 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1973621F8669 for ; Fri,  7 Oct 2011 09:27:02 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-78-4e8f29179cbd
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A9.58.20773.7192F8E4; Fri,  7 Oct 2011 18:30:15 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 18:30:14 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id CCD8D245F; Fri,  7 Oct 2011 19:30:14 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 95B1F517FB; Fri,  7 Oct 2011 19:30:14 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2346550A1D; Fri,  7 Oct 2011 19:30:14 +0300 (EEST)
Message-ID: <4E8F2915.9030709@ericsson.com>
Date: Fri, 7 Oct 2011 19:30:13 +0300
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Adam Roach 
References: <4E8EF582.6050403@ericsson.com>  <4E8F1C42.3010803@nostrum.com>
In-Reply-To: <4E8F1C42.3010803@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] new charter version for Session-id
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 16:27:04 -0000

On 10/7/11 6:35 PM, Adam Roach wrote:
> To aid in the discussion, I've attached a file that highlights the diffs
> between the charter we talked about in Quebec and the one Salvatore sent
> out today.
>
> Cullen: can you point to the changes that you believe contravene the
> consensus in the room?
>
> On a separate note, the charter remains silent on whether calls
> involving three or more parties are in scope. The current text is
> schizophrenic on the topic. In places, it strongly implies a model of
> one originating endpoint, multiple intermediaries, and one terminating
> endpoint. In others, it discusses the use of the "join" primitive, which
> implies conferencing.
>
> Regardless of intention, whether conference calls are in scope need to
> be explicitly stated in the charter rather than merely being implied.
> What I heard in Quebec was as assertion that the work would be
> addressing the two-party situation, rather than the (possibly
> intractable) general problem of conferencing.
the work we have done on the charter is to focus it to address only the 
two-party situation...
I agree that the example involving "join" is quite misleading we should 
clarify it or remove the related
text, so the make the charter less schizophrenic.

We can state more explicitly that it focus exclusively on the two-party 
scenario

cheers
/Sal


>
> /a
>
> On 10/7/11 9:51 AM, Cullen Jennings wrote:
>> With my chair hat on.
>>
>> This charter is completely out of line with what we had consensus on at the last meeting - I am shocked to see it go and add in so many of the things which people clearly objected to on provisos discussions of this.
>>
>> I encourage you to read the charter you proposed in your slides at IETF 81, read the minutes from the meetings, then give some thought to how you like to move this work forward.
>>
>> As chair, I would like to formally state there is no consensus for a charter such as the one below. There was consensus for a the charter presented at IETF 81.
>>
>> Cullen
>>
>> On Oct 7, 2011, at 6:50 AM, Salvatore Loreto wrote:
>>
>>> Hi,
>>>
>>> in Quebec we got a strong consensus on moving the Session-ID work forward,
>>> but in order to do so we have been asked
>>> to work on improving the charter so to make more clear and focused the aim of the mini-working group.
>>>
>>> Together with all the proponents of the initial charter [1] we have worked on it
>>> and we hope it now satisfy all the concerns we listened as well as all the questions/feedback we got
>>> during the Quebec presentation.
>>> (the charter is below)
>>>
>>> comments and feedback are really welcome
>>>
>>> cheers
>>> /Sal
>>> -- 
>>> Salvatore Loreto
>>>
>>> www.sloreto.com
>>> [1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html
>>>
>>>
>>>
>>> End-to-end Session Identifier in SIP (NEW charter proposal)
>>> The end-to-end Session Identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediary devices, management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices and hops.
>>>
>>> Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification.  Perhaps the most important factor worth describing is that in real-world deployments devices like Back-to-Back User Agents (B2BUAs) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through.
>>>
>>> An end-to-end Session Identifier aims to identify a Dialog (as defined in RFC 3261 Section 5), but does so in such a way as to overcome the limitations of the present means of Dialog identification.  The Session Identifier allows for the possibility of uniquely identifying the communication session from the originating endpoint, passing through any number of intermediaries, to the terminating endpoint.  The Session Identifier will address issues related to transferring or forwarding of sessions, as well as changes during mid-call of either of the endpoints by an intermediary (e.g., “joining” two calls at a B2BUA).
>>>
>>> As for Dialogs, an end-to-end Session Identifier should be “created through the generation of non-failure responses to requests with specific methods” (RFC 3261 Section 12.1).  That said, the end-to-end Session Identifier may change if an endpoint receives an INVITE or other request indicating through some means that the remote endpoint has changed.  This may occur, for example, when a B2BUA performs a call “join” or otherwise re-routes one end of the communication session.  Taking note of such changes is important to ensure a new end-to-end Session Identifier can be constructed.
>>>
>>> Further, the Session Identifier must be constructed so that it may be used by other session control protocols, such as H.323 or XMPP, to improve interworking between protocols.  The ITU-T has identified a need for an end-to-end session Identifier and is progressing work to be aligned with the output of this Working Group.
>>>
>>> The end-to-end Session Identifier has been considered as possible solution to different use cases like media and signaling correlation, session tracking, troubleshooting, billing, session recording, and so forth. Some of these requirements have also been identified and come directly from other existing working group within the RAI area (e.g., SIPRec and Splices).  The requirements document shall deliver the possible scenarios where the Session Identifier would be used.
>>>
>>> This group will first focus on a document that will identify, collect and discuss all the requirements and use cases. Once the needs are clear and identified, the working group will specify the end-to-end Session Identifier mechanism.
>>>
>>> The working group will produce the following deliverables:
>>>
>>> 1. A requirement and use case document with key consideration for SIP Session End-to-End Identification
>>>
>>> 2. Specification of new end-to-end Session Identifier mechanism
>>>
>>> Goal and Milestone:
>>>
>>> March 2012 - Requirement and use case document sent to the IESG (Information)
>>>
>>> November 2012 – Specification of the new mechanism sent to the IESG
>>>
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch

From davecruse1@hotmail.com  Fri Oct  7 11:47:15 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBFE21F87C5 for ; Fri,  7 Oct 2011 11:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lP2j9xOcdCF for ; Fri,  7 Oct 2011 11:47:15 -0700 (PDT)
Received: from blu0-omc4-s36.blu0.hotmail.com (blu0-omc4-s36.blu0.hotmail.com [65.55.111.175]) by ietfa.amsl.com (Postfix) with ESMTP id 406B921F87C9 for ; Fri,  7 Oct 2011 11:47:15 -0700 (PDT)
Received: from BLU161-W24 ([65.55.111.136]) by blu0-omc4-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 7 Oct 2011 11:50:29 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_a892f369-6029-43ea-adc5-81888b164532_"
X-Originating-IP: [122.178.207.168]
From: dave Cruse 
To: 
Date: Fri, 7 Oct 2011 18:50:28 +0000
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Oct 2011 18:50:29.0143 (UTC) FILETIME=[FBC6DA70:01CC8521]
Subject: Re: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 18:47:16 -0000

--_a892f369-6029-43ea-adc5-81888b164532_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


I have one concern in the draft.=20
As pointed out by John Elwell=2C =93playing an announcement to Caller for H=
OLDING call for another few min=2C in case the CALL is URGENT=94 doesn=92t =
works here ??

Regards=2C
Dave
 		 	   		  =

--_a892f369-6029-43ea-adc5-81888b164532_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







I have one concern in the draft. 
As pointed out by John Elwell=2C =93pl=
aying an announcement to Caller for HOLDING call for another few min=2C in =
case the CALL is URGENT=94 doesn=92t works here ??

Regards=2C
Dav=
e
 		 	   		  

=

--_a892f369-6029-43ea-adc5-81888b164532_--

From jmpolk@cisco.com  Fri Oct  7 12:42:09 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8C21F853A for ; Fri,  7 Oct 2011 12:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.143
X-Spam-Level: 
X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrHUPcw2kF2C for ; Fri,  7 Oct 2011 12:42:08 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 48BB321F851A for ; Fri,  7 Oct 2011 12:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=7677; q=dns/txt; s=iport; t=1318016722; x=1319226322; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=yTS0YwAWJHVfQEzVNguT/lww+sBzgnBt8DVUUOctRcc=; b=OC6G7st6qItQ+qUmFDnjkE0EGeWSmrkv+MMpfUg/KfRSdw6AM6STfqRa xNN73CygHicS1j6Ln1fC4eO8qHz5UzA48CFcrXK6N2PySDXmQzJXcAOyC YkVao2qJJruveUKFBO7rg0qDgeT3TwMfn3XHe6rgTo0DfCBWkFYdfM8Ik 8=;
X-IronPort-AV: E=Sophos;i="4.68,503,1312156800";  d="scan'208";a="6616530"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Oct 2011 19:45:22 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p97JjM3q009501; Fri, 7 Oct 2011 19:45:22 GMT
Message-Id: <201110071945.p97JjM3q009501@mtv-core-4.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 07 Oct 2011 14:45:20 -0500
To: Adam Roach , Cullen Jennings 
From: "James M. Polk" 
In-Reply-To: <4E8F1C42.3010803@nostrum.com>
References: <4E8EF582.6050403@ericsson.com>  <4E8F1C42.3010803@nostrum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] new charter version for Session-id
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Oct 2011 19:42:09 -0000

At 10:35 AM 10/7/2011, Adam Roach wrote:

>To aid in the discussion, I've attached a file=20
>that highlights the diffs between the charter we=20
>talked about in Quebec and the one Salvatore sent out today.

Adam - and remember, the 81 charter severely=20
deviated from the presentation of the slides - or=20
the slides the presenter was given by "the group=20
working on this" at the time, so I'm not sure=20
which way this effort is going now (spoken as the=20
loudest/firmest voice at the mic in Quebec).


>Cullen: can you point to the changes that you=20
>believe contravene the consensus in the room?
>
>On a separate note, the charter remains silent=20
>on whether calls involving three or more parties=20
>are in scope. The current text is schizophrenic=20
>on the topic. In places, it strongly implies a=20
>model of one originating endpoint, multiple=20
>intermediaries, and one terminating endpoint. In=20
>others, it discusses the use of the "join"=20
>primitive, which implies conferencing.
>
>Regardless of intention, whether conference=20
>calls are in scope need to be explicitly stated=20
>in the charter rather than merely being implied.

Clearly this is a mistake and needs to be called=20
out explicitly, and I would prefer a goal (but=20
not a mandatory solution containing) of=20
addressing conferencing. In other words, if we=20
come up with a solution that can address=20
conferencing, include it - but don't hold the=20
work back because we can't solve for conferencing.

James

>What I heard in Quebec was as assertion that the=20
>work would be addressing the two-party=20
>situation, rather than the (possibly=20
>intractable) general problem of conferencing.
>
>/a
>
>On 10/7/11 9:51 AM, Cullen Jennings wrote:
>>With my chair hat on.
>>
>>This charter is completely out of line with=20
>>what we had consensus on at the last meeting -=20
>>I am shocked to see it go and add in so many of=20
>>the things which people clearly objected to on provisos discussions of=
 this.
>>
>>I encourage you to read the charter you=20
>>proposed in your slides at IETF 81, read the=20
>>minutes from the meetings, then give some=20
>>thought to how you like to move this work forward.
>>
>>As chair, I would like to formally state there=20
>>is no consensus for a charter such as the one=20
>>below. There was consensus for a the charter presented at IETF 81.
>>
>>Cullen
>>
>>On Oct 7, 2011, at 6:50 AM, Salvatore Loreto wrote:
>>
>>>Hi,
>>>
>>>in Quebec we got a strong consensus on moving the Session-ID work=
 forward,
>>>but in order to do so we have been asked
>>>to work on improving the charter so to make=20
>>>more clear and focused the aim of the mini-working group.
>>>
>>>Together with all the proponents of the=20
>>>initial charter [1] we have worked on it
>>>and we hope it now satisfy all the concerns we=20
>>>listened as well as all the questions/feedback we got
>>>during the Quebec presentation.
>>>(the charter is below)
>>>
>>>comments and feedback are really welcome
>>>
>>>cheers
>>>/Sal
>>>--
>>>Salvatore Loreto
>>>
>>>www.sloreto.com
>>>[1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html
>>>
>>>
>>>
>>>End-to-end Session Identifier in SIP (NEW charter proposal)
>>>The end-to-end Session Identifier in SIP-based=20
>>>multimedia communication networks refers to=20
>>>the ability for endpoints, intermediary=20
>>>devices, management and monitoring system to=20
>>>identify and correlate SIP messages and=20
>>>dialogs of the same higher-level end-to-end=20
>>>"communication session" across multiple SIP devices and hops.
>>>
>>>Unfortunately, there are a number of factors=20
>>>that contribute to the fact that the current=20
>>>dialog identifiers defined in SIP are not=20
>>>suitable for end-to-end session=20
>>>identification.  Perhaps the most important=20
>>>factor worth describing is that in real-world=20
>>>deployments devices like Back-to-Back User=20
>>>Agents (B2BUAs) often change the call=20
>>>identifiers (e.g., the From-tag and To-tag=20
>>>that are used in conjunction with the Call-ID=20
>>>header to make the dialog-id) as the session signaling passes through.
>>>
>>>An end-to-end Session Identifier aims to=20
>>>identify a Dialog (as defined in RFC 3261=20
>>>Section 5), but does so in such a way as to=20
>>>overcome the limitations of the present means=20
>>>of Dialog identification.  The Session=20
>>>Identifier allows for the possibility of=20
>>>uniquely identifying the communication session=20
>>>from the originating endpoint, passing through=20
>>>any number of intermediaries, to the=20
>>>terminating endpoint.  The Session Identifier=20
>>>will address issues related to transferring or=20
>>>forwarding of sessions, as well as changes=20
>>>during mid-call of either of the endpoints by=20
>>>an intermediary (e.g., =93joining=94 two calls at a B2BUA).
>>>
>>>As for Dialogs, an end-to-end Session=20
>>>Identifier should be =93created through the=20
>>>generation of non-failure responses to=20
>>>requests with specific methods=94 (RFC 3261=20
>>>Section 12.1).  That said, the end-to-end=20
>>>Session Identifier may change if an endpoint=20
>>>receives an INVITE or other request indicating=20
>>>through some means that the remote endpoint=20
>>>has changed.  This may occur, for example,=20
>>>when a B2BUA performs a call =93join=94 or=20
>>>otherwise re-routes one end of the=20
>>>communication session.  Taking note of such=20
>>>changes is important to ensure a new=20
>>>end-to-end Session Identifier can be constructed.
>>>
>>>Further, the Session Identifier must be=20
>>>constructed so that it may be used by other=20
>>>session control protocols, such as H.323 or=20
>>>XMPP, to improve interworking between=20
>>>protocols.  The ITU-T has identified a need=20
>>>for an end-to-end session Identifier and is=20
>>>progressing work to be aligned with the output of this Working Group.
>>>
>>>The end-to-end Session Identifier has been=20
>>>considered as possible solution to different=20
>>>use cases like media and signaling=20
>>>correlation, session tracking,=20
>>>troubleshooting, billing, session recording,=20
>>>and so forth. Some of these requirements have=20
>>>also been identified and come directly from=20
>>>other existing working group within the RAI=20
>>>area (e.g., SIPRec and Splices).  The=20
>>>requirements document shall deliver the=20
>>>possible scenarios where the Session Identifier would be used.
>>>
>>>This group will first focus on a document that=20
>>>will identify, collect and discuss all the=20
>>>requirements and use cases. Once the needs are=20
>>>clear and identified, the working group will=20
>>>specify the end-to-end Session Identifier mechanism.
>>>
>>>The working group will produce the following deliverables:
>>>
>>>1. A requirement and use case document with=20
>>>key consideration for SIP Session End-to-End Identification
>>>
>>>2. Specification of new end-to-end Session Identifier mechanism
>>>
>>>Goal and Milestone:
>>>
>>>March 2012 - Requirement and use case document=20
>>>sent to the IESG (Information)
>>>
>>>November 2012 =AD Specification of the new mechanism sent to the IESG
>>>
>>_______________________________________________
>>dispatch mailing list
>>dispatch@ietf.org
>>https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>
>_______________________________________________
>dispatch mailing list
>dispatch@ietf.org
>https://www.ietf.org/mailman/listinfo/dispatch


From amardeep_sinha@rediffmail.com  Fri Oct  7 23:05:27 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77F021F8B5A for ; Fri,  7 Oct 2011 23:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.969
X-Spam-Level: 
X-Spam-Status: No, score=0.969 tagged_above=-999 required=5 tests=[AWL=-0.738,  BAYES_50=0.001, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n346qiXRImeD for ; Fri,  7 Oct 2011 23:05:27 -0700 (PDT)
Received: from rediffmail.com (f5mail-224-168.rediffmail.com [114.31.224.168]) by ietfa.amsl.com (Postfix) with SMTP id 320AD21F8B50 for ; Fri,  7 Oct 2011 23:05:25 -0700 (PDT)
Received: (qmail 12555 invoked by uid 510); 8 Oct 2011 06:08:33 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=XZYqHS3yMGMm/8hOh7kgu2zQ3PSv6LjFEiB8B/EOyDShjwzo4M1r2vZonhv6xshBg+8I1yuJUQeJUOydMFmSz4xj7XYgrDQGs6ySkPEF4gxkEGTj2L8ttV6Bur+F9TP/bI4Fwf81vj1fRLDF3p9c3xBztZ4uPdB2Sv+kEPwUsRs= ; 
x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd;
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: : 0
X-CTCH-RefID: str=0001.0A150201.4E8FE8E3.003E,ss=1,re=0.000,fgs=0
X-REDF-OSEN: amardeep_sinha@rediffmail.com
Date: 8 Oct 2011 06:08:33 -0000
MIME-Version: 1.0
To: 
Received: from unknown 122.167.85.68 by rediffmail.com via HTTP; 08 Oct 2011 06:08:33 -0000
Message-ID: <1318013444.S.6535.28353.F.H.WWRhdmUgQ3J1c2UAUmU6IFtkaXNwYXRjaF0gTmV3IERyYWZ0IC0gZHJhZnQtc2luaGEtZGlzcGF0Y2gtc2k_.f5-224-147.old.1318054113.10640@webmail.rediffmail.com>
in-reply-to: 
From: "amar  deep" 
Content-Type: multipart/alternative; boundary="=_058a64180788295c533ccc149c870a58"
Cc: dispatch@ietf.org
Subject: Re: [dispatch] =?utf-8?q?New_Draft_-_draft-sinha-dispatch-sip-continu?= =?utf-8?q?ation-option?=
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 08 Oct 2011 06:05:28 -0000

--=_058a64180788295c533ccc149c870a58
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"

Hi Dave,

We see two blocking factor in in implementing announcement while CONTINUE message are exchanged instead of pop-up text message, as below:

1. The probability of caller, initiating a call, might be able to hear an announcement while pressing CALL button, or might fail to understand what announcement is played .

2. Secondly there might be the case, where call is made from one-region to another, and Caller mobile has set with LOCAL lingual format, for e.g. CHINES, in such a case, caller might not understand ANNOUNCEMENT is played in ENGLISH.

As a result, displaying Pop-up menu locally on the Mobile could resolve both blocking factor mentioned above. Even pop-up could be displayed on local-language as per setting on Phone.

Its upto the features on the mobile to READ and PLAY pop-up message of the mobile-handset.

Regards,
Amardeep


On Sat, 08 Oct 2011 00:20:44 +0530  wrote
>




I have one concern in the draft. 
As pointed out by John Elwell, �playing an announcement to Caller for HOLDING call for another few min, in case the CALL is URGENT� doesn�t works here ??

Regards,
Dave
 		 	   		  

_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch



Amar

--=_058a64180788295c533ccc149c870a58
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

Hi Dave,



We see two blocking factor in in implementing announcement while CONTINUE m=
essage are exchanged instead of pop-up text message, as below:



1. The probability of caller, initiating a call, might be able to hear an a=
nnouncement while pressing CALL button, or might fail to understand what an=
nouncement is played .



2. Secondly there might be the case, where call is made from one-region to =
another, and Caller mobile has set with LOCAL lingual format, for e.g. CHIN=
ES, in such a case, caller might not understand ANNOUNCEMENT is played in E=
NGLISH.



As a result, displaying Pop-up menu locally on the Mobile could resolve bot=
h blocking factor mentioned above. Even pop-up could be displayed on local-=
language as per setting on Phone.



Its upto the features on the mobile to READ and PLAY pop-up message of the =
mobile-handset.



Regards,

Amardeep





On Sat, 08 Oct 2011 00:20:44 +0530  wrote

>









I have one concern in the draft. 

As pointed out by John Elwell, =EF=BF=BDplaying an announcement to Caller f=
or HOLDING call for another few min, in case the CALL is URGENT=EF=BF=BD do=
esn=EF=BF=BDt works here ??



Regards,

Dave

 		 	   		  



_______________________________________________



dispatch mailing list



dispatch@ietf.org



https://www.ietf.org/mailman/listinfo/dispatch





Amar



Treat yourself at a restaurant, sp=
a, resort and much more with Rediff De=
al ho jaye!
--=_058a64180788295c533ccc149c870a58--

From spromano@unina.it  Tue Oct 11 06:37:02 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBBB21F8BF7; Tue, 11 Oct 2011 06:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.719
X-Spam-Level: 
X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSWxAPjo2F-M; Tue, 11 Oct 2011 06:37:01 -0700 (PDT)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 037DF21F8BEF; Tue, 11 Oct 2011 06:37:00 -0700 (PDT)
Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p9BDanbp003334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 15:36:50 +0200
Message-ID: <4E94466F.8060905@unina.it>
Date: Tue, 11 Oct 2011 15:36:47 +0200
From: Simon Pietro Romano 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: dcon@ietf.org
Content-Type: multipart/mixed; boundary="------------040609010807020909040702"
Cc: DISPATCH 
Subject: [dispatch] Updated BOF description for DCON
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 13:37:02 -0000

This is a multi-part message in MIME format.
--------------040609010807020909040702
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Dear all,

please find attached an updated description of the DCON BOF.
We think it is important to define the scope very well so that what we 
include in the charter of a potential
WG can be realistically done. So, we encourage you all to devote some 
time to discuss scope-related issues.

Thanks,

Simon


-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: spromano@unina.it
           http://www.comics.unina.it/simonpietro.romano

     <>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/



--------------040609010807020909040702
Content-Type: text/plain;
 name="DCON-BOF-Description.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="DCON-BOF-Description.txt"

DCON BOF co-chairs:

Brian Rosen (br@brianrosen.net)
Simon Pietro Romano (spromano@unina.it)

DCON charter proposal:

- Decription of Working Group

The focus of this Working Group is to develop a standard solution for sca=
lable conferencing over the Internet. The WG will define a standard suite=
 of protocols for distributed conferencing and will draw inspiration from=
 the work carried out in the XCON working group, which has defined a comp=
lete architecture for centralized conferencing.  DCON is based on the ide=
a that a
distributed conference can be setup by appropriately orchestrating the op=
eration of a number of XCON focus elements, each in charge of managing a =
certain number of participants. Interaction between each participant and =
the corresponding conference focus will be entirely based on the standard=
 XCON framework, whereas inter-focus interaction will be defined by this =
WG.

In the DCON architecture a number of entities are used to manage conferen=
ce setup in the presence of clients which are distributed across a geogra=
phical
network.  Each managing entity plays the role of a conference focus as de=
fined in the XCON working group documents. Indeed, each XCON focus will b=
e in charge of managing a certain number of clients falling under its own=
 "realm".  In order to move the XCON scope towards a distributed environm=
ent, we will introduce inter-focus coordination, which is needed to effec=
tively setup and manage conference instantiation and coordination.  As in=
 the centralized    case, we will define logical entities and naming conv=
entions.  An appropriate data model for distributed conferencing will be =
potentially defined and will extend, when needed, the XCON data model.  F=
urthermore, we will propose the adoption of a suitable set of protocols w=
hich are complementary to the call signaling protocols and are needed to =
support advanced conferencing applications.

The WG will basically need to introduce two major functions: (i) a coordi=
nation level among conference focus entities; (ii) a way to effectively d=
istribute conference state information.  As to the first point above, the=
 coordination level is needed in order to manage a distributed conference=
 along its entire life-cycle. For instance, once a user decides to create=
 a new conference, the corresponding conference focus has to distribute c=
onference information to all other foci, in such a way as to enable other=
 potential participants to retrieve the needed data and possibly subscrib=
e to the event. The WG will make the assumption that all the operations n=
eeded inside a single conference island are   managed via the protocols a=
nd interfaces defined inside the XCON working group.  Hence, each single =
island will keep on being based on a star-topology graph for all what con=
cerns the call signaling part. The various available stars will then be c=
onnected through an upper-layer topology providing inter-focus communicat=
ion.  The overall topology of the distributed conferencing scenario will =
look like an overlay network of focus entities, each managing an underlyi=
ng "centralized" conferencing island. The WG will envisage the possibilit=
y to exploit extended Instant Messaging (IM) protocols (e.g. XMPP) for in=
ter-focus communication.
As to the second point mentioned above, it looks clear that a way to prop=
agate information about conferences is needed when switching the view fro=
m a centralized to a distributed perspective.  Indeed, whenever a new con=
ference is created (or an active conference changes its state) such an ev=
ent has to be communicated to all interested (or active) participants.  G=
iven the intrinsic nature of the distributed framework (which actually ex=
pands the centralized one through the introduction of an overlay network =
of focus entities), the actual   flow of information will always foresee =
the interaction among conference focus entities for both conference infor=
mation exchanging and state changes notifications.  The same obviously ap=
plies also to the involved natively centralized protocols defined in the =
XCON framework.  A suitable mechanism will be defined by the WG, allowing=
 for the dispatching of such centralized messages across the DCON network=
=2E The mechanism in question must be fully compliant with the existing o=
peration of XCON islands, which must keep their local participants   tota=
lly unaware of the potential distributed nature of conferences. Conferenc=
e state propagation will take place in a number of alternative ways.  For=
 instance, each focus might flood the received information across an inte=
r-focus communication mesh, thus guaranteeing that potential participants=
 belonging to heterogeneous islands can be reached.  In such case, focus =
entities are "stateful", i.e. each of them stores information about curre=
nt sessions and forwards such information to all peering entities in orde=
r to get them up-to-date with respect to available conference sessions.=20
On the other hand, a distributed repository might be employed for the sak=
e of storing conference information.  Focus entities would access such re=
pository, both to publish (either upon creation of a new conference, or t=
o notify a change in the state of an active conference) and to retrieve i=
nformation about active conferences (e.g. when a new participant wants to=
 access the list of ongoing/scheduled conference sessions he might be int=
erested to join).  In this last case, focus entities are "stateless". Fin=
ally, the WG will evaluate the benefits deriving from the adoption of a p=
ure peer-to-peer approach for the purpose of conference state information=
 spreading.

The deliverables for the group will be:

- A Framework for Distributed Conferencing (backward-compatible with XCON=
 in the single-island case)
- A survey of potential solutions to the construction and maintainance of=
 a DCON conference repository (stateless, stateful, based on flooding, p2=
p, etc.)
- Requirements for an XCON-DCON Synchronization Protocol (XDSP)
- Specification of the XDSP
- DCON call-flows draft (involving the use of XDSP)

- Goals and Milestones

February 2012 --> Submit Framework document for publication as PS
April 2012 --> Submit XDSP Requirements document for publication as Infor=
mational
June 2012 --> Submit survey of solutions for the DCON conference reposito=
ry for publication as Informational
September 2012 --> Submit XDSP Specification document for publication as =
PS
January 2013 --> Submit DCON call flows draft for publication as Informat=
ional

Current drafts related to such proposal:

1. Requirements for Distributed Conferencing --> http://tools.ietf.org/ht=
ml/draft-romano-dcon-requirements-09
2. A Framework for Distributed Conferencing --> http://tools.ietf.org/htm=
l/draft-romano-dcon-framework-09
3.  Requirements for the XCON-DCON Synchronization Protocol --> http://to=
ols.ietf.org/html/draft-romano-dcon-xdsp-reqs-09=20





--------------040609010807020909040702--

From akaithal@cisco.com  Wed Oct 12 23:40:28 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7BC21F8B19 for ; Wed, 12 Oct 2011 23:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0JZep85nyOx for ; Wed, 12 Oct 2011 23:40:27 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id DD7A421F8B18 for ; Wed, 12 Oct 2011 23:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akaithal@cisco.com; l=7119; q=dns/txt; s=iport; t=1318488026; x=1319697626; h=mime-version:subject:date:message-id:from:to; bh=y+sxn/G1MyXDddIcLC/X6hqNpqVHjrXyuMiLaR8DDhs=; b=Lh/iSmCB9zZxPoHkgqQH4M7rHpko9ZZQChq2sUu4lAtE0WN1kzvn5JlF 9vldgj5wAW+qmNG+Oz45QnEPPAzpJKe4wPTNTM3PBd3yT8A3HBDy2TzMP cn0LgORbKj4x4T4e+cgVPItRG29r/m+9wxuNhiYmtzD9uGW390bDtPZgk U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkHAMaGlk5Io8UQ/2dsb2JhbABDgk2XIY5egQWBVQEEEgEJEQNHFAEqBhgHVwEECxABEgeHZJgsgSYBniiHDGEEh3+RKows
X-IronPort-AV: E=Sophos;i="4.69,338,1315180800"; d="scan'208,217";a="917432"
Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-4.cisco.com with ESMTP; 13 Oct 2011 06:40:25 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9D6eM71024878 for ; Thu, 13 Oct 2011 06:40:24 GMT
Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 13 Oct 2011 12:10:16 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8972.F7F5498E"
Date: Thu, 13 Oct 2011 12:10:14 +0530
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version Notification for draft-kaithal-dispatch-sip-log-information-00.txt
Thread-Index: AcyJcvbAqUtQRrOcThW4vOoWqJmk7g==
From: "Adarsh Kaithal (akaithal)" 
To: 
X-OriginalArrivalTime: 13 Oct 2011 06:40:16.0894 (UTC) FILETIME=[F81EB1E0:01CC8972]
Subject: [dispatch] New Version Notification for draft-kaithal-dispatch-sip-log-information-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 06:40:28 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC8972.F7F5498E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All

=20

Introduction of the draft:-

The current mechanisms to debug issues in SIP network are not very

efficient.  It requires to enable debugging logs across different

devices, recreate the problem and then collect the logs.  The idea is

to provide a solution to automatically enable relevant logs (SIP

messages and any other debugging logs meaningful to SIP devices), and

also to indicate where the logs are to be collected or stored.  The

enabling of logs will happen at all the SIP devices(upstream or

downstream).  This will help to get the logs from all the SIP devices

in a Common logging format (CLF).  The solution extends SIP to

provide the infrastructure to enable logging for upstream and

downstream devices with each server deciding how much troubleshooting

information it wants to log - with freedom to simply ignore requests

if required.  This document specifies a new header called "Log-Me"
Header

in all the SIP messages

=20

Link to the draft:-=20

http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt

=20

Let me know if the working group is interested to solve this problem and
comments on the draft.

=20

Best Regards,

Adarsh

=20


------_=_NextPart_001_01CC8972.F7F5498E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi All



 



Introduction of the draft:-



The current mechanisms to debug issues in SIP =
network are
not very



efficient.&=
nbsp;
It requires to enable debugging logs across =
different



devices,
recreate the problem and then collect the logs.  The idea =
is



to
provide a solution to automatically enable relevant logs =
(SIP



messages
and any other debugging logs meaningful to SIP devices), =
and



also
to indicate where the logs are to be collected or stored.  =
The



enabling
of logs will happen at all the SIP devices(upstream =
or



downstream)=
. 
This will help to get the logs from all the SIP =
devices



in
a Common logging format (CLF).  The solution extends SIP =
to



provide
the infrastructure to enable logging for upstream =
and



downstream
devices with each server deciding how much =
troubleshooting



information=

it wants to log - with freedom to simply ignore =
requests



if
required.  This document specifies a new header called =
“Log-Me”
Header



in
all the SIP messages



 



Link to the draft:- 



http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-informatio=
n-00.txt



 



Let me know if the working group is interested to =
solve this
problem and comments on the draft.



 



Best Regards,



Adarsh



 









------_=_NextPart_001_01CC8972.F7F5498E--

From keith.drage@alcatel-lucent.com  Thu Oct 13 01:41:08 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD9721F8558 for ; Thu, 13 Oct 2011 01:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ5p2IN8ZfYf for ; Thu, 13 Oct 2011 01:41:07 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 94DA921F853E for ; Thu, 13 Oct 2011 01:41:06 -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 p9D8eJih022496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Oct 2011 10:41:01 +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, 13 Oct 2011 10:40:41 +0200
From: "DRAGE, Keith (Keith)" 
To: "Adarsh Kaithal (akaithal)" , "dispatch@ietf.org" 
Date: Thu, 13 Oct 2011 10:40:39 +0200
Thread-Topic: New Version Notification for draft-kaithal-dispatch-sip-log-information-00.txt
Thread-Index: AcyJcvbAqUtQRrOcThW4vOoWqJmk7gAEITag
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: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE220DBA661FRMRSSXCHMBSC3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [dispatch] New Version Notification for	draft-kaithal-dispatch-sip-log-information-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 08:41:08 -0000

--_000_EDC0A1AE77C57744B664A310A0B23AE220DBA661FRMRSSXCHMBSC3d_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Can I draw your attention to

http://tools.ietf.org/html/draft-dawes-sipping-debug-04

which I believe was a similar attempt to resolve this problem.

Keith

________________________________
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Adarsh Kaithal (akaithal)
Sent: 13 October 2011 07:40
To: dispatch@ietf.org
Subject: [dispatch] New Version Notification for draft-kaithal-dispatch-sip=
-log-information-00.txt

Hi All

Introduction of the draft:-
The current mechanisms to debug issues in SIP network are not very

efficient.  It requires to enable debugging logs across different

devices, recreate the problem and then collect the logs.  The idea is

to provide a solution to automatically enable relevant logs (SIP

messages and any other debugging logs meaningful to SIP devices), and

also to indicate where the logs are to be collected or stored.  The

enabling of logs will happen at all the SIP devices(upstream or

downstream).  This will help to get the logs from all the SIP devices

in a Common logging format (CLF).  The solution extends SIP to

provide the infrastructure to enable logging for upstream and

downstream devices with each server deciding how much troubleshooting

information it wants to log - with freedom to simply ignore requests

if required.  This document specifies a new header called "Log-Me" Header

in all the SIP messages

Link to the draft:-
http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt

Let me know if the working group is interested to solve this problem and co=
mments on the draft.

Best Regards,
Adarsh


--_000_EDC0A1AE77C57744B664A310A0B23AE220DBA661FRMRSSXCHMBSC3d_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















Can I draw your attention to



 



http://too=
ls.ietf.org/html/draft-dawes-sipping-debug-04<=
/p>


 



which I believe was a similar attempt =
to
resolve this problem.



 



Keith



 


















From:=

dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Adarsh Kaithal (akaithal=
)

Sent: 13 October 2011 07:40<=
br>
To: dispatch@ietf.org

Subject: [dispatch] New Vers=
ion
Notification for draft-kaithal-dispatch-sip-log-information-00.txt






 



Hi All



 



Introduction of the draft:-



The current mechanisms to debug issues in SIP network are not very<=
o:p>



efficient.  It requires=
 to
enable debugging logs across different



devices, recreate the proble=
m and
then collect the logs.  The idea is



to provide a solution to
automatically enable relevant logs (SIP



messages and any other debug=
ging
logs meaningful to SIP devices), and



also to indicate where the l=
ogs
are to be collected or stored.  The



enabling of logs will happen=
 at
all the SIP devices(upstream or



downstream).  This will=
 help
to get the logs from all the SIP devices



in a Common logging format
(CLF).  The solution extends SIP to



provide the infrastructure t=
o
enable logging for upstream and



downstream devices with each
server deciding how much troubleshooting



information it wants to log =
- with
freedom to simply ignore requests



if required.  This docu=
ment
specifies a new header called “Log-Me” Header=




in all the SIP messages=




 



Link to the draft:- 



http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00=
.txt



 



Let me know if the working group is interested to solve this proble=
m
and comments on the draft.



 



Best Regards,



Adarsh



 












--_000_EDC0A1AE77C57744B664A310A0B23AE220DBA661FRMRSSXCHMBSC3d_--

From salinisngh1@gmail.com  Thu Oct 13 04:42:44 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F282321F8B90 for ; Thu, 13 Oct 2011 04:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfy9WAhS5P26 for ; Thu, 13 Oct 2011 04:42:43 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D74A121F8B71 for ; Thu, 13 Oct 2011 04:42:42 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so619461vcb.31 for ; Thu, 13 Oct 2011 04:42:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=irayi7VwtjoReOU4cpId4ieD00gOnlVnwl4CNBruFYw=; b=ZKI4cY6dDGy8fWMAOTWbyua5NjiUWozaCk+ZHwZFNirIjCxOvzbQEN3nzlQxwK9csQ F+XHT0l+INexLvIogExyrmbWvlvqOfZGmyUzLRG097XboIJYpdTeoUYK4gVIy/KWbqPp 7JrcFJDb2zxHZQ10UoTf6z0I2ZFZK6pziBkGg=
MIME-Version: 1.0
Received: by 10.220.162.73 with SMTP id u9mr228832vcx.188.1318506162308; Thu, 13 Oct 2011 04:42:42 -0700 (PDT)
Received: by 10.220.180.68 with HTTP; Thu, 13 Oct 2011 04:42:42 -0700 (PDT)
In-Reply-To: <1318505664.S.13317.1688.F.H.TnNhbGluaSBzaW5naABSZTogRnc6IFJlOiBbZGlzcGF0Y2hdIE5ldyBEcmFmdCAtIGRyYWZ0LXNpbmhhLWQ_.f5-224-113.1318505721.26195@webmail.rediffmail.com>
References:  <1318505664.S.13317.1688.F.H.TnNhbGluaSBzaW5naABSZTogRnc6IFJlOiBbZGlzcGF0Y2hdIE5ldyBEcmFmdCAtIGRyYWZ0LXNpbmhhLWQ_.f5-224-113.1318505721.26195@webmail.rediffmail.com>
Date: Thu, 13 Oct 2011 17:12:42 +0530
Message-ID: 
From: salini singh 
To: dispatch@ietf.org
Content-Type: multipart/alternative; boundary=001485ea3b0e7045a704af2ca306
Subject: Re: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 11:42:44 -0000

--001485ea3b0e7045a704af2ca306
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

How about timing ?
How long session will be in a  provisional state, caller getting pop-up
message and taking long-time to give final YES or NO answer to - CONTINUE
response.

Thanks,
Salini


>
> From:"amar deep" **
> To: 08 Oct 2011 06:08:33 -0000
>
> Date:
> Subject:Re: [dispatch] New Draft -
> draft-sinha-dispatch-sip-continuation-option
> Hi Dave,
>
>
>
> We see two blocking factor in in implementing announcement while CONTINUE
> message are exchanged instead of pop-up text message, as below:
>
>
>
> 1. The probability of caller, initiating a call, might be able to hear an
> announcement while pressing CALL button, or might fail to understand what
> announcement is played .
>
>
>
> 2. Secondly there might be the case, where call is made from one-region t=
o
> another, and Caller mobile has set with LOCAL lingual format, for e.g.
> CHINES, in such a case, caller might not understand ANNOUNCEMENT is playe=
d
> in ENGLISH.
>
>
>
>
> As a result, displaying Pop-up menu locally on the Mobile could resolve
> both blocking factor mentioned above. Even pop-up could be displayed on
> local-language as per setting on Phone.
>
>
>
> Its upto the features on the mobile to READ and PLAY pop-up message of th=
e
> mobile-handset.
>
>
>
> Regards,
>
> Amardeep
>
>
>
>
>
> On Sat, 08 Oct 2011 00:20:44 +0530 wrote
>
> >
>
>
>
>
>
>
>
>
>
> I have one concern in the draft.
>
> As pointed out by John Elwell, =EF=BF=BDplaying an announcement to Caller=
 for
> HOLDING call for another few min, in case the CALL is URGENT=EF=BF=BD doe=
sn=EF=BF=BDt works
> here ??
>
>
>
> Regards,
>
> Dave
>
>
>
>
>
> _______________________________________________
>
>
>
> dispatch mailing list
>
>
>
> dispatch@ietf.org
>
>
>
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
> _______________________________________________
>
> dispatch mailing list
>
> dispatch@ietf.org
>
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> *
> *
>

--001485ea3b0e7045a704af2ca306
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

How about timing ? 
How long session will be in a=C2=A0 provisional stat=
e, caller getting pop-up message and taking long-time to give final YES or =
NO answer to - CONTINUE response.

Thanks,
Salini








From:"amar  deep" 

To: 08 Oct 2011 06:08:33 -0000



Date:

Subject:Re: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-op=
tion

Hi Dave,







We see two blocking factor in in implementing announcement while CONTINUE m=
essage are exchanged instead of pop-up text message, as below:







1. The probability of caller, initiating a call, might be able to hear an a=
nnouncement while pressing CALL button, or might fail to understand what an=
nouncement is played .







2. Secondly there might be the case, where call is made from one-region to =
another, and Caller mobile has set with LOCAL lingual format, for e.g. CHIN=
ES, in such a case, caller might not understand ANNOUNCEMENT is played in E=
NGLISH.










As a result, displaying Pop-up menu locally on the Mobile could resolve bot=
h blocking factor mentioned above. Even pop-up could be displayed on local-=
language as per setting on Phone.







Its upto the features on the mobile to READ and PLAY pop-up message of the =
mobile-handset.







Regards,



Amardeep











On Sat, 08 Oct 2011 00:20:44 +0530  wrote



>



















I have one concern in the draft. 



As pointed out by John Elwell, =EF=BF=BDplaying an announcement to Caller f=
or HOLDING call for another few min, in case the CALL is URGENT=EF=BF=BD do=
esn=EF=BF=BDt works here ??







Regards,



Dave



 		 	   		  







_______________________________________________







dispatch mailing list







dispatch@ietf.org







https://www.ietf.org/mailman/listinfo/dispatch







_______________________________________________



dispatch mailing list



dispatch@ietf.org



https://www.ietf.org/mailman/listinfo/dispatch








--001485ea3b0e7045a704af2ca306--

From vkg@bell-labs.com  Thu Oct 13 10:55:50 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81AD21F84F9 for ; Thu, 13 Oct 2011 10:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOu7mZjqt2SG for ; Thu, 13 Oct 2011 10:55:50 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E390E21F84D6 for ; Thu, 13 Oct 2011 10:55:49 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9DHtjWc009299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Oct 2011 12:55:46 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9DHtjKU008619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Oct 2011 12:55:45 -0500
Received: from shoonya.ih.lucent.com (shoonya.mh.lucent.com [135.222.160.76]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9DHtiCY005335 for ; Thu, 13 Oct 2011 12:55:45 -0500 (CDT)
Message-ID: <4E9726C5.3030609@bell-labs.com>
Date: Thu, 13 Oct 2011 12:58:29 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [dispatch] New Version Notification for draft-kaithal-dispatch-sip-log-information-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 17:55:50 -0000

On 10/13/2011 01:40 AM, Adarsh Kaithal (akaithal) wrote:
> Hi All
>
> Introduction of the draft:-
>
> The current mechanisms to debug issues in SIP network are not very
> efficient. It requires to enable debugging logs across different
[...]

Adarsh: I am sure you are aware of the working going on in SIPCLF
[1]...while your draft mentions "Common Logging Format", I am
not sure whether you meant the SIPCLF or not.

And, one more comment --- in the Security Considerations section,
mandating TLS does not appear to do much good.  A SIP entity can
operate over TLS but end up sending the log to a recipient
using cleartext smtp/ftp/http/tftp thereby negating the benefits
of TLS.

[1] http://datatracker.ietf.org/wg/sipclf/

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From dworley@avaya.com  Thu Oct 13 14:56:18 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C947221F8AE9 for ; Thu, 13 Oct 2011 14:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.349
X-Spam-Level: 
X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7daJ8jEHJAG2 for ; Thu, 13 Oct 2011 14:56:18 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E4CDE21F8A95 for ; Thu, 13 Oct 2011 14:56:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnUIAF1dl07GmAcF/2dsb2JhbABDqFt+B4FTAQEBAQIBEig0EA0BFQcBIUInBBsBGYdcCJdphA+bQYcMYQSZP4wq
X-IronPort-AV: E=Sophos;i="4.69,342,1315195200"; d="scan'208";a="308983728"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Oct 2011 17:56:16 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Oct 2011 17:54:53 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 13 Oct 2011 17:56:16 -0400
From: "Worley, Dale R (Dale)" 
To: "dispatch@ietf.org" 
Date: Thu, 13 Oct 2011 17:55:00 -0400
Thread-Topic: draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMifLA8qKPDawAXUG+zw9urVC4uw==
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: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 21:56:18 -0000

> From: "Worley, Dale R (Dale)" 
> Date: Thu, 15 Sep 2011 11:46:35 -0400
>=20
> (1) I formally request the chairs to recognize that rough consensus
> has been reached that the work described in
> draft-montemurro-gsma-imei-urn and
> draft-allen-dispatch-imei-urn-as-instanceid should progress, and those
> proposals be dispatched to an appropriate working group.

Seeing that I have published a list of the issues that might be
significant in this discussion
(http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
and seeing that no response has been made by *anybody* regarding that
list, and seeing that the stated opinions on the WG mailing list
remain at 17 favorable (hailing from at least 15 different
organizations) and 1 unfavorable...

For a second time, I formally request the chairs to recognize that
rough consensus has been reached that the work described in
draft-montemurro-gsma-imei-urn and
draft-allen-dispatch-imei-urn-as-instanceid should progress, and those
proposals be dispatched to an appropriate working group (which in this
case means an appropriate mailing list for discussion of an
AD-sponsired I-D).

Dale

From mary.ietf.barnes@gmail.com  Thu Oct 13 16:45:44 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11FB21F85A8 for ; Thu, 13 Oct 2011 16:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level: 
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxFOOX9I2JSk for ; Thu, 13 Oct 2011 16:45:44 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D71221F8558 for ; Thu, 13 Oct 2011 16:45:44 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so665537vcb.31 for ; Thu, 13 Oct 2011 16:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=u9NO8g1QOSoLnXf6H9rVJEETzGP2OLiOmdeu08rDkxY=; b=x2jU+jxEdlpD+Ah7ygMkp5FV5zHUHFeqpBH07WA9Y+cl8rvpfypbwNKy4nGsgdHLp7 TK6Hia81VaJYU33GW/y0D4VjbQ6ltbrAY4PuockL5GUbiNDgz3+whqOvoXrgZtY+PVgd +jXEfD8SoqEkfcoklP4EJxzGEG7QK5lUD2cDg=
MIME-Version: 1.0
Received: by 10.52.37.44 with SMTP id v12mr6272850vdj.53.1318549543812; Thu, 13 Oct 2011 16:45:43 -0700 (PDT)
Received: by 10.52.75.198 with HTTP; Thu, 13 Oct 2011 16:45:43 -0700 (PDT)
In-Reply-To: <20111013220824.67DD821F8B95@ietfa.amsl.com>
References: <20111013220824.67DD821F8B95@ietfa.amsl.com>
Date: Thu, 13 Oct 2011 19:45:43 -0400
Message-ID: 
From: Mary Barnes 
To: DISPATCH 
Content-Type: multipart/alternative; boundary=20cf3079bf4e2d7f7e04af36bdb9
Subject: [dispatch] Fwd: IETF 82 - DRAFT Agenda
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 23:45:45 -0000

--20cf3079bf4e2d7f7e04af36bdb9
Content-Type: text/plain; charset=ISO-8859-1

DISPATCH is tentatively scheduled to meet on Tuesday afternoon.

---------- Forwarded message ----------
From: IETF Agenda 
Date: Thu, Oct 13, 2011 at 6:08 PM
Subject: IETF 82 - DRAFT Agenda
To: IETF Announcement list 
Cc: 82all@ietf.org, irsg@irtf.org


The DRAFT agenda is available for viewing on the IETF 82 Meeting web page
at: http://www.ietf.org/meeting/82/index.html

The final agenda will be published on October 21, 2011.

Only 30 days until Taipei, 82nd IETF!
Online registration for the IETF meeting is at:
http://www.ietf.org/meeting/register.html
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--20cf3079bf4e2d7f7e04af36bdb9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

DISPATCH is tentatively scheduled to meet on Tuesday afternoon.

---------- Forwarded message ----------
From: IETF Agenda <agenda@ietf.org>

Date: Thu, Oct 13, 2011 at 6:08 PM
Subject: IETF 82 - DRAFT Agenda
To=
: IETF Announcement list <ietf=
-announce@ietf.org>
Cc: 82all@i=
etf.org, irsg@irtf.org



The DRAFT agenda is available for viewing on the IETF 82 Meeting we=
b page at: http://www.ietf.org/meeting/82/index.html



The final agenda will be published on October 21, 2011.



Only 30 days until Taipei, 82nd IETF!

Online registration for the IETF meeting is at:

htt=
p://www.ietf.org/meeting/register.html

_______________________________________________

IETF-Announce mailing list

IETF-Announce@ietf.org

https://www.ietf.org/mailman/listinfo/ietf-announce




--20cf3079bf4e2d7f7e04af36bdb9--

From aallen@rim.com  Thu Oct 13 18:45:10 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A2721F8BD8 for ; Thu, 13 Oct 2011 18:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Level: 
X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYYkT7-Oi9wy for ; Thu, 13 Oct 2011 18:45:10 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id E053921F8BE8 for ; Thu, 13 Oct 2011 18:45:09 -0700 (PDT)
X-AuditID: 0a412830-b7c77ae000005761-c8-4e97941ba56b
Received: from XHT106CNC.rim.net (xht106cnc.rim.net [10.65.22.53]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 4C.0E.22369.B14979E4; Fri, 14 Oct 2011 01:44:59 +0000 (GMT)
Received: from XCT101ADS.rim.net (10.67.111.42) by XHT106CNC.rim.net (10.65.22.53) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 13 Oct 2011 21:45:06 -0400
Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.01.0289.001; Thu, 13 Oct 2011 20:45:04 -0500
From: Andrew Allen 
To: "dworley@avaya.com" , "dispatch@ietf.org" 
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMifLA8qKPDawAXUG+zw9urVC4u5V7EeRi
Date: Fri, 14 Oct 2011 01:45:04 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.70.110.251]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsXC5Shmqis9ZbqfwfoVlhZLJy1gtWjbNYfZ gcnj4Mo57B5LlvxkCmCKamC0SczLyy9JLElVSEktTrZV8klNT8xRCCjKLEtMrlRwySxOzknM zE0tUlLITLFVMlFSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+ uhYWppa6hkp2ukgg4R93RtOEf6wFN3kqVva+Z2xgfMrVxcjBISFgIvHlhkcXIyeQKSZx4d56 ti5GLg4hgR4midZfE9khnKWMEv8ntEA5Wxglzv1tYgJpYRNQllj+ewYjiC0iECbx6lYHmC0s kC6x62IzVDxDom3lKyjbSOLo/Q2sIDaLgKrE6imf2EFsXgE3iR1/p4PZnEBzNpzYzwxiMwrI Suw+ex1sF7OAuMStJ/OZIE4VkFiy5zwzhC0q8fLxP1YIW1HiSeNmFoh6PYkbU6ewQdjaEssW vmaG2CUocXLmE7AaIQFpiR0n1zBOYBSbhWTFLCTts5C0z0LSvoCRZRWjYG5GsYGZYXJesl5R Zq5eXmrJJkZwotAw2ME4Ya/WIUYBDkYlHt65jdP9hFgTy4orcw8xSnAwK4nwzmwDCvGmJFZW pRblxxeV5qQWH2K0AIbKRGYp7uR8YBLLK4k3NjBA4SiJ88pcyvATEkgHpqTs1NSC1CKYViYO TqkGRq992td+HfqbPTtkq5TYzF9n/3SpGjDExjMard3+T1+5Ily4l4974vWDiz3PiLVuECn8 NeXg/fj0775X5spuPfQ2wurvZx2J1fL7nyx1Cv97zky2X9bwDF/8Stvck2s8m3Z/F18k4zSZ 4wqvh/vr54kX2E/8f/TPhyHc7Z4T4+wfT05mLm0snafEUpyRaKjFXFScCACcUE+3LQMAAA==
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 01:45:11 -0000

+1


----- Original Message -----
From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]
Sent: Thursday, October 13, 2011 04:55 PM=0A=
To: dispatch@ietf.org 
Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-i=
mei-urn-as-instanceid

> From: "Worley, Dale R (Dale)" 
> Date: Thu, 15 Sep 2011 11:46:35 -0400
> 
> (1) I formally request the chairs to recognize that rough consensus
> has been reached that the work described in
> draft-montemurro-gsma-imei-urn and
> draft-allen-dispatch-imei-urn-as-instanceid should progress, and those
> proposals be dispatched to an appropriate working group.

Seeing that I have published a list of the issues that might be
significant in this discussion
(http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
and seeing that no response has been made by *anybody* regarding that
list, and seeing that the stated opinions on the WG mailing list
remain at 17 favorable (hailing from at least 15 different
organizations) and 1 unfavorable...

For a second time, I formally request the chairs to recognize that
rough consensus has been reached that the work described in
draft-montemurro-gsma-imei-urn and
draft-allen-dispatch-imei-urn-as-instanceid should progress, and those
proposals be dispatched to an appropriate working group (which in this
case means an appropriate mailing list for discussion of an
AD-sponsired I-D).

Dale
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From akaithal@cisco.com  Thu Oct 13 21:40:59 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B4421F84D6 for ; Thu, 13 Oct 2011 21:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level: 
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EX3UKtn1ORw for ; Thu, 13 Oct 2011 21:40:58 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9A49121F84CE for ; Thu, 13 Oct 2011 21:40:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akaithal@cisco.com; l=13162; q=dns/txt; s=iport; t=1318567256; x=1319776856; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=a2S8GEoyPMdycr3c+nQJMDHLkZRz7/sQLySlWDrhKXU=; b=W6qEtWX6VWdW5H/Pqyiu07Q4jRcHEAyWYPrYmIPMBdV/Vm+JYnL+3JHS RTmo4qpVHinDR+DWM/CI/33d+zq21NwHv7Xd8pz4iOFVY7H2VUpt+Xb1m m1pyqMak92zIEm8hTxU14pOMmWCio8zu77E/nVWtTv56PSZLI5NxLvdEq Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqUAADq8l05Io8UR/2dsb2JhbABDgk2WaIdsAYc4gQWBUwEBAQEDEgEJEQNHEgIBCBEEAQELBhcBBgFFCQgBAQQBCggIARIHh2SZCgGeMocMYQSHf5EpjCw
X-IronPort-AV: E=Sophos;i="4.69,344,1315180800"; d="scan'208,217";a="994171"
Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-4.cisco.com with ESMTP; 14 Oct 2011 04:40:54 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9E4enhg007225; Fri, 14 Oct 2011 04:40:53 GMT
Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 14 Oct 2011 10:10:50 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8A2B.72C42DC0"
Date: Fri, 14 Oct 2011 10:10:48 +0530
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version Notification fordraft-kaithal-dispatch-sip-log-information-00.txt
Thread-Index: AcyJcvbAqUtQRrOcThW4vOoWqJmk7gAEITagACnTVsA=
References:  
From: "Adarsh Kaithal (akaithal)" 
To: "DRAGE, Keith (Keith)" , 
X-OriginalArrivalTime: 14 Oct 2011 04:40:50.0410 (UTC) FILETIME=[72F9C4A0:01CC8A2B]
Subject: Re: [dispatch] New Version Notification fordraft-kaithal-dispatch-sip-log-information-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 04:41:00 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC8A2B.72C42DC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Keith,

=20

We have already looked in to this before starting with the new one.

=20

The approach on the new draft is different but I agree the goal is same.

=20

I would request you to go through the new draft and let me know your
comments.

=20

Thanks,

=20

Best Regards,

Adarsh

=20

From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20
Sent: Thursday, October 13, 2011 2:11 PM
To: Adarsh Kaithal (akaithal); dispatch@ietf.org
Subject: RE: New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

=20

Can I draw your attention to

=20

http://tools.ietf.org/html/draft-dawes-sipping-debug-04

=20

which I believe was a similar attempt to resolve this problem.

=20

Keith

=20

________________________________

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Adarsh Kaithal (akaithal)
Sent: 13 October 2011 07:40
To: dispatch@ietf.org
Subject: [dispatch] New Version Notification for
draft-kaithal-dispatch-sip-log-information-00.txt

=20

Hi All

=20

Introduction of the draft:-

The current mechanisms to debug issues in SIP network are not very

efficient.  It requires to enable debugging logs across different

devices, recreate the problem and then collect the logs.  The idea is

to provide a solution to automatically enable relevant logs (SIP

messages and any other debugging logs meaningful to SIP devices), and

also to indicate where the logs are to be collected or stored.  The

enabling of logs will happen at all the SIP devices(upstream or

downstream).  This will help to get the logs from all the SIP devices

in a Common logging format (CLF).  The solution extends SIP to

provide the infrastructure to enable logging for upstream and

downstream devices with each server deciding how much troubleshooting

information it wants to log - with freedom to simply ignore requests

if required.  This document specifies a new header called "Log-Me"
Header

in all the SIP messages

=20

Link to the draft:-=20

http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt

=20

Let me know if the working group is interested to solve this problem and
comments on the draft.

=20

Best Regards,

Adarsh

=20


------_=_NextPart_001_01CC8A2B.72C42DC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















Hi =
Keith,



 



We have already =
looked in to
this before starting with the new one.



 



The approach on the =
new draft is
different but I agree the goal is same.



 



I would request you =
to go through
the new draft and let me know your comments.



 



Thanks,



 



Best =
Regards,



Adarsh



 









From:=
 DRAGE, =
Keith
(Keith) [mailto:keith.drage@alcatel-lucent.com] 

Sent: Thursday, October 13, 2011 2:11 PM

To: Adarsh Kaithal (akaithal); dispatch@ietf.org

Subject: RE: New Version Notification =
fordraft-kaithal-dispatch-sip-log-information-00.txt








 



Can I draw your attention to



 



http://t=
ools.ietf.org/html/draft-dawes-sipping-debug-04
=



 



which I believe was a similar attempt to resolve this =
problem.



 



Keith



 


















From:=

dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Adarsh
Kaithal (akaithal)

Sent: 13 October 2011 07:40

To: dispatch@ietf.org

Subject: [dispatch] New Version Notification for
draft-kaithal-dispatch-sip-log-information-00.txt






 



Hi All



 



Introduction of the draft:-



The current mechanisms to debug issues in SIP =
network are
not very



efficient.&=
nbsp;
It requires to enable debugging logs across =
different



devices,
recreate the problem and then collect the logs.  The idea =
is



to
provide a solution to automatically enable relevant logs =
(SIP



messages
and any other debugging logs meaningful to SIP devices), =
and



also
to indicate where the logs are to be collected or stored.  =
The



enabling
of logs will happen at all the SIP devices(upstream =
or



downstream)=
. 
This will help to get the logs from all the SIP =
devices



in
a Common logging format (CLF).  The solution extends SIP =
to



provide
the infrastructure to enable logging for upstream =
and



downstream
devices with each server deciding how much =
troubleshooting



information=

it wants to log - with freedom to simply ignore =
requests



if
required.  This document specifies a new header called
“Log-Me” Header



in
all the SIP messages



 



Link to the draft:- 



http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-informatio=
n-00.txt



 



Let me know if the working group is interested to =
solve this
problem and comments on the draft.



 



Best Regards,



Adarsh



 












------_=_NextPart_001_01CC8A2B.72C42DC0--

From amardeep_sinha@rediffmail.com  Fri Oct 14 00:27:44 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DDE21F8C1F for ; Fri, 14 Oct 2011 00:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level: 
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz+iWvYeqJVE for ; Fri, 14 Oct 2011 00:27:44 -0700 (PDT)
Received: from rediffmail.com (f5mail-224-116.rediffmail.com [114.31.224.116]) by ietfa.amsl.com (Postfix) with SMTP id DFD0C21F8B70 for ; Fri, 14 Oct 2011 00:27:42 -0700 (PDT)
Received: (qmail 10093 invoked by uid 510); 14 Oct 2011 07:27:38 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=H4kcSy9ezBzqWoiBbcFpo8r5TMZdKDTwxYflzfntndaRP/E18fySC1cGZYtY+IQa+4HhCpgx7KhPqDorjoXVZSigURqiZCvPN7F0UtY5R9ZdU469ATS0Vofd8UXRQKMt0L1A5XA3tMLB9vOpqaBNdhloGEs+QXLJpKyIN0cAoLg= ; 
x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd;
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-Flags: : 0
X-CTCH-RefID: str=0001.0A150201.4E97E46A.006F,ss=1,re=0.000,fgs=0
X-REDF-OSEN: amardeep_sinha@rediffmail.com
Date: 14 Oct 2011 07:27:38 -0000
MIME-Version: 1.0
To: 
Received: from unknown 72.163.180.205 by rediffmail.com via HTTP; 14 Oct 2011 07:27:37 -0000
Message-ID: <1318506173.S.10534.32188.F.H.WXNhbGluaSBzaW5naABSZTogW2Rpc3BhdGNoXSBOZXcgRHJhZnQgLSBkcmFmdC1zaW5oYS1kaXNwYXRjaC0_.f5-147-128.old.1318577257.30588@webmail.rediffmail.com>
in-reply-to: 
From: "amar  deep" 
Content-Type: multipart/alternative; boundary="=_728f9721754d8ef34098961548f6ca35"
Cc: dispatch@ietf.org
Subject: Re: [dispatch] =?utf-8?q?New_Draft_-_draft-sinha-dispatch-sip-continu?= =?utf-8?q?ation-option?=
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 07:27:45 -0000

--=_728f9721754d8ef34098961548f6ca35
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"


The session time-out for a SIP session after initiating Provisional response 1XX (except 100 Trying) by the callee, will work as per the RFC-3261 implementation.

Regards,
Amardeep Sinha

On Thu, 13 Oct 2011 17:12:53 +0530  wrote
>How about timing ? 
How long session will be in a provisional state, caller getting pop-up message and taking long-time to give final YES or NO answer to - CONTINUE response.

Thanks,
Salini







From:"amar  deep" 

To: 08 Oct 2011 06:08:33 -0000



Date:

Subject:Re: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-option

Hi Dave,







We see two blocking factor in in implementing announcement while CONTINUE message are exchanged instead of pop-up text message, as below:







1. The probability of caller, initiating a call, might be able to hear an announcement while pressing CALL button, or might fail to understand what announcement is played .







2. Secondly there might be the case, where call is made from one-region to another, and Caller mobile has set with LOCAL lingual format, for e.g. CHINES, in such a case, caller might not understand ANNOUNCEMENT is played in ENGLISH.










As a result, displaying Pop-up menu locally on the Mobile could resolve both blocking factor mentioned above. Even pop-up could be displayed on local-language as per setting on Phone.







Its upto the features on the mobile to READ and PLAY pop-up message of the mobile-handset.







Regards,



Amardeep











On Sat, 08 Oct 2011 00:20:44 +0530  wrote



>



















I have one concern in the draft. 



As pointed out by John Elwell, �playing an announcement to Caller for HOLDING call for another few min, in case the CALL is URGENT� doesn�t works here ??







Regards,



Dave



 		 	   		  







_______________________________________________







dispatch mailing list







dispatch@ietf.org







https://www.ietf.org/mailman/listinfo/dispatch







_______________________________________________



dispatch mailing list



dispatch@ietf.org



https://www.ietf.org/mailman/listinfo/dispatch







_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch



Amar

--=_728f9721754d8ef34098961548f6ca35
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"



The session time-out for a SIP session after initiating Provisional respons=
e 1XX (except 100 Trying) by the callee, will work as per the RFC-3261 impl=
ementation.



Regards,

Amardeep Sinha



On Thu, 13 Oct 2011 17:12:53 +0530  wrote

>How about timing ? 

How long session will be in a provisional state, caller getting pop-up mess=
age and taking long-time to give final YES or NO answer to - CONTINUE respo=
nse.



Thanks,

Salini















From:"amar  deep" 



To: 08 Oct 2011 06:08:33 -0000







Date:



Subject:Re: [dispatch] New Draft - draft-sinha-dispatch-sip-continuation-op=
tion



Hi Dave,















We see two blocking factor in in implementing announcement while CONTINUE m=
essage are exchanged instead of pop-up text message, as below:















1. The probability of caller, initiating a call, might be able to hear an a=
nnouncement while pressing CALL button, or might fail to understand what an=
nouncement is played .















2. Secondly there might be the case, where call is made from one-region to =
another, and Caller mobile has set with LOCAL lingual format, for e.g. CHIN=
ES, in such a case, caller might not understand ANNOUNCEMENT is played in E=
NGLISH.





















As a result, displaying Pop-up menu locally on the Mobile could resolve bot=
h blocking factor mentioned above. Even pop-up could be displayed on local-=
language as per setting on Phone.















Its upto the features on the mobile to READ and PLAY pop-up message of the =
mobile-handset.















Regards,







Amardeep























On Sat, 08 Oct 2011 00:20:44 +0530  wrote







>







































I have one concern in the draft. 







As pointed out by John Elwell, =EF=BF=BDplaying an announcement to Caller f=
or HOLDING call for another few min, in case the CALL is URGENT=EF=BF=BD do=
esn=EF=BF=BDt works here ??















Regards,







Dave







 		 	   		  















_______________________________________________















dispatch mailing list















dispatch@ietf.org















https://www.ietf.org/mailman/listinfo/dispatch















_______________________________________________







dispatch mailing list







dispatch@ietf.org







https://www.ietf.org/mailman/listinfo/dispatch















_______________________________________________



dispatch mailing list



dispatch@ietf.org



https://www.ietf.org/mailman/listinfo/dispatch





Amar



Treat yourself at a restaurant, sp=
a, resort and much more with Rediff De=
al ho jaye!
--=_728f9721754d8ef34098961548f6ca35--

From md3135@att.com  Fri Oct 14 04:01:39 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9902621F89BA for ; Fri, 14 Oct 2011 04:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a86s6Nd8g+vc for ; Fri, 14 Oct 2011 04:01:38 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id AAACC21F886A for ; Fri, 14 Oct 2011 04:01:36 -0700 (PDT)
X-Env-Sender: md3135@att.com
X-Msg-Ref: server-2.tower-119.messagelabs.com!1318590094!30806164!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21116 invoked from network); 14 Oct 2011 11:01:35 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Oct 2011 11:01:35 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9EB21GS006122; Fri, 14 Oct 2011 07:02:01 -0400
Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9EB1piX005918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Oct 2011 07:01:52 -0400
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.48]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0289.001; Fri, 14 Oct 2011 07:01:24 -0400
From: "DOLLY, MARTIN C" 
To: Andrew Allen , "dworley@avaya.com" , "dispatch@ietf.org" 
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMifLA8qKPDawAXUG+zw9urVC4u5V7EeRigACbP0A=
Date: Fri, 14 Oct 2011 11:01:24 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.138.105]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 11:01:39 -0000

Agreed, please progress these drafts.

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Andrew Allen
Sent: Thursday, October 13, 2011 9:45 PM
To: dworley@avaya.com; dispatch@ietf.org
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispa=
tch-imei-urn-as-instanceid


+1


----- Original Message -----
From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]
Sent: Thursday, October 13, 2011 04:55 PM
To: dispatch@ietf.org 
Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-=
imei-urn-as-instanceid

> From: "Worley, Dale R (Dale)" 
> Date: Thu, 15 Sep 2011 11:46:35 -0400
>=20
> (1) I formally request the chairs to recognize that rough consensus
> has been reached that the work described in
> draft-montemurro-gsma-imei-urn and
> draft-allen-dispatch-imei-urn-as-instanceid should progress, and those
> proposals be dispatched to an appropriate working group.

Seeing that I have published a list of the issues that might be
significant in this discussion
(http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
and seeing that no response has been made by *anybody* regarding that
list, and seeing that the stated opinions on the WG mailing list
remain at 17 favorable (hailing from at least 15 different
organizations) and 1 unfavorable...

For a second time, I formally request the chairs to recognize that
rough consensus has been reached that the work described in
draft-montemurro-gsma-imei-urn and
draft-allen-dispatch-imei-urn-as-instanceid should progress, and those
proposals be dispatched to an appropriate working group (which in this
case means an appropriate mailing list for discussion of an
AD-sponsired I-D).

Dale
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From atle.monrad@ericsson.com  Fri Oct 14 04:20:14 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6FB21F8B35 for ; Fri, 14 Oct 2011 04:20:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpZeJk8YXF6F for ; Fri, 14 Oct 2011 04:20:13 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 93F4021F8B1E for ; Fri, 14 Oct 2011 04:20:13 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-e7-4e981aec2b94
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 80.44.13753.CEA189E4; Fri, 14 Oct 2011 13:20:12 +0200 (CEST)
Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.187]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 14 Oct 2011 13:20:12 +0200
From: Atle Monrad 
To: "DOLLY, MARTIN C" , Andrew Allen , "dworley@avaya.com" , "dispatch@ietf.org" 
Date: Fri, 14 Oct 2011 13:20:10 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMifLA8qKPDawAXUG+zw9urVC4u5V7EeRigACbP0CAAATiQA==
Message-ID: <7A051DFAA46D0246A82293C7CEF621E9056D5BA21E@ESESSCMS0352.eemea.ericsson.se>
References:   
In-Reply-To: 
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: nb-NO, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 11:20:14 -0000

Hi

I would like to team up with the persons supporting progress of these draft=
s.

/atle

________________________________=20


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management=20
Ericsson

=20


-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of DOLLY, MARTIN C
Sent: 14. oktober 2011 13:01
To: Andrew Allen; dworley@avaya.com; dispatch@ietf.org
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispa=
tch-imei-urn-as-instanceid

Agreed, please progress these drafts.

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Andrew Allen
Sent: Thursday, October 13, 2011 9:45 PM
To: dworley@avaya.com; dispatch@ietf.org
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispa=
tch-imei-urn-as-instanceid


+1


----- Original Message -----
From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]
Sent: Thursday, October 13, 2011 04:55 PM
To: dispatch@ietf.org 
Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-=
imei-urn-as-instanceid

> From: "Worley, Dale R (Dale)" 
> Date: Thu, 15 Sep 2011 11:46:35 -0400
>=20
> (1) I formally request the chairs to recognize that rough consensus=20
> has been reached that the work described in=20
> draft-montemurro-gsma-imei-urn and=20
> draft-allen-dispatch-imei-urn-as-instanceid should progress, and those=20
> proposals be dispatched to an appropriate working group.

Seeing that I have published a list of the issues that might be significant=
 in this discussion (http://www.ietf.org/mail-archive/web/dispatch/current/=
msg03779.html),
and seeing that no response has been made by *anybody* regarding that list,=
 and seeing that the stated opinions on the WG mailing list remain at 17 fa=
vorable (hailing from at least 15 different
organizations) and 1 unfavorable...

For a second time, I formally request the chairs to recognize that rough co=
nsensus has been reached that the work described in draft-montemurro-gsma-i=
mei-urn and draft-allen-dispatch-imei-urn-as-instanceid should progress, an=
d those proposals be dispatched to an appropriate working group (which in t=
his case means an appropriate mailing list for discussion of an AD-sponsire=
d I-D).

Dale
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From sandks@cisco.com  Fri Oct 14 07:39:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3841321F8CA3 for ; Fri, 14 Oct 2011 07:39:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGu5UgGEB4iY for ; Fri, 14 Oct 2011 07:39:46 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2A51721F8C9B for ; Fri, 14 Oct 2011 07:39:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sandks@cisco.com; l=2740; q=dns/txt; s=iport; t=1318603186; x=1319812786; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=UIaQrsXFGD9NIcd4iYfWmSahE3ioIVajQsJgABS1nh0=; b=dYlUwkJBy6DMg2z2pes9r5W4lenAo3hFWijnOFk3FnF2j7Y0MlRyr2PY 30XmxXSlHxGVM9OWyy8JZpDOlHlL/LVdKQDcBBVt8YwXE3ErvagQSkril OhIAqdtIxlBajLDQAj8H6x6iy73d2m97qKrDDMYBSheYjqtumLDnU2Vnw o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMAACZJmE5Io8US/2dsb2JhbABDmTuPKIEFgW4BAQEEAQEBDwEdCjQJDgQCAQgRBAEBAQoGFwEGASYfCQgBAQQBCggIGodlmH0BnkaHGGEEh3+RKYws
X-IronPort-AV: E=Sophos;i="4.69,346,1315180800";  d="scan'208";a="1038627"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 14 Oct 2011 14:39:44 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9EEdhO7002949; Fri, 14 Oct 2011 14:39:43 GMT
Received: from xmb-bgl-418.cisco.com ([72.163.129.214]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 14 Oct 2011 20:09:43 +0530
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: Fri, 14 Oct 2011 20:09:41 +0530
Message-ID: <2D490F9E9907974589E48127DD01C850058F09A2@XMB-BGL-418.cisco.com>
In-Reply-To: <4E9726C5.3030609@bell-labs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] New Version Notification fordraft-kaithal-dispatch-sip-log-information-00.txt
Thread-Index: AcyJ0WOTcEm0oA2DQJqtUfCkSD03dgArHPsA
References:  <4E9726C5.3030609@bell-labs.com>
From: "Sandeep K.S (sandks)" 
To: "Vijay K. Gurbani" , 
X-OriginalArrivalTime: 14 Oct 2011 14:39:43.0401 (UTC) FILETIME=[1CB51190:01CC8A7F]
Subject: Re: [dispatch] New Version Notification fordraft-kaithal-dispatch-sip-log-information-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 14:39:47 -0000

Hello Vijay,

Thanks for your review and the comments.

Our responses to your comments are below:

1. Adarsh: I am sure you are aware of the working going on in SIPCLF
[1]...while your draft mentions "Common Logging Format", I am
not sure whether you meant the SIPCLF or not.
 By "Common Logging Format", we are actually referring to the
work being done as part of SIPCLF WG itself. We could probably add a
citation to the WG here for more clarity.

2. And, one more comment --- in the Security Considerations section,
mandating TLS does not appear to do much good.  A SIP entity can
operate over TLS but end up sending the log to a recipient
using cleartext smtp/ftp/http/tftp thereby negating the benefits
of TLS.
 In section 4. Applicability Statement, we have already
mentioned this - " 5) If SIP signaling is secure then logging MUST be
secure.".
 Also as part of the log-type in the ABNF, we have specified sftp as one
of the logging methods, and have provided provision to support any other
(secure) mechanism via the 'other-type' log-type option. So with this,
we are insisting that if SIP signaling is via TLS, then the logging MUST
use sftp or any other secure mechanism.

Hope the responses have clarified your doubts.

Regards
Sandeep

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Vijay K. Gurbani
Sent: Thursday, October 13, 2011 11:28 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

On 10/13/2011 01:40 AM, Adarsh Kaithal (akaithal) wrote:
> Hi All
>
> Introduction of the draft:-
>
> The current mechanisms to debug issues in SIP network are not very
> efficient. It requires to enable debugging logs across different
[...]

Adarsh: I am sure you are aware of the working going on in SIPCLF
[1]...while your draft mentions "Common Logging Format", I am
not sure whether you meant the SIPCLF or not.

And, one more comment --- in the Security Considerations section,
mandating TLS does not appear to do much good.  A SIP entity can
operate over TLS but end up sending the log to a recipient
using cleartext smtp/ftp/http/tftp thereby negating the benefits
of TLS.

[1] http://datatracker.ietf.org/wg/sipclf/

Thanks,

- vijay
--=20
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From pravindran@sonusnet.com  Fri Oct 14 08:29:18 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C584E21F8C90 for ; Fri, 14 Oct 2011 08:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4HmnEYkth7T for ; Fri, 14 Oct 2011 08:29:16 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAE921F8C78 for ; Fri, 14 Oct 2011 08:29:16 -0700 (PDT)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9EFTm46013816;  Fri, 14 Oct 2011 11:29:48 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 14 Oct 2011 11:29:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8A86.0547029B"
Date: Fri, 14 Oct 2011 20:59:08 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F17F5@sonusinmail02.sonusnet.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] New Version Notification fordraft-kaithal-dispatch-sip-log-information-00.txt
Thread-Index: AcyJcvbAqUtQRrOcThW4vOoWqJmk7gBDJZRQ
References: 
From: "Ravindran Parthasarathi" 
To: "Adarsh Kaithal (akaithal)" , 
X-OriginalArrivalTime: 14 Oct 2011 15:29:14.0160 (UTC) FILETIME=[076AEB00:01CC8A86]
Subject: Re: [dispatch] New Version Notification fordraft-kaithal-dispatch-sip-log-information-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 15:29:18 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC8A86.0547029B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Adarsh,

=20

I skimmed through your draft. IIUC, your intention is to log SIPCLF
messages in all SIP devices during the session, SIPCLF with session-id
(dialog-id) will serve the purpose to collect the session in all the SIP
devices, "Log-me" header is used to enable the logging mechanism in each
SIP devices dynamically.  I like the idea in high level but the draft
has lot of loose ends:

=20

1)      SIP header passing through B2BUA has lot of challenges because
lot of SIP services enables specific services which results in zero or
one or more messages is the other side of the B2BUA. Session-id is the
crucial for this work to move ahead but Dispatch has to first dispatch
session-id WG first.  For the time being, let us assume the world is
full of SIP proxy, then dialog-id shall be used as unique id to identify
the dialog.

2)      "Log-me" MUST NOT direct the other device to use the logging
type (tftp, sftp) because it involves the device control of another SIP
entity. In case device control is desired as part of this functionality,
there is an ongoing dispatch discussion on device control whose
mechanism has to integrated into this header. IMO, device control should
not integrated with this. Let implementers choose their own mechanism as
a starting point.

3)      SIP primitives like REFER, join has to be well defined. "Log-me"
may not pass across automatically.

4)      There is no stopping "logging" mechanism within the dialog=20

5)      How this header applies to SUBSCRIBE, REGISTER, PUBLISH, OPTIONS

=20

Thanks

Partha

=20

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Adarsh Kaithal (akaithal)
Sent: Thursday, October 13, 2011 12:10 PM
To: dispatch@ietf.org
Subject: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

=20

Hi All

=20

Introduction of the draft:-

The current mechanisms to debug issues in SIP network are not very

efficient.  It requires to enable debugging logs across different

devices, recreate the problem and then collect the logs.  The idea is

to provide a solution to automatically enable relevant logs (SIP

messages and any other debugging logs meaningful to SIP devices), and

also to indicate where the logs are to be collected or stored.  The

enabling of logs will happen at all the SIP devices(upstream or

downstream).  This will help to get the logs from all the SIP devices

in a Common logging format (CLF).  The solution extends SIP to

provide the infrastructure to enable logging for upstream and

downstream devices with each server deciding how much troubleshooting

information it wants to log - with freedom to simply ignore requests

if required.  This document specifies a new header called "Log-Me"
Header

in all the SIP messages

=20

Link to the draft:-=20

http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt

=20

Let me know if the working group is interested to solve this problem and
comments on the draft.

=20

Best Regards,

Adarsh

=20


------_=_NextPart_001_01CC8A86.0547029B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Adarsh,



 



I skimmed through =
your draft. IIUC,
your intention is to log SIPCLF messages in all SIP devices during the =
session,
SIPCLF with session-id (dialog-id) will serve the purpose to collect the
session in all the SIP devices, “Log-me” header is used to =
enable
the logging mechanism in each SIP devices dynamically.  I like the =
idea in
high level but the draft has lot of loose ends:



 



1)     
SIP header =
passing through
B2BUA has lot of challenges because lot of SIP services enables specific
services which results in zero or one or more messages is the other side =
of the
B2BUA. Session-id is the crucial for this work to move ahead but =
Dispatch has
to first dispatch session-id WG first.  For the time being, let us =
assume
the world is full of SIP proxy, then dialog-id shall be used as unique =
id to
identify the dialog.



2)     
“Log-me”
MUST NOT direct the other device to use the logging type (tftp, sftp) =
because
it involves the device control of another SIP entity. In case device =
control is
desired as part of this functionality, there is an ongoing dispatch =
discussion
on device control whose mechanism has to integrated into this header. =
IMO, device
control should not integrated with this. Let implementers choose their =
own
mechanism as a starting point.



3)     
SIP =
primitives like
REFER, join has to be well defined. “Log-me” may not pass =
across
automatically.



4)     
There is no =
stopping
“logging” mechanism within the dialog 



5)     
How this =
header
applies to SUBSCRIBE, REGISTER, PUBLISH, OPTIONS



 



Thanks



Partha



 












From:=

dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Adarsh
Kaithal (akaithal)

Sent: Thursday, October 13, 2011 12:10 PM

To: dispatch@ietf.org

Subject: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt








 



Hi All



 



Introduction of the draft:-



The current mechanisms to debug issues in SIP =
network are
not very



efficient.&=
nbsp;
It requires to enable debugging logs across =
different



devices,
recreate the problem and then collect the logs.  The idea =
is



to
provide a solution to automatically enable relevant logs =
(SIP



messages
and any other debugging logs meaningful to SIP devices), =
and



also
to indicate where the logs are to be collected or stored.  =
The



enabling
of logs will happen at all the SIP devices(upstream =
or



downstream)=
. 
This will help to get the logs from all the SIP =
devices



in
a Common logging format (CLF).  The solution extends SIP =
to



provide
the infrastructure to enable logging for upstream =
and



downstream
devices with each server deciding how much =
troubleshooting



information=

it wants to log - with freedom to simply ignore =
requests



if
required.  This document specifies a new header called
“Log-Me” Header



in
all the SIP messages



 



Link to the draft:- 



http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-informatio=
n-00.txt



 



Let me know if the working group is interested to =
solve this
problem and comments on the draft.



 



Best Regards,



Adarsh



 












------_=_NextPart_001_01CC8A86.0547029B--

From HKaplan@acmepacket.com  Fri Oct 14 10:22:13 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB31B21F8C65 for ; Fri, 14 Oct 2011 10:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level: 
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89995oW27xZB for ; Fri, 14 Oct 2011 10:22:13 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E6E2821F8BEC for ; Fri, 14 Oct 2011 10:22:12 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 Oct 2011 13:22:09 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 13:22:10 -0400
From: Hadriel Kaplan 
To: "dispatch@ietf.org list" 
Thread-Topic: SIP Traceroute with media-loopback I-D
Thread-Index: AQHMipXN2EauTppw/0iiIMAibAZmwA==
Date: Fri, 14 Oct 2011 17:22:09 +0000
Message-ID: <7D21EB4B-802A-47D6-8F10-6E2692499BC4@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Subject: [dispatch] SIP Traceroute with media-loopback I-D
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 17:22:13 -0000

Howdy,
I've submitted an I-D with a strawman proposal for how to provide the abili=
ty to make media-loopback test calls to B2BUAs along the path to a target. =
 The current proposal is to use a new SIP header, but there are other possi=
ble solutions.

Any comments/flames/feedback are welcome.

In particular, I'm trying to see if there's interest in DISPATCHing this wo=
rk anywhere in the IETF, or if I should go the individual path instead.
Thanks!

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

	Title           : A Media-based Traceroute Function for the Session Initia=
tion Protocol (SIP)
	Author(s)       : Hadriel Kaplan
	Filename        : draft-kaplan-dispatch-sip-traceroute-00.txt
	Pages           : 7
	Date            : 2011-10-14

  SIP already provides the ability to perform hop-by-hop traceroute
  for SIP messages using the Max-Forwards header field, in order to
  determine the reachability path of requests to a target.  A new
  mechanism for media-loopback calls is also being defined separately,
  which enables test calls to be generated which result in media being
  looped back to the originator.  This document is a strawman proposal
  for a means of performing hop-by-hop traceroute-style test calls
  using the media-loopback mechanism, in order to test the media path
  when SIP sessions go through media-relaying B2BUAs.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-sip-traceroute-00=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-kaplan-dispatch-sip-traceroute-00.=
txt


From HKaplan@acmepacket.com  Fri Oct 14 13:24:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5F21F8CEF for ; Fri, 14 Oct 2011 13:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level: 
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZngZ19QTTVn7 for ; Fri, 14 Oct 2011 13:24:47 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B395821F8CE5 for ; Fri, 14 Oct 2011 13:24:46 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 Oct 2011 16:24:42 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 16:24:43 -0400
From: Hadriel Kaplan 
To: "dispatch@ietf.org list" 
Thread-Topic: BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMiq9OXX9LeDoA90O2vC51RKdIFg==
Date: Fri, 14 Oct 2011 20:24:41 +0000
Message-ID: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Subject: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 20:24:48 -0000

Howdy,
a year ago or so, there was a thread and informal bar-bof around the topic =
of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the conclusi=
on of the discussion, but it appears there was not enough interest at the t=
ime, or perhaps not enough concrete work to do and people to do it.  Since =
that time, we've had several I-Ds which could arguably fit in such a WG, or=
 at least benefit from one, if it applied to B2BUAs in general.

This email is to see if there's interest now, but with a slightly different=
 tack: a concrete WG charter proposal, as described below.

Interest/comments/flames welcomed.


Description of STRAW Working Group
=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
Name: Sip Traversal Required for Applications to Work (STRAW)

Problem Statement:=20
Within the context of the SIP protocol and architecture, a Back-to-Back Use=
r Agent (B2BUA) is any SIP device in the logical path between two User Agen=
ts performing a role beyond that of a Proxy as defined in RFC 3261.  The B2=
BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order =
to terminate dead sessions by generating BYEs; or it may be a 3PCC-style ag=
ent only modifying SDP; or it may be a Session Border Controller performing=
 such functions as in RFC 5853; or it may be an Enterprise PBX terminating =
REFERs and such; or it may be a complete UAS and UAC implementation with a =
PRI loopback in-between.=20

In its most extreme form, the scope of the SIP protocol ends at the UAS of =
the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practic=
e, however, users expect some SIP protocol aspects to go beyond the scope o=
f the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA=
 was not an end unto itself; this is similar to the expectation that emails=
 work when they cross from POP and IMAP to/from SMTP.

It is impossible to normatively define all the behaviors of B2BUAs in gener=
al, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs perf=
orm widely varying functions for purposes which may be unique to their envi=
ronment, unique to their architecture, or unique to the wishes of their adm=
inistrator.  Instead of defining all things a given type of B2BUA must do, =
a more practical objective would be to define what very few things any B2BU=
A must do to make a specific SIP mechanism work, and let the market decide =
whether to do those things.

The name of this working group reflects that practical objective: if there =
were a thin straw between the SIP UAS and UAC of a B2BUA, what must be pass=
ed through that straw and used on each side.  Or viewed another way, if a B=
2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and =
if we could extend ISDN, what information would we carry in ISDN across the=
 PRI for a specific SIP mechanism to work end-to-end.

For example, the WG could produce a document which specifies that the Max-F=
orwards header field value should be copied and decremented across the B2BU=
A, if the B2BUA wishes to prevent loops.  Administrators could then tell th=
eir B2BUA vendors to comply with the document, if the administrator so wish=
es.

Objectives:
The objectives of the STRAW Working Group are to publish normative document=
s which define which SIP header fields, parameters, MIME bodies, body conte=
nt fields/information, or media-plane characteristics are required to trave=
rse between the User Agent "sides" of a B2BUA for specific functions to wor=
k. =20

Deliverables would indicate which types of B2BUAs would apply or not.  For =
example, a document defining the requirements for end-to-end DTLS-SRTP woul=
d not apply to B2BUAs which terminate media, such as transcoders or recorde=
rs.

The intention of this WG is to document such requirements in separate docum=
ents, per SIP or media function, instead of as one document for all functio=
ns.  That will both reduce the time to publication, as well a provide B2BUA=
 administrators and manufacturers with simple comply/no-comply criteria.


Initial Deliverables:
1) A document defining the requirements for B2BUAs to identify specific fea=
tures/capabilities support.
2) A document defining the requirements for B2BUAs with respect to loop det=
ection/prevention.
3) A document defining the requirements for B2BUAs to support end-to-end an=
d hop-by-hop media-loopback test calls.
4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RF=
C 5764) end-to-end.
5) A document defining the requirements for B2BUAs to support STUN connecti=
vity checks end-to-end.

[also add a taxonomy document?]


From kpfleming@digium.com  Fri Oct 14 13:34:11 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6B121F8D0D for ; Fri, 14 Oct 2011 13:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.568
X-Spam-Level: 
X-Spam-Status: No, score=-105.568 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cglUkmZNTS2Q for ; Fri, 14 Oct 2011 13:34:10 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id B180D21F8D09 for ; Fri, 14 Oct 2011 13:34:10 -0700 (PDT)
Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1REoSH-0008GD-SU for dispatch@ietf.org; Fri, 14 Oct 2011 15:34:09 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id D8355D82A3 for ; Fri, 14 Oct 2011 15:34:09 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH+nGosogShP for ; Fri, 14 Oct 2011 15:34:09 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 52696D8024 for ; Fri, 14 Oct 2011 15:34:09 -0500 (CDT)
Message-ID: <4E989CC0.1010701@digium.com>
Date: Fri, 14 Oct 2011 15:34:08 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
In-Reply-To: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 20:34:11 -0000

On 10/14/2011 03:24 PM, Hadriel Kaplan wrote:
> Howdy,
> a year ago or so, there was a thread and informal bar-bof around the topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the conclusion of the discussion, but it appears there was not enough interest at the time, or perhaps not enough concrete work to do and people to do it.  Since that time, we've had several I-Ds which could arguably fit in such a WG, or at least benefit from one, if it applied to B2BUAs in general.
>
> This email is to see if there's interest now, but with a slightly different tack: a concrete WG charter proposal, as described below.
>
> Interest/comments/flames welcomed.
>
>
> Description of STRAW Working Group
> ====================================
> Name: Sip Traversal Required for Applications to Work (STRAW)
>
> Problem Statement:
> Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI loopback in-between.
>
> In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP.
>
> It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator.  Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things.
>
> The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side.  Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end.
>
> For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes.
>
> Objectives:
> The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work.
>
> Deliverables would indicate which types of B2BUAs would apply or not.  For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.
>
> The intention of this WG is to document such requirements in separate documents, per SIP or media function, instead of as one document for all functions.  That will both reduce the time to publication, as well a provide B2BUA administrators and manufacturers with simple comply/no-comply criteria.
>
>
> Initial Deliverables:
> 1) A document defining the requirements for B2BUAs to identify specific features/capabilities support.
> 2) A document defining the requirements for B2BUAs with respect to loop detection/prevention.
> 3) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls.
> 4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end.
> 5) A document defining the requirements for B2BUAs to support STUN connectivity checks end-to-end.
>
> [also add a taxonomy document?]

I would be interested in participating in this effort. I think this is 
an excellent first-draft charter proposal.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

From pkyzivat@alum.mit.edu  Fri Oct 14 14:53:51 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E1921F8D14 for ; Fri, 14 Oct 2011 14:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQehAlpqDFv8 for ; Fri, 14 Oct 2011 14:53:50 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 723BE21F8CE5 for ; Fri, 14 Oct 2011 14:53:24 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id klqJ1h00416LCl05EltQwN; Fri, 14 Oct 2011 21:53:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta06.westchester.pa.mail.comcast.net with comcast id kltP1h0110tdiYw3SltQQs; Fri, 14 Oct 2011 21:53:24 +0000
Message-ID: <4E98AF51.2090704@alum.mit.edu>
Date: Fri, 14 Oct 2011 17:53:21 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
In-Reply-To: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 21:53:51 -0000

Hadriel,

Yes, we had an informal dinner meeting on this, I think in Mastricht. 
(Weren't you at it?) And IIRC we could not convince ourselves that 
anything we might produce would have any effect to justify the effort.

But SBCs continue to be ubiquitous on real deployments, and we continue 
to try to adjust new work so it will work with SBCs without any real 
specifications about how to do that.

So I do think there is justification for work on this subject. But the 
devil is in the details of exactly what the result of the work will be. 
I appreciate your effort to put together a charter that spells out a 
work plan. I think it is a reasonable start. But we should hammer on it, 
and eventually polish it, until we have a really clear direction that 
people buy into.

I'd be interested in working on this.

More inline.

	Thanks,
	Paul

On 10/14/11 4:24 PM, Hadriel Kaplan wrote:
> Howdy,
> a year ago or so, there was a thread and informal bar-bof around the topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the conclusion of the discussion, but it appears there was not enough interest at the time, or perhaps not enough concrete work to do and people to do it.  Since that time, we've had several I-Ds which could arguably fit in such a WG, or at least benefit from one, if it applied to B2BUAs in general.
>
> This email is to see if there's interest now, but with a slightly different tack: a concrete WG charter proposal, as described below.
>
> Interest/comments/flames welcomed.
>
>
> Description of STRAW Working Group
> ====================================
> Name: Sip Traversal Required for Applications to Work (STRAW)
>
> Problem Statement:
> Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI loopback in-between.
>
> In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP.
>
> It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator.  Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things.
>
> The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side.  Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end.
>
> For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes.
>
> Objectives:
> The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work.

The key above is "for specific functions to work".
IMO enumerating what those things are will be a real task.
Even defining what sorts of things ought to be considered "functions" 
may be hard.

I think we need to at least agree as part of the charter what sorts of 
things need to be enumerated.

> Deliverables would indicate which types of B2BUAs would apply or not.

In the problem statement you seemed to declining to define types of 
B2BUAs. But here you seem to be suggesting that we have such a 
classification.

While I think the potential functions of B2BUAs is unbounded, I suspect 
it is possible to define some interesting types, and constrain what they 
do sufficiently to be useful.

SIP already did this, to a lesser degree than you are seeking: UA, 
Proxy, Registrar, Focus, Transcoder. (Transcoder is defined in 5369, but 
not in a form that puts it in the signaling path between UAC and UAS.)

> For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.
>
> The intention of this WG is to document such requirements in separate documents, per SIP or media function, instead of as one document for all functions.  That will both reduce the time to publication, as well a provide B2BUA administrators and manufacturers with simple comply/no-comply criteria.
>
>
> Initial Deliverables:
> 1) A document defining the requirements for B2BUAs to identify specific features/capabilities support.
> 2) A document defining the requirements for B2BUAs with respect to loop detection/prevention.
> 3) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls.
> 4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end.
> 5) A document defining the requirements for B2BUAs to support STUN connectivity checks end-to-end.

So, from the above I conclude that some examples of the "functions" you 
are considering are: loop detection/prevention, media-loopback test 
calls, media connectivity, media security.

> [also add a taxonomy document?]

Maybe two: taxonomy of functions, taxonomy of B2BUA types.



From HKaplan@acmepacket.com  Fri Oct 14 16:17:10 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D8121F8CBF for ; Fri, 14 Oct 2011 16:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level: 
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.105,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6mQgofPqbkZ for ; Fri, 14 Oct 2011 16:17:09 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 98F0D21F8B1D for ; Fri, 14 Oct 2011 16:17:09 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 Oct 2011 19:17:08 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 19:17:08 -0400
From: Hadriel Kaplan 
To: Paul Kyzivat 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMisdkZeImkHYNAECIP5mIbqvV+A==
Date: Fri, 14 Oct 2011 23:17:07 +0000
Message-ID: 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <4E98AF51.2090704@alum.mit.edu>
In-Reply-To: <4E98AF51.2090704@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 23:17:10 -0000

On Oct 14, 2011, at 5:53 PM, Paul Kyzivat wrote:

> Yes, we had an informal dinner meeting on this, I think in Mastricht. (We=
ren't you at it?)

Not as far as I can recall. (and no I didn't partake of the "coffee shops" =
in Maastricht :)


> The key above is "for specific functions to work".
> IMO enumerating what those things are will be a real task.
> Even defining what sorts of things ought to be considered "functions" may=
 be hard.
> I think we need to at least agree as part of the charter what sorts of th=
ings need to be enumerated.

You mean agree on what specific things in the future could be included in t=
he charter in the future?

I'm thinking of just using the deliverables list for that level of detail. =
 Any change to deliverables requires a re-charter/update anyway right?  So =
we get to decide if something new is reasonable at that time.


>=20
>> Deliverables would indicate which types of B2BUAs would apply or not.
>=20
> In the problem statement you seemed to declining to define types of B2BUA=
s. But here you seem to be suggesting that we have such a classification.

In the deliverable itself, ie inside the specific document/RFC, rather than=
 saying the STRAW working group would only cover "SBCs" for example.=20

But I was thinking we could have a taxonomy doc which enumerated B2BUA type=
s as much as possible, so that the individual docs could just use the terms=
 without repetition.

>>=20
>> Initial Deliverables:
>> 1) A document defining the requirements for B2BUAs to identify specific =
features/capabilities support.
>> 2) A document defining the requirements for B2BUAs with respect to loop =
detection/prevention.
>> 3) A document defining the requirements for B2BUAs to support end-to-end=
 and hop-by-hop media-loopback test calls.
>> 4) A document defining the requirements for B2BUAs to support DTLS-SRTP =
(RFC 5764) end-to-end.
>> 5) A document defining the requirements for B2BUAs to support STUN conne=
ctivity checks end-to-end.
>=20
> So, from the above I conclude that some examples of the "functions" you a=
re considering are: loop detection/prevention, media-loopback test calls, m=
edia connectivity, media security.

Ahh, no.  By "function" I didn't mean high-level thing like "media security=
".  I meant for a specific capability/extension/usage - i.e., one for DTLS-=
SRTP, a separate one for SDES, etc.  At least as a general rule I would exp=
ect discrete documents on discrete capabilities.  Obviously it would be up =
to the WG to decide that on a case-by-case basis anyway, and for DTLS-SRTP/=
SDES-SRTP they may decide to do both in one RFC.  I mean WG's make those ty=
pes of decisions on deliverables in general anyway, but I put it in the cha=
rter as a guideline, so the WG would consciously make such a decision. (I g=
uess this seems silly in hindsight)

-hadriel


From marshall.eubanks@gmail.com  Fri Oct 14 16:56:51 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2E21F8C78 for ; Fri, 14 Oct 2011 16:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.524
X-Spam-Level: 
X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyyyn9PTRyWV for ; Fri, 14 Oct 2011 16:56:50 -0700 (PDT)
Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 792F521F8C6F for ; Fri, 14 Oct 2011 16:56:50 -0700 (PDT)
Received: by ywp17 with SMTP id 17so4205041ywp.27 for ; Fri, 14 Oct 2011 16:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dHTbh1GKnUKfTPxzYr1UxusoSABcgnTtRNja5kNHfh0=; b=A2L8YqTD06gFrvUhZSD374JgdoJ4zAZy+rGpZbn7NuGyuU9tDFpQlh36AfWcBnw00Y nroclYEzNG9dvapaLvQT2zKHFLo8ZVsheeX2cI7sUzbgv/SddtNjZo1MpCcutX47QtFZ aYwQ5iFXNVYqZ1bCerAjHpj7soLu1tBlFISAY=
MIME-Version: 1.0
Received: by 10.182.131.34 with SMTP id oj2mr6560049obb.71.1318636609891; Fri, 14 Oct 2011 16:56:49 -0700 (PDT)
Received: by 10.182.111.7 with HTTP; Fri, 14 Oct 2011 16:56:49 -0700 (PDT)
In-Reply-To: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
Date: Fri, 14 Oct 2011 19:56:49 -0400
Message-ID: 
From: Marshall Eubanks 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2011 23:56:51 -0000

Dear Hadriel;

On Fri, Oct 14, 2011 at 4:24 PM, Hadriel Kaplan  wr=
ote:
> Howdy,
> a year ago or so, there was a thread and informal bar-bof around the topi=
c of "Should the IETF have a BEHAVE WG for SBCs".

Yes. I organized this, at Maastricht, although it wasn't BEHAVE
specific. The conclusion was that SBCs had gotten away from us (i.e.,
that there is no standard definition of what an SBC does) and so there
wasn't consensus to take this further inside the IETF.

Regards
Marshall

=A0I do not know the conclusion of the discussion, but it appears there
was not enough interest at the time, or perhaps not enough concrete
work to do and people to do it. =A0Since that time, we've had several
I-Ds which could arguably fit in such a WG, or at least benefit from
one, if it applied to B2BUAs in general.
>
> This email is to see if there's interest now, but with a slightly differe=
nt tack: a concrete WG charter proposal, as described below.
>
> Interest/comments/flames welcomed.
>
>
> Description of STRAW Working Group
> =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
> Name: Sip Traversal Required for Applications to Work (STRAW)
>
> Problem Statement:
> Within the context of the SIP protocol and architecture, a Back-to-Back U=
ser Agent (B2BUA) is any SIP device in the logical path between two User Ag=
ents performing a role beyond that of a Proxy as defined in RFC 3261. =A0Th=
e B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in or=
der to terminate dead sessions by generating BYEs; or it may be a 3PCC-styl=
e agent only modifying SDP; or it may be a Session Border Controller perfor=
ming such functions as in RFC 5853; or it may be an Enterprise PBX terminat=
ing REFERs and such; or it may be a complete UAS and UAC implementation wit=
h a PRI loopback in-between.
>
> In its most extreme form, the scope of the SIP protocol ends at the UAS o=
f the B2BUA, and a new SIP protocol scope begins on its UAC side. =A0In pra=
ctice, however, users expect some SIP protocol aspects to go beyond the sco=
pe of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B=
2BUA was not an end unto itself; this is similar to the expectation that em=
ails work when they cross from POP and IMAP to/from SMTP.
>
> It is impossible to normatively define all the behaviors of B2BUAs in gen=
eral, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs pe=
rform widely varying functions for purposes which may be unique to their en=
vironment, unique to their architecture, or unique to the wishes of their a=
dministrator. =A0Instead of defining all things a given type of B2BUA must =
do, a more practical objective would be to define what very few things any =
B2BUA must do to make a specific SIP mechanism work, and let the market dec=
ide whether to do those things.
>
> The name of this working group reflects that practical objective: if ther=
e were a thin straw between the SIP UAS and UAC of a B2BUA, what must be pa=
ssed through that straw and used on each side. =A0Or viewed another way, if=
 a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, =
and if we could extend ISDN, what information would we carry in ISDN across=
 the PRI for a specific SIP mechanism to work end-to-end.
>
> For example, the WG could produce a document which specifies that the Max=
-Forwards header field value should be copied and decremented across the B2=
BUA, if the B2BUA wishes to prevent loops. =A0Administrators could then tel=
l their B2BUA vendors to comply with the document, if the administrator so =
wishes.
>
> Objectives:
> The objectives of the STRAW Working Group are to publish normative docume=
nts which define which SIP header fields, parameters, MIME bodies, body con=
tent fields/information, or media-plane characteristics are required to tra=
verse between the User Agent "sides" of a B2BUA for specific functions to w=
ork.
>
> Deliverables would indicate which types of B2BUAs would apply or not. =A0=
For example, a document defining the requirements for end-to-end DTLS-SRTP =
would not apply to B2BUAs which terminate media, such as transcoders or rec=
orders.
>
> The intention of this WG is to document such requirements in separate doc=
uments, per SIP or media function, instead of as one document for all funct=
ions. =A0That will both reduce the time to publication, as well a provide B=
2BUA administrators and manufacturers with simple comply/no-comply criteria=
.
>
>
> Initial Deliverables:
> 1) A document defining the requirements for B2BUAs to identify specific f=
eatures/capabilities support.
> 2) A document defining the requirements for B2BUAs with respect to loop d=
etection/prevention.
> 3) A document defining the requirements for B2BUAs to support end-to-end =
and hop-by-hop media-loopback test calls.
> 4) A document defining the requirements for B2BUAs to support DTLS-SRTP (=
RFC 5764) end-to-end.
> 5) A document defining the requirements for B2BUAs to support STUN connec=
tivity checks end-to-end.
>
> [also add a taxonomy document?]
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

From HKaplan@acmepacket.com  Fri Oct 14 22:31:53 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A768521F8A58 for ; Fri, 14 Oct 2011 22:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level: 
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ0tKi9LNjyC for ; Fri, 14 Oct 2011 22:31:53 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 01CCE21F86DD for ; Fri, 14 Oct 2011 22:31:52 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 15 Oct 2011 01:31:49 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 15 Oct 2011 01:31:49 -0400
From: Hadriel Kaplan 
To: "dispatch@ietf.org list" 
Thread-Topic: B2BUA-taxonomy for STRAW WG
Thread-Index: AQHMivu8XavJOl9Oz0qGnxQdIgTq3g==
Date: Sat, 15 Oct 2011 05:31:48 +0000
Message-ID: <84B0F69E-5BB5-41FD-A331-6C7B469C0EB2@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Subject: [dispatch] B2BUA-taxonomy for STRAW WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Oct 2011 05:31:53 -0000

As part of the proposed STRAW WG charter, a possible deliverable might be a=
 taxonomy document of B2BUA roles as might be useful for STRAW WG work item=
s to reference.

I have submitted such an I-D, referenced below, as a straw-man proposal. (o=
h yeah the puns have begun)


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

	Title           : A Taxonomy of Session Initiation Protocol (SIP) Back-to-=
Back User Agents
	Author(s)       : Hadriel Kaplan
	Filename        : draft-kaplan-dispatch-b2bua-taxonomy-00.txt
	Pages           : 8
	Date            : 2011-10-14

  There are numerous types of SIP Back-to-Back User Agents (B2BUAs),
  performing different roles in different ways.  This document
  identifies several common B2BUA roles, in order to provide taxonomy
  other documents can use and reference.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-b2bua-taxonomy-00=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-kaplan-dispatch-b2bua-taxonomy-00.=
txt


From keith.drage@alcatel-lucent.com  Sat Oct 15 05:52:56 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34121F8B1A for ; Sat, 15 Oct 2011 05:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah48tsxHXOg6 for ; Sat, 15 Oct 2011 05:52:55 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4F93721F8B15 for ; Sat, 15 Oct 2011 05:52:51 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9FCqk6h005192 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 15 Oct 2011 14:52:46 +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; Sat, 15 Oct 2011 14:52:46 +0200
From: "DRAGE, Keith (Keith)" 
To: Paul Kyzivat , "dispatch@ietf.org" 
Date: Sat, 15 Oct 2011 14:52:45 +0200
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AcyKu8aqem2Z0BN3Qim3a8wh6dGPFAAMkyNw
Message-ID: 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <4E98AF51.2090704@alum.mit.edu>
In-Reply-To: <4E98AF51.2090704@alum.mit.edu>
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.69 on 155.132.188.13
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Oct 2011 12:52:56 -0000

The essential blocker in Maastricht was that noone could identify a plan of=
 work where it was expected that there might be consensus on the output.

Has that changed?

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: 14 October 2011 22:53
> To: dispatch@ietf.org
> Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
>=20
> Hadriel,
>=20
> Yes, we had an informal dinner meeting on this, I think in Mastricht.
> (Weren't you at it?) And IIRC we could not convince ourselves that
> anything we might produce would have any effect to justify the effort.
>=20
> But SBCs continue to be ubiquitous on real deployments, and we continue
> to try to adjust new work so it will work with SBCs without any real
> specifications about how to do that.
>=20
> So I do think there is justification for work on this subject. But the
> devil is in the details of exactly what the result of the work will be.
> I appreciate your effort to put together a charter that spells out a
> work plan. I think it is a reasonable start. But we should hammer on it,
> and eventually polish it, until we have a really clear direction that
> people buy into.
>=20
> I'd be interested in working on this.
>=20
> More inline.
>=20
> 	Thanks,
> 	Paul
>=20
> On 10/14/11 4:24 PM, Hadriel Kaplan wrote:
> > Howdy,
> > a year ago or so, there was a thread and informal bar-bof around the
> topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the
> conclusion of the discussion, but it appears there was not enough interes=
t
> at the time, or perhaps not enough concrete work to do and people to do
> it.  Since that time, we've had several I-Ds which could arguably fit in
> such a WG, or at least benefit from one, if it applied to B2BUAs in
> general.
> >
> > This email is to see if there's interest now, but with a slightly
> different tack: a concrete WG charter proposal, as described below.
> >
> > Interest/comments/flames welcomed.
> >
> >
> > Description of STRAW Working Group
> > =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
> > Name: Sip Traversal Required for Applications to Work (STRAW)
> >
> > Problem Statement:
> > Within the context of the SIP protocol and architecture, a Back-to-Back
> User Agent (B2BUA) is any SIP device in the logical path between two User
> Agents performing a role beyond that of a Proxy as defined in RFC 3261.
> The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA i=
n
> order to terminate dead sessions by generating BYEs; or it may be a 3PCC-
> style agent only modifying SDP; or it may be a Session Border Controller
> performing such functions as in RFC 5853; or it may be an Enterprise PBX
> terminating REFERs and such; or it may be a complete UAS and UAC
> implementation with a PRI loopback in-between.
> >
> > In its most extreme form, the scope of the SIP protocol ends at the UAS
> of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In
> practice, however, users expect some SIP protocol aspects to go beyond th=
e
> scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if
> the B2BUA was not an end unto itself; this is similar to the expectation
> that emails work when they cross from POP and IMAP to/from SMTP.
> >
> > It is impossible to normatively define all the behaviors of B2BUAs in
> general, or even subsets of them such as SBCs. Unlike consumer NATs,
> B2BUAs perform widely varying functions for purposes which may be unique
> to their environment, unique to their architecture, or unique to the
> wishes of their administrator.  Instead of defining all things a given
> type of B2BUA must do, a more practical objective would be to define what
> very few things any B2BUA must do to make a specific SIP mechanism work,
> and let the market decide whether to do those things.
> >
> > The name of this working group reflects that practical objective: if
> there were a thin straw between the SIP UAS and UAC of a B2BUA, what must
> be passed through that straw and used on each side.  Or viewed another
> way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback
> circuit, and if we could extend ISDN, what information would we carry in
> ISDN across the PRI for a specific SIP mechanism to work end-to-end.
> >
> > For example, the WG could produce a document which specifies that the
> Max-Forwards header field value should be copied and decremented across
> the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could
> then tell their B2BUA vendors to comply with the document, if the
> administrator so wishes.
> >
> > Objectives:
> > The objectives of the STRAW Working Group are to publish normative
> documents which define which SIP header fields, parameters, MIME bodies,
> body content fields/information, or media-plane characteristics are
> required to traverse between the User Agent "sides" of a B2BUA for
> specific functions to work.
>=20
> The key above is "for specific functions to work".
> IMO enumerating what those things are will be a real task.
> Even defining what sorts of things ought to be considered "functions"
> may be hard.
>=20
> I think we need to at least agree as part of the charter what sorts of
> things need to be enumerated.
>=20
> > Deliverables would indicate which types of B2BUAs would apply or not.
>=20
> In the problem statement you seemed to declining to define types of
> B2BUAs. But here you seem to be suggesting that we have such a
> classification.
>=20
> While I think the potential functions of B2BUAs is unbounded, I suspect
> it is possible to define some interesting types, and constrain what they
> do sufficiently to be useful.
>=20
> SIP already did this, to a lesser degree than you are seeking: UA,
> Proxy, Registrar, Focus, Transcoder. (Transcoder is defined in 5369, but
> not in a form that puts it in the signaling path between UAC and UAS.)
>=20
> > For example, a document defining the requirements for end-to-end DTLS-
> SRTP would not apply to B2BUAs which terminate media, such as transcoders
> or recorders.
> >
> > The intention of this WG is to document such requirements in separate
> documents, per SIP or media function, instead of as one document for all
> functions.  That will both reduce the time to publication, as well a
> provide B2BUA administrators and manufacturers with simple comply/no-
> comply criteria.
> >
> >
> > Initial Deliverables:
> > 1) A document defining the requirements for B2BUAs to identify specific
> features/capabilities support.
> > 2) A document defining the requirements for B2BUAs with respect to loop
> detection/prevention.
> > 3) A document defining the requirements for B2BUAs to support end-to-en=
d
> and hop-by-hop media-loopback test calls.
> > 4) A document defining the requirements for B2BUAs to support DTLS-SRTP
> (RFC 5764) end-to-end.
> > 5) A document defining the requirements for B2BUAs to support STUN
> connectivity checks end-to-end.
>=20
> So, from the above I conclude that some examples of the "functions" you
> are considering are: loop detection/prevention, media-loopback test
> calls, media connectivity, media security.
>=20
> > [also add a taxonomy document?]
>=20
> Maybe two: taxonomy of functions, taxonomy of B2BUA types.
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From salvatore.loreto@ericsson.com  Sat Oct 15 08:29:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876F521F8A7E for ; Sat, 15 Oct 2011 08:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3S3onQsyRqu for ; Sat, 15 Oct 2011 08:29:46 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3661D21F8A7D for ; Sat, 15 Oct 2011 08:29:46 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-dd-4e99a6e622aa
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E6.57.20773.6E6A99E4; Sat, 15 Oct 2011 17:29:42 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Sat, 15 Oct 2011 17:29:42 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 42021245F	for ; Sat, 15 Oct 2011 18:29:42 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EE1D7517B1	for ; Sat, 15 Oct 2011 18:29:41 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8EFB650832	for ; Sat, 15 Oct 2011 18:29:41 +0300 (EEST)
Message-ID: <4E99A6E5.7000608@ericsson.com>
Date: Sat, 15 Oct 2011 18:29:41 +0300
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
In-Reply-To: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Oct 2011 15:29:47 -0000

the subject is really interesting,
I like the idea to concentrate on a thin straw between the SIP UAS and UAC,
and specified what should (not sure if we can say MUST) be passed 
through that straw and used on each side.

this is a good start for a concrete charter proposal.

Ciao
Sal

-- 
Salvatore Loreto
www.sloreto.com



On 10/14/11 11:24 PM, Hadriel Kaplan wrote:
> Howdy,
> a year ago or so, there was a thread and informal bar-bof around the topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the conclusion of the discussion, but it appears there was not enough interest at the time, or perhaps not enough concrete work to do and people to do it.  Since that time, we've had several I-Ds which could arguably fit in such a WG, or at least benefit from one, if it applied to B2BUAs in general.
>
> This email is to see if there's interest now, but with a slightly different tack: a concrete WG charter proposal, as described below.
>
> Interest/comments/flames welcomed.
>
>
> Description of STRAW Working Group
> ====================================
> Name: Sip Traversal Required for Applications to Work (STRAW)
>
> Problem Statement:
> Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI loopback in-between.
>
> In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP.
>
> It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator.  Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things.
>
> The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side.  Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end.
>
> For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes.
>
> Objectives:
> The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work.
>
> Deliverables would indicate which types of B2BUAs would apply or not.  For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.
>
> The intention of this WG is to document such requirements in separate documents, per SIP or media function, instead of as one document for all functions.  That will both reduce the time to publication, as well a provide B2BUA administrators and manufacturers with simple comply/no-comply criteria.
>
>
> Initial Deliverables:
> 1) A document defining the requirements for B2BUAs to identify specific features/capabilities support.
> 2) A document defining the requirements for B2BUAs with respect to loop detection/prevention.
> 3) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls.
> 4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end.
> 5) A document defining the requirements for B2BUAs to support STUN connectivity checks end-to-end.
>
> [also add a taxonomy document?]
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>


From pravindran@sonusnet.com  Sun Oct 16 23:05:15 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AFC1F0C36 for ; Sun, 16 Oct 2011 23:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhMhfXc8OESQ for ; Sun, 16 Oct 2011 23:05:14 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 87CAA1F0C35 for ; Sun, 16 Oct 2011 23:05:14 -0700 (PDT)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9H65jBO004849;  Mon, 17 Oct 2011 02:05:45 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 17 Oct 2011 02:05:10 -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: Mon, 17 Oct 2011 11:35:20 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMisdkZeImkHYNAECIP5mIbqvV+JV/9TKw
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com><4E98AF51.2090704@alum.mit.edu> 
From: "Ravindran Parthasarathi" 
To: "Hadriel Kaplan" , "Paul Kyzivat" 
X-OriginalArrivalTime: 17 Oct 2011 06:05:10.0836 (UTC) FILETIME=[BA76BF40:01CC8C92]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 06:05:15 -0000

Hadriel,

As Paul & others mentioned, there is a Bar Bof on SBC (one kind of
B2BUA) discussion in IETF-78 and there is no convergence. The aim of the
SBC Bar BOF meeting was to come up with Behave for SBC and not generic
B2BUA. The conclusion of the Bar BOF was that there is no way to define
exactly whatz SBC is in IETF? Also, it is possible to fix some of the
SBC issues in case the pattern of the issues is spelt out correctly in
IETF.=20

Looking at the some of the proposed B2BUA work item, I guess that your
proposal is more lean towards B2BUA with media relay (RTP translator or
RTP endpoint to RTP endpoint) functionality. Some of the B2BUA
(Signaling only SBC) are signaling boxes and does not handle media
directly. In case B2BUA performs supplementary services handling, the
behavior is very different from passing the signaling through B2BUA.
Another variant wherein B2BUA with supplementary services may acts as
RTP translator. All the behavior are supported by different SBC in the
deployment. Hope you agree with me.

Infact, SIPConnect 1.1 standardization helps interop between SP SBC and
Enterprise SBC. Whether SIPConnect 1.2 shall solve your proposed issues
as the basic interop is ensured through SIPConnect 1.1. Here I'm
interested to know how this WG is different from what SIPConnect
achieves.

Also, most of your WG items are related to media (STUN, DTLS-SRTP,
SDES-SRTP). There is an existing WG item
(draft-ietf-mmusic-media-path-middleboxes-03.txt) which shall solve some
of the problem in case there is proper review and consensus.  =20

I'll be interested in your charter in case your charter is different
from future extension possibility of SIPConnect 1.2,
draft-ietf-mmusic-media-path-middleboxes-03.txt (SDP offer/answer),
session-id charter (loop detection),
draft-ietf-mmusic-media-loopback-16(media loopback). BTW, I guess that
hop-by-hop media loopback was proposed earlier.

Thanks
Partha



>-----Original Message-----
>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
>Behalf Of Hadriel Kaplan
>Sent: Saturday, October 15, 2011 4:47 AM
>To: Paul Kyzivat
>Cc: 
>Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
>
>
>On Oct 14, 2011, at 5:53 PM, Paul Kyzivat wrote:
>
>> Yes, we had an informal dinner meeting on this, I think in
Maastricht.
>(Weren't you at it?)
>
>Not as far as I can recall. (and no I didn't partake of the "coffee
>shops" in Maastricht :)
>
>
>> The key above is "for specific functions to work".
>> IMO enumerating what those things are will be a real task.
>> Even defining what sorts of things ought to be considered "functions"
>may be hard.
>> I think we need to at least agree as part of the charter what sorts
of
>things need to be enumerated.
>
>You mean agree on what specific things in the future could be included
>in the charter in the future?
>
>I'm thinking of just using the deliverables list for that level of
>detail.  Any change to deliverables requires a re-charter/update anyway
>right?  So we get to decide if something new is reasonable at that
time.
>
>
>>
>>> Deliverables would indicate which types of B2BUAs would apply or
not.
>>
>> In the problem statement you seemed to declining to define types of
>B2BUAs. But here you seem to be suggesting that we have such a
>classification.
>
>In the deliverable itself, ie inside the specific document/RFC, rather
>than saying the STRAW working group would only cover "SBCs" for
example.
>
>But I was thinking we could have a taxonomy doc which enumerated B2BUA
>types as much as possible, so that the individual docs could just use
>the terms without repetition.
>
>>>
>>> Initial Deliverables:
>>> 1) A document defining the requirements for B2BUAs to identify
>specific features/capabilities support.
>>> 2) A document defining the requirements for B2BUAs with respect to
>loop detection/prevention.
>>> 3) A document defining the requirements for B2BUAs to support
end-to-
>end and hop-by-hop media-loopback test calls.
>>> 4) A document defining the requirements for B2BUAs to support DTLS-
>SRTP (RFC 5764) end-to-end.
>>> 5) A document defining the requirements for B2BUAs to support STUN
>connectivity checks end-to-end.
>>
>> So, from the above I conclude that some examples of the "functions"
>you are considering are: loop detection/prevention, media-loopback test
>calls, media connectivity, media security.
>
>Ahh, no.  By "function" I didn't mean high-level thing like "media
>security".  I meant for a specific capability/extension/usage - i.e.,
>one for DTLS-SRTP, a separate one for SDES, etc.  At least as a general
>rule I would expect discrete documents on discrete capabilities.
>Obviously it would be up to the WG to decide that on a case-by-case
>basis anyway, and for DTLS-SRTP/SDES-SRTP they may decide to do both in
>one RFC.  I mean WG's make those types of decisions on deliverables in
>general anyway, but I put it in the charter as a guideline, so the WG
>would consciously make such a decision. (I guess this seems silly in
>hindsight)
>
>-hadriel
>
>_______________________________________________
>dispatch mailing list
>dispatch@ietf.org
>https://www.ietf.org/mailman/listinfo/dispatch

From R.Jesske@telekom.de  Sun Oct 16 23:16:22 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24F01F0C35 for ; Sun, 16 Oct 2011 23:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-bl7hw1XDWk for ; Sun, 16 Oct 2011 23:16:21 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFD621F8551 for ; Sun, 16 Oct 2011 23:16:21 -0700 (PDT)
Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 17 Oct 2011 08:16:16 +0200
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.163]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 17 Oct 2011 08:16:16 +0200
From: 
To: , , , , 
Date: Mon, 17 Oct 2011 08:16:14 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMifLA8qKPDawAXUG+zw9urVC4u5V7EeRigACbP0CAAATiQIAEYpGw
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0969A75CCF@HE111648.emea1.cds.t-internal.com>
References:    <7A051DFAA46D0246A82293C7CEF621E9056D5BA21E@ESESSCMS0352.eemea.ericsson.se>
In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E9056D5BA21E@ESESSCMS0352.eemea.ericsson.se>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 06:16:22 -0000

+1

Mit freundlichen Gr=FC=DFen
Roland Jesske


Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 58 12766 (Tel.)
+49 391 580 133 831 (Fax)
+49 171 8618-445  (Mobil)
E-Mail: mailto:r.jesske@telekom.de
http://www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe=
is, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede=
 E-Mail drucken.


> -----Urspr=FCngliche Nachricht-----
> Von: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Atle Monrad
> Gesendet: Freitag, 14. Oktober 2011 13:20
> An: DOLLY, MARTIN C; Andrew Allen; dworley@avaya.com;
> dispatch@ietf.org
> Betreff: Re: [dispatch] draft-montemurro-gsma-imei-urn
> anddraft-allen-dispatch-imei-urn-as-instanceid
>
> Hi
>
> I would like to team up with the persons supporting progress
> of these drafts.
>
> /atle
>
> ________________________________
>
>
> Atle Monrad
> 3GPP CT Chairman
> Standardization and Regulation,
> Group Function Technology and Portfolio Management
> Ericsson
>
>
>
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
> Sent: 14. oktober 2011 13:01
> To: Andrew Allen; dworley@avaya.com; dispatch@ietf.org
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn
> anddraft-allen-dispatch-imei-urn-as-instanceid
>
> Agreed, please progress these drafts.
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Andrew Allen
> Sent: Thursday, October 13, 2011 9:45 PM
> To: dworley@avaya.com; dispatch@ietf.org
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn
> anddraft-allen-dispatch-imei-urn-as-instanceid
>
>
> +1
>
>
> ----- Original Message -----
> From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]
> Sent: Thursday, October 13, 2011 04:55 PM
> To: dispatch@ietf.org 
> Subject: [dispatch] draft-montemurro-gsma-imei-urn
> anddraft-allen-dispatch-imei-urn-as-instanceid
>
> > From: "Worley, Dale R (Dale)" 
> > Date: Thu, 15 Sep 2011 11:46:35 -0400
> >
> > (1) I formally request the chairs to recognize that rough consensus
> > has been reached that the work described in
> > draft-montemurro-gsma-imei-urn and
> > draft-allen-dispatch-imei-urn-as-instanceid should
> progress, and those
> > proposals be dispatched to an appropriate working group.
>
> Seeing that I have published a list of the issues that might
> be significant in this discussion
> (http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
> and seeing that no response has been made by *anybody*
> regarding that list, and seeing that the stated opinions on
> the WG mailing list remain at 17 favorable (hailing from at
> least 15 different
> organizations) and 1 unfavorable...
>
> For a second time, I formally request the chairs to recognize
> that rough consensus has been reached that the work described
> in draft-montemurro-gsma-imei-urn and
> draft-allen-dispatch-imei-urn-as-instanceid should progress,
> and those proposals be dispatched to an appropriate working
> group (which in this case means an appropriate mailing list
> for discussion of an AD-sponsired I-D).
>
> Dale
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain
> confidential information, privileged material (including
> material protected by the solicitor-client or other
> applicable privileges), or constitute non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender
> and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and
> may be unlawful.
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

From jan.van.geel@belgacom.be  Sun Oct 16 23:32:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5211E808B for ; Sun, 16 Oct 2011 23:32:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BDjIFECUmqf for ; Sun, 16 Oct 2011 23:32:46 -0700 (PDT)
Received: from mx24.belgacom.be (mx24.belgacom.be [213.181.45.234]) by ietfa.amsl.com (Postfix) with ESMTP id A45B611E8087 for ; Sun, 16 Oct 2011 23:32:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.69,357,1315173600"; d="scan'208";a="14889263"
Received: from unknown (HELO A03007.BGC.NET) ([10.120.129.162]) by mx24.belgacom.be with ESMTP; 17 Oct 2011 08:31:34 +0200
X-TM-IMSS-Message-ID: <216be01300015a55@belgacom.be>
Received: from A03167.BGC.NET ([45.223.1.34]) by belgacom.be ([10.120.129.162]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 216be01300015a55 ; Mon, 17 Oct 2011 08:31:33 +0200
Received: from CMS03.BGC.NET ([169.254.1.90]) by A03167.BGC.NET ([45.223.1.34]) with mapi; Mon, 17 Oct 2011 08:31:33 +0200
From: "VAN GEEL Jan (SDV/PSE)" 
To: "dispatch@ietf.org" 
Date: Mon, 17 Oct 2011 08:31:32 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMifLA8qKPDawAXUG+zw9urVC4u5V7EeRigACbP0CAAATiQIAEYpGwgAAD3EA=
Message-ID: <208EAE1DFA28FC419529619ABB8622441B8CDA5A12@CMS03.BGC.NET>
References:    <7A051DFAA46D0246A82293C7CEF621E9056D5BA21E@ESESSCMS0352.eemea.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D0969A75CCF@HE111648.emea1.cds.t-internal.com>
In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0969A75CCF@HE111648.emea1.cds.t-internal.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 06:32:47 -0000

+1

Jan Van Geel
IT and Network Specialist
Belgacom SDE/SDV/PSE/FVC
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : jan.van.geel@belgacom.be



-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of R.Jesske@telekom.de
Sent: 17 October 2011 08:16
To: atle.monrad@ericsson.com; md3135@att.com; aallen@rim.com; dworley@avaya=
.com; dispatch@ietf.org
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispa=
tch-imei-urn-as-instanceid

+1

Mit freundlichen Gr=FC=DFen
Roland Jesske


Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 58 12766 (Tel.)
+49 391 580 133 831 (Fax)
+49 171 8618-445  (Mobil)
E-Mail: mailto:r.jesske@telekom.de
http://www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe=
is, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede=
 E-Mail drucken.


> -----Urspr=FCngliche Nachricht-----
> Von: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Atle Monrad
> Gesendet: Freitag, 14. Oktober 2011 13:20
> An: DOLLY, MARTIN C; Andrew Allen; dworley@avaya.com;
> dispatch@ietf.org
> Betreff: Re: [dispatch] draft-montemurro-gsma-imei-urn
> anddraft-allen-dispatch-imei-urn-as-instanceid
>
> Hi
>
> I would like to team up with the persons supporting progress
> of these drafts.
>
> /atle
>
> ________________________________
>
>
> Atle Monrad
> 3GPP CT Chairman
> Standardization and Regulation,
> Group Function Technology and Portfolio Management
> Ericsson
>
>
>
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
> Sent: 14. oktober 2011 13:01
> To: Andrew Allen; dworley@avaya.com; dispatch@ietf.org
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn
> anddraft-allen-dispatch-imei-urn-as-instanceid
>
> Agreed, please progress these drafts.
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Andrew Allen
> Sent: Thursday, October 13, 2011 9:45 PM
> To: dworley@avaya.com; dispatch@ietf.org
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn
> anddraft-allen-dispatch-imei-urn-as-instanceid
>
>
> +1
>
>
> ----- Original Message -----
> From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]
> Sent: Thursday, October 13, 2011 04:55 PM
> To: dispatch@ietf.org 
> Subject: [dispatch] draft-montemurro-gsma-imei-urn
> anddraft-allen-dispatch-imei-urn-as-instanceid
>
> > From: "Worley, Dale R (Dale)" 
> > Date: Thu, 15 Sep 2011 11:46:35 -0400
> >
> > (1) I formally request the chairs to recognize that rough consensus
> > has been reached that the work described in
> > draft-montemurro-gsma-imei-urn and
> > draft-allen-dispatch-imei-urn-as-instanceid should
> progress, and those
> > proposals be dispatched to an appropriate working group.
>
> Seeing that I have published a list of the issues that might
> be significant in this discussion
> (http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
> and seeing that no response has been made by *anybody*
> regarding that list, and seeing that the stated opinions on
> the WG mailing list remain at 17 favorable (hailing from at
> least 15 different
> organizations) and 1 unfavorable...
>
> For a second time, I formally request the chairs to recognize
> that rough consensus has been reached that the work described
> in draft-montemurro-gsma-imei-urn and
> draft-allen-dispatch-imei-urn-as-instanceid should progress,
> and those proposals be dispatched to an appropriate working
> group (which in this case means an appropriate mailing list
> for discussion of an AD-sponsired I-D).
>
> Dale
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain
> confidential information, privileged material (including
> material protected by the solicitor-client or other
> applicable privileges), or constitute non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender
> and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and
> may be unlawful.
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

*****  Disclaimer *****
http://www.belgacom.be/maildisclaimer/

From HKaplan@acmepacket.com  Mon Oct 17 07:34:49 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85D521F8B98 for ; Mon, 17 Oct 2011 07:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level: 
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acJeW4VJFJ5a for ; Mon, 17 Oct 2011 07:34:49 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0196721F8B91 for ; Mon, 17 Oct 2011 07:34:48 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 Oct 2011 10:34:46 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 17 Oct 2011 10:34:46 -0400
From: Hadriel Kaplan 
To: Ravindran Parthasarathi 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMjNnqjGuE9TK8CkqU1ZS+3V5ITA==
Date: Mon, 17 Oct 2011 14:34:45 +0000
Message-ID: 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com><4E98AF51.2090704@alum.mit.edu>  <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2DDD7828F2135B4C92D60EF6BDEFF33A@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 14:34:49 -0000

On Oct 17, 2011, at 2:05 AM, Ravindran Parthasarathi wrote:

> Looking at the some of the proposed B2BUA work item, I guess that your
> proposal is more lean towards B2BUA with media relay (RTP translator or
> RTP endpoint to RTP endpoint) functionality. Some of the B2BUA
> (Signaling only SBC) are signaling boxes and does not handle media
> directly. In case B2BUA performs supplementary services handling, the
> behavior is very different from passing the signaling through B2BUA.
> Another variant wherein B2BUA with supplementary services may acts as
> RTP translator. All the behavior are supported by different SBC in the
> deployment. Hope you agree with me.

Yup.  And thus the charter I'm proposing is not about "SBCs" - it's about B=
2BUAs, and for both signaling-only and signaling+media plane B2BUAs.


> Infact, SIPConnect 1.1 standardization helps interop between SP SBC and
> Enterprise SBC. Whether SIPConnect 1.2 shall solve your proposed issues
> as the basic interop is ensured through SIPConnect 1.1. Here I'm
> interested to know how this WG is different from what SIPConnect
> achieves.

SIPConnect is about the logical connection between an Enterprise and a Serv=
ice Provider, defining a profile for basic behavior across that connection.=
  SIPConnect (and the SIP Forum itself) does not create standards, and as a=
 profile merely says which standards should be supported for interop to wor=
k.  SIPConnect does not define behavior for particular devices, and doesn't=
 even require there be B2BUAs (nor should it). =20

In contrast, the STRAW Working Group I'm proposing would focus on defining =
very specific requirements for B2BUAs, in order for discrete SIP/media func=
tions to work across them.  STRAW would not be a holistic "how do we make S=
IP trunks work" type thing but rather about specific mechanisms, nor would =
it focus solely on SIP trunks but rather be general.  This is at a differen=
t layer and scope than SIPConnect.


> Also, most of your WG items are related to media (STUN, DTLS-SRTP,
> SDES-SRTP). There is an existing WG item
> (draft-ietf-mmusic-media-path-middleboxes-03.txt) which shall solve some
> of the problem in case there is proper review and consensus.  =20

I don't think so.  For one thing, it's basically a dead draft.  For another=
, it has lots of problems.  For example, see the email thread starting here=
:
http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html


> I'll be interested in your charter in case your charter is different
> from future extension possibility of SIPConnect 1.2,
> draft-ietf-mmusic-media-path-middleboxes-03.txt (SDP offer/answer),
> session-id charter (loop detection),
> draft-ietf-mmusic-media-loopback-16(media loopback). BTW, I guess that
> hop-by-hop media loopback was proposed earlier.

I don't know of any prior draft proposing hop-by-hop traceroute-type mechan=
ism for media-loopback.  The draft-ietf-mmusic-media-loopback-16 mechanism =
itself is not the issue.

The session-id mechanism is *not* about loop detection. (and it's dangerous=
 to use it for loop detection)
I plan to submit a draft for loop detection this week, but it's not too con=
troversial I think - it just uses Max-Forwards and Max-Breadth as one would=
 expect.

-hadriel



From pkyzivat@alum.mit.edu  Mon Oct 17 08:15:23 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC30821F8C41 for ; Mon, 17 Oct 2011 08:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level: 
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSmnBSacfqAB for ; Mon, 17 Oct 2011 08:15:23 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 053D921F8C86 for ; Mon, 17 Oct 2011 08:15:22 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id lpe41h0041ZXKqc51rF2cP; Mon, 17 Oct 2011 15:15:02 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id lrF11h0260tdiYw3hrF1MZ; Mon, 17 Oct 2011 15:15:02 +0000
Message-ID: <4E9C4674.8090107@alum.mit.edu>
Date: Mon, 17 Oct 2011 11:15:00 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com><4E98AF51.2090704@alum.mit.edu>  <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 15:15:24 -0000

Hadriel,

A question about your approach:

On 10/17/11 10:34 AM, Hadriel Kaplan wrote:

> In contrast, the STRAW Working Group I'm proposing
> would focus on defining very specific requirements for B2BUAs,
> in order for discrete SIP/media functions to work across them.
> STRAW would not be a holistic "how do we make SIP trunks work"
> type thing but rather about specific mechanisms,
> nor would it focus solely on SIP trunks but rather be general.

So, today we have a bunch of RFCs that define the various behaviors that 
constitute "SIP". And most of them define behaviors for various sorts of 
elements (UAC, UAS, Proxy, Registrar).

Determining compliance is then a matter of saying "this box conforms to 
RFC XYZ in the role of a (UAC, UAS, UA, Proxy, etc.)" Somebody drafting 
a purchase spec for equipment to build a sip *system* has to call out 
the components desired and the compliance required of each.

Groups like SIPForum, 3GPP, CableLabs define more elaborate profiles of 
what conformance means. But typically it comes down to saying that a box 
conforms to some list of RFCs while acting in one or more of those 
roles. Most of those also define how certain "features" should be 
realized using the basic sip mechanisms, and ensure that the RFCs 
defining those sip mechanisms are included in those called out for 
compliance. Doing a purchase spec for a system based on one of those 
specs is a matter of referencing the group-developed spec.

I guess you are proposing to develop a number of additional RFCs that 
will each define the behavior of a B2BUA in order that some particular 
"function" will work end-to-end even when the B2BUA is present between 
the ends.

Someone who is developing a purchase spec by themselves would then need 
to identify which of the "functions" are needed, and require compliance 
to them, in addition to other things. Its not clear to me whether this 
will be something well known to those building a system, or not. (It 
seems to require a level of understanding of how features are 
implemented that may exceed what a purchaser should be expected to know.)

In the case of the group-based specs, I suppose it would fall on the 
group to identify which of these new RFCs are important and require 
them. But it seems to me those groups have already defined the behavior 
required of B2BUAs in their systems, so this might not help them at all.

Can you please clarify how what you are proposing would typically be used?

	Thanks,
	Paul

From oej@edvina.net  Mon Oct 17 08:17:07 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4F621F8CAE for ; Mon, 17 Oct 2011 08:17:07 -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.597,  BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hwNOyLD8mrV for ; Mon, 17 Oct 2011 08:17:07 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B23D821F8C86 for ; Mon, 17 Oct 2011 08:17:06 -0700 (PDT)
Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id C44D8754BCD5; Mon, 17 Oct 2011 15:16:10 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" 
In-Reply-To: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
Date: Mon, 17 Oct 2011 17:16:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
To: Hadriel Kaplan 
X-Mailer: Apple Mail (2.1251.1)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 15:17:07 -0000

14 okt 2011 kl. 22:24 skrev Hadriel Kaplan:

> Howdy,
> a year ago or so, there was a thread and informal bar-bof around the =
topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the =
conclusion of the discussion, but it appears there was not enough =
interest at the time, or perhaps not enough concrete work to do and =
people to do it.  Since that time, we've had several I-Ds which could =
arguably fit in such a WG, or at least benefit from one, if it applied =
to B2BUAs in general.
>=20
> This email is to see if there's interest now, but with a slightly =
different tack: a concrete WG charter proposal, as described below.
>=20
> Interest/comments/flames welcomed.
I think it's high time to start this work. We have seen the need for it =
in the discussions around Asterisk
for a very long time. One could easily add SIP Identity for User Agents =
to this list, as RFC 4744 is=20
horribly underspecified in this regard...

/O
>=20
>=20
> Description of STRAW Working Group
> =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
> Name: Sip Traversal Required for Applications to Work (STRAW)
>=20
> Problem Statement:=20
> Within the context of the SIP protocol and architecture, a =
Back-to-Back User Agent (B2BUA) is any SIP device in the logical path =
between two User Agents performing a role beyond that of a Proxy as =
defined in RFC 3261.  The B2BUA may be as simple as a session-stateful =
Proxy becoming a B2BUA in order to terminate dead sessions by generating =
BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a =
Session Border Controller performing such functions as in RFC 5853; or =
it may be an Enterprise PBX terminating REFERs and such; or it may be a =
complete UAS and UAC implementation with a PRI loopback in-between.=20
>=20
> In its most extreme form, the scope of the SIP protocol ends at the =
UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  =
In practice, however, users expect some SIP protocol aspects to go =
beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC =
side, as if the B2BUA was not an end unto itself; this is similar to the =
expectation that emails work when they cross from POP and IMAP to/from =
SMTP.
>=20
> It is impossible to normatively define all the behaviors of B2BUAs in =
general, or even subsets of them such as SBCs. Unlike consumer NATs, =
B2BUAs perform widely varying functions for purposes which may be unique =
to their environment, unique to their architecture, or unique to the =
wishes of their administrator.  Instead of defining all things a given =
type of B2BUA must do, a more practical objective would be to define =
what very few things any B2BUA must do to make a specific SIP mechanism =
work, and let the market decide whether to do those things.
>=20
> The name of this working group reflects that practical objective: if =
there were a thin straw between the SIP UAS and UAC of a B2BUA, what =
must be passed through that straw and used on each side.  Or viewed =
another way, if a B2BUA were in fact a UAS and UAC connected with a PRI =
loopback circuit, and if we could extend ISDN, what information would we =
carry in ISDN across the PRI for a specific SIP mechanism to work =
end-to-end.
>=20
> For example, the WG could produce a document which specifies that the =
Max-Forwards header field value should be copied and decremented across =
the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could =
then tell their B2BUA vendors to comply with the document, if the =
administrator so wishes.
>=20
> Objectives:
> The objectives of the STRAW Working Group are to publish normative =
documents which define which SIP header fields, parameters, MIME bodies, =
body content fields/information, or media-plane characteristics are =
required to traverse between the User Agent "sides" of a B2BUA for =
specific functions to work. =20
>=20
> Deliverables would indicate which types of B2BUAs would apply or not.  =
For example, a document defining the requirements for end-to-end =
DTLS-SRTP would not apply to B2BUAs which terminate media, such as =
transcoders or recorders.
>=20
> The intention of this WG is to document such requirements in separate =
documents, per SIP or media function, instead of as one document for all =
functions.  That will both reduce the time to publication, as well a =
provide B2BUA administrators and manufacturers with simple =
comply/no-comply criteria.
>=20
>=20
> Initial Deliverables:
> 1) A document defining the requirements for B2BUAs to identify =
specific features/capabilities support.
> 2) A document defining the requirements for B2BUAs with respect to =
loop detection/prevention.
> 3) A document defining the requirements for B2BUAs to support =
end-to-end and hop-by-hop media-loopback test calls.
> 4) A document defining the requirements for B2BUAs to support =
DTLS-SRTP (RFC 5764) end-to-end.
> 5) A document defining the requirements for B2BUAs to support STUN =
connectivity checks end-to-end.
>=20
> [also add a taxonomy document?]
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

---
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden




From HKaplan@acmepacket.com  Mon Oct 17 09:44:10 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB0A21F8C0F for ; Mon, 17 Oct 2011 09:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.221
X-Spam-Level: 
X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNYTTqK55BtK for ; Mon, 17 Oct 2011 09:44:09 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3E99421F8BF6 for ; Mon, 17 Oct 2011 09:44:09 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 Oct 2011 12:44:07 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 17 Oct 2011 12:44:07 -0400
From: Hadriel Kaplan 
To: Paul Kyzivat 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMjOv8jGuE9TK8CkqU1ZS+3V5ITA==
Date: Mon, 17 Oct 2011 16:44:06 +0000
Message-ID: <0085E4F9-43DE-42E2-B730-1D44849FBBA2@acmepacket.com>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com><4E98AF51.2090704@alum.mit.edu>  <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com>  <4E9C4674.8090107@alum.mit.edu>
In-Reply-To: <4E9C4674.8090107@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7DA37D5253DC394DA1094A64B5A6A4EF@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 16:44:10 -0000

On Oct 17, 2011, at 11:15 AM, Paul Kyzivat wrote:

> I guess you are proposing to develop a number of additional RFCs that wil=
l each define the behavior of a B2BUA in order that some particular "functi=
on" will work end-to-end even when the B2BUA is present between the ends.
>=20
> Someone who is developing a purchase spec by themselves would then need t=
o identify which of the "functions" are needed, and require compliance to t=
hem, in addition to other things. Its not clear to me whether this will be =
something well known to those building a system, or not. (It seems to requi=
re a level of understanding of how features are implemented that may exceed=
 what a purchaser should be expected to know.)
>=20
> In the case of the group-based specs, I suppose it would fall on the grou=
p to identify which of these new RFCs are important and require them. But i=
t seems to me those groups have already defined the behavior required of B2=
BUAs in their systems, so this might not help them at all.
>=20
> Can you please clarify how what you are proposing would typically be used=
?

I would expect that RFCs published by the STRAW WG would be used in the sam=
e way as other RFCs published by the RAI area: by manufacturers/developers/=
product-managers, by system purchasers, and by other SDOs and Industry Fora=
 such as 3GPP, ETSI, ATIS, Cablelabs, SIPForum, i3Forum, GSMA, UCIF, NENA, =
NICC, TTC, etc., referencing them.

For system purchasers: it's true that many wouldn't know the level of detai=
l required to know to reference such an RFC, but it's also true that many *=
do* know such things. (or at least that appears to be the case, since I see=
 plenty of RFIs/RFPs that are that detailed)

For device manufacturers: a lot of them already know what they need to do f=
or most things, but a lot of them apparently don't know, or don't care, or =
can't due to their architecture.  Take the Max-Forwards case, for example: =
plenty of B2BUAs create a new/reset Max-Forwards header value on their UAC =
side for forwarded requests.  We've seen this cause unbounded loops in real=
 deployed networks.  Either the B2BUA vendors don't know better, or don't c=
are, or can't do it.  Having a published RFC means that the purchasers can =
point to a MUST statement in an RFC and tell the vendor to do it, or if the=
 vendor can't do it then the purchaser can (a) know the vendor can't and ta=
ke some other steps to prevent loops, and/or (b) decide to choose another v=
endor.

For "group-based-specs": it's true some of them define behavior of B2BUA's =
in their group-system (not all of them do, BTW)... and obviously some or ev=
en all RFCs created in STRAW might not help those groups at all.  That's ok=
.  They don't need our help.  But there are a lot of SIP domains built that=
 are not based on group-specs.  Virtually every Enterprise SIP deployment, =
for example.  And I think for some functions, the IETF is the most logical =
place to define how it works across B2BUAs because the technical competence=
/knowledge for the particular function is in the IETF.  Like the DTLS-SRTP =
case, for example.

-hadriel


From pkyzivat@alum.mit.edu  Mon Oct 17 10:55:21 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0240521F8BBC for ; Mon, 17 Oct 2011 10:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.145
X-Spam-Level: 
X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl0dResKNJ60 for ; Mon, 17 Oct 2011 10:55:20 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2F21F8B54 for ; Mon, 17 Oct 2011 10:55:20 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta14.westchester.pa.mail.comcast.net with comcast id lrli1h00A1ei1Bg5EtvLgP; Mon, 17 Oct 2011 17:55:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id ltvL1h00B0tdiYw3ktvLX0; Mon, 17 Oct 2011 17:55:20 +0000
Message-ID: <4E9C6C05.3030307@alum.mit.edu>
Date: Mon, 17 Oct 2011 13:55:17 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com><4E98AF51.2090704@alum.mit.edu>  <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com>  <4E9C4674.8090107@alum.mit.edu> <0085E4F9-43DE-42E2-B730-1D44849FBBA2@acmepacket.com>
In-Reply-To: <0085E4F9-43DE-42E2-B730-1D44849FBBA2@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 17:55:21 -0000

Hadriel,

OK, I guess you see it the same was I was interpreting it.
I certainly agree that having this info is better than *not* having it.
But it will further increase what must be understood to correctly spec a 
system to be assembled out of piece parts. Without this info its hard to 
spec it at all - you have to hope for the best, that your vendors can 
tweak things until the system works.

If all goes well, the existence of a spec for some function will lead 
those who make B2BUAs think "maybe I should support that", where 
previously they weren't forced to think about it at all.

ISTM it would be *nicer* if we could have classifications for different 
sorts of B2BUAs, and rules for their behavior, as we have for UAs and 
Proxies. But it may be that real devices don't fall into those neat 
classifications well enough for that to work in practice. And what you 
propose doesn't preclude doing that later.

	Thanks,
	Paul

On 10/17/11 12:44 PM, Hadriel Kaplan wrote:
>
> On Oct 17, 2011, at 11:15 AM, Paul Kyzivat wrote:
>
>> I guess you are proposing to develop a number of additional RFCs that will each define the behavior of a B2BUA in order that some particular "function" will work end-to-end even when the B2BUA is present between the ends.
>>
>> Someone who is developing a purchase spec by themselves would then need to identify which of the "functions" are needed, and require compliance to them, in addition to other things. Its not clear to me whether this will be something well known to those building a system, or not. (It seems to require a level of understanding of how features are implemented that may exceed what a purchaser should be expected to know.)
>>
>> In the case of the group-based specs, I suppose it would fall on the group to identify which of these new RFCs are important and require them. But it seems to me those groups have already defined the behavior required of B2BUAs in their systems, so this might not help them at all.
>>
>> Can you please clarify how what you are proposing would typically be used?
>
> I would expect that RFCs published by the STRAW WG would be used in the same way as other RFCs published by the RAI area: by manufacturers/developers/product-managers, by system purchasers, and by other SDOs and Industry Fora such as 3GPP, ETSI, ATIS, Cablelabs, SIPForum, i3Forum, GSMA, UCIF, NENA, NICC, TTC, etc., referencing them.
>
> For system purchasers: it's true that many wouldn't know the level of detail required to know to reference such an RFC, but it's also true that many *do* know such things. (or at least that appears to be the case, since I see plenty of RFIs/RFPs that are that detailed)
>
> For device manufacturers: a lot of them already know what they need to do for most things, but a lot of them apparently don't know, or don't care, or can't due to their architecture.  Take the Max-Forwards case, for example: plenty of B2BUAs create a new/reset Max-Forwards header value on their UAC side for forwarded requests.  We've seen this cause unbounded loops in real deployed networks.  Either the B2BUA vendors don't know better, or don't care, or can't do it.  Having a published RFC means that the purchasers can point to a MUST statement in an RFC and tell the vendor to do it, or if the vendor can't do it then the purchaser can (a) know the vendor can't and take some other steps to prevent loops, and/or (b) decide to choose another vendor.
>
> For "group-based-specs": it's true some of them define behavior of B2BUA's in their group-system (not all of them do, BTW)... and obviously some or even all RFCs created in STRAW might not help those groups at all.  That's ok.  They don't need our help.  But there are a lot of SIP domains built that are not based on group-specs.  Virtually every Enterprise SIP deployment, for example.  And I think for some functions, the IETF is the most logical place to define how it works across B2BUAs because the technical competence/knowledge for the particular function is in the IETF.  Like the DTLS-SRTP case, for example.
>
> -hadriel
>
>


From SBharrat@sonusnet.com  Mon Oct 17 10:55:53 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF2021F86D0 for ; Mon, 17 Oct 2011 10:55:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISQAgTVZn4XG for ; Mon, 17 Oct 2011 10:55:52 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 878DB21F853E for ; Mon, 17 Oct 2011 10:55:52 -0700 (PDT)
Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9HHuOYC015431;  Mon, 17 Oct 2011 13:56:24 -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: Mon, 17 Oct 2011 13:52:54 -0400
Message-ID: <637C77B6763BB54ABF989B6B21D5323504C33B0B@sonusmail05.sonusnet.com>
In-Reply-To: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMiq9OXX9LeDoA90O2vC51RKdIFpWA1ZMw
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
From: "Bharrat, Shaun" 
To: "Hadriel Kaplan" , 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 17:55:53 -0000

> This email is to see if there's interest now, but with a slightly
different
> tack: a concrete WG charter proposal, as described below.

This is sorely needed. I would be interested in participating.

Cheers,
Shaun


> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf
> Of Hadriel Kaplan
> Sent: Friday, October 14, 2011 4:25 PM
> To: dispatch@ietf.org list
> Subject: [dispatch] BEHAVE for B2BUAs charter proposal
>=20
> Howdy,
> a year ago or so, there was a thread and informal bar-bof around the
topic of
> "Should the IETF have a BEHAVE WG for SBCs".  I do not know the
conclusion of
> the discussion, but it appears there was not enough interest at the
time, or
> perhaps not enough concrete work to do and people to do it.  Since
that time,
> we've had several I-Ds which could arguably fit in such a WG, or at
least
> benefit from one, if it applied to B2BUAs in general.
>=20
> This email is to see if there's interest now, but with a slightly
different
> tack: a concrete WG charter proposal, as described below.
>=20
> Interest/comments/flames welcomed.
>=20
>=20
> Description of STRAW Working Group
> =
=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
> Name: Sip Traversal Required for Applications to Work (STRAW)
>=20
> Problem Statement:
> Within the context of the SIP protocol and architecture, a
Back-to-Back User
> Agent (B2BUA) is any SIP device in the logical path between two User
Agents
> performing a role beyond that of a Proxy as defined in RFC 3261.  The
B2BUA
> may be as simple as a session-stateful Proxy becoming a B2BUA in order
to
> terminate dead sessions by generating BYEs; or it may be a 3PCC-style
agent
> only modifying SDP; or it may be a Session Border Controller
performing such
> functions as in RFC 5853; or it may be an Enterprise PBX terminating
REFERs
> and such; or it may be a complete UAS and UAC implementation with a
PRI
> loopback in-between.
>=20
> In its most extreme form, the scope of the SIP protocol ends at the
UAS of the
> B2BUA, and a new SIP protocol scope begins on its UAC side.  In
practice,
> however, users expect some SIP protocol aspects to go beyond the scope
of the
> B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA
was not
> an end unto itself; this is similar to the expectation that emails
work when
> they cross from POP and IMAP to/from SMTP.
>=20
> It is impossible to normatively define all the behaviors of B2BUAs in
general,
> or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs
perform
> widely varying functions for purposes which may be unique to their
> environment, unique to their architecture, or unique to the wishes of
their
> administrator.  Instead of defining all things a given type of B2BUA
must do,
> a more practical objective would be to define what very few things any
B2BUA
> must do to make a specific SIP mechanism work, and let the market
decide
> whether to do those things.
>=20
> The name of this working group reflects that practical objective: if
there
> were a thin straw between the SIP UAS and UAC of a B2BUA, what must be
passed
> through that straw and used on each side.  Or viewed another way, if a
B2BUA
> were in fact a UAS and UAC connected with a PRI loopback circuit, and
if we
> could extend ISDN, what information would we carry in ISDN across the
PRI for
> a specific SIP mechanism to work end-to-end.
>=20
> For example, the WG could produce a document which specifies that the
Max-
> Forwards header field value should be copied and decremented across
the B2BUA,
> if the B2BUA wishes to prevent loops.  Administrators could then tell
their
> B2BUA vendors to comply with the document, if the administrator so
wishes.
>=20
> Objectives:
> The objectives of the STRAW Working Group are to publish normative
documents
> which define which SIP header fields, parameters, MIME bodies, body
content
> fields/information, or media-plane characteristics are required to
traverse
> between the User Agent "sides" of a B2BUA for specific functions to
work.
>=20
> Deliverables would indicate which types of B2BUAs would apply or not.
For
> example, a document defining the requirements for end-to-end DTLS-SRTP
would
> not apply to B2BUAs which terminate media, such as transcoders or
recorders.
>=20
> The intention of this WG is to document such requirements in separate
> documents, per SIP or media function, instead of as one document for
all
> functions.  That will both reduce the time to publication, as well a
provide
> B2BUA administrators and manufacturers with simple comply/no-comply
criteria.
>=20
>=20
> Initial Deliverables:
> 1) A document defining the requirements for B2BUAs to identify
specific
> features/capabilities support.
> 2) A document defining the requirements for B2BUAs with respect to
loop
> detection/prevention.
> 3) A document defining the requirements for B2BUAs to support
end-to-end and
> hop-by-hop media-loopback test calls.
> 4) A document defining the requirements for B2BUAs to support
DTLS-SRTP (RFC
> 5764) end-to-end.
> 5) A document defining the requirements for B2BUAs to support STUN
> connectivity checks end-to-end.
>=20
> [also add a taxonomy document?]
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From wilhelm@wimmreuter.de  Mon Oct 17 13:03:11 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A375A21F8C3F for ; Mon, 17 Oct 2011 13:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7MFXYbQN8a5 for ; Mon, 17 Oct 2011 13:03:11 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0AA21F8C39 for ; Mon, 17 Oct 2011 13:03:10 -0700 (PDT)
Received: from wwn04.wwnet.ww (p4FE5AB6B.dip.t-dialin.net [79.229.171.107]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0M4P8q-1QqXNk1F2i-00z9ij; Mon, 17 Oct 2011 22:03:05 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Wilhelm Wimmreuter 
In-Reply-To: <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>
Date: Mon, 17 Oct 2011 22:03:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>
To: "Olle E. Johansson" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:IrK+z2p9Iwg4T0JfyDMgmx79inJ+U45dyfpScWOSjrZ QqTqdQLWcUFwlWoFFmBNDxOzJ4HisQnB7iSoOhEjpRWX+nKX8t M2jP9YrbmUA19Jvzq2KeAHkPOxj6cJTLf89hVvOSybipLesD1g ouRe9I1M/CXOJ02kKkA3okdEIFWoosdu6WNCXu73402uOoQuE2 fbnQ4qvJ4Eo53m9cvJHso3GXqDN+GsQGAJTY1Yuo+22PePFQV/ 3SFiJC9RACF2P+OgoIkAotUbcBJ86Tx/TbZ3aG89myNYqSwGXB /8jcZ+wKieEd6ChN2LL6xBl8u71Z6jd09s3YcSl3xAm1mEFrdM fBQRmVBOdGBSaDqPBcVpmgCxwSFvrUFsTIIrFcTy44eb73LCoW dPI6/EhX/nwMg==
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 20:03:11 -0000

Think it shall be RFC4474

Agree, it is underspecified and in parts to some extents way overloaded.
- Signs elements that will be modified by SBCs
- Signs things that have only marginally to do with the originators =
identity
- does nit clearly distinguish between the originators domain and a =
phone number
- ...

However it seems to be quite difficult and likely becomes even more =
complex if we add things like federations and cross PKI certificate =
acceptance.

My guess is that we to take a lot of usability issues in to =
consideration if we want to make it really useful. e.g. initial =
enrollment and certificate renewal.

Besides usability, one shall think about reducing the functionality to =
sign the originating identity and domain only. This still would allow to =
protect the sip message by other means. This approach has the advantage =
of separating transport security and the originating identity. With this =
clear separation, authentication would become transparent to SBCs and =
other servers in the setup path. With that, any element in the call path =
can validate the caller ID and decide on further authorization. This =
would also be relevant for the recently signed CALLER-ID Act.

Willi


On 17.10.2011, at 17:16, Olle E. Johansson wrote:

>=20
> 14 okt 2011 kl. 22:24 skrev Hadriel Kaplan:
>=20
>> Howdy,
>> a year ago or so, there was a thread and informal bar-bof around the =
topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the =
conclusion of the discussion, but it appears there was not enough =
interest at the time, or perhaps not enough concrete work to do and =
people to do it.  Since that time, we've had several I-Ds which could =
arguably fit in such a WG, or at least benefit from one, if it applied =
to B2BUAs in general.
>>=20
>> This email is to see if there's interest now, but with a slightly =
different tack: a concrete WG charter proposal, as described below.
>>=20
>> Interest/comments/flames welcomed.
> I think it's high time to start this work. We have seen the need for =
it in the discussions around Asterisk
> for a very long time. One could easily add SIP Identity for User =
Agents to this list, as RFC 4744 is=20
> horribly underspecified in this regard...
>=20
> /O
>>=20
>>=20
>> Description of STRAW Working Group
>> =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
>> Name: Sip Traversal Required for Applications to Work (STRAW)
>>=20
>> Problem Statement:=20
>> Within the context of the SIP protocol and architecture, a =
Back-to-Back User Agent (B2BUA) is any SIP device in the logical path =
between two User Agents performing a role beyond that of a Proxy as =
defined in RFC 3261.  The B2BUA may be as simple as a session-stateful =
Proxy becoming a B2BUA in order to terminate dead sessions by generating =
BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a =
Session Border Controller performing such functions as in RFC 5853; or =
it may be an Enterprise PBX terminating REFERs and such; or it may be a =
complete UAS and UAC implementation with a PRI loopback in-between.=20
>>=20
>> In its most extreme form, the scope of the SIP protocol ends at the =
UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  =
In practice, however, users expect some SIP protocol aspects to go =
beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC =
side, as if the B2BUA was not an end unto itself; this is similar to the =
expectation that emails work when they cross from POP and IMAP to/from =
SMTP.
>>=20
>> It is impossible to normatively define all the behaviors of B2BUAs in =
general, or even subsets of them such as SBCs. Unlike consumer NATs, =
B2BUAs perform widely varying functions for purposes which may be unique =
to their environment, unique to their architecture, or unique to the =
wishes of their administrator.  Instead of defining all things a given =
type of B2BUA must do, a more practical objective would be to define =
what very few things any B2BUA must do to make a specific SIP mechanism =
work, and let the market decide whether to do those things.
>>=20
>> The name of this working group reflects that practical objective: if =
there were a thin straw between the SIP UAS and UAC of a B2BUA, what =
must be passed through that straw and used on each side.  Or viewed =
another way, if a B2BUA were in fact a UAS and UAC connected with a PRI =
loopback circuit, and if we could extend ISDN, what information would we =
carry in ISDN across the PRI for a specific SIP mechanism to work =
end-to-end.
>>=20
>> For example, the WG could produce a document which specifies that the =
Max-Forwards header field value should be copied and decremented across =
the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could =
then tell their B2BUA vendors to comply with the document, if the =
administrator so wishes.
>>=20
>> Objectives:
>> The objectives of the STRAW Working Group are to publish normative =
documents which define which SIP header fields, parameters, MIME bodies, =
body content fields/information, or media-plane characteristics are =
required to traverse between the User Agent "sides" of a B2BUA for =
specific functions to work. =20
>>=20
>> Deliverables would indicate which types of B2BUAs would apply or not. =
 For example, a document defining the requirements for end-to-end =
DTLS-SRTP would not apply to B2BUAs which terminate media, such as =
transcoders or recorders.
>>=20
>> The intention of this WG is to document such requirements in separate =
documents, per SIP or media function, instead of as one document for all =
functions.  That will both reduce the time to publication, as well a =
provide B2BUA administrators and manufacturers with simple =
comply/no-comply criteria.
>>=20
>>=20
>> Initial Deliverables:
>> 1) A document defining the requirements for B2BUAs to identify =
specific features/capabilities support.
>> 2) A document defining the requirements for B2BUAs with respect to =
loop detection/prevention.
>> 3) A document defining the requirements for B2BUAs to support =
end-to-end and hop-by-hop media-loopback test calls.
>> 4) A document defining the requirements for B2BUAs to support =
DTLS-SRTP (RFC 5764) end-to-end.
>> 5) A document defining the requirements for B2BUAs to support STUN =
connectivity checks end-to-end.
>>=20
>> [also add a taxonomy document?]
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>=20
> ---
> * Olle E Johansson - oej@edvina.net
> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
>=20
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From pkyzivat@alum.mit.edu  Mon Oct 17 13:31:33 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983CD11E8081 for ; Mon, 17 Oct 2011 13:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level: 
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SJtam5KdXXP for ; Mon, 17 Oct 2011 13:31:32 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8FABF11E807F for ; Mon, 17 Oct 2011 13:31:32 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id lwSY1h0041uE5Es58wXYwy; Mon, 17 Oct 2011 20:31:32 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id lwXY1h00j0tdiYw3cwXY1G; Mon, 17 Oct 2011 20:31:32 +0000
Message-ID: <4E9C90A2.2020400@alum.mit.edu>
Date: Mon, 17 Oct 2011 16:31:30 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 20:31:33 -0000

On 10/17/11 4:03 PM, Wilhelm Wimmreuter wrote:
> Think it shall be RFC4474
>
> Agree, it is underspecified and in parts to some extents way overloaded.
> - Signs elements that will be modified by SBCs
> - Signs things that have only marginally to do with the originators identity
> - does nit clearly distinguish between the originators domain and a phone number
> - ...
>
> However it seems to be quite difficult and likely becomes even more complex if we add things like federations and cross PKI certificate acceptance.
>
> My guess is that we to take a lot of usability issues in to consideration if we want to make it really useful. e.g. initial enrollment and certificate renewal.
>
> Besides usability, one shall think about reducing the functionality to sign the originating identity and domain only. This still would allow to protect the sip message by other means. This approach has the advantage of separating transport security and the originating identity. With this clear separation, authentication would become transparent to SBCs and other servers in the setup path. With that, any element in the call path can validate the caller ID and decide on further authorization. This would also be relevant for the recently signed CALLER-ID Act.

IIUC you are in essence suggesting signing a blank sheet of paper and 
then sending it. The recipient will know that the sheet was blank when 
signed, and gets to decide whether to believe other stuff on the 
received sheet.

When you say "protecting the message by other means", presumably you 
mean transitive trust, since a lot of what matters in the message is 
changed by the B2BUAs. The point of 4474 was to get beyond transitive trust.

	Thanks,
	Paul

> Willi
>
>
> On 17.10.2011, at 17:16, Olle E. Johansson wrote:
>
>>
>> 14 okt 2011 kl. 22:24 skrev Hadriel Kaplan:
>>
>>> Howdy,
>>> a year ago or so, there was a thread and informal bar-bof around the topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the conclusion of the discussion, but it appears there was not enough interest at the time, or perhaps not enough concrete work to do and people to do it.  Since that time, we've had several I-Ds which could arguably fit in such a WG, or at least benefit from one, if it applied to B2BUAs in general.
>>>
>>> This email is to see if there's interest now, but with a slightly different tack: a concrete WG charter proposal, as described below.
>>>
>>> Interest/comments/flames welcomed.
>> I think it's high time to start this work. We have seen the need for it in the discussions around Asterisk
>> for a very long time. One could easily add SIP Identity for User Agents to this list, as RFC 4744 is
>> horribly underspecified in this regard...
>>
>> /O
>>>
>>>
>>> Description of STRAW Working Group
>>> ====================================
>>> Name: Sip Traversal Required for Applications to Work (STRAW)
>>>
>>> Problem Statement:
>>> Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI loopback in-between.
>>>
>>> In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP.
>>>
>>> It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator.  Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things.
>>>
>>> The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side.  Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end.
>>>
>>> For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes.
>>>
>>> Objectives:
>>> The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work.
>>>
>>> Deliverables would indicate which types of B2BUAs would apply or not.  For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.
>>>
>>> The intention of this WG is to document such requirements in separate documents, per SIP or media function, instead of as one document for all functions.  That will both reduce the time to publication, as well a provide B2BUA administrators and manufacturers with simple comply/no-comply criteria.
>>>
>>>
>>> Initial Deliverables:
>>> 1) A document defining the requirements for B2BUAs to identify specific features/capabilities support.
>>> 2) A document defining the requirements for B2BUAs with respect to loop detection/prevention.
>>> 3) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls.
>>> 4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end.
>>> 5) A document defining the requirements for B2BUAs to support STUN connectivity checks end-to-end.
>>>
>>> [also add a taxonomy document?]
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>> ---
>> * Olle E Johansson - oej@edvina.net
>> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
>>
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>


From wilhelm@wimmreuter.de  Mon Oct 17 13:53:15 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E745521F8B83 for ; Mon, 17 Oct 2011 13:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QahH3WADmOx5 for ; Mon, 17 Oct 2011 13:53:15 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id B909021F8B88 for ; Mon, 17 Oct 2011 13:53:14 -0700 (PDT)
Received: from wwn04.wwnet.ww (p4FE5AB6B.dip.t-dialin.net [79.229.171.107]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Lunm1-1R7LRZ31jF-0108EQ; Mon, 17 Oct 2011 22:53:13 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Wilhelm Wimmreuter 
In-Reply-To: <4E9C90A2.2020400@alum.mit.edu>
Date: Mon, 17 Oct 2011 22:53:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <46684468-E14A-4A98-AA18-E731158665C8@wimmreuter.de>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>  <4E9C90A2.2020400@alum.mit.edu>
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:Zk3HcYrJ8M+dQv9ONIrPKBhZTUiTCrI2yRALynEiNCv BjApz/mvjx0jK5V0ULvsM8c/9kUGcjQj+qG+VNrE2vU1u6us24 89ukLRvMD/l7BwAtA8OnTfVitDZYVXy0lueXanoWcuN//6/9mK T3tIr46fEYHviVl2e1smllJHI2So8pU5K2MDhKyt2bMQtnWbQH 8FS6tUEjZV4uG93hkwFpuEsJ0dyQxJAWvUOsV/iM9Kx2AlXFwc E8OR7uecN5zXaZK3ENFB6hbJJfLbaPNEQHR7k471YM/TcVMbVm 7Za2iurMxrjJ79KOHMzDkZA5+PJnpSWJqaAvhHZ7/5T39UEHBZ Vbt1MqrZ4ZRdy4OSmP0hNmzo4LH1DKGklDGBW68pdIiYa3SJnT hnrEdr2tKbtyQ==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 20:53:16 -0000

On 17.10.2011, at 22:31, Paul Kyzivat wrote:

> On 10/17/11 4:03 PM, Wilhelm Wimmreuter wrote:
>> Think it shall be RFC4474
>>=20
>> Agree, it is underspecified and in parts to some extents way =
overloaded.
>> - Signs elements that will be modified by SBCs
>> - Signs things that have only marginally to do with the originators =
identity
>> - does nit clearly distinguish between the originators domain and a =
phone number
>> - ...
>>=20
>> However it seems to be quite difficult and likely becomes even more =
complex if we add things like federations and cross PKI certificate =
acceptance.
>>=20
>> My guess is that we to take a lot of usability issues in to =
consideration if we want to make it really useful. e.g. initial =
enrollment and certificate renewal.
>>=20
>> Besides usability, one shall think about reducing the functionality =
to sign the originating identity and domain only. This still would allow =
to protect the sip message by other means. This approach has the =
advantage of separating transport security and the originating identity. =
With this clear separation, authentication would become transparent to =
SBCs and other servers in the setup path. With that, any element in the =
call path can validate the caller ID and decide on further =
authorization. This would also be relevant for the recently signed =
CALLER-ID Act.
>=20
> IIUC you are in essence suggesting signing a blank sheet of paper and =
then sending it. The recipient will know that the sheet was blank when =
signed, and gets to decide whether to believe other stuff on the =
received sheet.

Not really a blank shet of paper ;-). Just the identity of the =
originator but not the parts of the message that can be changed on link =
by link. Other elements shall be protected link by link if necessary. As =
such the digest will be reduced to a minimum and can be forwarded =
transparently throughout the chain.


>=20
> When you say "protecting the message by other means", presumably you =
mean transitive trust, since a lot of what matters in the message is =
changed by the B2BUAs. The point of 4474 was to get beyond transitive =
trust.

Guess transitive is the best way since all other stuff can only be =
protected on a link by link base. Did we not have the same problem with =
IPsec as well?

On top of this, I believe that the final solution must be a user centric =
authentication anyhow and with that we can only accept a digest with =
information that will not be modified throughout the communication path. =
e.g. originating id, terminating id and possibly the timestamp.=20

Thanks

Willi

>=20
> 	Thanks,
> 	Paul
>=20
>> Willi
>>=20
>>=20
>> On 17.10.2011, at 17:16, Olle E. Johansson wrote:
>>=20
>>>=20
>>> 14 okt 2011 kl. 22:24 skrev Hadriel Kaplan:
>>>=20
>>>> Howdy,
>>>> a year ago or so, there was a thread and informal bar-bof around =
the topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know =
the conclusion of the discussion, but it appears there was not enough =
interest at the time, or perhaps not enough concrete work to do and =
people to do it.  Since that time, we've had several I-Ds which could =
arguably fit in such a WG, or at least benefit from one, if it applied =
to B2BUAs in general.
>>>>=20
>>>> This email is to see if there's interest now, but with a slightly =
different tack: a concrete WG charter proposal, as described below.
>>>>=20
>>>> Interest/comments/flames welcomed.
>>> I think it's high time to start this work. We have seen the need for =
it in the discussions around Asterisk
>>> for a very long time. One could easily add SIP Identity for User =
Agents to this list, as RFC 4744 is
>>> horribly underspecified in this regard...
>>>=20
>>> /O
>>>>=20
>>>>=20
>>>> Description of STRAW Working Group
>>>> =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
>>>> Name: Sip Traversal Required for Applications to Work (STRAW)
>>>>=20
>>>> Problem Statement:
>>>> Within the context of the SIP protocol and architecture, a =
Back-to-Back User Agent (B2BUA) is any SIP device in the logical path =
between two User Agents performing a role beyond that of a Proxy as =
defined in RFC 3261.  The B2BUA may be as simple as a session-stateful =
Proxy becoming a B2BUA in order to terminate dead sessions by generating =
BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a =
Session Border Controller performing such functions as in RFC 5853; or =
it may be an Enterprise PBX terminating REFERs and such; or it may be a =
complete UAS and UAC implementation with a PRI loopback in-between.
>>>>=20
>>>> In its most extreme form, the scope of the SIP protocol ends at the =
UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  =
In practice, however, users expect some SIP protocol aspects to go =
beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC =
side, as if the B2BUA was not an end unto itself; this is similar to the =
expectation that emails work when they cross from POP and IMAP to/from =
SMTP.
>>>>=20
>>>> It is impossible to normatively define all the behaviors of B2BUAs =
in general, or even subsets of them such as SBCs. Unlike consumer NATs, =
B2BUAs perform widely varying functions for purposes which may be unique =
to their environment, unique to their architecture, or unique to the =
wishes of their administrator.  Instead of defining all things a given =
type of B2BUA must do, a more practical objective would be to define =
what very few things any B2BUA must do to make a specific SIP mechanism =
work, and let the market decide whether to do those things.
>>>>=20
>>>> The name of this working group reflects that practical objective: =
if there were a thin straw between the SIP UAS and UAC of a B2BUA, what =
must be passed through that straw and used on each side.  Or viewed =
another way, if a B2BUA were in fact a UAS and UAC connected with a PRI =
loopback circuit, and if we could extend ISDN, what information would we =
carry in ISDN across the PRI for a specific SIP mechanism to work =
end-to-end.
>>>>=20
>>>> For example, the WG could produce a document which specifies that =
the Max-Forwards header field value should be copied and decremented =
across the B2BUA, if the B2BUA wishes to prevent loops.  Administrators =
could then tell their B2BUA vendors to comply with the document, if the =
administrator so wishes.
>>>>=20
>>>> Objectives:
>>>> The objectives of the STRAW Working Group are to publish normative =
documents which define which SIP header fields, parameters, MIME bodies, =
body content fields/information, or media-plane characteristics are =
required to traverse between the User Agent "sides" of a B2BUA for =
specific functions to work.
>>>>=20
>>>> Deliverables would indicate which types of B2BUAs would apply or =
not.  For example, a document defining the requirements for end-to-end =
DTLS-SRTP would not apply to B2BUAs which terminate media, such as =
transcoders or recorders.
>>>>=20
>>>> The intention of this WG is to document such requirements in =
separate documents, per SIP or media function, instead of as one =
document for all functions.  That will both reduce the time to =
publication, as well a provide B2BUA administrators and manufacturers =
with simple comply/no-comply criteria.
>>>>=20
>>>>=20
>>>> Initial Deliverables:
>>>> 1) A document defining the requirements for B2BUAs to identify =
specific features/capabilities support.
>>>> 2) A document defining the requirements for B2BUAs with respect to =
loop detection/prevention.
>>>> 3) A document defining the requirements for B2BUAs to support =
end-to-end and hop-by-hop media-loopback test calls.
>>>> 4) A document defining the requirements for B2BUAs to support =
DTLS-SRTP (RFC 5764) end-to-end.
>>>> 5) A document defining the requirements for B2BUAs to support STUN =
connectivity checks end-to-end.
>>>>=20
>>>> [also add a taxonomy document?]
>>>>=20
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dispatch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>=20
>>> ---
>>> * Olle E Johansson - oej@edvina.net
>>> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From pravindran@sonusnet.com  Mon Oct 17 15:07:56 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA78111E809A for ; Mon, 17 Oct 2011 15:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.669
X-Spam-Level: 
X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFsDWm5UDX5B for ; Mon, 17 Oct 2011 15:07:56 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id F315C11E8073 for ; Mon, 17 Oct 2011 15:07:55 -0700 (PDT)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9HM8Rfx017380;  Mon, 17 Oct 2011 18:08:27 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 17 Oct 2011 18:07:52 -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: Tue, 18 Oct 2011 03:37:37 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159955@sonusinmail02.sonusnet.com>
In-Reply-To: <4E9C6C05.3030307@alum.mit.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AcyM9fJlvEnEjw3KTcyqJIBeWIQfDgAIMNrw
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com><4E98AF51.2090704@alum.mit.edu>  <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com>  <4E9C4674.8090107@alum.mit.edu> <0085E4F9-43DE-42E2-B730-1D44849FBBA2@acmepacket.com> <4E9C6C05.3030307@alum.mit.edu>
From: "Ravindran Parthasarathi" 
To: "Paul Kyzivat" , "Hadriel Kaplan" 
X-OriginalArrivalTime: 17 Oct 2011 22:07:52.0927 (UTC) FILETIME=[375A5EF0:01CC8D19]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 22:07:56 -0000

Hadriel/Paul,

I like the idea of classification of B2BUA because it helps to
understand the function (service) of specific classification of B2BUA.
Few of the B2BUA classification shall be

1) 3PCC
2) SBC (SIP signaling normalization only)
3) 3PCC + media handling
4) SBC + media handling

Thanks
Partha


>-----Original Message-----
>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>Sent: Monday, October 17, 2011 11:25 PM
>To: Hadriel Kaplan
>Cc: Ravindran Parthasarathi; 
>Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
>
>Hadriel,
>
>OK, I guess you see it the same was I was interpreting it.
>I certainly agree that having this info is better than *not* having it.
>But it will further increase what must be understood to correctly spec
a
>system to be assembled out of piece parts. Without this info its hard
to
>spec it at all - you have to hope for the best, that your vendors can
>tweak things until the system works.
>
>If all goes well, the existence of a spec for some function will lead
>those who make B2BUAs think "maybe I should support that", where
>previously they weren't forced to think about it at all.
>
>ISTM it would be *nicer* if we could have classifications for different
>sorts of B2BUAs, and rules for their behavior, as we have for UAs and
>Proxies. But it may be that real devices don't fall into those neat
>classifications well enough for that to work in practice. And what you
>propose doesn't preclude doing that later.
>
>	Thanks,
>	Paul
>
>On 10/17/11 12:44 PM, Hadriel Kaplan wrote:
>>
>> On Oct 17, 2011, at 11:15 AM, Paul Kyzivat wrote:
>>
>>> I guess you are proposing to develop a number of additional RFCs
that
>will each define the behavior of a B2BUA in order that some particular
>"function" will work end-to-end even when the B2BUA is present between
>the ends.
>>>
>>> Someone who is developing a purchase spec by themselves would then
>need to identify which of the "functions" are needed, and require
>compliance to them, in addition to other things. Its not clear to me
>whether this will be something well known to those building a system,
or
>not. (It seems to require a level of understanding of how features are
>implemented that may exceed what a purchaser should be expected to
>know.)
>>>
>>> In the case of the group-based specs, I suppose it would fall on the
>group to identify which of these new RFCs are important and require
>them. But it seems to me those groups have already defined the behavior
>required of B2BUAs in their systems, so this might not help them at
all.
>>>
>>> Can you please clarify how what you are proposing would typically be
>used?
>>
>> I would expect that RFCs published by the STRAW WG would be used in
>the same way as other RFCs published by the RAI area: by
>manufacturers/developers/product-managers, by system purchasers, and by
>other SDOs and Industry Fora such as 3GPP, ETSI, ATIS, Cablelabs,
>SIPForum, i3Forum, GSMA, UCIF, NENA, NICC, TTC, etc., referencing them.
>>
>> For system purchasers: it's true that many wouldn't know the level of
>detail required to know to reference such an RFC, but it's also true
>that many *do* know such things. (or at least that appears to be the
>case, since I see plenty of RFIs/RFPs that are that detailed)
>>
>> For device manufacturers: a lot of them already know what they need
to
>do for most things, but a lot of them apparently don't know, or don't
>care, or can't due to their architecture.  Take the Max-Forwards case,
>for example: plenty of B2BUAs create a new/reset Max-Forwards header
>value on their UAC side for forwarded requests.  We've seen this cause
>unbounded loops in real deployed networks.  Either the B2BUA vendors
>don't know better, or don't care, or can't do it.  Having a published
>RFC means that the purchasers can point to a MUST statement in an RFC
>and tell the vendor to do it, or if the vendor can't do it then the
>purchaser can (a) know the vendor can't and take some other steps to
>prevent loops, and/or (b) decide to choose another vendor.
>>
>> For "group-based-specs": it's true some of them define behavior of
>B2BUA's in their group-system (not all of them do, BTW)... and
obviously
>some or even all RFCs created in STRAW might not help those groups at
>all.  That's ok.  They don't need our help.  But there are a lot of SIP
>domains built that are not based on group-specs.  Virtually every
>Enterprise SIP deployment, for example.  And I think for some
functions,
>the IETF is the most logical place to define how it works across B2BUAs
>because the technical competence/knowledge for the particular function
>is in the IETF.  Like the DTLS-SRTP case, for example.
>>
>> -hadriel
>>
>>


From HKaplan@acmepacket.com  Mon Oct 17 15:17:34 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590C51F0C41 for ; Mon, 17 Oct 2011 15:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX70YlkQG71a for ; Mon, 17 Oct 2011 15:17:33 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7725F21F869E for ; Mon, 17 Oct 2011 15:17:33 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 Oct 2011 18:17:32 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 17 Oct 2011 18:17:32 -0400
From: Hadriel Kaplan 
To: Ravindran Parthasarathi 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMjRqQjGuE9TK8CkqU1ZS+3V5ITA==
Date: Mon, 17 Oct 2011 22:17:32 +0000
Message-ID: <440CEEB7-5138-4719-A7C7-425E66D9A18B@acmepacket.com>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com><4E98AF51.2090704@alum.mit.edu>  <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com>  <4E9C4674.8090107@alum.mit.edu> <0085E4F9-43DE-42E2-B730-1D44849FBBA2@acmepacket.com> <4E9C6C05.3030307@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF51159955@sonusinmail02.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159955@sonusinmail02.sonusnet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <04434EB29CA8B54CA1E1CE18C3B93507@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 22:17:34 -0000

Have you looked at:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-b2bua-taxonomy-00=
.txt


On Oct 17, 2011, at 6:07 PM, Ravindran Parthasarathi wrote:

> Hadriel/Paul,
>=20
> I like the idea of classification of B2BUA because it helps to
> understand the function (service) of specific classification of B2BUA.
> Few of the B2BUA classification shall be
>=20
> 1) 3PCC
> 2) SBC (SIP signaling normalization only)
> 3) 3PCC + media handling
> 4) SBC + media handling
>=20
> Thanks
> Partha
>=20
>=20
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Monday, October 17, 2011 11:25 PM
>> To: Hadriel Kaplan
>> Cc: Ravindran Parthasarathi; 
>> Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
>>=20
>> Hadriel,
>>=20
>> OK, I guess you see it the same was I was interpreting it.
>> I certainly agree that having this info is better than *not* having it.
>> But it will further increase what must be understood to correctly spec
> a
>> system to be assembled out of piece parts. Without this info its hard
> to
>> spec it at all - you have to hope for the best, that your vendors can
>> tweak things until the system works.
>>=20
>> If all goes well, the existence of a spec for some function will lead
>> those who make B2BUAs think "maybe I should support that", where
>> previously they weren't forced to think about it at all.
>>=20
>> ISTM it would be *nicer* if we could have classifications for different
>> sorts of B2BUAs, and rules for their behavior, as we have for UAs and
>> Proxies. But it may be that real devices don't fall into those neat
>> classifications well enough for that to work in practice. And what you
>> propose doesn't preclude doing that later.
>>=20
>> 	Thanks,
>> 	Paul
>>=20
>> On 10/17/11 12:44 PM, Hadriel Kaplan wrote:
>>>=20
>>> On Oct 17, 2011, at 11:15 AM, Paul Kyzivat wrote:
>>>=20
>>>> I guess you are proposing to develop a number of additional RFCs
> that
>> will each define the behavior of a B2BUA in order that some particular
>> "function" will work end-to-end even when the B2BUA is present between
>> the ends.
>>>>=20
>>>> Someone who is developing a purchase spec by themselves would then
>> need to identify which of the "functions" are needed, and require
>> compliance to them, in addition to other things. Its not clear to me
>> whether this will be something well known to those building a system,
> or
>> not. (It seems to require a level of understanding of how features are
>> implemented that may exceed what a purchaser should be expected to
>> know.)
>>>>=20
>>>> In the case of the group-based specs, I suppose it would fall on the
>> group to identify which of these new RFCs are important and require
>> them. But it seems to me those groups have already defined the behavior
>> required of B2BUAs in their systems, so this might not help them at
> all.
>>>>=20
>>>> Can you please clarify how what you are proposing would typically be
>> used?
>>>=20
>>> I would expect that RFCs published by the STRAW WG would be used in
>> the same way as other RFCs published by the RAI area: by
>> manufacturers/developers/product-managers, by system purchasers, and by
>> other SDOs and Industry Fora such as 3GPP, ETSI, ATIS, Cablelabs,
>> SIPForum, i3Forum, GSMA, UCIF, NENA, NICC, TTC, etc., referencing them.
>>>=20
>>> For system purchasers: it's true that many wouldn't know the level of
>> detail required to know to reference such an RFC, but it's also true
>> that many *do* know such things. (or at least that appears to be the
>> case, since I see plenty of RFIs/RFPs that are that detailed)
>>>=20
>>> For device manufacturers: a lot of them already know what they need
> to
>> do for most things, but a lot of them apparently don't know, or don't
>> care, or can't due to their architecture.  Take the Max-Forwards case,
>> for example: plenty of B2BUAs create a new/reset Max-Forwards header
>> value on their UAC side for forwarded requests.  We've seen this cause
>> unbounded loops in real deployed networks.  Either the B2BUA vendors
>> don't know better, or don't care, or can't do it.  Having a published
>> RFC means that the purchasers can point to a MUST statement in an RFC
>> and tell the vendor to do it, or if the vendor can't do it then the
>> purchaser can (a) know the vendor can't and take some other steps to
>> prevent loops, and/or (b) decide to choose another vendor.
>>>=20
>>> For "group-based-specs": it's true some of them define behavior of
>> B2BUA's in their group-system (not all of them do, BTW)... and
> obviously
>> some or even all RFCs created in STRAW might not help those groups at
>> all.  That's ok.  They don't need our help.  But there are a lot of SIP
>> domains built that are not based on group-specs.  Virtually every
>> Enterprise SIP deployment, for example.  And I think for some
> functions,
>> the IETF is the most logical place to define how it works across B2BUAs
>> because the technical competence/knowledge for the particular function
>> is in the IETF.  Like the DTLS-SRTP case, for example.
>>>=20
>>> -hadriel
>>>=20
>>>=20
>=20


From pravindran@sonusnet.com  Mon Oct 17 15:30:16 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D4811E809D for ; Mon, 17 Oct 2011 15:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level: 
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdwxylG2qPW6 for ; Mon, 17 Oct 2011 15:30:15 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8321511E8082 for ; Mon, 17 Oct 2011 15:30:15 -0700 (PDT)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9HMUl3J032011;  Mon, 17 Oct 2011 18:30:47 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 17 Oct 2011 18:30:13 -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: Tue, 18 Oct 2011 03:59:54 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159958@sonusinmail02.sonusnet.com>
In-Reply-To: <440CEEB7-5138-4719-A7C7-425E66D9A18B@acmepacket.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMjRqQjGuE9TK8CkqU1ZS+3V5ITJWBHhHw
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com><4E98AF51.2090704@alum.mit.edu>  <2E239D6FCD033C4BAF15F386A979BF511598D8@sonusinmail02.sonusnet.com>  <4E9C4674.8090107@alum.mit.edu> <0085E4F9-43DE-42E2-B730-1D44849FBBA2@acmepacket.com> <4E9C6C05.3030307@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF51159955@sonusinmail02.sonusnet.com> <440CEEB7-5138-4719-A7C7-425E66D9A18B@acmepacket.com>
From: "Ravindran Parthasarathi" 
To: "Hadriel Kaplan" 
X-OriginalArrivalTime: 17 Oct 2011 22:30:13.0309 (UTC) FILETIME=[56486ED0:01CC8D1C]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Oct 2011 22:30:16 -0000

Hadriel,

Thanks for sending B2BUA taxonomy draft. It will be good starting point
to discuss. I'll review and provide my comments.

Thanks
Partha

>-----Original Message-----
>From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
>Sent: Tuesday, October 18, 2011 3:48 AM
>To: Ravindran Parthasarathi
>Cc: Paul Kyzivat; 
>Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
>
>
>Have you looked at:
>http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-b2bua-
>taxonomy-00.txt
>
>
>On Oct 17, 2011, at 6:07 PM, Ravindran Parthasarathi wrote:
>
>> Hadriel/Paul,
>>
>> I like the idea of classification of B2BUA because it helps to
>> understand the function (service) of specific classification of
B2BUA.
>> Few of the B2BUA classification shall be
>>
>> 1) 3PCC
>> 2) SBC (SIP signaling normalization only)
>> 3) 3PCC + media handling
>> 4) SBC + media handling
>>
>> Thanks
>> Partha
>>
>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Monday, October 17, 2011 11:25 PM
>>> To: Hadriel Kaplan
>>> Cc: Ravindran Parthasarathi; 
>>> Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
>>>
>>> Hadriel,
>>>
>>> OK, I guess you see it the same was I was interpreting it.
>>> I certainly agree that having this info is better than *not* having
>it.
>>> But it will further increase what must be understood to correctly
>spec
>> a
>>> system to be assembled out of piece parts. Without this info its
hard
>> to
>>> spec it at all - you have to hope for the best, that your vendors
can
>>> tweak things until the system works.
>>>
>>> If all goes well, the existence of a spec for some function will
lead
>>> those who make B2BUAs think "maybe I should support that", where
>>> previously they weren't forced to think about it at all.
>>>
>>> ISTM it would be *nicer* if we could have classifications for
>different
>>> sorts of B2BUAs, and rules for their behavior, as we have for UAs
and
>>> Proxies. But it may be that real devices don't fall into those neat
>>> classifications well enough for that to work in practice. And what
>you
>>> propose doesn't preclude doing that later.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>> On 10/17/11 12:44 PM, Hadriel Kaplan wrote:
>>>>
>>>> On Oct 17, 2011, at 11:15 AM, Paul Kyzivat wrote:
>>>>
>>>>> I guess you are proposing to develop a number of additional RFCs
>> that
>>> will each define the behavior of a B2BUA in order that some
>particular
>>> "function" will work end-to-end even when the B2BUA is present
>between
>>> the ends.
>>>>>
>>>>> Someone who is developing a purchase spec by themselves would then
>>> need to identify which of the "functions" are needed, and require
>>> compliance to them, in addition to other things. Its not clear to me
>>> whether this will be something well known to those building a
system,
>> or
>>> not. (It seems to require a level of understanding of how features
>are
>>> implemented that may exceed what a purchaser should be expected to
>>> know.)
>>>>>
>>>>> In the case of the group-based specs, I suppose it would fall on
>the
>>> group to identify which of these new RFCs are important and require
>>> them. But it seems to me those groups have already defined the
>behavior
>>> required of B2BUAs in their systems, so this might not help them at
>> all.
>>>>>
>>>>> Can you please clarify how what you are proposing would typically
>be
>>> used?
>>>>
>>>> I would expect that RFCs published by the STRAW WG would be used in
>>> the same way as other RFCs published by the RAI area: by
>>> manufacturers/developers/product-managers, by system purchasers, and
>by
>>> other SDOs and Industry Fora such as 3GPP, ETSI, ATIS, Cablelabs,
>>> SIPForum, i3Forum, GSMA, UCIF, NENA, NICC, TTC, etc., referencing
>them.
>>>>
>>>> For system purchasers: it's true that many wouldn't know the level
>of
>>> detail required to know to reference such an RFC, but it's also true
>>> that many *do* know such things. (or at least that appears to be the
>>> case, since I see plenty of RFIs/RFPs that are that detailed)
>>>>
>>>> For device manufacturers: a lot of them already know what they need
>> to
>>> do for most things, but a lot of them apparently don't know, or
don't
>>> care, or can't due to their architecture.  Take the Max-Forwards
>case,
>>> for example: plenty of B2BUAs create a new/reset Max-Forwards header
>>> value on their UAC side for forwarded requests.  We've seen this
>cause
>>> unbounded loops in real deployed networks.  Either the B2BUA vendors
>>> don't know better, or don't care, or can't do it.  Having a
published
>>> RFC means that the purchasers can point to a MUST statement in an
RFC
>>> and tell the vendor to do it, or if the vendor can't do it then the
>>> purchaser can (a) know the vendor can't and take some other steps to
>>> prevent loops, and/or (b) decide to choose another vendor.
>>>>
>>>> For "group-based-specs": it's true some of them define behavior of
>>> B2BUA's in their group-system (not all of them do, BTW)... and
>> obviously
>>> some or even all RFCs created in STRAW might not help those groups
at
>>> all.  That's ok.  They don't need our help.  But there are a lot of
>SIP
>>> domains built that are not based on group-specs.  Virtually every
>>> Enterprise SIP deployment, for example.  And I think for some
>> functions,
>>> the IETF is the most logical place to define how it works across
>B2BUAs
>>> because the technical competence/knowledge for the particular
>function
>>> is in the IETF.  Like the DTLS-SRTP case, for example.
>>>>
>>>> -hadriel
>>>>
>>>>
>>


From rmohanr@cisco.com  Mon Oct 17 21:27:44 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3FB11E80D2 for ; Mon, 17 Oct 2011 21:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.419
X-Spam-Level: 
X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpNju7yAdS8q for ; Mon, 17 Oct 2011 21:27:44 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8D67A11E80C8 for ; Mon, 17 Oct 2011 21:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=5612; q=dns/txt; s=iport; t=1318912063; x=1320121663; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5JzjlEYYHxR+xX/Qyz2dm6w3o80G5exXLqxK/NTb3fQ=; b=YfgBhAm6HiDpsVD/p4i7c9+qeM6g3qHG0zzEPPfnHFVJvhpHiH7fAqpL rBAeDa5xo10XXIZoKcwbkTMSpQMH5X20sW9WaYbel6NHhOyLOEKtbOmNw ZPWY5dKBG9/YUkcN9v7XgKlC7wqYbIZ4rCBuxGZ5Syv/uudMmXlB1H3YU E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApgAAD7/nE5Io8UT/2dsb2JhbAA5Cpk1jyaBBYFuAQEBAQMBAQEPAR0KNBcEAgEIDgMBAwEBCwYXAQYBJh8DBggCBAEKCAgah2WXeQGfBgSEWYJOYQSIAJEvjCs
X-IronPort-AV: E=Sophos;i="4.69,363,1315180800";  d="scan'208";a="1203208"
Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-3.cisco.com with ESMTP; 18 Oct 2011 04:27:41 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9I4RVxG009617; Tue, 18 Oct 2011 04:27:40 GMT
Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 18 Oct 2011 09:57:23 +0530
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: Tue, 18 Oct 2011 09:57:21 +0530
Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD08091B66@XMB-BGL-417.cisco.com>
In-Reply-To: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMiq9OXX9LeDoA90O2vC51RKdIFpWBhSLw
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com>
From: "Ram Mohan R (rmohanr)" 
To: "Hadriel Kaplan" , 
X-OriginalArrivalTime: 18 Oct 2011 04:27:23.0388 (UTC) FILETIME=[3B9AFBC0:01CC8D4E]
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2011 04:27:45 -0000

I would be interested in this work and this is a good start. We have a
lot of B2BUA that continues to add lots of functionalities without any
real specifications on how to do that.=20
I will review your taxonomy draft and provide my comments.

Regards,
Ram

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Saturday, October 15, 2011 1:55 AM
> To: dispatch@ietf.org list
> Subject: [dispatch] BEHAVE for B2BUAs charter proposal
>=20
> Howdy,
> a year ago or so, there was a thread and informal bar-bof around the
> topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know
> the conclusion of the discussion, but it appears there was not enough
> interest at the time, or perhaps not enough concrete work to do and
> people to do it.  Since that time, we've had several I-Ds which could
> arguably fit in such a WG, or at least benefit from one, if it applied
> to B2BUAs in general.
>=20
> This email is to see if there's interest now, but with a slightly
> different tack: a concrete WG charter proposal, as described below.
>=20
> Interest/comments/flames welcomed.
>=20
>=20
> Description of STRAW Working Group
> =
=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
> Name: Sip Traversal Required for Applications to Work (STRAW)
>=20
> Problem Statement:
> Within the context of the SIP protocol and architecture, a
Back-to-Back
> User Agent (B2BUA) is any SIP device in the logical path between two
> User Agents performing a role beyond that of a Proxy as defined in RFC
> 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming
> a B2BUA in order to terminate dead sessions by generating BYEs; or it
> may be a 3PCC-style agent only modifying SDP; or it may be a Session
> Border Controller performing such functions as in RFC 5853; or it may
> be an Enterprise PBX terminating REFERs and such; or it may be a
> complete UAS and UAC implementation with a PRI loopback in-between.
>=20
> In its most extreme form, the scope of the SIP protocol ends at the
UAS
> of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In
> practice, however, users expect some SIP protocol aspects to go beyond
> the scope of the B2BUA's UAS side, and be traversed onto its UAC side,
> as if the B2BUA was not an end unto itself; this is similar to the
> expectation that emails work when they cross from POP and IMAP to/from
> SMTP.
>=20
> It is impossible to normatively define all the behaviors of B2BUAs in
> general, or even subsets of them such as SBCs. Unlike consumer NATs,
> B2BUAs perform widely varying functions for purposes which may be
> unique to their environment, unique to their architecture, or unique
to
> the wishes of their administrator.  Instead of defining all things a
> given type of B2BUA must do, a more practical objective would be to
> define what very few things any B2BUA must do to make a specific SIP
> mechanism work, and let the market decide whether to do those things.
>=20
> The name of this working group reflects that practical objective: if
> there were a thin straw between the SIP UAS and UAC of a B2BUA, what
> must be passed through that straw and used on each side.  Or viewed
> another way, if a B2BUA were in fact a UAS and UAC connected with a
PRI
> loopback circuit, and if we could extend ISDN, what information would
> we carry in ISDN across the PRI for a specific SIP mechanism to work
> end-to-end.
>=20
> For example, the WG could produce a document which specifies that the
> Max-Forwards header field value should be copied and decremented
across
> the B2BUA, if the B2BUA wishes to prevent loops.  Administrators could
> then tell their B2BUA vendors to comply with the document, if the
> administrator so wishes.
>=20
> Objectives:
> The objectives of the STRAW Working Group are to publish normative
> documents which define which SIP header fields, parameters, MIME
> bodies, body content fields/information, or media-plane
characteristics
> are required to traverse between the User Agent "sides" of a B2BUA for
> specific functions to work.
>=20
> Deliverables would indicate which types of B2BUAs would apply or not.
> For example, a document defining the requirements for end-to-end DTLS-
> SRTP would not apply to B2BUAs which terminate media, such as
> transcoders or recorders.
>=20
> The intention of this WG is to document such requirements in separate
> documents, per SIP or media function, instead of as one document for
> all functions.  That will both reduce the time to publication, as well
> a provide B2BUA administrators and manufacturers with simple
comply/no-
> comply criteria.
>=20
>=20
> Initial Deliverables:
> 1) A document defining the requirements for B2BUAs to identify
specific
> features/capabilities support.
> 2) A document defining the requirements for B2BUAs with respect to
loop
> detection/prevention.
> 3) A document defining the requirements for B2BUAs to support end-to-
> end and hop-by-hop media-loopback test calls.
> 4) A document defining the requirements for B2BUAs to support
DTLS-SRTP
> (RFC 5764) end-to-end.
> 5) A document defining the requirements for B2BUAs to support STUN
> connectivity checks end-to-end.
>=20
> [also add a taxonomy document?]
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From akaithal@cisco.com  Mon Oct 17 21:58:32 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44391F0C62 for ; Mon, 17 Oct 2011 21:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.598
X-Spam-Level: 
X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=3.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD72HQSgDx7x for ; Mon, 17 Oct 2011 21:58:29 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DFE9D1F0C5A for ; Mon, 17 Oct 2011 21:57:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akaithal@cisco.com; l=19381; q=dns/txt; s=iport; t=1318913870; x=1320123470; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=jZQHtvOrRvfjUWQ5NFbznf8j31RHCmXMXBykAt/ezdQ=; b=lU7pEI6+gBadgOokrIluGDa5FP+prKivP0j4K57HtxdzkKI8vCgt6BMU 9YExdTY6W2aziqu/q8qQyypRCgItta6MeyhFpOWbkd76NGXleySwyO+Po l7izYBhkdf59sC0lbX1whdv7zNwbKGiW6FIwwQ0H7oyPYQ6Cg04/6RPrj o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApgAAPkGnU5Io8UT/2dsb2JhbAA5CoJNlmiPJoEFgW4BAQEBAxIBCREDRxICAQgOAwQBAQsCBBcBBgFFCQgBAQQBCggIARIHh2WYCQGfCIRZgk5hBIgAkS+MKw
X-IronPort-AV: E=Sophos;i="4.69,363,1315180800";  d="scan'208,217";a="119339876"
Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2011 04:57:43 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9I4vgjT017060; Tue, 18 Oct 2011 04:57:43 GMT
Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 18 Oct 2011 10:27:41 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8D52.76BE91DE"
x-cr-puzzleid: {2D59AA9D-4C78-41A0-B2EF-0AECFCC208AB}
x-cr-hashedpuzzle: A/4E Cudl C7Yd H/9j JxjH J+zD LfZR MXQl NB9P PLRr QY/l SCQR TKd7 TXP0 T4Ry VHxW; 2; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAcAByAGEAdgBpAG4AZAByAGEAbgBAAHMAbwBuAHUAcwBuAGUAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {2D59AA9D-4C78-41A0-B2EF-0AECFCC208AB}; YQBrAGEAaQB0AGgAYQBsAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Tue, 18 Oct 2011 04:57:26 GMT; UgBFADoAIABbAGQAaQBzAHAAYQB0AGMAaABdACAATgBlAHcAIABWAGUAcgBzAGkAbwBuACAATgBvAHQAaQBmAGkAYwBhAHQAaQBvAG4AIABmAG8AcgBkAHIAYQBmAHQALQBrAGEAaQB0AGgAYQBsAC0AZABpAHMAcABhAHQAYwBoAC0AcwBpAHAALQBsAG8AZwAtAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAtADAAMAAuAHQAeAB0AA==
Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2011 10:27:25 +0530
Message-ID: 
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F17F5@sonusinmail02.sonusnet.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] New Version Notification fordraft-kaithal-dispatch-sip-log-information-00.txt
Thread-Index: AcyJcvbAqUtQRrOcThW4vOoWqJmk7gBDJZRQALKhUhA=
References:  <2E239D6FCD033C4BAF15F386A979BF510F17F5@sonusinmail02.sonusnet.com>
From: "Adarsh Kaithal (akaithal)" 
To: "Ravindran Parthasarathi" , 
X-OriginalArrivalTime: 18 Oct 2011 04:57:41.0328 (UTC) FILETIME=[772E9D00:01CC8D52]
Subject: Re: [dispatch] New Version Notification fordraft-kaithal-dispatch-sip-log-information-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2011 04:58:32 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC8D52.76BE91DE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Partha,

=20

Thanks for your comments.

=20

It is good to have session-id , it will solve our purpose  and we can
use this to indentify the session end to end.=20

=20

Please see the response inline.

=20

Best Regards,

Adarsh

=20

From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com]=20

Sent: Friday, October 14, 2011 8:59 PM

To: Adarsh Kaithal (akaithal); dispatch@ietf.org

Subject: RE: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

=20

Adarsh,

=20

I skimmed through your draft. IIUC, your intention is to log SIPCLF
messages in all SIP devices during the session, SIPCLF with session-id
(dialog-id) will serve the purpose to collect the session in all the SIP
devices, "Log-me" header is used to enable the logging mechanism in each
SIP devices dynamically.  I like the idea in high level but the draft
has lot of loose ends:

=20

1) SIP header passing through B2BUA has lot of challenges because lot of
SIP services enables specific services which results in zero or one or
more messages is the other side of the B2BUA. Session-id is the crucial
for this work to move ahead but Dispatch has to first dispatch
session-id WG first.  For the time being, let us assume the world is
full of SIP proxy, then dialog-id shall be used as unique id to identify
the dialog.

[Adarsh] I agree, I have put a clause of B2BUA not to remove the
"Log-Me" header. It can add one of its own but have to have same tag to
match the call  .

=20

2) "Log-me" MUST NOT direct the other device to use the loSessgging type
(tftp, sftp) because it involves the device control of another SIP
entity. In case device control is desired as part of this functionality,
there is an ongoing dispatch discussion on device control whose
mechanism has to integrated into this header. IMO, device control should
not integrated with this. Let implementers choose their own mechanism as
a starting point.

[Adarsh] This is not a device control. I am putting data to use those
server to put the logs that it. There is nothing like controlling the
device.=20

=20

3) SIP primitives like REFER, join has to be well defined. "Log-me" may
not pass across automatically.

[Adarsh] "Log-Me" is an optional header and it can present REFER and
JOIN, if it present in the REFER the subsequent  INVITE etc should have
the "LOG-Me" as well. I will explain more about Join in the draft.

=20

4) There is no stopping "logging" mechanism within the dialog=20

=20

[Adarsh] I have not provided that mechanism purposefully as I have put a
applicability statement "Each entity is free to simply ignore request ,
if it is not interested in log collection, or busy with other
activities." As this is call based so one complete dialog will be
logged, I did not find much use of stop logging mechanism within the
dialog. It will be over kill.

=20

5) How this header applies to SUBSCRIBE, REGISTER, PUBLISH, OPTIONS

=20

[Adarsh] yes it is applicable for SUBSCRIBE, REGISTER and OPTION. I need
to thing about PUBLISH use cases before adding it in the RFC.

=20

Thanks

Partha

=20

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Adarsh Kaithal (akaithal)

Sent: Thursday, October 13, 2011 12:10 PM

To: dispatch@ietf.org

Subject: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt

=20

Hi All

=20

Introduction of the draft:-

The current mechanisms to debug issues in SIP network are not very

efficient.  It requires to enable debugging logs across different

devices, recreate the problem and then collect the logs.  The idea is

to provide a solution to automatically enable relevant logs (SIP

messages and any other debugging logs meaningful to SIP devices), and

also to indicate where the logs are to be collected or stored.  The

enabling of logs will happen at all the SIP devices(upstream or

downstream).  This will help to get the logs from all the SIP devices

in a Common logging format (CLF).  The solution extends SIP to

provide the infrastructure to enable logging for upstream and

downstream devices with each server deciding how much troubleshooting

information it wants to log - with freedom to simply ignore requests

if required.  This document specifies a new header called "Log-Me"
Header

in all the SIP messages

=20

Link to the draft:-=20

http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt

=20

Let me know if the working group is interested to solve this problem and
comments on the draft.

=20

Best Regards,

Adarsh

=20


------_=_NextPart_001_01CC8D52.76BE91DE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi Partha,



 



Thanks for your comments.



 



It is good to have session-id , it will solve =
our
purpose  and we can use this to indentify the session end to end. =




 



Please see the response inline.



 



Best Regards,



Adarsh



 



From: Ravindran Parthasarathi =
[mailto:pravindran@sonusnet.com]




Sent: Friday, October 14, 2011 8:59 =
PM



To: Adarsh Kaithal (akaithal); =
dispatch@ietf.org



Subject: RE: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt



 



Adarsh,



 



I skimmed through your draft. IIUC, your =
intention is to
log SIPCLF messages in all SIP devices during the session, SIPCLF with
session-id (dialog-id) will serve the purpose to collect the session in =
all the
SIP devices, “Log-me” header is used to enable the logging
mechanism in each SIP devices dynamically.  I like the idea in high =
level
but the draft has lot of loose ends:



 



1) SIP header passing through B2BUA has lot of =
challenges
because lot of SIP services enables specific services which results in =
zero or
one or more messages is the other side of the B2BUA. Session-id is the =
crucial
for this work to move ahead but Dispatch has to first dispatch =
session-id WG
first.  For the time being, let us assume the world is full of SIP =
proxy,
then dialog-id shall be used as unique id to identify the =
dialog.



[Adarsh] I agree, I have put a clause of B2BUA =
not to
remove the “Log-Me” header. It can add one of its own but =
have to
have same tag to match the call <have to put this in draft> =
.



 



2) “Log-me” MUST NOT direct the =
other device
to use the loSessgging type (tftp, sftp) because it involves the device =
control
of another SIP entity. In case device control is desired as part of this
functionality, there is an ongoing dispatch discussion on device control =
whose
mechanism has to integrated into this header. IMO, device control should =
not
integrated with this. Let implementers choose their own mechanism as a =
starting
point.



[Adarsh] This is not a device control. I am =
putting data
to use those server to put the logs that it. There is nothing like =
controlling
the device. 



 



3) SIP primitives like REFER, join has to be =
well
defined. “Log-me” may not pass across =
automatically.



[Adarsh] “Log-Me” is an optional =
header and
it can present REFER and JOIN, if it present in the REFER the =
subsequent 
INVITE etc should have the “LOG-Me” as well. I will explain =
more
about Join in the draft.



 



4) There is no stopping “logging” =
mechanism
within the dialog 



 



[Adarsh] I have not provided that mechanism =
purposefully
as I have put a applicability statement “Each entity is free to =
simply
ignore request , if it is not interested in log collection, or busy with =
other
activities.” As this is call based so one complete dialog will be =
logged,
I did not find much use of stop logging mechanism within the dialog. It =
will be
over kill.



 



5) How this header applies to SUBSCRIBE, =
REGISTER,
PUBLISH, OPTIONS



 



[Adarsh] yes it is applicable for SUBSCRIBE, =
REGISTER and
OPTION. I need to thing about PUBLISH use cases before adding it in the =
RFC.



 



Thanks



Partha



 



From: dispatch-bounces@ietf.org =
[mailto:dispatch-bounces@ietf.org]
On Behalf Of Adarsh Kaithal (akaithal)



Sent: Thursday, October 13, 2011 12:10 =
PM



To: dispatch@ietf.org



Subject: [dispatch] New Version Notification
fordraft-kaithal-dispatch-sip-log-information-00.txt



 



Hi All



 



Introduction of the draft:-



The current mechanisms to debug issues in SIP =
network are
not very



efficient.  It requires to enable debugging =
logs
across different



devices, recreate the problem and then collect =
the
logs.  The idea is



to provide a solution to automatically enable =
relevant
logs (SIP



messages and any other debugging logs meaningful =
to SIP
devices), and



also to indicate where the logs are to be =
collected or
stored.  The



enabling of logs will happen at all the SIP
devices(upstream or



downstream).  This will help to get the =
logs from
all the SIP devices



in a Common logging format (CLF).  The =
solution
extends SIP to



provide the infrastructure to enable logging for =
upstream
and



downstream devices with each server deciding how =
much
troubleshooting



information it wants to log - with freedom to =
simply
ignore requests



if required.  This document specifies a new =
header
called “Log-Me” Header



in all the SIP messages



 



Link to the draft:- 



http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-informatio=
n-00.txt



 



Let me know if the working group is interested =
to solve
this problem and comments on the draft.



 



Best Regards,



Adarsh



 









------_=_NextPart_001_01CC8D52.76BE91DE--

From oej@edvina.net  Tue Oct 18 00:03:04 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAD31F0C6E for ; Tue, 18 Oct 2011 00:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.853
X-Spam-Level: 
X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoZi9rYuRQGY for ; Tue, 18 Oct 2011 00:03:03 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1B1F0C5D for ; Tue, 18 Oct 2011 00:03:03 -0700 (PDT)
Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 876F9754BCD5; Tue, 18 Oct 2011 07:02:59 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Tue, 18 Oct 2011 09:00:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> 
To: Wilhelm Wimmreuter 
X-Mailer: Apple Mail (2.1251.1)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2011 07:03:04 -0000

17 okt 2011 kl. 22:03 skrev Wilhelm Wimmreuter:

> Think it shall be RFC4474
>=20
> Agree, it is underspecified and in parts to some extents way =
overloaded.
> - Signs elements that will be modified by SBCs
> - Signs things that have only marginally to do with the originators =
identity
> - does nit clearly distinguish between the originators domain and a =
phone number
> - ...
>=20
> However it seems to be quite difficult and likely becomes even more =
complex if we add things like federations and cross PKI certificate =
acceptance.
>=20
> My guess is that we to take a lot of usability issues in to =
consideration if we want to make it really useful. e.g. initial =
enrollment and certificate renewal.
>=20
> Besides usability, one shall think about reducing the functionality to =
sign the originating identity and domain only. This still would allow to =
protect the sip message by other means. This approach has the advantage =
of separating transport security and the originating identity. With this =
clear separation, authentication would become transparent to SBCs and =
other servers in the setup path. With that, any element in the call path =
can validate the caller ID and decide on further authorization. This =
would also be relevant for the recently signed CALLER-ID Act.
>=20
Seems like there are some issues to discuss here. Also, why is not the =
Identity-Info header signed? It points to where
the certificate exists, but can easily be changed by middlemen unless =
I've missed something.

/O
> Willi
>=20
>=20
> On 17.10.2011, at 17:16, Olle E. Johansson wrote:
>=20
>>=20
>> 14 okt 2011 kl. 22:24 skrev Hadriel Kaplan:
>>=20
>>> Howdy,
>>> a year ago or so, there was a thread and informal bar-bof around the =
topic of "Should the IETF have a BEHAVE WG for SBCs".  I do not know the =
conclusion of the discussion, but it appears there was not enough =
interest at the time, or perhaps not enough concrete work to do and =
people to do it.  Since that time, we've had several I-Ds which could =
arguably fit in such a WG, or at least benefit from one, if it applied =
to B2BUAs in general.
>>>=20
>>> This email is to see if there's interest now, but with a slightly =
different tack: a concrete WG charter proposal, as described below.
>>>=20
>>> Interest/comments/flames welcomed.
>> I think it's high time to start this work. We have seen the need for =
it in the discussions around Asterisk
>> for a very long time. One could easily add SIP Identity for User =
Agents to this list, as RFC 4744 is=20
>> horribly underspecified in this regard...
>>=20
>> /O
>>>=20
>>>=20
>>> Description of STRAW Working Group
>>> =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
>>> Name: Sip Traversal Required for Applications to Work (STRAW)
>>>=20
>>> Problem Statement:=20
>>> Within the context of the SIP protocol and architecture, a =
Back-to-Back User Agent (B2BUA) is any SIP device in the logical path =
between two User Agents performing a role beyond that of a Proxy as =
defined in RFC 3261.  The B2BUA may be as simple as a session-stateful =
Proxy becoming a B2BUA in order to terminate dead sessions by generating =
BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a =
Session Border Controller performing such functions as in RFC 5853; or =
it may be an Enterprise PBX terminating REFERs and such; or it may be a =
complete UAS and UAC implementation with a PRI loopback in-between.=20
>>>=20
>>> In its most extreme form, the scope of the SIP protocol ends at the =
UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  =
In practice, however, users expect some SIP protocol aspects to go =
beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC =
side, as if the B2BUA was not an end unto itself; this is similar to the =
expectation that emails work when they cross from POP and IMAP to/from =
SMTP.
>>>=20
>>> It is impossible to normatively define all the behaviors of B2BUAs =
in general, or even subsets of them such as SBCs. Unlike consumer NATs, =
B2BUAs perform widely varying functions for purposes which may be unique =
to their environment, unique to their architecture, or unique to the =
wishes of their administrator.  Instead of defining all things a given =
type of B2BUA must do, a more practical objective would be to define =
what very few things any B2BUA must do to make a specific SIP mechanism =
work, and let the market decide whether to do those things.
>>>=20
>>> The name of this working group reflects that practical objective: if =
there were a thin straw between the SIP UAS and UAC of a B2BUA, what =
must be passed through that straw and used on each side.  Or viewed =
another way, if a B2BUA were in fact a UAS and UAC connected with a PRI =
loopback circuit, and if we could extend ISDN, what information would we =
carry in ISDN across the PRI for a specific SIP mechanism to work =
end-to-end.
>>>=20
>>> For example, the WG could produce a document which specifies that =
the Max-Forwards header field value should be copied and decremented =
across the B2BUA, if the B2BUA wishes to prevent loops.  Administrators =
could then tell their B2BUA vendors to comply with the document, if the =
administrator so wishes.
>>>=20
>>> Objectives:
>>> The objectives of the STRAW Working Group are to publish normative =
documents which define which SIP header fields, parameters, MIME bodies, =
body content fields/information, or media-plane characteristics are =
required to traverse between the User Agent "sides" of a B2BUA for =
specific functions to work. =20
>>>=20
>>> Deliverables would indicate which types of B2BUAs would apply or =
not.  For example, a document defining the requirements for end-to-end =
DTLS-SRTP would not apply to B2BUAs which terminate media, such as =
transcoders or recorders.
>>>=20
>>> The intention of this WG is to document such requirements in =
separate documents, per SIP or media function, instead of as one =
document for all functions.  That will both reduce the time to =
publication, as well a provide B2BUA administrators and manufacturers =
with simple comply/no-comply criteria.
>>>=20
>>>=20
>>> Initial Deliverables:
>>> 1) A document defining the requirements for B2BUAs to identify =
specific features/capabilities support.
>>> 2) A document defining the requirements for B2BUAs with respect to =
loop detection/prevention.
>>> 3) A document defining the requirements for B2BUAs to support =
end-to-end and hop-by-hop media-loopback test calls.
>>> 4) A document defining the requirements for B2BUAs to support =
DTLS-SRTP (RFC 5764) end-to-end.
>>> 5) A document defining the requirements for B2BUAs to support STUN =
connectivity checks end-to-end.
>>>=20
>>> [also add a taxonomy document?]
>>>=20
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
>> ---
>> * Olle E Johansson - oej@edvina.net
>> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
>>=20
>>=20
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch

---
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden




From HKaplan@acmepacket.com  Tue Oct 18 06:48:53 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB2F21F8B5D for ; Tue, 18 Oct 2011 06:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.496
X-Spam-Level: 
X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dAs7nfvBvXL for ; Tue, 18 Oct 2011 06:48:52 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BC1DC21F8AD8 for ; Tue, 18 Oct 2011 06:48:52 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 18 Oct 2011 09:48:51 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 09:48:51 -0400
From: Hadriel Kaplan 
To: "Olle E. Johansson" 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMjZyqjGuE9TK8CkqU1ZS+3V5ITA==
Date: Tue, 18 Oct 2011 13:48:50 +0000
Message-ID: <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6B565D4361E4E0428E5C74BD6581C533@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2011 13:48:53 -0000

On Oct 18, 2011, at 3:00 AM, Olle E. Johansson wrote:

> Seems like there are some issues to discuss here. Also, why is not the Id=
entity-Info header signed? It points to where
> the certificate exists, but can easily be changed by middlemen unless I'v=
e missed something.

It doesn't matter if the Identity-Info header is changed by a middleman.  D=
oing so doesn't help the middleman lie about anything. =20

Either the middleman modifies the Identity-Info to point to a different cer=
tificate, which will correctly invalidate the 4474 signature (which a middl=
eman can do any number of other ways).  Or the middleman can point to a dif=
ferent location for the same certificate so the signature remains valid, bu=
t that still doesn't help the middleman do anything since it can't change t=
he SIP message without invalidating the signature.

-hadriel


From dean.willis@softarmor.com  Tue Oct 18 16:46:08 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BAD21F889A for ; Tue, 18 Oct 2011 16:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jk7lfPrzGfG for ; Tue, 18 Oct 2011 16:46:08 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A37A21F86B3 for ; Tue, 18 Oct 2011 16:46:08 -0700 (PDT)
Received: by qadb12 with SMTP id b12so1115987qad.31 for ; Tue, 18 Oct 2011 16:46:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.65.203 with SMTP id k11mr974525qci.233.1318981567691; Tue, 18 Oct 2011 16:46:07 -0700 (PDT)
Received: by 10.229.219.195 with HTTP; Tue, 18 Oct 2011 16:46:07 -0700 (PDT)
In-Reply-To: <7D21EB4B-802A-47D6-8F10-6E2692499BC4@acmepacket.com>
References: <7D21EB4B-802A-47D6-8F10-6E2692499BC4@acmepacket.com>
Date: Tue, 18 Oct 2011 18:46:07 -0500
Message-ID: 
From: Dean Willis 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] SIP Traceroute with media-loopback I-D
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2011 23:46:08 -0000

On Fri, Oct 14, 2011 at 12:22 PM, Hadriel Kaplan  w=
rote:
> Howdy,
> I've submitted an I-D with a strawman proposal for how to provide the abi=
lity to make media-loopback test calls to B2BUAs along the path to a target=
. =A0The current proposal is to use a new SIP header, but there are other p=
ossible solutions.

Sadly, a needed thing. We have created a monstrosity, might as well
add some bolts to its neck for the jumper cables to attach to.

--
Dean

From dean.willis@softarmor.com  Tue Oct 18 17:23:30 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B9921F8AEA for ; Tue, 18 Oct 2011 17:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbGX0x4gyDXX for ; Tue, 18 Oct 2011 17:23:30 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7CC21F8AF5 for ; Tue, 18 Oct 2011 17:23:30 -0700 (PDT)
Received: by qyk34 with SMTP id 34so2499604qyk.10 for ; Tue, 18 Oct 2011 17:23:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.11.145 with SMTP id t17mr1010326qct.5.1318981953558; Tue, 18 Oct 2011 16:52:33 -0700 (PDT)
Received: by 10.229.219.195 with HTTP; Tue, 18 Oct 2011 16:52:33 -0700 (PDT)
In-Reply-To: <84B0F69E-5BB5-41FD-A331-6C7B469C0EB2@acmepacket.com>
References: <84B0F69E-5BB5-41FD-A331-6C7B469C0EB2@acmepacket.com>
Date: Tue, 18 Oct 2011 18:52:33 -0500
Message-ID: 
From: Dean Willis 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] B2BUA-taxonomy for STRAW WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Oct 2011 00:23:31 -0000

On Sat, Oct 15, 2011 at 12:31 AM, Hadriel Kaplan  wrote:
>
> As part of the proposed STRAW WG charter, a possible deliverable might be a taxonomy document of B2BUA roles as might be useful for STRAW WG work items to reference.
>

Howdy, Forks!

I believe I enumerated some aspects of transparency on one of our
lists back in 2002 that might be relevant to this discussion:


Repost follows:
-----------------------


The 3GPP idea is to try and make the B2BUA as "transparent" to new
functions as it can be while still accomplishing other things required
by 3GPP. I suspect they're a long way from solving this, as it makes for
wicked and subtle compromises.

One might argue that a proxy is, by definition, a particularly
transparent B2BUA -- it basically alters nothing but the next hop, and
doesn't mess with things it doesn't understand.

One can actually define a whole range of "transparency" if one is so
inclined. I suppose I should write a draft on this someday. But it makes
a good Top-10 list . . .

1) Dialog transparency: The call-ID is the same on "both sides" of the
B2BUA. Proxies have this characteristic. A B2BUA that actually
terminates a dialog on one side and generates a new dialog on the other
doesn't. Some 3GPP AS functions fall into this category, as do 3PCC
controllers.

2) Identity transparency: The user appears to have the same identity on
both sides of the B2BUA. A proxy has this property. An identity
anonymizer doesn't.

3) CSEQ transparency: The B2BUA does not alter CSEQ numbers. A
traditional proxy has this property. A 3GPP P-CSCF does not, as it can
generate a BYE message and then have to manage disjoint CSEQ spaces on
each side.

4) Header transparency: The B2BUA doesn't change headers that transit
it. Proxies have mostly this property, changing onlya few headers that
are specifically changed by the proxy function. Proxies don't change
headers they don't understand. 3GPP "proxies" are likely to go to town
changing all SORTS of headers. All with the best of intentions, mind
you.

5) Body transparency: The MIME bodies on the SIP message are not altered
by the B2BUA. Real SIP proxies have this property. Firewall proxies that
modify SDP, and most everything in 3GPP, doesn't.

6) Media transparency: AS with body transparency, but considering only
the media aspects. The 3GPP P-CSCF breaks this transparency rule by
editing one's SDP to meet operator preferences.

7) Topology transparency. Via, Route, Record-Route, Path,
P-Service-Route, and other headers that reveal topology are roughly the
same on both sides of the B2BUA, save for any which uniquely identify
that B2BUA. Proxies have this characteristic. Topology hiding devices
like the dynamicosft "firewall proxy in edge proxy mode" or the 3GPP
THIG don't.

8) Security transparency: The B2BUA doesn't alter security aspects, such
as encryptions, authorization headers, etc. Proxies generally have this
property, but 3GPP stuff  doesn't.

9) Accounting transparency: Stuff used to generate records or track
usage is not altered by a B2BUA with this property. Proxies have this
property. 3GPP is trying to define a P-header (P-original-dialog-ID, I
believe) to provide for accounting transparency across 3GPP AS elements
operating at a low level of transparency.

10) Functional transparency: The task that the user of the UA wants to
accomplish actually works across the B2BUA, rather than being
blocked/distorted by it. Proxies generally have this property, with the
caveat the proxy can reject a request if needed. Some 3GPP entities can
mutate functionality beyond all recognition. This is probably the single
most important transparency concept. The rules of a "proxy" as defined
in RFC3162 are there to preserve functional transparency, and anything
that "breaks" those rules is likely to compromise functionality in some
way.



-- 
Dean Willis

From wilhelm@wimmreuter.de  Wed Oct 19 00:55:52 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C025921F8AF5 for ; Wed, 19 Oct 2011 00:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q0jmifLiSBZ for ; Wed, 19 Oct 2011 00:55:52 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1448821F8AF4 for ; Wed, 19 Oct 2011 00:55:51 -0700 (PDT)
Received: from [192.168.0.42] (83-215-77-219.stjo.dyn.salzburg-online.at [83.215.77.219]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0M9AKX-1RMG0t3k2H-00D5CS; Wed, 19 Oct 2011 09:55:39 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Wilhelm Wimmreuter 
In-Reply-To: <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com>
Date: Wed, 19 Oct 2011 09:55:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>   <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com>
To: Hadriel Kaplan 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:jdo+ibh8sfPWIupTWrl1GyILmRqOeR/FPnGkTZ2sITB Y46JAKIl539OQpyCBSP6dsx71QHJmtp+p35WabirNqAm68HUP3 xemuDtlN+U5GfO0RpKbRXk24FFkHqjiDpiUejcFB8eUG23/QDy PDDXSxVPsUG9SiHJCviiXDBbQzbsfecm54XwYpFw2/CP/MGuSh FyhG+xPaeGei51hjyvgtR1z6yXgJVTIn58uvZaT4tzz0HvpDjb 8+VXiVgXscYlnhxbXqb/UG3GnwE9uOc1obLhfWJ/7RhoLJvPEp Q7soMMa2Najh6K8+0WMGKVV2a+f7vqNsXf9/x7/fVRLbr+Y3iE Ug4QzbkTxaLiwQ9yStkipZbVqeXNabcpL1c1IYztnqZJfvBZ2s QleHjYN5Y0ZkA==
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Oct 2011 07:55:52 -0000

Correct!

 The validation will fail in either case. However, in case the whole =
message including the identity info is changed, the validation relies on =
the trust-relation to the trusted third party which of course will be =
rejected due to the fact, that there is no CA certificate for the fake =
certificate-authority in the system of the relying party. In that case, =
a weak validation code can open a loophole if they do not traverse the =
whole chain.
... just think about people that answer to all web-browser certificate =
validation requests with "Always Trust" because they do not know better.

Such cases are more likely with an unsigned identity info.

Willi


On 18.10.2011, at 15:48, Hadriel Kaplan wrote:

>=20
> On Oct 18, 2011, at 3:00 AM, Olle E. Johansson wrote:
>=20
>> Seems like there are some issues to discuss here. Also, why is not =
the Identity-Info header signed? It points to where
>> the certificate exists, but can easily be changed by middlemen unless =
I've missed something.
>=20
> It doesn't matter if the Identity-Info header is changed by a =
middleman.  Doing so doesn't help the middleman lie about anything. =20
>=20
> Either the middleman modifies the Identity-Info to point to a =
different certificate, which will correctly invalidate the 4474 =
signature (which a middleman can do any number of other ways).  Or the =
middleman can point to a different location for the same certificate so =
the signature remains valid, but that still doesn't help the middleman =
do anything since it can't change the SIP message without invalidating =
the signature.
>=20
> -hadriel
>=20


From Ranjit.Avasarala@Polycom.com  Thu Oct 20 10:23:16 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D849921F8C2D for ; Thu, 20 Oct 2011 10:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.336
X-Spam-Level: 
X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.262,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2MYluEz3O1X for ; Thu, 20 Oct 2011 10:23:14 -0700 (PDT)
Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id AA4E521F8C12 for ; Thu, 20 Oct 2011 10:23:12 -0700 (PDT)
Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Fri, 21 Oct 2011 01:23:11 +0800
From: "Avasarala, Ranjit" 
To: "dispatch@ietf.org" 
Date: Fri, 21 Oct 2011 01:23:07 +0800
Thread-Topic: New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt 
Thread-Index: AcyPTO7+UIiLVVuzRHyQ5NhzzaOEmQ==
Message-ID: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.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_1F2A2C70609D9E41844A2126145FC0980442ADCBHKGMBOXPRD22pol_"
MIME-Version: 1.0
Cc: "pkyzivat@cisco.com" , "Barnes, Mary" 
Subject: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Oct 2011 17:23:16 -0000

--_000_1F2A2C70609D9E41844A2126145FC0980442ADCBHKGMBOXPRD22pol_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all

I have uploaded updated version of draft-avasarala-dispatch-comm-div-notifi=
cation-08.txt incorporating the following comments
a)      Updated the state information to reflect the CDIVN state and state =
diagram
b)      Added text to support subscription forking.

http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-08.tx=
t

Please review and comment

Thanks


Regards
Ranjit




--_000_1F2A2C70609D9E41844A2126145FC0980442ADCBHKGMBOXPRD22pol_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all


 


I have uploaded updated version of draft-avasarala-dispatch-comm-div-n=
otification-08.txt incorporating the following comments


    

  1. Updated the state information to reflect the CDIVN state and state diag=
ram
  2. Added text to support subscription forking.


 



 


Please review and comment


 


Thanks


 


 


Regards


Ranjit


 


 


 





--_000_1F2A2C70609D9E41844A2126145FC0980442ADCBHKGMBOXPRD22pol_--

From Ranjit.Avasarala@Polycom.com  Thu Oct 20 10:26:52 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC6821F84D5 for ; Thu, 20 Oct 2011 10:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.388
X-Spam-Level: 
X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.210,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huB91x+qeu7y for ; Thu, 20 Oct 2011 10:26:52 -0700 (PDT)
Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC021F84D3 for ; Thu, 20 Oct 2011 10:26:51 -0700 (PDT)
Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Fri, 21 Oct 2011 01:26:50 +0800
From: "Avasarala, Ranjit" 
To: "dispatch@ietf.org" 
Date: Fri, 21 Oct 2011 01:26:46 +0800
Thread-Topic: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
Thread-Index: AcyPTO7+UIiLVVuzRHyQ5NhzzaOEmQAAHSlQ
Message-ID: <1F2A2C70609D9E41844A2126145FC0980442ADCC@HKGMBOXPRD22.polycom.com>
References: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.com>
In-Reply-To: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.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_1F2A2C70609D9E41844A2126145FC0980442ADCCHKGMBOXPRD22pol_"
MIME-Version: 1.0
Cc: "Barnes, Mary" 
Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Oct 2011 17:26:52 -0000

--_000_1F2A2C70609D9E41844A2126145FC0980442ADCCHKGMBOXPRD22pol_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Adding Paul

Regards
Ranjit

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Avasarala, Ranjit
Sent: Thursday, October 20, 2011 10:53 PM
To: dispatch@ietf.org
Cc: pkyzivat@cisco.com; Barnes, Mary
Subject: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notif=
ication-08.txt

Hi all

I have uploaded updated version of draft-avasarala-dispatch-comm-div-notifi=
cation-08.txt incorporating the following comments

 1.  Updated the state information to reflect the CDIVN state and state dia=
gram
 2.  Added text to support subscription forking.

http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-08.tx=
t

Please review and comment

Thanks


Regards
Ranjit




--_000_1F2A2C70609D9E41844A2126145FC0980442ADCCHKGMBOXPRD22pol_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Adding Pa=
ul
 
Regards
Ranjit
=
 
From: d=
ispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of=
 Avasarala, Ranjit
Sent: Thursday, October 20, 2011 10:53 PM<=
br>To: dispatch@ietf.org
Cc: pkyzivat@cisco.com; Barnes, M=
ary
Subject: [dispatch] New Version I-D draft-avasarala-dispatch-=
comm-div-notification-08.txt
 
Hi all
 
I have uploaded updated version of draft-avasarala-dispatch-comm-div-=
notification-08.txt incorporating the following comments<=
/p>
  1. Updated the state =
information to reflect the CDIVN state and state diagram<=
/li>
  2. Added text to support subscription forking.
 
<=
p class=3DMsoNormal> 
Please re=
view and comment
 <=
/o:p>
Thanks
=

 
&nb=
sp;
Regards=

Ranjit
 
 
 
=

--_000_1F2A2C70609D9E41844A2126145FC0980442ADCCHKGMBOXPRD22pol_--

From pkyzivat@alum.mit.edu  Thu Oct 20 13:03:14 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E42F11E80B5 for ; Thu, 20 Oct 2011 13:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9mHkxT7ZrrE for ; Thu, 20 Oct 2011 13:03:13 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB211E809D for ; Thu, 20 Oct 2011 13:03:13 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id n7yN1h0030QuhwU5C83DSH; Thu, 20 Oct 2011 20:03:13 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta02.westchester.pa.mail.comcast.net with comcast id n83D1h00b0tdiYw3N83D9q; Thu, 20 Oct 2011 20:03:13 +0000
Message-ID: <4EA07E7E.5060302@alum.mit.edu>
Date: Thu, 20 Oct 2011 16:03:10 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
References: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.com>
In-Reply-To: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Oct 2011 20:03:14 -0000

Ranjit,

I have just started to look at this version. It seems to be an 
improvement. Before I do a thorough review I'll bring up a few things 
that jumped out at me:

Section 6.5:

    All subscribers of "comm-div-info" event package who wish to add
    filter criteria to their subscription requests MUST support the
    application/comm-div-info-filter+xml" data format as described in
    Section 8.1.1 while the notifiers SHALL support the "application/
    comm-div-info+xml" data format as described in Section 8.1.2.  The
    SUBSCRIBE request MAY contain an Accept header field.  If no such
    header field is present, it has a default value of "application/
    comm-div-info-ntfy+xml" (assuming Event header has a value of "comm-
    div-info-ntfy").  If the Accept header field is present, it MUST
    contain the value "application/comm-div-info-ntfy+xml" only.

I think I know what you want to say, but this doesn't say it. What I 
think you are trying to say (or ought to be trying to say) is:

- the subscriber that wants a filter has to encode it according
   to the filter xml schema and indicate the content-type accordingly.

- the notifier MUST be capable of accepting the filter xml, in case
   a subscriber wants to use one.

- the subscriber must always Accept receiving a notify xml
   in the notify.

- the notifier MUST encode notifications according to the notify
   xml schema and indicate the content type accordingly.

- The default Accept for a subscribe to this package is the
   notify xml.

If I have that right, we can discuss how to write a paragraph that says 
it concisely and clearly.

I *think* that you are trying to allow notifiers that don't support 
filtering. I question the wisdom of that. And if you really want that, I 
think it would be helpful to consider what that means. Does it mean that 
the notifier ignores the presence of the filter document? Or does it 
mean that it recognizes the presence of the filter but chooses not to 
honor the filter? Could that refusal be partial? (I.e. it understands 
the document but chooses to not apply certain filter criteria?)

What about a subscriber that feels it needs the filter? It might choose 
not to subscribe if it can't have the filter. But then it either needs 
the subscribe to fail in that case, or else it needs a way to tell that 
the filter isn't being honored.

I would think it better to have the subscribe rejected with a 415 if the 
notifier doesn't support filtering, or else have the notify indicate 
that the requested filter is not being applied.

Section 6.11:

I appreciate your having provided a state diagram. But I don't 
understand it.

    +------------+  Diversion  +---------------+
    |            +--+--------->+               |
    |   IDLE     |  ^          |   DIVERSION   |
    |            |  |  +------>+   DETECTED    |
    +------------+  |  |       +--+----+-------+
                    |  | no match      |  |filter
                    +------------------+  |match
                       |                  v
                       |          +-------+-------+
                       |          |   DIVERSION   |
                       |          |    NOTIFIED   |
                       |          +-----+---------+
                       |    Diversion   |
                       +----------------+

As I read this, what I conclude is:

- the subscriber will not learn about any diversions which occurred
   prior to the subscription. (This may be what you intend.
   at least its easy.)

- the first diversion after subscribing moves to
   DIVERSION DETECTED state.

- upon entry to DIVERSION DETECTED, a filter match is
   attempted. (Presumably this always succeeds if there
   is no filter.)

- its unclear what happens if the filter fails to match.
   The transition for that connects to the Diversion
   transition. That would seem to create an infinite loop.
   I expect the "no match" transition ought to go to IDLE.

- if the filter match succeeds, DIVERSION NOTIFIED state
   is entered. No action is indicated. I suppose its implied
   that a notification is sent. Then apparently the subscription
   remains in this state until another diversion occurs.
   Then the transition is back to DIVERSION DETECTED, and
   things repeat.

I'm also puzzling over:

    The subscriber could receive, as part of the notification
    information, the state the FSM was in prior to detecting the
    diversion.

    o  [IDLE]: meaning that there have been no missed diversions since
       setting the present "filter".

    o  [DIVERSION_NOTIFIED]: meaning that there have been no missed
       diversions.

    o  [DIVERSION_DETECTED]: meaning that there have been some missed
       diversions.

I don't get how that would work. It isn't going to report the missing of 
diversions that occurred prior to the subscribe, because the 
subscription always starts in the IDLE state. And I don't know how you 
miss diversions after the subscription is established.

That's all for now.

	Thanks,
	Paul

On 10/20/11 1:23 PM, Avasarala, Ranjit wrote:
> Hi all
> I have uploaded updated version of
> draft-avasarala-dispatch-comm-div-notification-08.txt incorporating the
> following comments
>
>  1. Updated the state information to reflect the CDIVN state and state
>     diagram
>  2. Added text to support subscription forking.
>
> _http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-08.txt_
> Please review and comment
> Thanks
> Regards
> Ranjit
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From oej@edvina.net  Thu Oct 20 13:09:27 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2557B1F0C5F for ; Thu, 20 Oct 2011 13:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.116
X-Spam-Level: 
X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.132,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKVZ-E1F+7yY for ; Thu, 20 Oct 2011 13:09:26 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 933791F0C34 for ; Thu, 20 Oct 2011 13:09:26 -0700 (PDT)
Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id C47AB754BCD5 for ; Thu, 20 Oct 2011 20:09:23 +0000 (UTC)
From: "Olle E. Johansson" 
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/alternative; boundary="Apple-Mail=_83B59988-5EEB-4E8C-B567-F4AAD08CDA1D"
Date: Thu, 20 Oct 2011 22:09:29 +0200
In-Reply-To: <4EA07E7E.5060302@alum.mit.edu>
To: dispatch@ietf.org
References: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.com> <4EA07E7E.5060302@alum.mit.edu>
Message-Id: <7A37C7D8-2BA8-42AA-BD96-72CA15DDC926@edvina.net>
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Oct 2011 20:09:27 -0000

--Apple-Mail=_83B59988-5EEB-4E8C-B567-F4AAD08CDA1D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Nitpicking, but anyway:

" The body of the NOTIFY MUST be sent using the type "application/
   comm-div-info-ntfy+xml" and must contain the elements defined in
   Section 8.1.2 only.  The Content-Type header field MUST be set to
   "application/comm-div-info-ntfy+xml".
"

The MUST here seems to stop any attempts at protecting the message
with S/MIME. If one turns the text around saying something like "there =
MUST be a
message of type YYY and the content-type of this body part must be
set to XXX" we are still open for S/MIME integrity as well as =
confidentiality.

/O=

--Apple-Mail=_83B59988-5EEB-4E8C-B567-F4AAD08CDA1D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

 The body of the NOTIFY MUST be sent using the =
type "application/
   comm-div-info-ntfy+xml" and must contain =
the elements defined in
   Section 8.1.2 only.  The Content-Type =
header field MUST be set to
   "application/comm-div-info-ntfy+xml".
"

The MUST here seems to stop any attempts at =
protecting the message
set to XXX" we are =
still open for S/MIME integrity as well as confidentiality.

 Nitpicking, but anyway:
>
> "The body of the NOTIFY MUST be sent using the type "application/
>
>     comm-div-info-ntfy+xml" and must contain the elements defined in
>     Section 8.1.2    only.  The Content-Type header field MUST be set to
>     "application/comm-div-info-ntfy+xml".
>
> "
>
>
> The MUST here seems to stop any attempts at protecting the message
>
> with S/MIME. If one turns the text around saying something like "there MUST be a
>
> message of type YYY and the content-type of this body part must be
>
> set to XXX" we are still open for S/MIME integrity as well as confidentiality.
>
>
> /O
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From kumiko@cs.columbia.edu  Thu Oct 20 19:26:27 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8DD21F85F2 for ; Thu, 20 Oct 2011 19:26:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBn-P1VY+fSc for ; Thu, 20 Oct 2011 19:26:27 -0700 (PDT)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id E126B21F85D1 for ; Thu, 20 Oct 2011 19:26:26 -0700 (PDT)
Received: from dhcp1.cs.columbia.edu (dhcp1.cs.columbia.edu [128.59.19.201]) (user=ko2155 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p9L2QNiX015191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2011 22:26:26 -0400 (EDT)
Message-ID: <4EA0D84F.8090600@cs.columbia.edu>
Date: Thu, 20 Oct 2011 22:26:23 -0400
From: Kumiko Ono 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Subject: [dispatch] New I-D: Referencing and Validating User Attributes for SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Oct 2011 02:26:27 -0000

Hi all,

We've just submitted an I-D which proposes a simple mechanism for 
referencing and validating user attributes in SIP communication.
You'll find the html version at 
http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 .

We're trying to see whether there is sufficient community interest in 
this work at DISPATCH or related WGs.

Your interest, comments, and other feedback are appreciated.

Thanks,
Kumiko

-----------
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Reply-to: internet-drafts@ietf.org
Subject: I-D Action: draft-ono-dispatch-attribute-validation-00.txt
X-RSN: 1/0/935/39411/42796

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title : Referencing and Validating User Attributes
Author(s) : Kumiko Ono Henning Schulzrinne
Filename : draft-ono-dispatch-attribute-validation-00.txt
Pages : 21
Date : 2011-10-20

This document describes a mechanism for referencing and validating
user attributes in SIP communication. User attributes, such as an
organizational affiliation and role, are helpful for the recipients
of a communication request to decide whether or not to grant the
sender access to the recipient's resources, especially when the
sender identity is unknown to the recipients. This mechanism allows
the sender to claim her attributes to recipients using an attribute
reference identifier without needing to prove the sender identity.
This document defines a new SIP "Sender-References" header field to
convey one or more attribute reference identifiers. This mechanism
satisfies all the requirements for trait-based authorization defined
in RFC 4484, except that it provides only one assertion scheme.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ono-dispatch-attribute-validation-00.txt 


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ono-dispatch-attribute-validation-00.txt 

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From dworley@avaya.com  Fri Oct 21 10:41:12 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC89721F8AE6 for ; Fri, 21 Oct 2011 10:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.426
X-Spam-Level: 
X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgxcU2KlHT3E for ; Fri, 21 Oct 2011 10:41:11 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 834E221F8AC3 for ; Fri, 21 Oct 2011 10:41:11 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAOetoU6HCzI1/2dsb2JhbAA6CQ6pEYEFgW4BAQEBAxIoTwIBCA0pEDIlAQEEARIIGqAnm0uFEoJNYQSZTItYUw
X-IronPort-AV: E=Sophos;i="4.69,387,1315195200"; d="scan'208";a="310403217"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Oct 2011 13:41:09 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Oct 2011 13:30:40 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Fri, 21 Oct 2011 13:41:09 -0400
From: "Worley, Dale R (Dale)" 
To: Kumiko Ono , "dispatch@ietf.org" 
Date: Fri, 21 Oct 2011 13:41:08 -0400
Thread-Topic: [dispatch] New I-D: Referencing and Validating User Attributes for	SIP
Thread-Index: AcyPmNzWZCLlv8AeSQmp9Q6RWFV47gAfhqws
Message-ID: 
References: <4EA0D84F.8090600@cs.columbia.edu>
In-Reply-To: <4EA0D84F.8090600@cs.columbia.edu>
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: [dispatch] New I-D: Referencing and Validating User Attributes for	SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Oct 2011 17:41:12 -0000

The problem is interesting, but the draft needs some improvement.

First, there is a problem of terminology.  The term "contact address"
is used in many places.  I think the meaning is what in SIP we would
call "recipient's AOR", whereas in SIP, the term "Contact address"
means the address in the Contact header, which is a transient address.

There is also the term "caller ID", which is a term I've not heard
used in a SIP context.  I think you mean the "From URI" of the
message.

It looks like the ARID contains the caller's identity and the
recipient's AOR, but nothing binding it to the specific dialog.  The
recipeint can steal the ARID, but can only use it to call one of the
recipeint AORs in the ARID.  This isn't a threat if the AOR is that of
an individual, but is if the AOR is an organizational role (e.g.,
, or if there are multiple AORs.

That threat could be reduced if the ARID was bound to a nonce provided
by the recipient of the call.  The to-tag of a 1xx response (sent
reliably) would be a good choice for the nonce.  The ARID could then
be sent in an UPDATE.  That approach does require the caller to have
real-time access to the AVS while the call is "ringing", but this
mechanism requires real-time access to the AVS already.

Dale

From mphmmr@gmail.com  Fri Oct 21 11:10:31 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6541521F8BA4 for ; Fri, 21 Oct 2011 11:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnGvjNhQozKl for ; Fri, 21 Oct 2011 11:10:30 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 376F221F8BA0 for ; Fri, 21 Oct 2011 11:10:30 -0700 (PDT)
Received: by wwe6 with SMTP id 6so4309463wwe.13 for ; Fri, 21 Oct 2011 11:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xg0X7JDY4B+I3PK4U3zL/36Lor3Jeq/VmgvlD2x6lSs=; b=Gk6xSVMuz7e7bPXSLAYaR8YQJhT067DdR4DqQWZwZTwXviXokUc+IaJmMN8LCttp1G JeUSjFl016b9MNKuTD1xxlnkl5RFqGPa9vLGUmfiLRPb+vECgDMQbxohYfs/tGx/RSFt Z96LRWWKbvbuSOQiJz9NIw1ml2MXi4+k9VU/M=
MIME-Version: 1.0
Received: by 10.216.221.80 with SMTP id q58mr3502946wep.36.1319220603691; Fri, 21 Oct 2011 11:10:03 -0700 (PDT)
Received: by 10.216.61.208 with HTTP; Fri, 21 Oct 2011 11:10:03 -0700 (PDT)
In-Reply-To: 
References: <4EA0D84F.8090600@cs.columbia.edu> 
Date: Fri, 21 Oct 2011 14:10:03 -0400
Message-ID: 
From: Michael Hammer 
To: "Worley, Dale R (Dale)" 
Content-Type: multipart/alternative; boundary=0016e65a0a0276a2c904afd2fb3f
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] New I-D: Referencing and Validating User Attributes for SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Oct 2011 18:10:31 -0000

--0016e65a0a0276a2c904afd2fb3f
Content-Type: text/plain; charset=ISO-8859-1

Dale,

>From header???  for caller ID?
That is not so trustworthy.
Would the P-Asserted-ID be better?

Mike



On Fri, Oct 21, 2011 at 1:41 PM, Worley, Dale R (Dale) wrote:

> The problem is interesting, but the draft needs some improvement.
>
> First, there is a problem of terminology.  The term "contact address"
> is used in many places.  I think the meaning is what in SIP we would
> call "recipient's AOR", whereas in SIP, the term "Contact address"
> means the address in the Contact header, which is a transient address.
>
> There is also the term "caller ID", which is a term I've not heard
> used in a SIP context.  I think you mean the "From URI" of the
> message.
>
> It looks like the ARID contains the caller's identity and the
> recipient's AOR, but nothing binding it to the specific dialog.  The
> recipeint can steal the ARID, but can only use it to call one of the
> recipeint AORs in the ARID.  This isn't a threat if the AOR is that of
> an individual, but is if the AOR is an organizational role (e.g.,
> , or if there are multiple AORs.
>
> That threat could be reduced if the ARID was bound to a nonce provided
> by the recipient of the call.  The to-tag of a 1xx response (sent
> reliably) would be a good choice for the nonce.  The ARID could then
> be sent in an UPDATE.  That approach does require the caller to have
> real-time access to the AVS while the call is "ringing", but this
> mechanism requires real-time access to the AVS already.
>
> Dale
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

--0016e65a0a0276a2c904afd2fb3f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Dale,
=A0
From header???=A0 for caller ID?
That is not so trustworthy.=A0 
Would the P-Asserted-ID be bet=
ter?
=A0
Mike


=A0

On Fri, Oct 21, 2011 at 1:41 PM, Worley, Dale R (Dale) &l=
t;dworley@avaya.com> wro=
te:

The problem is interesting, but the draft needs some improvement.



First, there is a problem of terminology. =A0The term "contact address=
"

is used in many places. =A0I think the meaning is what in SIP we would

call "recipient's AOR", whereas in SIP, the term "Contac=
t address"

means the address in the Contact header, which is a transient address.



There is also the term "caller ID", which is a term I've not =
heard

used in a SIP context. =A0I think you mean the "From URI" of the<=
br>
message.



It looks like the ARID contains the caller's identity and the

recipient's AOR, but nothing binding it to the specific dialog. =A0The<=
br>
recipeint can steal the ARID, but can only use it to call one of the

recipeint AORs in the ARID. =A0This isn't a threat if the AOR is that o=
f

an individual, but is if the AOR is an organizational role (e.g.,

<sip:customer-serv=
ice@example.com>, or if there are multiple AORs.



That threat could be reduced if the ARID was bound to a nonce provided

by the recipient of the call. =A0The to-tag of a 1xx response (sent

reliably) would be a good choice for the nonce. =A0The ARID could then

be sent in an UPDATE. =A0That approach does require the caller to have

real-time access to the AVS while the call is "ringing", but this=


mechanism requires real-time access to the AVS already.



Dale

_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





--0016e65a0a0276a2c904afd2fb3f--

From kumiko@cs.columbia.edu  Fri Oct 21 14:10:34 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B7421F8B3D for ; Fri, 21 Oct 2011 14:10:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCkdfy9PDbND for ; Fri, 21 Oct 2011 14:10:33 -0700 (PDT)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 85A0F21F8B35 for ; Fri, 21 Oct 2011 14:10:33 -0700 (PDT)
Received: from dhcp0.cs.columbia.edu (dhcp0.cs.columbia.edu [128.59.19.200]) (user=ko2155 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p9LLA97x028309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Oct 2011 17:10:09 -0400 (EDT)
Message-ID: <4EA1DFB1.70508@cs.columbia.edu>
Date: Fri, 21 Oct 2011 17:10:09 -0400
From: Kumiko Ono 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" 
References: <4EA0D84F.8090600@cs.columbia.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] New I-D: Referencing and Validating User Attributes for	SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Oct 2011 21:10:34 -0000

Hi Dale,

Thanks for your interest.

On 10/21/11 1:41 PM, Worley, Dale R (Dale) wrote:
> The problem is interesting, but the draft needs some improvement.
>
> First, there is a problem of terminology.  The term "contact address"
> is used in many places.  I think the meaning is what in SIP we would
> call "recipient's AOR", whereas in SIP, the term "Contact address"
> means the address in the Contact header, which is a transient address.
>
> There is also the term "caller ID", which is a term I've not heard
> used in a SIP context.  I think you mean the "From URI" of the
> message.

I used both terms "contact address" and "caller ID" as generic terms.
A user's contact address in SIP is an AOR to be used to reach the user. 
The caller ID is a URI found in the From or P-Asserted-Identity header.
To avoid confusion, I'll clarify/fix these terms in the next version.

> It looks like the ARID contains the caller's identity and the
> recipient's AOR, but nothing binding it to the specific dialog.

The ARID is generated by encoding the caller's identity issued in an 
organization, the recipient's AOR, and the timestamp. But as you pointed 
out, there is no tight binding to the specific dialog.

> The
> recipeint can steal the ARID, but can only use it to call one of the
> recipeint AORs in the ARID.  This isn't a threat if the AOR is that of
> an individual, but is if the AOR is an organizational role (e.g.,
> , or if there are multiple AORs.

That's a good point. Forwarding attacks among legitimate recipients 
involved in the same dialog is possible. However, it would happen only 
when a dialog has multiple recipients using a forking 
proxy/conference/list service/PBX service, despite the caller's intention.

Although your suggestion below could make this mechanism more secure, I 
don't think the UAC can receive all 1xx responses sent from the 
recipients. Thus, we rather rely on limiting the ARID's lifetime to 
mitigate the damage from such attacks. Additionally, although there is a 
trade-off between service applicability and security, we can limit the 
number of times an ARID can be used to one.

> That threat could be reduced if the ARID was bound to a nonce provided
> by the recipient of the call.  The to-tag of a 1xx response (sent
> reliably) would be a good choice for the nonce.  The ARID could then
> be sent in an UPDATE.  That approach does require the caller to have
> real-time access to the AVS while the call is "ringing", but this
> mechanism requires real-time access to the AVS already.
 >
> Dale
>

Thanks,
Kumiko

From hgs@cs.columbia.edu  Sat Oct 22 10:40:54 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D333F21F8496 for ; Sat, 22 Oct 2011 10:40:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJfF5MhSuen4 for ; Sat, 22 Oct 2011 10:40:54 -0700 (PDT)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC7421F8494 for ; Sat, 22 Oct 2011 10:40:54 -0700 (PDT)
Received: from upstairs-3.home (pool-108-5-121-49.nwrknj.fios.verizon.net [108.5.121.49]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p9MHem3X010550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Oct 2011 13:40:49 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Henning Schulzrinne 
In-Reply-To: <4EA1DFB1.70508@cs.columbia.edu>
Date: Sat, 22 Oct 2011 13:40:48 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <587A9A01-9DA3-4E5E-83CE-CBB2F168E9CA@cs.columbia.edu>
References: <4EA0D84F.8090600@cs.columbia.edu>  <4EA1DFB1.70508@cs.columbia.edu>
To: "Worley, Dale R (Dale)" 
X-Mailer: Apple Mail (2.1251.1)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8
Cc: DISPATCH 
Subject: Re: [dispatch] New I-D: Referencing and Validating User Attributes for	SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Oct 2011 17:40:54 -0000

Dale,

also my thanks for your comments. Some quick remarks inline below, =
mainly asking for clarification.

On Oct 21, 2011, at 5:10 PM, Kumiko Ono wrote:

>=20
>> It looks like the ARID contains the caller's identity and the
>> recipient's AOR, but nothing binding it to the specific dialog.
>=20
> The ARID is generated by encoding the caller's identity issued in an =
organization, the recipient's AOR, and the timestamp. But as you pointed =
out, there is no tight binding to the specific dialog.

I'm curious what the advantage of such a binding would be. My concern is =
that B2BUAs may destroy end-to-end dialog continuity, so that this would =
make the mechanism less likely to work in practice.

>=20
>> The
>> recipeint can steal the ARID, but can only use it to call one of the
>> recipeint AORs in the ARID.  This isn't a threat if the AOR is that =
of
>> an individual, but is if the AOR is an organizational role (e.g.,
>> , or if there are multiple AORs.

What would you see as the threat in that model? If I address a call to =
customer-service, I presumably trust any agent of that designation to =
obtain my credentials. After all, even a standard residential phone =
number resolves to multiple devices and people (members of the family).

>=20
> That's a good point. Forwarding attacks among legitimate recipients =
involved in the same dialog is possible. However, it would happen only =
when a dialog has multiple recipients using a forking =
proxy/conference/list service/PBX service, despite the caller's =
intention.
>=20
> Although your suggestion below could make this mechanism more secure, =
I don't think the UAC can receive all 1xx responses sent from the =
recipients. Thus, we rather rely on limiting the ARID's lifetime to =
mitigate the damage from such attacks. Additionally, although there is a =
trade-off between service applicability and security, we can limit the =
number of times an ARID can be used to one.
>=20
>> That threat could be reduced if the ARID was bound to a nonce =
provided
>> by the recipient of the call.  The to-tag of a 1xx response (sent
>> reliably) would be a good choice for the nonce.  The ARID could then
>> be sent in an UPDATE.  That approach does require the caller to have
>> real-time access to the AVS while the call is "ringing", but this
>> mechanism requires real-time access to the AVS already.
> >
>> Dale
>>=20
>=20
> Thanks,
> Kumiko
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20


From ibc@aliax.net  Sun Oct 23 05:13:16 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBB421F8560 for ; Sun, 23 Oct 2011 05:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level: 
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuaMgABCqoZa for ; Sun, 23 Oct 2011 05:13:15 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6954B21F84F5 for ; Sun, 23 Oct 2011 05:13:13 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so5125380vcb.31 for ; Sun, 23 Oct 2011 05:13:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.210.137 with SMTP id gk9mr1494329vcb.131.1319371992868; Sun, 23 Oct 2011 05:13:12 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Sun, 23 Oct 2011 05:13:12 -0700 (PDT)
Date: Sun, 23 Oct 2011 14:13:12 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: dispatch@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [dispatch] RFC 5626 and double Record-Route
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Oct 2011 12:13:16 -0000

Hi, when SIP natted clients (implementing Outbound) connect to a proxy
which also acts as registrar (so a single server with Outbound
support), usage of double Record-Route is a MUST in order to allow
dialogs between two SIP natted clients. So if for example Alice and
Bob are two SIP UDP clients behind NAT and use Proxy as
proxy/registrar, when Alice calls Bob:

- Proxy detects Outbound request in Alice's INVITE so adds a
Record-Route with token flow A (associated to Alice's public IP:port).

- Proxy gets Bob location (is natted and requested Outbund during registrat=
ion).

- Proxy inserts a second Record-Route (on top) with token flow B
(associated to Bob public IP:port).

- Bob mirrors Record-Routes in the 200 response.

- When Alice sends the ACK it contains:
    Route: 
    Route: 

- Proxy inspects the *bottom* Route's token flow (B) so routes the ACK
to the IP:port associated to Bob (after removing both Route).

- When Bob sends a BYE it contains:
    Route: 
    Route: 

- Proxy inspects the *bottom* Route's token flow (A) so routes the BYE
to the IP:port associated to Alice (after removing both Route).


I've successfully implemented it, but IMHO this should be explained in
the RFC 5626 (somethere in the section "3.2. Single Registrar and
UA").


Regards.


--=20
I=C3=B1aki Baz Castillo


From Ranjit.Avasarala@Polycom.com  Mon Oct 24 01:50:58 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A91B21F8AFF for ; Mon, 24 Oct 2011 01:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.424
X-Spam-Level: 
X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNJF3MK-jvKg for ; Mon, 24 Oct 2011 01:50:57 -0700 (PDT)
Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id E26D421F8AF7 for ; Mon, 24 Oct 2011 01:50:56 -0700 (PDT)
Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Mon, 24 Oct 2011 16:50:54 +0800
From: "Avasarala, Ranjit" 
To: Paul Kyzivat , "dispatch@ietf.org" 
Date: Mon, 24 Oct 2011 16:50:53 +0800
Thread-Topic: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
Thread-Index: AcyPY1Ig93Qss5ceSqqtCuhpAwRyEwCxYgRA
Message-ID: <1F2A2C70609D9E41844A2126145FC0980442AF70@HKGMBOXPRD22.polycom.com>
References: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.com> <4EA07E7E.5060302@alum.mit.edu>
In-Reply-To: <4EA07E7E.5060302@alum.mit.edu>
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: [dispatch] New Version I-D	draft-avasarala-dispatch-comm-div-notification-08.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 08:50:58 -0000

Hi Paul

My comments inline 

Regards
Ranjit


-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Paul Kyzivat
Sent: Friday, October 21, 2011 1:33 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-n=
otification-08.txt

Ranjit,

I have just started to look at this version. It seems to be an=20
improvement. Before I do a thorough review I'll bring up a few things=20
that jumped out at me:

Section 6.5:

    All subscribers of "comm-div-info" event package who wish to add
    filter criteria to their subscription requests MUST support the
    application/comm-div-info-filter+xml" data format as described in
    Section 8.1.1 while the notifiers SHALL support the "application/
    comm-div-info+xml" data format as described in Section 8.1.2.  The
    SUBSCRIBE request MAY contain an Accept header field.  If no such
    header field is present, it has a default value of "application/
    comm-div-info-ntfy+xml" (assuming Event header has a value of "comm-
    div-info-ntfy").  If the Accept header field is present, it MUST
    contain the value "application/comm-div-info-ntfy+xml" only.

I think I know what you want to say, but this doesn't say it. What I=20
think you are trying to say (or ought to be trying to say) is:

- the subscriber that wants a filter has to encode it according
   to the filter xml schema and indicate the content-type accordingly.

- the notifier MUST be capable of accepting the filter xml, in case
   a subscriber wants to use one.

- the subscriber must always Accept receiving a notify xml
   in the notify.

- the notifier MUST encode notifications according to the notify
   xml schema and indicate the content type accordingly.

- The default Accept for a subscribe to this package is the
   notify xml.

If I have that right, we can discuss how to write a paragraph that says=20
it concisely and clearly.

that seems "right". Except for:

- the notifier MUST be capable of accepting the filter xml, in case
   a subscriber wants to use one.

In my opinion a notifier must always support the filter as it can't predict=
 if a suberiber wants to use a filter.


I *think* that you are trying to allow notifiers that don't support=20
filtering. I question the wisdom of that. And if you really want that, I=20
think it would be helpful to consider what that means. Does it mean that=20
the notifier ignores the presence of the filter document? Or does it=20
mean that it recognizes the presence of the filter but chooses not to=20
honor the filter? Could that refusal be partial? (I.e. it understands=20
the document but chooses to not apply certain filter criteria?)

 I am okay requiring the support for filters in the notifier=20

What about a subscriber that feels it needs the filter? It might choose=20
not to subscribe if it can't have the filter. But then it either needs=20
the subscribe to fail in that case, or else it needs a way to tell that=20
the filter isn't being honored.

I would think it better to have the subscribe rejected with a 415 if the=20
notifier doesn't support filtering, or else have the notify indicate=20
that the requested filter is not being applied.

 I am okay requiring the support for filters in the notifier. If st=
ill not supported, sending a 415 is sufficient (and subscription for this e=
vent then fails).=20

Section 6.11:

I appreciate your having provided a state diagram. But I don't=20
understand it.

    +------------+  Diversion  +---------------+
    |            +--+--------->+               |
    |   IDLE     |  ^          |   DIVERSION   |
    |            |  |  +------>+   DETECTED    |
    +------------+  |  |       +--+----+-------+
                    |  | no match      |  |filter
                    +------------------+  |match
                       |                  v
                       |          +-------+-------+
                       |          |   DIVERSION   |
                       |          |    NOTIFIED   |
                       |          +-----+---------+
                       |    Diversion   |
                       +----------------+

As I read this, what I conclude is:

- the subscriber will not learn about any diversions which occurred
   prior to the subscription. (This may be what you intend.
   at least its easy.)
 Correct

- the first diversion after subscribing moves to
   DIVERSION DETECTED state.
 Correct

- upon entry to DIVERSION DETECTED, a filter match is
   attempted. (Presumably this always succeeds if there
   is no filter.)

 well if we require the support of a filter then we shouldn't get h=
ere "if there is no filter" as then there was a 415 response?

- its unclear what happens if the filter fails to match.
   The transition for that connects to the Diversion
   transition. That would seem to create an infinite loop.
   I expect the "no match" transition ought to go to IDLE.

 well, we should transition to DIVERSION_DETECTED per "no match". T=
he diversion did occur and was detected but no notification was sent. I wou=
ld like to somehow express that the state machine stops at DIVERSION_DETECT=
ED in this case. IDLE could be read as "NOTHING DETECTED" e.g. because ther=
e is no subscription so no need to detect anything.

- if the filter match succeeds, DIVERSION NOTIFIED state
   is entered. No action is indicated. I suppose its implied
   that a notification is sent.
 we clarify that a notification is sent

 Then apparently the subscription
   remains in this state until another diversion occurs.
   Then the transition is back to DIVERSION DETECTED, and
   things repeat.

 yes. So, I am not sure how to address the comment but perhaps the =
below diagram would capture the situation? Upon detecting the first diversi=
on, we enter the state machine, we attempt to match filters, then we're stu=
ck in a state until we can satisfy the transition condition of detecting a =
next transition
I'm also puzzling over:

    The subscriber could receive, as part of the notification
    information, the state the FSM was in prior to detecting the
    diversion.

    o  [IDLE]: meaning that there have been no missed diversions since
       setting the present "filter".

    o  [DIVERSION_NOTIFIED]: meaning that there have been no missed
       diversions.
actually, "notifications or diversions" are not missed due to all d=
iversions matching filters

    o  [DIVERSION_DETECTED]: meaning that there have been some missed
       diversions.
actually, "notifications or diversions" are missed due to diversion=
s having failed to match any filters

I don't get how that would work. It isn't going to report the missing of=20
diversions that occurred prior to the subscribe, because the=20
subscription always starts in the IDLE state.=20
 Correct

And I don't know how you=20
miss diversions after the subscription is established.
 see clarification.=20

That's all for now.

	Thanks,
	Paul

On 10/20/11 1:23 PM, Avasarala, Ranjit wrote:
> Hi all
> I have uploaded updated version of
> draft-avasarala-dispatch-comm-div-notification-08.txt incorporating the
> following comments
>
>  1. Updated the state information to reflect the CDIVN state and state
>     diagram
>  2. Added text to support subscription forking.
>
> _http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-08=
.txt_
> Please review and comment
> Thanks
> Regards
> Ranjit
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From Ranjit.Avasarala@Polycom.com  Mon Oct 24 01:51:29 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C5C21F8B8A for ; Mon, 24 Oct 2011 01:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level: 
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5+4KEgiLJu0 for ; Mon, 24 Oct 2011 01:51:29 -0700 (PDT)
Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 922F621F8B56 for ; Mon, 24 Oct 2011 01:51:28 -0700 (PDT)
Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Mon, 24 Oct 2011 16:51:23 +0800
From: "Avasarala, Ranjit" 
To: "Olle E. Johansson" , "dispatch@ietf.org" 
Date: Mon, 24 Oct 2011 16:51:21 +0800
Thread-Topic: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
Thread-Index: AcyPZDBBu39jHrmiTVeCLXC11aMJrwCxeAPg
Message-ID: <1F2A2C70609D9E41844A2126145FC0980442AF71@HKGMBOXPRD22.polycom.com>
References: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.com> <4EA07E7E.5060302@alum.mit.edu> <7A37C7D8-2BA8-42AA-BD96-72CA15DDC926@edvina.net>
In-Reply-To: <7A37C7D8-2BA8-42AA-BD96-72CA15DDC926@edvina.net>
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_1F2A2C70609D9E41844A2126145FC0980442AF71HKGMBOXPRD22pol_"
MIME-Version: 1.0
Subject: Re: [dispatch] New Version I-D	draft-avasarala-dispatch-comm-div-notification-08.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 08:51:29 -0000

--_000_1F2A2C70609D9E41844A2126145FC0980442AF71HKGMBOXPRD22pol_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi olle

Agreed.

Regards
Ranjit

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Olle E. Johansson
Sent: Friday, October 21, 2011 1:39 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-n=
otification-08.txt

Nitpicking, but anyway:

" The body of the NOTIFY MUST be sent using the type "application/

   comm-div-info-ntfy+xml" and must contain the elements defined in

   Section 8.1.2 only.  The Content-Type header field MUST=
 be set to

   "application/comm-div-info-ntfy+xml".

"


The MUST here seems to stop any attempts at protecting the message

with S/MIME. If one turns the text around saying something like "there MUST=
 be a

message of type YYY and the content-type of this body part must be

set to XXX" we are still open for S/MIME integrity as well as confidentiali=
ty.


/O

--_000_1F2A2C70609D9E41844A2126145FC0980442AF71HKGMBOXPRD22pol_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi olle
&n=
bsp;
Agreed. =

 
Regards
Ranjit
 =

From: dispatch-bounces@i=
etf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Olle E. Joha=
nsson
Sent: Friday, October 21, 2011 1:39 AM
To: dispat=
ch@ietf.org
Subject: Re: [dispatch] New Version I-D draft-avasara=
la-dispatch-comm-div-notification-08.txt
<=
p class=3DMsoNormal> 
Nitpicking, b=
ut anyway:
 
" The body of the NOTIFY MUST be sent using=
 the type "application/
  =
 comm-div-info-ntfy+xml" and must contain the elements defined in=

   Section 8.1.2=
 only.  The Content-Type header field MUST be set to=

   "application/comm-div-info-ntfy+xml".=

"

The MUST here seems to stop any attempts at protecting the message
with S/MIME. If one turns the text around saying somethi=
ng like "there MUST be a
message of type YYY and =
the content-type of this body part must be
set to XXX&=
quot; we are still open for S/MIME integrity as well as confidentiality.

/O
=

--_000_1F2A2C70609D9E41844A2126145FC0980442AF71HKGMBOXPRD22pol_--

From fluffy@cisco.com  Mon Oct 24 05:15:31 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CE121F8CED for ; Mon, 24 Oct 2011 05:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.215
X-Spam-Level: 
X-Spam-Status: No, score=-106.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VJbqhXUV7SE for ; Mon, 24 Oct 2011 05:15:30 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9784921F8C04 for ; Mon, 24 Oct 2011 05:15:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2365; q=dns/txt; s=iport; t=1319458530; x=1320668130; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oREtSZspEb0zEhnWBt8q1pUp9J87P188ZNkMkhrAhbQ=; b=OikzmWvdL2M2XEDvyJEaJM+g4ouMuMwll7VjH9Y+gUvysqSSgFwUo1e5 7qTfY/B+rEHusKub8QFrUxkB1McF6zrNbpGGELKqzi6KRkhakGLgpmLH/ WEtgzn6yp6/N7roKRA+Q4ae+6IIE6WVMWLSSl4VjdiHaVaqko4A1DZald w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAEBWpU6rRDoH/2dsb2JhbABDqRKBBYFuAQEBAQIBAQEBDwEKHTQLEAsUATEnMAYTCRmHXgiVHAGdd4dfYQSIBowDhSyMTg
X-IronPort-AV: E=Sophos;i="4.69,398,1315180800";  d="scan'208";a="9802160"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 24 Oct 2011 12:15:30 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9OCFTO2019351; Mon, 24 Oct 2011 12:15:29 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Mon, 24 Oct 2011 06:15:29 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <01E059E6-5EAB-4106-9417-7DE6B217ACD0@cisco.com>
References: 
To: "Worley, Dale R (Dale)" 
X-Mailer: Apple Mail (2.1084)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 12:15:31 -0000

Dale, you are confused on what the process for this document is.=20

It is left over from before dispatch was formed and is being discussed =
on this list primarily so Gonzalo can decide if he wants to AD sponsor =
it or not. A consensus call for progression of the draft would be made =
by Gonzalo after an IETF LC. If people want want to take this work and =
bring it through the dispatch process - normally I'd explain that =
process here but I'm sure you are very well aware of what it is.  =
Bringing this problem through the dispatch process would be fine of =
course but that has not happened. As such, I don't think the consensus =
call you are asking the chairs to make is one that they can make - or =
indeed would make any difference if it was made - the AD can decide =
independently decide if they want to AD sponsor a draft or not.=20

Cullen 



On Oct 13, 2011, at 3:55 PM, Worley, Dale R (Dale) wrote:

>> From: "Worley, Dale R (Dale)" 
>> Date: Thu, 15 Sep 2011 11:46:35 -0400
>>=20
>> (1) I formally request the chairs to recognize that rough consensus
>> has been reached that the work described in
>> draft-montemurro-gsma-imei-urn and
>> draft-allen-dispatch-imei-urn-as-instanceid should progress, and =
those
>> proposals be dispatched to an appropriate working group.
>=20
> Seeing that I have published a list of the issues that might be
> significant in this discussion
> (http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
> and seeing that no response has been made by *anybody* regarding that
> list, and seeing that the stated opinions on the WG mailing list
> remain at 17 favorable (hailing from at least 15 different
> organizations) and 1 unfavorable...
>=20
> For a second time, I formally request the chairs to recognize that
> rough consensus has been reached that the work described in
> draft-montemurro-gsma-imei-urn and
> draft-allen-dispatch-imei-urn-as-instanceid should progress, and those
> proposals be dispatched to an appropriate working group (which in this
> case means an appropriate mailing list for discussion of an
> AD-sponsired I-D).
>=20
> Dale
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From fluffy@cisco.com  Mon Oct 24 06:36:40 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E3221F8D00 for ; Mon, 24 Oct 2011 06:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.234
X-Spam-Level: 
X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6Pck2CQ71-w for ; Mon, 24 Oct 2011 06:36:39 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5C521F8CE4 for ; Mon, 24 Oct 2011 06:36:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=10032; q=dns/txt; s=iport; t=1319463399; x=1320672999; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lNQXAdGa0aEaRbYVrQRmeReX2d82CPJdD4+0sdMGc38=; b=GdCDNFLgdu71zx9NjNtfDKVYnmo++LlwtRyiITCFmD6QFlogc+2Cy4Xw 0aINYy8qbQdPlK55m/qSKE+pF7S1edE6OmPNm/IuNkhQ683PwjB87iIdF ef+FGC2XF5PapL89DDfMxforY7m/A5vfmGIdCQkYsM1qwiOpuUmc2o0CP U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAGlppU6rRDoH/2dsb2JhbABDqRKBBYFuAQEBAQIBAQEBDwEnNAsFCwtGJzAGEyKHXgiVUwGdegSHX2EEiAaMA4UsjE4
X-IronPort-AV: E=Sophos;i="4.69,398,1315180800";  d="scan'208";a="9163293"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 24 Oct 2011 13:36:39 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9ODach7032708; Mon, 24 Oct 2011 13:36:38 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Mon, 24 Oct 2011 07:36:38 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> 
To: "Worley, Dale R (Dale)" 
X-Mailer: Apple Mail (2.1084)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 13:36:40 -0000

Dale - sent in my role as an individual contributor. (all my emails are =
in my role as an individual contributor unless they are clearly signed =
as some other role)

In the past I have made the mistake of listing all my concerns with this =
draft then one or two would get discussed for a bit and rest ignored so =
this time I'm going to try and stick with a few high level ones and some =
minor ones. We can try to resolve theses a bit then we can move on the =
others. Lets start with the stuff from your email.=20

Interoperability.

I've asked multiple people does this happen in INVITEs or just REGISTERs =
and got mixed answers. It makes a big difference - at some level this is =
a proposal to black list phones and / or part of a malware prevention =
systems. Or perhaps it is a proposal to white list phones and ones that =
don't have this won't work. You can say this going to be restricted to =
just the sets of people that want to use it but that is seldom how =
standards work out That might be true in the cases of if it only went =
from a phone to the domain for it's AOR. However, if this will also be =
used in INVITE cases, would it stop calls from any 3GPP phone to non =
3GPP phone? Making sure that we did not have needless lack of =
interoperability between classic IETF SIP and 3GPP style SIP has always =
been a goal. Even if this is only only on IMS phones, theses are now =
used well outside the mobile environment - we see them used on wireline =
and enterprise environments so would there be a problem from other SIP =
devices to theses. Could a soft phone get the required IMEI identifier =
so it was not blacklisted? Could a small vendor get them? These are all =
things I wonder.

It's impossible to answer any of the above questions without knowing =
something about how this blacklisting stuff works and what this =
identifier is used for. This leads to my first issues. I want a =
description of how this works so we can decide if there are =
interoperability problems or not. I am constantly told this is important =
to 3GPP yet I can't find a 3GPP document that even has a reference to =
this draft or explains how it works. So this is my most important =
question to you -  Do you think this is unreasonable that we should ask =
how this works and if there are interoperability problems? If this is =
important to 3GPP, could they provide a pointer to a document that has =
reference to it and defines how it is used.

On a minor notes related to references - I'm not objecting based on =
process crap around the references but it would be really really nice if =
the drafts could be updated so that the reference pointed at a specific =
document - not a vague family of documents where I have no idea if I am =
reading the right one or not. I never know what to read when I see 3GPP =
24.237 but if you gave me a date and version, or even a link, it would =
be easier. A reference should be something where we both know we are =
reading the same document. I realize the 3GPP documents  have some =
examples that have this identifier in them but I could not find a =
description of how it worked. I'd also like to point out that in 2007 I =
asked for the pointer to the document that explains the GSMA allocation =
policy as you will eventually need that for IESG approval but the link =
in the draft is still wrong. Yes, I can figure out how to find the right =
one but is really too much to ask that someone could have fixed this. =
Again, none of things in this paragraph matter to me on the big topic of =
how to proceed but it's hard to put this on top of ones priority list =
when no one can bother to fix stuff that is clearly wrong. =20

So let me be very clear on what I am looking for to start the =
interoperability discussion. We need to understand the specification for =
this to decide what interoperability problems there may or may not be. =
My assumptions how how this works may be very wrong. Lets get the facts =
and make an informed decision.=20


Privacy

So what's the position of everyone that has been sending opinions of =
this draft. Is the IMEI of my phone personal identifying information or =
now? Sort of hard to have a discussion without deciding that first.=20


IPR

On the topic of IPR. I think we need to sort out some of the simpler =
issues first and in the end I will probably rather have the IPR =
discussion on the ietf list than here. To put it pretty bluntly, the =
IETF list is a more favorable environment for the arguments I will =
probably make around IPR. It always fascinates me me to see the =
proponents of this draft sending nasty grams to the chairs telling them =
do something that process wise they can't do but would effectively move =
the conversation from the dispatch list to the ietf list while at the =
same time the ADs and Chairs are trying to resolve the conversation in =
dispatch first which is typically much less concerned about IPR than the =
IETF is in general.  I will note that Gonzalo thinks my drafts runs into =
the Andrews's patents but I have been working on the assumption that it =
does not as Andrew commented on it and did not file any IPR disclosure =
or notify the WG.=20


On a finally note, I get the feeling that you think the chairs on not =
doing something they should. Obviously if there was anything that =
required making a call where the consensus was not obvious or anything I =
would leave that type of decision to Mary. I am participating in this =
conversation as one of the individuals in the WG and would leave any =
complex judgment call to Mary. If you think there is something where my =
individual opinions are causing the chairs not to do the right things, =
please, grab a phone and call me about it and we will figure out a way =
where everyone agrees the chairs are doing the right thing. I'm not a =
fan of the current passive aggressive approach.=20



On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:

> Given that the decision to be made in this working group is whether to
> assign these I-Ds for further work to be done on them, there are a
> small number of questions in play (with assorted other issues to be
> addressed during the technical refinement of the proposal):
>=20
> 1.  Does this proposal introduce any interoperability problems?
> 2.  Does this proposal present any privacy concerns?
> 3.  Does this proposal allow anyone to extract an unconscionable
>    "tax" (through the use of IPR)?
>=20
> Here are my assessments of these issues:
>=20
> 1.  Does this proposal introduce any interoperability problems?
>=20
> I don't see what interoperability problems can result from the
> introduction of an additional format of URN, as long as the format
> adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
> clear that a SIP element may receive a +sip.instance value which is in
> a URN namespace that it does not recognize, so any properly
> constructed SIP element should be able to handle +sip.instance values
> in namespaces that it does not have prior knowledge of.
>=20
> (Certainly, the one product/project that I have detailed knowledge of
> has always treated +sip.instance as a string.  Thereon hangs a tale:
> If the +sip.instance is a UUID-based URN, and if the UUID is based on
> a MAC address, the registrar extracts the MAC address so that the UA
> can be addressed through a special URI that encodes its MAC address.
> But it turns out that a popular make of UA formats its UUIDs
> incorrectly, so that it was not recognized as a MAC-based UUID.  We've
> had to add special code to the registrar to recognize this defective
> URN format!)
>=20
> 2.  Does this proposal present any privacy concerns?
>=20
> There would be general privacy concerns if this or any other
> +sip.instance value was present in dialog-forming requests or
> responses, and so could be seen by the other end of phone calls.  But
> as far as I can tell, no UA uses +sip.instance in INVITEs;
> +sip.instance values are presented only in REGISTER messages.
>=20
> On the other hand, generated GRUU values are given in INVITEs, and the
> GRUU can give information about the UA's +sip.instance and the AOR,
> even if the GRUU is generated using a secret key.  However, the
> problems resulting from this seem to be essentially the same when the
> +sip.instance is derived from an IMEI as when it is derived from a MAC
> address.
>=20
> In regard to registrations, given that the intended scope of
> application of the proposal is entirely within paid wireless networks,
> there can be no privacy between the UA and its registrar.
>=20
> 3.  Does this proposal allow anyone to extract an unconscionable
>    "tax" (through the use of IPR)?
>=20
> Though this proposal may be encumbered by IPR claims, the only users
> who would be *required* to use this URN format are products within the
> GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts this
> as mandatory-to-implement.  Those users might be subjected to an
> unconscionable tax, but the GSM/3GPP/IMS universe has its own
> political/economic structure for deciding what licensed technology is
> mandatory to implement and what licensing terms are considered
> acceptable.  It seems to me that we can justly leave these questions
> to GSM/3GPP/IMS.
>=20
> There is some concern that the IPR disclosures were filed "late".
> However, as the latest IPR disclosure was filed in January 2011, the
> working group is now even later, and the objection has expired.
>=20
> In summary, I don't see any of these issues as being particularly
> problematic.  If I've overlooked an important aspect of this, I would
> like to see some detailed information about it.
>=20
> Dale
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From fluffy@cisco.com  Mon Oct 24 07:05:53 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B3A21F8BA6 for ; Mon, 24 Oct 2011 07:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.25
X-Spam-Level: 
X-Spam-Status: No, score=-106.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC6xQsjvW15L for ; Mon, 24 Oct 2011 07:05:53 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 26BBF21F8B66 for ; Mon, 24 Oct 2011 07:05:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1091; q=dns/txt; s=iport; t=1319465153; x=1320674753; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Dr8N8EtEq2tLHI8CExwlRaY3+JjzaXNJKA65T4eGSLk=; b=kHIgEKP1w9rJrxzsnFBXdSyoiSgwn/fjBuxwebz/3kh1WxTbpatUkA/V ZxH3KEF99WOIA1CzO6JJp3S4o0FBHJM6qY0h6Oj2jL/3hulTJyrFWK+To WYqFpoYScl6HbYDbFG/7Llth1vO529+Zfj6hf+28sTfBK+a/7TZBs+KBd 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPFvpU6rRDoJ/2dsb2JhbAA9BqkSgQWBbgEBAQECARIBJz8QCxUxVwYTIodelWoBnX+FHIMkBIgGjAOFLIxO
X-IronPort-AV: E=Sophos;i="4.69,398,1315180800";  d="scan'208";a="9821610"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 24 Oct 2011 14:05:53 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9OE5qkx013541; Mon, 24 Oct 2011 14:05:52 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Mon, 24 Oct 2011 08:05:52 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <69DB4BA3-9DCD-4044-9229-9198264BDECC@cisco.com>
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.40803 07@alum.mit.edu> 
To: "Worley, Dale R (Dale)" 
X-Mailer: Apple Mail (2.1084)
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] Deriving URI from MAC-based URN ???
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 14:05:53 -0000

On Sep 23, 2011, at 9:46 AM, Worley, Dale R (Dale) wrote:

>> From: Paul Kyzivat [pkyzivat@alum.mit.edu]
>>=20
>> You can just configure the phone as you say, IF:
>>=20
>> - the phone has a configurable light
>> - the light can be configured with a URI
>> - the phone determines the light status by using the URI
>>   in the way intended by the target of that URI
>>=20
>> AFAIK all of those are unusual properties, except for the specific
>> equipment that currently supports it. If I have some "other" phone I =
am
>> out of luck unless I am in a position to modify it in that way.
>=20
> I may be completely misunderstanding you, but I know of no SIP phone
> which is claimed to "have BLF lights" that does *not* implement the
> points you've listed.
>=20
> Dale

Huh ... I'm pretty confused Dale. I seem to recall  IETF has a RFC for =
using sub/nof for this that is widely implements and does not work that =
way. ( I do understand that Cisco implementations of it is a bit broken =
in that the NOTIFY are un solicited but it's still roughly the same ).=20=





From fluffy@cisco.com  Mon Oct 24 07:05:56 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B75121F8C18 for ; Mon, 24 Oct 2011 07:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.265
X-Spam-Level: 
X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5vxOm-kY1uC for ; Mon, 24 Oct 2011 07:05:55 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DD85021F8BF7 for ; Mon, 24 Oct 2011 07:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=340; q=dns/txt; s=iport; t=1319465156; x=1320674756; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Dq7REn2RGxC8Oik7cTnf90LXLZSv5XN4wIxZTs/nbNM=; b=bdmRJZzU67JEJOPi7ld22g6cYJ4KVukenUw4k4zreNdmEKemLjH/2U9W w2ZIMWOCeM6MGtfQJQohPCOQmOLQveGelFeOA7uZeCts5TEzu1/UK+Xc7 ejAly4Xrbxq5HvolNAYFDzceRT/PbBwzKXe1euZG7ikQhktM7B3QYQOXw 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAGpwpU6rRDoJ/2dsb2JhbABDqRKBBYFuAQEBAQIBEgEnPxALRlcGNYdelWoBnX+HX2EEiAaMA4UsjE4
X-IronPort-AV: E=Sophos;i="4.69,398,1315180800";  d="scan'208";a="9841835"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 24 Oct 2011 14:05:55 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9OE5ql0013541; Mon, 24 Oct 2011 14:05:55 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Mon, 24 Oct 2011 08:05:54 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C308C99-684A-4F53-A117-A31670D770BB@cisco.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080307@alum.mit.edu>  <4E7CB229.2050207@digium.com>, <4E88F5BC.6010904@alum.mit.edu> 
To: "Worley, Dale R (Dale)" 
X-Mailer: Apple Mail (2.1084)
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] Deriving URI from MAC-based URN ???
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 14:05:56 -0000

On Oct 3, 2011, at 1:34 PM, Worley, Dale R (Dale) wrote:

>=20
> And conversely, Cisco phones have never implemented enough of SIP to
> be usable in our pure-proxy system.

Dale - they work fine for most people using proxy based systems. I do =
note in fact that pingtell claimed they worked with their system at one =
point.=20


From pkyzivat@alum.mit.edu  Mon Oct 24 07:24:56 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4CA21F8DF8 for ; Mon, 24 Oct 2011 07:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level: 
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcG4LUhgx074 for ; Mon, 24 Oct 2011 07:24:56 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1A51521F8DF7 for ; Mon, 24 Oct 2011 07:24:55 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta14.westchester.pa.mail.comcast.net with comcast id obq41h0021vXlb85EeQw3a; Mon, 24 Oct 2011 14:24:56 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id oeQs1h0110tdiYw3deQsA9; Mon, 24 Oct 2011 14:24:53 +0000
Message-ID: <4EA57531.4060807@alum.mit.edu>
Date: Mon, 24 Oct 2011 10:24:49 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Cullen Jennings 
References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080! 307@alum.mit.edu>  <69DB4BA3-9DCD-4044-9229-9198264BDECC@cisco.com>
In-Reply-To: <69DB4BA3-9DCD-4044-9229-9198264BDECC@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] Deriving URI from MAC-based URN ???
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 14:24:56 -0000

On 10/24/11 10:05 AM, Cullen Jennings wrote:
>
> On Sep 23, 2011, at 9:46 AM, Worley, Dale R (Dale) wrote:
>
>>> From: Paul Kyzivat [pkyzivat@alum.mit.edu]
>>>
>>> You can just configure the phone as you say, IF:
>>>
>>> - the phone has a configurable light
>>> - the light can be configured with a URI
>>> - the phone determines the light status by using the URI
>>>    in the way intended by the target of that URI
>>>
>>> AFAIK all of those are unusual properties, except for the specific
>>> equipment that currently supports it. If I have some "other" phone I am
>>> out of luck unless I am in a position to modify it in that way.
>>
>> I may be completely misunderstanding you, but I know of no SIP phone
>> which is claimed to "have BLF lights" that does *not* implement the
>> points you've listed.
>>
>> Dale
>
> Huh ... I'm pretty confused Dale. I seem to recall  IETF has a RFC for using sub/nof for this that is widely implements and does not work that way. ( I do understand that Cisco implementations of it is a bit broken in that the NOTIFY are un solicited but it's still roughly the same ).

I was questioning the assumption that any phone possessing a BLF "light" 
(or other indication) will have an end-user configuration option that 
associates an arbitrary URI with the light, and that then does a 
subscription to the dialog event package and derives a status for the 
light from the resulting notifications.

That gets well into areas of configuration that we don't standardize.

	Thanks,
	Paul

From fluffy@cisco.com  Mon Oct 24 07:36:43 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724CB21F8DEE for ; Mon, 24 Oct 2011 07:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.279
X-Spam-Level: 
X-Spam-Status: No, score=-106.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWnyNjSF6ka5 for ; Mon, 24 Oct 2011 07:36:42 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A280221F8DE2 for ; Mon, 24 Oct 2011 07:36:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1976; q=dns/txt; s=iport; t=1319467002; x=1320676602; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OimcJ/3isBiX5Q2CrJulTjmRGxIMjO4G7BJkSWrgZlA=; b=Vo4Fzqt1onP/Nxa+5CpIJwGw4sovLQAggFwhBojC4vAh2N/qRaVfMQ1a VSz3PNb9PQTHRE5pnXQPEMWBbM61UDoG+rRYTXyzpiq5yMD+fwUqI9anG Fa41Z3+pk+lINktGlE9iv+kadJbybqlCVY97P4zrIoO0lKNRBSUUbo7+r Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EADV3pU6rRDoI/2dsb2JhbAA9Bg6pBIEFgW4BAQEBAgESASc/BQsLDgcDDSFXBhMih16VZwGeAoUcgkNhBIgGjAOFLIt4Vg
X-IronPort-AV: E=Sophos;i="4.69,398,1315180800";  d="scan'208";a="9827725"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 24 Oct 2011 14:36:42 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9OEaffk014699; Mon, 24 Oct 2011 14:36:42 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: <4EA57531.4060807@alum.mit.edu>
Date: Mon, 24 Oct 2011 08:36:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A2D982E-481B-4D0E-8C18-335B79B42577@cisco.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080! 307@alum.mit.edu>  <69DB4BA3-9DCD-4044-9229-9198264BDECC@cisco.com> <4EA57531.4060807@alum. mit.edu>
To: "Paul Kyzivat" 
X-Mailer: Apple Mail (2.1084)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Deriving URI from MAC-based URN ???
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 14:36:43 -0000

On Oct 24, 2011, at 8:24 AM, Paul Kyzivat wrote:

> On 10/24/11 10:05 AM, Cullen Jennings wrote:
> >
> > On Sep 23, 2011, at 9:46 AM, Worley, Dale R (Dale) wrote:
> >
> >>> From: Paul Kyzivat [pkyzivat@alum.mit.edu]
> >>>
> >>> You can just configure the phone as you say, IF:
> >>>
> >>> - the phone has a configurable light
> >>> - the light can be configured with a URI
> >>> - the phone determines the light status by using the URI
> >>>    in the way intended by the target of that URI
> >>>
> >>> AFAIK all of those are unusual properties, except for the specific
> >>> equipment that currently supports it. If I have some "other" phone =
I am
> >>> out of luck unless I am in a position to modify it in that way.
> >>
> >> I may be completely misunderstanding you, but I know of no SIP =
phone
> >> which is claimed to "have BLF lights" that does *not* implement the
> >> points you've listed.
> >>
> >> Dale
> >
> > Huh ... I'm pretty confused Dale. I seem to recall  IETF has a RFC =
for using sub/nof for this that is widely implements and does not work =
that way. ( I do understand that Cisco implementations of it is a bit =
broken in that the NOTIFY are un solicited but it's still roughly the =
same ).
>=20
> I was questioning the assumption that any phone possessing a BLF =
"light"
> (or other indication) will have an end-user configuration option that
> associates an arbitrary URI with the light, and that then does a
> subscription to the dialog event package and derives a status for the
> light from the resulting notifications.
>=20
> That gets well into areas of configuration that we don't standardize.
>=20
>         Thanks,
>         Paul
>=20

agree on that's config but even so, typically you want the BLF =
subscribed to AOR that is the same as the phones registers for. Hard to =
see how a MAC gets involved with BLF unless you have a really broken =
confusion between users and devices.=20



From pkyzivat@alum.mit.edu  Mon Oct 24 08:47:02 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B179521F8C75 for ; Mon, 24 Oct 2011 08:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.355
X-Spam-Level: 
X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcIMPbmJbYwB for ; Mon, 24 Oct 2011 08:47:02 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id F3D1921F8BF6 for ; Mon, 24 Oct 2011 08:47:01 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id ofK81h0050mv7h05Dfn23r; Mon, 24 Oct 2011 15:47:02 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta11.westchester.pa.mail.comcast.net with comcast id ofmz1h0100tdiYw3Xfn0ME; Mon, 24 Oct 2011 15:47:02 +0000
Message-ID: <4EA58872.4050303@alum.mit.edu>
Date: Mon, 24 Oct 2011 11:46:58 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Cullen Jennings 
References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080! 307@alum.mit.edu>  <69DB4BA3-9DCD-4044-9229-9198264BDECC@cisco.com> <4EA57531.4060807@alum! .mit.edu> <0A2D982E-481B-4D0E-8C18-335B79B42577@cisco.com>
In-Reply-To: <0A2D982E-481B-4D0E-8C18-335B79B42577@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Deriving URI from MAC-based URN ???
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 15:47:02 -0000

On 10/24/11 10:36 AM, Cullen Jennings wrote:
>
> On Oct 24, 2011, at 8:24 AM, Paul Kyzivat wrote:
>
>> On 10/24/11 10:05 AM, Cullen Jennings wrote:
>>>
>>> On Sep 23, 2011, at 9:46 AM, Worley, Dale R (Dale) wrote:
>>>
>>>>> From: Paul Kyzivat [pkyzivat@alum.mit.edu]
>>>>>
>>>>> You can just configure the phone as you say, IF:
>>>>>
>>>>> - the phone has a configurable light
>>>>> - the light can be configured with a URI
>>>>> - the phone determines the light status by using the URI
>>>>>     in the way intended by the target of that URI
>>>>>
>>>>> AFAIK all of those are unusual properties, except for the specific
>>>>> equipment that currently supports it. If I have some "other" phone I am
>>>>> out of luck unless I am in a position to modify it in that way.
>>>>
>>>> I may be completely misunderstanding you, but I know of no SIP phone
>>>> which is claimed to "have BLF lights" that does *not* implement the
>>>> points you've listed.
>>>>
>>>> Dale
>>>
>>> Huh ... I'm pretty confused Dale. I seem to recall  IETF has a RFC for using sub/nof for this that is widely implements and does not work that way. ( I do understand that Cisco implementations of it is a bit broken in that the NOTIFY are un solicited but it's still roughly the same ).
>>
>> I was questioning the assumption that any phone possessing a BLF "light"
>> (or other indication) will have an end-user configuration option that
>> associates an arbitrary URI with the light, and that then does a
>> subscription to the dialog event package and derives a status for the
>> light from the resulting notifications.
>>
>> That gets well into areas of configuration that we don't standardize.
>>
>>          Thanks,
>>          Paul
>>
>
> agree on that's config but even so, typically you want the BLF subscribed to AOR that is the same as the phones registers for. Hard to see how a MAC gets involved with BLF unless you have a really broken confusion between users and devices.

It makes some sense to derive BLF info by subscribing to the AOR being 
registered. And that doesn't require any manual configuration of the BLF 
at all.

But Dale was describing a technique his system uses that assigns a 
special AOR, based on MAC, that is used as the target of this subscription.

	Thanks,
	Paul

From adam@nostrum.com  Mon Oct 24 13:01:52 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4621F8BB3 for ; Mon, 24 Oct 2011 13:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level: 
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL5l-48NvdJN for ; Mon, 24 Oct 2011 13:01:51 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6127221F8BB2 for ; Mon, 24 Oct 2011 13:01: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 p9OK1kV9095403 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 15:01:47 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4EA5C42A.7030707@nostrum.com>
Date: Mon, 24 Oct 2011 15:01:46 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" 
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: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 20:01:52 -0000

On 10/13/11 4:55 PM, Worley, Dale R (Dale) wrote:
> Seeing that I have published a list of the issues that might be
> significant in this discussion
> (http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
> and seeing that no response has been made by *anybody* regarding that
> list, and seeing that the stated opinions on the WG mailing list
> remain at 17 favorable (hailing from at least 15 different
> organizations) and 1 unfavorable...

While there have been a number of parties expressing support for the 
document, I don't see any that have attempted to allay the concerns that 
Cullen initially expressed (and which he clarified earlier today).

In particular, I do find the issue of the use of IMSI and/or IMEI-based 
URNs as a means for whitelist/blacklist control -- where URNs formed by 
other means may not be compatible -- to be a real and pertinent concern. 
And the issue of being able to positively correlate, as an ordinary 
user, that two calls came from the same terminal, raises some stark and 
valid privacy concerns.

I don't want to minimize Andrew's contribution to this conversation (or 
yours) -- it's going somewhere but has not yet reached that destination. 
However, the remainder of the "supporting" parties you cite have largely 
contributed in this fashion:

Christer: "+1"
Atle: "+1."
Jan: "Also Belgacom would like to see this draft progressed."
Olle: "+1"
Laura: "+1"
Roland: "+1"
Ricky: "I would like to repeat my support for the progressing of this 
work in IETF."*
Lili: "+1"
Shida: "We support the draft as well."
Itsuma: "NTT DOCOMO also supports this draft moving forward."
Martin: "AT&T supports this draft moving forward"

(I can't find the remaining five voices of support you mention, but I 
suspect they have similar technical content.)

Certainly you're familiar with David Clark's well-known quote about IETF 
process: "We reject kings, presidents, and voting."

While it's not irrelevant that there is a broad base of people who would 
like to see this document published, we do need to keep in mind that 
"+1" does not make for a valid technical argument or rebuttal. In 
particular, most WG chairs will justly treat a cascade of 
unsubstantiated "+1" responses as an attempt at ballot stuffing. For the 
purposes of calling consensus on a *technical* topic, chairs have an 
obligation to discount vague statements of support.

I, for one, see substantial merit in at least two of the technical 
issues that Cullen has raised. I don't think the treatment of privacy or 
the treatment of compatibility have been sufficiently addressed in the 
current document.

/a

___
* To be fair, Ricky also cited an earlier email that detailed why 3GPP 
wants this work to progress; however, it does not address any of the 
technical concerns that have been subsequently raised.

From dworley@avaya.com  Mon Oct 24 13:07:21 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4721F8C54 for ; Mon, 24 Oct 2011 13:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.446
X-Spam-Level: 
X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB9TpygGKUkR for ; Mon, 24 Oct 2011 13:07:21 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D471A21F8C53 for ; Mon, 24 Oct 2011 13:07:20 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAMzEpU6HCzI1/2dsb2JhbAA6CQ6pBIEFgW4BAQEBAgESKD8FCwIBCA0BByEQMiUBAQQOBQgah16YXJtAhRKCTWEEmVSLWVM
X-IronPort-AV: E=Sophos;i="4.69,399,1315195200"; d="scan'208";a="274230214"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Oct 2011 16:07:19 -0400
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Oct 2011 15:56:43 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 24 Oct 2011 16:07:17 -0400
From: "Worley, Dale R (Dale)" 
To: Henning Schulzrinne 
Date: Mon, 24 Oct 2011 16:04:00 -0400
Thread-Topic: [dispatch] New I-D: Referencing and Validating User Attributes for	SIP
Thread-Index: AcyQ4b/vo4L8glXIRnm/iBPwdDamKgBplH7J
Message-ID: 
References: <4EA0D84F.8090600@cs.columbia.edu>  <4EA1DFB1.70508@cs.columbia.edu>, <587A9A01-9DA3-4E5E-83CE-CBB2F168E9CA@cs.columbia.edu>
In-Reply-To: <587A9A01-9DA3-4E5E-83CE-CBB2F168E9CA@cs.columbia.edu>
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: DISPATCH 
Subject: Re: [dispatch] New I-D: Referencing and Validating User Attributes for	SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 20:07:21 -0000

> From: Henning Schulzrinne [hgs@cs.columbia.edu]
>=20
> >> It looks like the ARID contains the caller's identity and the
> >> recipient's AOR, but nothing binding it to the specific dialog.
> >
> > The ARID is generated by encoding the caller's identity issued in an
> > organization, the recipient's AOR, and the timestamp. But as you
> > pointed out, there is no tight binding to the specific dialog.
>=20
> I'm curious what the advantage of such a binding would be. My concern
> is that B2BUAs may destroy end-to-end dialog continuity, so that this
> would make the mechanism less likely to work in practice.

I haven't spent nearly enough time to fully digest the security
implications of ARID (and I'm not likely to), but initially I am
highly suspect of any authentication mehcanism that is not bound to
the dialog which is being authenticated.

> >> The
> >> recipeint can steal the ARID, but can only use it to call one of the
> >> recipeint AORs in the ARID.  This isn't a threat if the AOR is that of
> >> an individual, but is if the AOR is an organizational role (e.g.,
> >> , or if there are multiple AORs.
>=20
> What would you see as the threat in that model? If I address a call to
> customer-service, I presumably trust any agent of that designation to
> obtain my credentials. After all, even a standard residential phone
> number resolves to multiple devices and people (members of the
> family).

If I address a call to customer-service, I do *not* trust an agent of
the organization to be able to call the organization's
customer-service line *pretending to be me*.

Dale

From ibc@aliax.net  Mon Oct 24 13:32:31 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A790211E8121 for ; Mon, 24 Oct 2011 13:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.637
X-Spam-Level: 
X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgxDdm5XmSpe for ; Mon, 24 Oct 2011 13:32:31 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C02B11E811F for ; Mon, 24 Oct 2011 13:32:31 -0700 (PDT)
Received: by vws5 with SMTP id 5so5856787vws.31 for ; Mon, 24 Oct 2011 13:32:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.30.79 with SMTP id q15mr24079706vdh.111.1319488350397; Mon, 24 Oct 2011 13:32:30 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Mon, 24 Oct 2011 13:32:30 -0700 (PDT)
Date: Mon, 24 Oct 2011 22:32:30 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: dispatch@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [dispatch] [OT] Creating URN in JavaScript running in a browser
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 20:32:31 -0000

Hi, I've read the draft-allen-dispatch-imei-urn-as-instanceid and I
wonder how to get a constant URN using JavaScript in a browser, this
is, a constant value unique for each web browser. The question is
related to a SIP stack in JavaScript.

Any thoughts on this?

Thanks a lot.

--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Mon Oct 24 13:45:35 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2078B11E8138 for ; Mon, 24 Oct 2011 13:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.637
X-Spam-Level: 
X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yek7+VuRdUjK for ; Mon, 24 Oct 2011 13:45:34 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E563211E8132 for ; Mon, 24 Oct 2011 13:45:31 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so6319026vcb.31 for ; Mon, 24 Oct 2011 13:45:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.28.141 with SMTP id b13mr24354615vdh.128.1319489131310; Mon, 24 Oct 2011 13:45:31 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Mon, 24 Oct 2011 13:45:31 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 24 Oct 2011 22:45:31 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: "Richard L. Barnes" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: dispatch@ietf.org
Subject: Re: [dispatch] [OT] Creating URN in JavaScript running in a browser
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 20:45:35 -0000

2011/10/24 Richard L. Barnes :
> Cookies are probably your friend here. =C2=A0Have your script set a cooki=
e, use that as the unique ID.

A Cookie stored in the browser with constant value (until it expires,
but it is good enough). Great :)

Thanks a lot.






--=20
I=C3=B1aki Baz Castillo


From keith.drage@alcatel-lucent.com  Mon Oct 24 14:50:09 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E8311E818A for ; Mon, 24 Oct 2011 14:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.966
X-Spam-Level: 
X-Spam-Status: No, score=-105.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxnZSOcx8eK0 for ; Mon, 24 Oct 2011 14:50:08 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5D911E818E for ; Mon, 24 Oct 2011 14:50:08 -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 p9OLnxJs008914 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 Oct 2011 23:50:01 +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; Mon, 24 Oct 2011 23:50:00 +0200
From: "DRAGE, Keith (Keith)" 
To: Adam Roach , "Worley, Dale R (Dale)" 
Date: Mon, 24 Oct 2011 23:49:56 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySh8qNTLflA84kTciTuOmBSbmBqQADkXfw
Message-ID: 
References:  <4EA5C42A.7030707@nostrum.com>
In-Reply-To: <4EA5C42A.7030707@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.69 on 155.132.188.80
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn	anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 21:50:09 -0000

On the contrary.

I believe Andrew Allen replied on 28th May 2011 to the last technical point=
s that Cullen made, which were on the 18th May 2011.

Cullen's response to that consisted of a sequence of statements that basica=
lly said "I've already indicated that".

As Andrew specifically asked Cullen for clarification on a number of issues=
 in that response, and has not so far done so (at least so far as my email =
tracking goes) I think you are being overly critical.

This draft seems to be in a state where Cullen is holding it hostage by NOT=
 indulging in the appropriate dialog required of an internet draft.

And I do note that I have seen messages from both you and Cullen indicating=
 "+1" on various subjects.

When in principle there is little technical content from the objector to re=
spond to, do you expect the supporters of a draft to indicate anything else=
 other than "+1" as in let's get on with finishing this off.

I'll respond on the whitelisting / blacklisting in a separate mail

Regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Adam Roach
> Sent: 24 October 2011 21:02
> To: Worley, Dale R (Dale)
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-
> dispatch-imei-urn-as-instanceid
>=20
> On 10/13/11 4:55 PM, Worley, Dale R (Dale) wrote:
> > Seeing that I have published a list of the issues that might be
> > significant in this discussion
> > (http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
> > and seeing that no response has been made by *anybody* regarding that
> > list, and seeing that the stated opinions on the WG mailing list
> > remain at 17 favorable (hailing from at least 15 different
> > organizations) and 1 unfavorable...
>=20
> While there have been a number of parties expressing support for the
> document, I don't see any that have attempted to allay the concerns that
> Cullen initially expressed (and which he clarified earlier today).
>=20
> In particular, I do find the issue of the use of IMSI and/or IMEI-based
> URNs as a means for whitelist/blacklist control -- where URNs formed by
> other means may not be compatible -- to be a real and pertinent concern.
> And the issue of being able to positively correlate, as an ordinary
> user, that two calls came from the same terminal, raises some stark and
> valid privacy concerns.
>=20
> I don't want to minimize Andrew's contribution to this conversation (or
> yours) -- it's going somewhere but has not yet reached that destination.
> However, the remainder of the "supporting" parties you cite have largely
> contributed in this fashion:
>=20
> Christer: "+1"
> Atle: "+1."
> Jan: "Also Belgacom would like to see this draft progressed."
> Olle: "+1"
> Laura: "+1"
> Roland: "+1"
> Ricky: "I would like to repeat my support for the progressing of this
> work in IETF."*
> Lili: "+1"
> Shida: "We support the draft as well."
> Itsuma: "NTT DOCOMO also supports this draft moving forward."
> Martin: "AT&T supports this draft moving forward"
>=20
> (I can't find the remaining five voices of support you mention, but I
> suspect they have similar technical content.)
>=20
> Certainly you're familiar with David Clark's well-known quote about IETF
> process: "We reject kings, presidents, and voting."
>=20
> While it's not irrelevant that there is a broad base of people who would
> like to see this document published, we do need to keep in mind that
> "+1" does not make for a valid technical argument or rebuttal. In
> particular, most WG chairs will justly treat a cascade of
> unsubstantiated "+1" responses as an attempt at ballot stuffing. For the
> purposes of calling consensus on a *technical* topic, chairs have an
> obligation to discount vague statements of support.
>=20
> I, for one, see substantial merit in at least two of the technical
> issues that Cullen has raised. I don't think the treatment of privacy or
> the treatment of compatibility have been sufficiently addressed in the
> current document.
>=20
> /a
>=20
> ___
> * To be fair, Ricky also cited an earlier email that detailed why 3GPP
> wants this work to progress; however, it does not address any of the
> technical concerns that have been subsequently raised.
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From HKaplan@acmepacket.com  Mon Oct 24 15:04:18 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A506E11E80B1 for ; Mon, 24 Oct 2011 15:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.423
X-Spam-Level: 
X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnhMuHmJCCUZ for ; Mon, 24 Oct 2011 15:04:18 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E0EC611E8080 for ; Mon, 24 Oct 2011 15:04:17 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 24 Oct 2011 18:04:16 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 18:04:16 -0400
From: Hadriel Kaplan 
To: Adam Roach 
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMkpjfxvfECQHqnUi65i23oORIgw==
Date: Mon, 24 Oct 2011 22:04:16 +0000
Message-ID: 
References:  <4EA5C42A.7030707@nostrum.com>
In-Reply-To: <4EA5C42A.7030707@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn	anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 22:04:18 -0000

On Oct 24, 2011, at 4:01 PM, Adam Roach wrote:

> Christer: "+1"
> Atle: "+1."
> Jan: "Also Belgacom would like to see this draft progressed."
> Olle: "+1"
> Laura: "+1"
> Roland: "+1"
> Ricky: "I would like to repeat my support for the progressing of this wor=
k in IETF."*
> Lili: "+1"
> Shida: "We support the draft as well."
> Itsuma: "NTT DOCOMO also supports this draft moving forward."
> Martin: "AT&T supports this draft moving forward"
>=20
> (I can't find the remaining five voices of support you mention, but I sus=
pect they have similar technical content.)

I did, without using "+1":
http://www.ietf.org/mail-archive/web/dispatch/current/msg03774.html

-hadriel


From dworley@avaya.com  Mon Oct 24 15:07:13 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA7711E8148 for ; Mon, 24 Oct 2011 15:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.457
X-Spam-Level: 
X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIjWbCDz+N5D for ; Mon, 24 Oct 2011 15:07:11 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5408D11E8080 for ; Mon, 24 Oct 2011 15:07:11 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOzgpU6HCzI1/2dsb2JhbABDqROBBYFuAQEBAQIBEig/BQsCAQgNAQchEDIlAQEEDgUIARmHXgiYVZtOh19hBJlUjCw
X-IronPort-AV: E=Sophos;i="4.69,400,1315195200"; d="scan'208";a="274245106"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Oct 2011 18:07:09 -0400
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Oct 2011 17:56:33 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 24 Oct 2011 18:07:08 -0400
From: "Worley, Dale R (Dale)" 
To: Cullen Jennings 
Date: Mon, 24 Oct 2011 18:03:29 -0400
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySRqBKNps63K9wR/GCE9NGnrdWfQAUiKDy
Message-ID: 
References: , <01E059E6-5EAB-4106-9417-7DE6B217ACD0@cisco.com>
In-Reply-To: <01E059E6-5EAB-4106-9417-7DE6B217ACD0@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: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 22:07:13 -0000

> From: Cullen Jennings [fluffy@cisco.com]
>=20
> Dale, you are confused on what the process for this document is.
>=20
> It is left over from before dispatch was formed and is being discussed
> on this list primarily so Gonzalo can decide if he wants to AD sponsor
> it or not.

Indeed, if that is so, then I have made an amusing mistake.

Although it would have been helpful if you had corrected me after my
first "formal request" message, of Sept. 15.
(http://www.ietf.org/mail-archive/web/dispatch/current/msg03768.html).

Dale

From keith.drage@alcatel-lucent.com  Mon Oct 24 15:08:02 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCDB11E816C for ; Mon, 24 Oct 2011 15:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.994
X-Spam-Level: 
X-Spam-Status: No, score=-105.994 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr4tClvqN8Jg for ; Mon, 24 Oct 2011 15:08:01 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0C911E8080 for ; Mon, 24 Oct 2011 15:08:00 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9OM7rvv018352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2011 00:07:53 +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 Oct 2011 00:07:53 +0200
From: "DRAGE, Keith (Keith)" 
To: Cullen Jennings , "Worley, Dale R (Dale)" 
Date: Tue, 25 Oct 2011 00:07:50 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySUgIjsISTdMFyQZ+NQZx+6F9d1wARQdvA
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>
In-Reply-To: <234F9B2D-1FE7-417C-80A9-36497A9275CD@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 22:08:02 -0000

Responding on the blacklisting / whitelisting issue.

As far as I understand, the use of the IMEI to do this (blacklisting / whit=
elisting) happens on every cellphone already (be it according to 3GPP or 3G=
PP standards (where the IMEI is the MEID).=20

The degree to which it occurs is as a result of regulatory pressure. Essent=
ially the prime requirement is from law enforcement agencies who want to id=
entify the use of stolen phones, and prevent those stolen phones having val=
ue, and from operators who want to prevent stolen phones incurring network =
costs for which they will never be reimbursed. For the existing non-IMS cel=
lphones you will find the IMEI or MEID populating many messages including t=
hose that establish new calls.

For IMS phones the same IMEI / MEID is present in messages when you obtain =
the data channel, but as far as I understand operators want it in messages =
that get exchanged more frequently, and that means putting it in INVITE mes=
sages at the SIP layer.

So in conclusion, the usage in this respect is to lessen the incidence of s=
omeone coming up behind you, putting a knife in your ribs, and making off w=
ith your latest model of fancy cellphone. And for non-IMS usage its probabl=
y been doing that for the last 10 years (depending on when operators were p=
ressured by law enforcement agencies to implement the EIR (the online datab=
ase against which EIRs are checked).

Yes it will stop calls. Does someone whos stolen your phone have the right =
to make calls?

As regards IMEIs, it is associated with the hardware, not the software. The=
 hardware manufacturer applies for them from some designated authority ulti=
mately supervised by a joint group of GSMA and TIA/TTA. So you do not have =
the ability to craft your own. I believe the same applies to MAC addresses.

I believe the way it is used in 3GPP the IMEI is not visible to any other t=
han the end user who owns the phone and the network. I do not believe it is=
 seen by any other user (barring someone of course deliberately revealing i=
t).

While there are various databases around that attempt to correlate IMEI val=
ues to a particular type of phone, these have all been reverse engineered b=
y people plugging in the values in phones they have. You will need a sight =
more privileges to find the equivalent information from the official alloca=
tion database, and there is no intention to make it any more public.

Regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Cullen Jennings
> Sent: 24 October 2011 14:37
> To: Worley, Dale R (Dale)
> Cc: dispatch@ietf.org list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
>=20
>=20
> Dale - sent in my role as an individual contributor. (all my emails are i=
n
> my role as an individual contributor unless they are clearly signed as
> some other role)
>=20
> In the past I have made the mistake of listing all my concerns with this
> draft then one or two would get discussed for a bit and rest ignored so
> this time I'm going to try and stick with a few high level ones and some
> minor ones. We can try to resolve theses a bit then we can move on the
> others. Lets start with the stuff from your email.
>=20
> Interoperability.
>=20
> I've asked multiple people does this happen in INVITEs or just REGISTERs
> and got mixed answers. It makes a big difference - at some level this is =
a
> proposal to black list phones and / or part of a malware prevention
> systems. Or perhaps it is a proposal to white list phones and ones that
> don't have this won't work. You can say this going to be restricted to
> just the sets of people that want to use it but that is seldom how
> standards work out That might be true in the cases of if it only went fro=
m
> a phone to the domain for it's AOR. However, if this will also be used in
> INVITE cases, would it stop calls from any 3GPP phone to non 3GPP phone?
> Making sure that we did not have needless lack of interoperability betwee=
n
> classic IETF SIP and 3GPP style SIP has always been a goal. Even if this
> is only only on IMS phones, theses are now used well outside the mobile
> environment - we see them used on wireline and enterprise environments so
> would there be a problem from other SIP devices
>  to theses. Could a soft phone get the required IMEI identifier so it was
> not blacklisted? Could a small vendor get them? These are all things I
> wonder.
>=20
> It's impossible to answer any of the above questions without knowing
> something about how this blacklisting stuff works and what this identifie=
r
> is used for. This leads to my first issues. I want a description of how
> this works so we can decide if there are interoperability problems or not=
.
> I am constantly told this is important to 3GPP yet I can't find a 3GPP
> document that even has a reference to this draft or explains how it works=
.
> So this is my most important question to you -  Do you think this is
> unreasonable that we should ask how this works and if there are
> interoperability problems? If this is important to 3GPP, could they
> provide a pointer to a document that has reference to it and defines how
> it is used.
>=20
> On a minor notes related to references - I'm not objecting based on
> process crap around the references but it would be really really nice if
> the drafts could be updated so that the reference pointed at a specific
> document - not a vague family of documents where I have no idea if I am
> reading the right one or not. I never know what to read when I see 3GPP
> 24.237 but if you gave me a date and version, or even a link, it would be
> easier. A reference should be something where we both know we are reading
> the same document. I realize the 3GPP documents  have some examples that
> have this identifier in them but I could not find a description of how it
> worked. I'd also like to point out that in 2007 I asked for the pointer t=
o
> the document that explains the GSMA allocation policy as you will
> eventually need that for IESG approval but the link in the draft is still
> wrong. Yes, I can figure out how to find the right one but is really too
> much to ask that someone could have fixed this. Ag
>  ain, none of things in this paragraph matter to me on the big topic of
> how to proceed but it's hard to put this on top of ones priority list whe=
n
> no one can bother to fix stuff that is clearly wrong.
>=20
> So let me be very clear on what I am looking for to start the
> interoperability discussion. We need to understand the specification for
> this to decide what interoperability problems there may or may not be. My
> assumptions how how this works may be very wrong. Lets get the facts and
> make an informed decision.
>=20
>=20
> Privacy
>=20
> So what's the position of everyone that has been sending opinions of this
> draft. Is the IMEI of my phone personal identifying information or now?
> Sort of hard to have a discussion without deciding that first.
>=20
>=20
> IPR
>=20
> On the topic of IPR. I think we need to sort out some of the simpler
> issues first and in the end I will probably rather have the IPR discussio=
n
> on the ietf list than here. To put it pretty bluntly, the IETF list is a
> more favorable environment for the arguments I will probably make around
> IPR. It always fascinates me me to see the proponents of this draft
> sending nasty grams to the chairs telling them do something that process
> wise they can't do but would effectively move the conversation from the
> dispatch list to the ietf list while at the same time the ADs and Chairs
> are trying to resolve the conversation in dispatch first which is
> typically much less concerned about IPR than the IETF is in general.  I
> will note that Gonzalo thinks my drafts runs into the Andrews's patents
> but I have been working on the assumption that it does not as Andrew
> commented on it and did not file any IPR disclosure or notify the WG.
>=20
>=20
> On a finally note, I get the feeling that you think the chairs on not
> doing something they should. Obviously if there was anything that require=
d
> making a call where the consensus was not obvious or anything I would
> leave that type of decision to Mary. I am participating in this
> conversation as one of the individuals in the WG and would leave any
> complex judgment call to Mary. If you think there is something where my
> individual opinions are causing the chairs not to do the right things,
> please, grab a phone and call me about it and we will figure out a way
> where everyone agrees the chairs are doing the right thing. I'm not a fan
> of the current passive aggressive approach.
>=20
>=20
>=20
> On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:
>=20
> > Given that the decision to be made in this working group is whether to
> > assign these I-Ds for further work to be done on them, there are a
> > small number of questions in play (with assorted other issues to be
> > addressed during the technical refinement of the proposal):
> >
> > 1.  Does this proposal introduce any interoperability problems?
> > 2.  Does this proposal present any privacy concerns?
> > 3.  Does this proposal allow anyone to extract an unconscionable
> >    "tax" (through the use of IPR)?
> >
> > Here are my assessments of these issues:
> >
> > 1.  Does this proposal introduce any interoperability problems?
> >
> > I don't see what interoperability problems can result from the
> > introduction of an additional format of URN, as long as the format
> > adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
> > clear that a SIP element may receive a +sip.instance value which is in
> > a URN namespace that it does not recognize, so any properly
> > constructed SIP element should be able to handle +sip.instance values
> > in namespaces that it does not have prior knowledge of.
> >
> > (Certainly, the one product/project that I have detailed knowledge of
> > has always treated +sip.instance as a string.  Thereon hangs a tale:
> > If the +sip.instance is a UUID-based URN, and if the UUID is based on
> > a MAC address, the registrar extracts the MAC address so that the UA
> > can be addressed through a special URI that encodes its MAC address.
> > But it turns out that a popular make of UA formats its UUIDs
> > incorrectly, so that it was not recognized as a MAC-based UUID.  We've
> > had to add special code to the registrar to recognize this defective
> > URN format!)
> >
> > 2.  Does this proposal present any privacy concerns?
> >
> > There would be general privacy concerns if this or any other
> > +sip.instance value was present in dialog-forming requests or
> > responses, and so could be seen by the other end of phone calls.  But
> > as far as I can tell, no UA uses +sip.instance in INVITEs;
> > +sip.instance values are presented only in REGISTER messages.
> >
> > On the other hand, generated GRUU values are given in INVITEs, and the
> > GRUU can give information about the UA's +sip.instance and the AOR,
> > even if the GRUU is generated using a secret key.  However, the
> > problems resulting from this seem to be essentially the same when the
> > +sip.instance is derived from an IMEI as when it is derived from a MAC
> > address.
> >
> > In regard to registrations, given that the intended scope of
> > application of the proposal is entirely within paid wireless networks,
> > there can be no privacy between the UA and its registrar.
> >
> > 3.  Does this proposal allow anyone to extract an unconscionable
> >    "tax" (through the use of IPR)?
> >
> > Though this proposal may be encumbered by IPR claims, the only users
> > who would be *required* to use this URN format are products within the
> > GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts this
> > as mandatory-to-implement.  Those users might be subjected to an
> > unconscionable tax, but the GSM/3GPP/IMS universe has its own
> > political/economic structure for deciding what licensed technology is
> > mandatory to implement and what licensing terms are considered
> > acceptable.  It seems to me that we can justly leave these questions
> > to GSM/3GPP/IMS.
> >
> > There is some concern that the IPR disclosures were filed "late".
> > However, as the latest IPR disclosure was filed in January 2011, the
> > working group is now even later, and the objection has expired.
> >
> > In summary, I don't see any of these issues as being particularly
> > problematic.  If I've overlooked an important aspect of this, I would
> > like to see some detailed information about it.
> >
> > Dale
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From md3135@att.com  Mon Oct 24 15:16:51 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64711E81A9 for ; Mon, 24 Oct 2011 15:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvgSHi82iazS for ; Mon, 24 Oct 2011 15:16:50 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF4911E81A7 for ; Mon, 24 Oct 2011 15:16:50 -0700 (PDT)
X-Env-Sender: md3135@att.com
X-Msg-Ref: server-2.tower-119.messagelabs.com!1319494608!32694079!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4267 invoked from network); 24 Oct 2011 22:16:48 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Oct 2011 22:16:48 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9OMHFXk026025; Mon, 24 Oct 2011 18:17:16 -0400
Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9OMHBWH025943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Oct 2011 18:17:11 -0400
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0339.001; Mon, 24 Oct 2011 18:16:43 -0400
From: "DOLLY, MARTIN C" 
To: Adam Roach , "Worley, Dale R (Dale)" , Christer Holmberg 
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMkofLWMBTTdUH50+t4lHtUU1MOpWMDe5g
Date: Mon, 24 Oct 2011 22:16:42 +0000
Message-ID: 
References:  <4EA5C42A.7030707@nostrum.com>
In-Reply-To: <4EA5C42A.7030707@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.158.21]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn	anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 22:16:51 -0000

You state, "We reject kings, presidents, and voting."

Then why do folks (not to highlight names) walk like kings in the IETF.

The draft meets AT&T's business needs. (period)

How many "kings" of the IETF hide like cowards with pseudo "technical" comm=
ents to protect their ill designed company products?
:)=20

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Adam Roach
Sent: Monday, October 24, 2011 4:02 PM
To: Worley, Dale R (Dale)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispa=
tch-imei-urn-as-instanceid

On 10/13/11 4:55 PM, Worley, Dale R (Dale) wrote:
> Seeing that I have published a list of the issues that might be
> significant in this discussion
> (http://www.ietf.org/mail-archive/web/dispatch/current/msg03779.html),
> and seeing that no response has been made by *anybody* regarding that
> list, and seeing that the stated opinions on the WG mailing list
> remain at 17 favorable (hailing from at least 15 different
> organizations) and 1 unfavorable...

While there have been a number of parties expressing support for the=20
document, I don't see any that have attempted to allay the concerns that=20
Cullen initially expressed (and which he clarified earlier today).

In particular, I do find the issue of the use of IMSI and/or IMEI-based=20
URNs as a means for whitelist/blacklist control -- where URNs formed by=20
other means may not be compatible -- to be a real and pertinent concern.=20
And the issue of being able to positively correlate, as an ordinary=20
user, that two calls came from the same terminal, raises some stark and=20
valid privacy concerns.

I don't want to minimize Andrew's contribution to this conversation (or=20
yours) -- it's going somewhere but has not yet reached that destination.=20
However, the remainder of the "supporting" parties you cite have largely=20
contributed in this fashion:

Christer: "+1"
Atle: "+1."
Jan: "Also Belgacom would like to see this draft progressed."
Olle: "+1"
Laura: "+1"
Roland: "+1"
Ricky: "I would like to repeat my support for the progressing of this=20
work in IETF."*
Lili: "+1"
Shida: "We support the draft as well."
Itsuma: "NTT DOCOMO also supports this draft moving forward."
Martin: "AT&T supports this draft moving forward"

(I can't find the remaining five voices of support you mention, but I=20
suspect they have similar technical content.)

Certainly you're familiar with David Clark's well-known quote about IETF=20
process: "We reject kings, presidents, and voting."

While it's not irrelevant that there is a broad base of people who would=20
like to see this document published, we do need to keep in mind that=20
"+1" does not make for a valid technical argument or rebuttal. In=20
particular, most WG chairs will justly treat a cascade of=20
unsubstantiated "+1" responses as an attempt at ballot stuffing. For the=20
purposes of calling consensus on a *technical* topic, chairs have an=20
obligation to discount vague statements of support.

I, for one, see substantial merit in at least two of the technical=20
issues that Cullen has raised. I don't think the treatment of privacy or=20
the treatment of compatibility have been sufficiently addressed in the=20
current document.

/a

___
* To be fair, Ricky also cited an earlier email that detailed why 3GPP=20
wants this work to progress; however, it does not address any of the=20
technical concerns that have been subsequently raised.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From aallen@rim.com  Mon Oct 24 15:59:16 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFE821F8C0A for ; Mon, 24 Oct 2011 15:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.377
X-Spam-Level: 
X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M0LF-l3GQxv for ; Mon, 24 Oct 2011 15:59:15 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id BDAFB21F8541 for ; Mon, 24 Oct 2011 15:59:14 -0700 (PDT)
X-AuditID: 0a41282f-b7b96ae00000702f-98-4ea5edc1ebf0
Received: from XHT109CNC.rim.net (xht109cnc.rim.net [10.65.12.218]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 05.F6.28719.1CDE5AE4; Mon, 24 Oct 2011 22:59:13 +0000 (GMT)
Received: from XHT141CNC.rim.net (10.65.22.70) by XHT109CNC.rim.net (10.65.12.218) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 24 Oct 2011 18:59:13 -0400
Received: from XCT103ADS.rim.net (10.67.111.44) by XHT141CNC.rim.net (10.65.22.70) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 24 Oct 2011 18:59:13 -0400
Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.01.0289.001; Mon, 24 Oct 2011 17:59:12 -0500
From: Andrew Allen 
To: "DRAGE, Keith (Keith)" , Cullen Jennings , "Worley, Dale R (Dale)" 
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri	and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMkplwK9cWE1Ok1Um/mLi8u637fJWMGN0Q
Date: Mon, 24 Oct 2011 22:59:11 +0000
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com> 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.70.110.254]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEKsWRmVeSWpSXmKPExsXC5chzS/fg26V+Bgt+6FksnbSA1aJt1xxm i47JbBZPG88yOrB4tD7by+pxcOUcdo8pvzeyeixZ8pMpgCWqgdEmMS8vvySxJFUhJbU42VbJ JzU9MUchoCizLDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksB A9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnpIoGEf9wZpzoeMxf0VFbsOXODpYHxfVwX IyeHhICJxIvvHcwQtpjEhXvr2boYuTiEBHqZJK4tbGKCcJYySqxtP8cK4SxjlGjpbGeHcLYw SrxqnskI0s8moCyx/PcMIJuDQ0Sgj1HiYA5ImFnAQGLVh7ssILawQIbElfef2EBsEYFMieMz e1kgbCOJw4dvgZ3BIqAqcflSHyuIzSvgJvHm8HeoK+aySXy6vg+smVMgTmLN9TXsIDajgKzE 7rPXmSCWiUvcejKfCeIfAYkle85D/SYq8fLxP1aQ2yQEFCVen66DKNeRWLAb4h5mAW2JZQtf M0PsFZQ4OfMJ2G1CAtISO06uYZzAKDkLyYZZSNpnIWmfhaR9ASPLKkbB3IxiAzOD5LxkvaLM XL281JJNjODEpKG/g7Fvr9YhRgEORiUeXpVXS/2EWBPLiitzDzFKcDArifDOswYK8aYkVlal FuXHF5XmpBYfYrQAhtBEZinu5Hxg0swriTc2MEDhKInz8l7K8BMSSAcmt+zU1ILUIphWJg5O qQZGwc0dz1K2XtWNOsourrZgzXM9V8/71TmNNp8NvlW/FXVWNZ2aMG2D0NSg7xNe/Fr1Yt1E 44DFNxlWau63/yRcv/sK22z3xOVbnEpurK/af+ONQPSv9/UF+TE5FUyhd77q/tXKnpgVGqGw zzhtivmG+JdZH+UZL5rzvNN/X3VuYe/6z96vC5+VKrEUZyQaajEXFScCAOK94YplAwAA
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 22:59:16 -0000

Just to add to and correct some of Keith's comments.

> As far as I understand, the use of the IMEI to do this (blacklisting /
> whitelisting) happens on every cellphone already (be it according to 3GPP
> or 3GPP standards (where the IMEI is the MEID).

Should be "according to 3GPP or 3GPP2 standards"

One other correction/clarification is that:

According to 3GPP TS 24.229 the Instance ID is not normally placed in SIP IN=
VITE requests or responses to INVITE for the purposes of telephony calls. Th=
e exception to this is Emergency calls when the Instance ID containing the I=
MEI is placed in the Contact header field of the SIP INVITE request. Other b=
odies (such as OMA for push to talk) may have specified including the instan=
ce ID in SIP INVITE request but (as specified in 3GPP specifications that if=
 this is included this is to be done) the Instance ID is removed by an inter=
mediate server (e.g the PoC Server).

Whitelist/Blacklist checking can be done based on the Instance ID containing=
 the IMEI being included in the SIP REGISTER request (as I have indicated in=
 a previous email)

But basically I agree with the rest of Keith's comments

Andrew

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Monday, October 24, 2011 5:08 PM
> To: Cullen Jennings; Worley, Dale R (Dale)
> Cc: dispatch@ietf.org list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
> 
> Responding on the blacklisting / whitelisting issue.
> 
> As far as I understand, the use of the IMEI to do this (blacklisting /
> whitelisting) happens on every cellphone already (be it according to 3GPP
> or 3GPP standards (where the IMEI is the MEID).
> 
> The degree to which it occurs is as a result of regulatory pressure.
> Essentially the prime requirement is from law enforcement agencies who
> want to identify the use of stolen phones, and prevent those stolen phones
> having value, and from operators who want to prevent stolen phones
> incurring network costs for which they will never be reimbursed. For the
> existing non-IMS cellphones you will find the IMEI or MEID populating many
> messages including those that establish new calls.
> 
> For IMS phones the same IMEI / MEID is present in messages when you obtain
> the data channel, but as far as I understand operators want it in messages
> that get exchanged more frequently, and that means putting it in INVITE
> messages at the SIP layer.
> 
> So in conclusion, the usage in this respect is to lessen the incidence of
> someone coming up behind you, putting a knife in your ribs, and making off
> with your latest model of fancy cellphone. And for non-IMS usage its
> probably been doing that for the last 10 years (depending on when
> operators were pressured by law enforcement agencies to implement the EIR
> (the online database against which EIRs are checked).
> 
> Yes it will stop calls. Does someone whos stolen your phone have the right
> to make calls?
> 
> As regards IMEIs, it is associated with the hardware, not the software.
> The hardware manufacturer applies for them from some designated authority
> ultimately supervised by a joint group of GSMA and TIA/TTA. So you do not
> have the ability to craft your own. I believe the same applies to MAC
> addresses.
> 
> I believe the way it is used in 3GPP the IMEI is not visible to any other
> than the end user who owns the phone and the network. I do not believe it
> is seen by any other user (barring someone of course deliberately
> revealing it).
> 
> While there are various databases around that attempt to correlate IMEI
> values to a particular type of phone, these have all been reverse
> engineered by people plugging in the values in phones they have. You will
> need a sight more privileges to find the equivalent information from the
> official allocation database, and there is no intention to make it any
> more public.
> 
> Regards
> 
> Keith
> 
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> > Behalf Of Cullen Jennings
> > Sent: 24 October 2011 14:37
> > To: Worley, Dale R (Dale)
> > Cc: dispatch@ietf.org list
> > Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> > dispatch-imei-urn-as-instanceid
> >
> >
> > Dale - sent in my role as an individual contributor. (all my emails are
> in
> > my role as an individual contributor unless they are clearly signed as
> > some other role)
> >
> > In the past I have made the mistake of listing all my concerns with this
> > draft then one or two would get discussed for a bit and rest ignored so
> > this time I'm going to try and stick with a few high level ones and some
> > minor ones. We can try to resolve theses a bit then we can move on the
> > others. Lets start with the stuff from your email.
> >
> > Interoperability.
> >
> > I've asked multiple people does this happen in INVITEs or just REGISTERs
> > and got mixed answers. It makes a big difference - at some level this is
> a
> > proposal to black list phones and / or part of a malware prevention
> > systems. Or perhaps it is a proposal to white list phones and ones that
> > don't have this won't work. You can say this going to be restricted to
> > just the sets of people that want to use it but that is seldom how
> > standards work out That might be true in the cases of if it only went
> from
> > a phone to the domain for it's AOR. However, if this will also be used
> in
> > INVITE cases, would it stop calls from any 3GPP phone to non 3GPP phone?
> > Making sure that we did not have needless lack of interoperability
> between
> > classic IETF SIP and 3GPP style SIP has always been a goal. Even if this
> > is only only on IMS phones, theses are now used well outside the mobile
> > environment - we see them used on wireline and enterprise environments
> so
> > would there be a problem from other SIP devices
> >  to theses. Could a soft phone get the required IMEI identifier so it
> was
> > not blacklisted? Could a small vendor get them? These are all things I
> > wonder.
> >
> > It's impossible to answer any of the above questions without knowing
> > something about how this blacklisting stuff works and what this
> identifier
> > is used for. This leads to my first issues. I want a description of how
> > this works so we can decide if there are interoperability problems or
> not.
> > I am constantly told this is important to 3GPP yet I can't find a 3GPP
> > document that even has a reference to this draft or explains how it
> works.
> > So this is my most important question to you -  Do you think this is
> > unreasonable that we should ask how this works and if there are
> > interoperability problems? If this is important to 3GPP, could they
> > provide a pointer to a document that has reference to it and defines how
> > it is used.
> >
> > On a minor notes related to references - I'm not objecting based on
> > process crap around the references but it would be really really nice if
> > the drafts could be updated so that the reference pointed at a specific
> > document - not a vague family of documents where I have no idea if I am
> > reading the right one or not. I never know what to read when I see 3GPP
> > 24.237 but if you gave me a date and version, or even a link, it would
> be
> > easier. A reference should be something where we both know we are
> reading
> > the same document. I realize the 3GPP documents  have some examples that
> > have this identifier in them but I could not find a description of how
> it
> > worked. I'd also like to point out that in 2007 I asked for the pointer
> to
> > the document that explains the GSMA allocation policy as you will
> > eventually need that for IESG approval but the link in the draft is
> still
> > wrong. Yes, I can figure out how to find the right one but is really too
> > much to ask that someone could have fixed this. Ag
> >  ain, none of things in this paragraph matter to me on the big topic of
> > how to proceed but it's hard to put this on top of ones priority list
> when
> > no one can bother to fix stuff that is clearly wrong.
> >
> > So let me be very clear on what I am looking for to start the
> > interoperability discussion. We need to understand the specification for
> > this to decide what interoperability problems there may or may not be.
> My
> > assumptions how how this works may be very wrong. Lets get the facts and
> > make an informed decision.
> >
> >
> > Privacy
> >
> > So what's the position of everyone that has been sending opinions of
> this
> > draft. Is the IMEI of my phone personal identifying information or now?
> > Sort of hard to have a discussion without deciding that first.
> >
> >
> > IPR
> >
> > On the topic of IPR. I think we need to sort out some of the simpler
> > issues first and in the end I will probably rather have the IPR
> discussion
> > on the ietf list than here. To put it pretty bluntly, the IETF list is a
> > more favorable environment for the arguments I will probably make around
> > IPR. It always fascinates me me to see the proponents of this draft
> > sending nasty grams to the chairs telling them do something that process
> > wise they can't do but would effectively move the conversation from the
> > dispatch list to the ietf list while at the same time the ADs and Chairs
> > are trying to resolve the conversation in dispatch first which is
> > typically much less concerned about IPR than the IETF is in general.  I
> > will note that Gonzalo thinks my drafts runs into the Andrews's patents
> > but I have been working on the assumption that it does not as Andrew
> > commented on it and did not file any IPR disclosure or notify the WG.
> >
> >
> > On a finally note, I get the feeling that you think the chairs on not
> > doing something they should. Obviously if there was anything that
> required
> > making a call where the consensus was not obvious or anything I would
> > leave that type of decision to Mary. I am participating in this
> > conversation as one of the individuals in the WG and would leave any
> > complex judgment call to Mary. If you think there is something where my
> > individual opinions are causing the chairs not to do the right things,
> > please, grab a phone and call me about it and we will figure out a way
> > where everyone agrees the chairs are doing the right thing. I'm not a
> fan
> > of the current passive aggressive approach.
> >
> >
> >
> > On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:
> >
> > > Given that the decision to be made in this working group is whether to
> > > assign these I-Ds for further work to be done on them, there are a
> > > small number of questions in play (with assorted other issues to be
> > > addressed during the technical refinement of the proposal):
> > >
> > > 1.  Does this proposal introduce any interoperability problems?
> > > 2.  Does this proposal present any privacy concerns?
> > > 3.  Does this proposal allow anyone to extract an unconscionable
> > >    "tax" (through the use of IPR)?
> > >
> > > Here are my assessments of these issues:
> > >
> > > 1.  Does this proposal introduce any interoperability problems?
> > >
> > > I don't see what interoperability problems can result from the
> > > introduction of an additional format of URN, as long as the format
> > > adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
> > > clear that a SIP element may receive a +sip.instance value which is in
> > > a URN namespace that it does not recognize, so any properly
> > > constructed SIP element should be able to handle +sip.instance values
> > > in namespaces that it does not have prior knowledge of.
> > >
> > > (Certainly, the one product/project that I have detailed knowledge of
> > > has always treated +sip.instance as a string.  Thereon hangs a tale:
> > > If the +sip.instance is a UUID-based URN, and if the UUID is based on
> > > a MAC address, the registrar extracts the MAC address so that the UA
> > > can be addressed through a special URI that encodes its MAC address.
> > > But it turns out that a popular make of UA formats its UUIDs
> > > incorrectly, so that it was not recognized as a MAC-based UUID.  We've
> > > had to add special code to the registrar to recognize this defective
> > > URN format!)
> > >
> > > 2.  Does this proposal present any privacy concerns?
> > >
> > > There would be general privacy concerns if this or any other
> > > +sip.instance value was present in dialog-forming requests or
> > > responses, and so could be seen by the other end of phone calls.  But
> > > as far as I can tell, no UA uses +sip.instance in INVITEs;
> > > +sip.instance values are presented only in REGISTER messages.
> > >
> > > On the other hand, generated GRUU values are given in INVITEs, and the
> > > GRUU can give information about the UA's +sip.instance and the AOR,
> > > even if the GRUU is generated using a secret key.  However, the
> > > problems resulting from this seem to be essentially the same when the
> > > +sip.instance is derived from an IMEI as when it is derived from a MAC
> > > address.
> > >
> > > In regard to registrations, given that the intended scope of
> > > application of the proposal is entirely within paid wireless networks,
> > > there can be no privacy between the UA and its registrar.
> > >
> > > 3.  Does this proposal allow anyone to extract an unconscionable
> > >    "tax" (through the use of IPR)?
> > >
> > > Though this proposal may be encumbered by IPR claims, the only users
> > > who would be *required* to use this URN format are products within the
> > > GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts this
> > > as mandatory-to-implement.  Those users might be subjected to an
> > > unconscionable tax, but the GSM/3GPP/IMS universe has its own
> > > political/economic structure for deciding what licensed technology is
> > > mandatory to implement and what licensing terms are considered
> > > acceptable.  It seems to me that we can justly leave these questions
> > > to GSM/3GPP/IMS.
> > >
> > > There is some concern that the IPR disclosures were filed "late".
> > > However, as the latest IPR disclosure was filed in January 2011, the
> > > working group is now even later, and the objection has expired.
> > >
> > > In summary, I don't see any of these issues as being particularly
> > > problematic.  If I've overlooked an important aspect of this, I would
> > > like to see some detailed information about it.
> > >
> > > Dale
> > > _______________________________________________
> > > dispatch mailing list
> > > dispatch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dispatch
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From HKaplan@acmepacket.com  Mon Oct 24 16:53:23 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91311E81EC for ; Mon, 24 Oct 2011 16:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.429
X-Spam-Level: 
X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2IpL2DGPhLi for ; Mon, 24 Oct 2011 16:53:22 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1C06F11E81D7 for ; Mon, 24 Oct 2011 16:53:22 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 24 Oct 2011 19:53:21 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 19:53:21 -0400
From: Hadriel Kaplan 
To: "dispatch@ietf.org list" 
Thread-Topic: I-D Action: draft-kaplan-dispatch-b2bua-loop-detection-00.txt
Thread-Index: AQHMkqgccfYmwdDkwEKbeedCvb88fw==
Date: Mon, 24 Oct 2011 23:53:20 +0000
Message-ID: <2EA1F0AC-9B14-4E92-A9FD-31C954C804BC@acmepacket.com>
References: <20111024230221.1524.14771.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Subject: [dispatch] Fwd: I-D Action: draft-kaplan-dispatch-b2bua-loop-detection-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 23:53:23 -0000

Howdy,
we submitted an I-D for the proposed STRAW WG's proposed deliverables, for =
the loop-detection deliverable.
We do not plan to present on this in Taiwan, as we hope a STRAW WG type con=
cept will be accepted and such discussions can occur there. :)

-hadriel


Begin forwarded message:

> From: 
> Subject: I-D Action: draft-kaplan-dispatch-b2bua-loop-detection-00.txt
> Date: October 24, 2011 7:02:21 PM EDT
> To: 
> Reply-To: 
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
> 	Title           : Loop Detection Mechanisms for Session Initiation Proto=
col (SIP) Back-to-Back User Agents (B2BUAs)
> 	Author(s)       : Hadriel Kaplan
>                          Victor Pascual
> 	Filename        : draft-kaplan-dispatch-b2bua-loop-detection-00.txt
> 	Pages           : 6
> 	Date            : 2011-10-24
>=20
>   SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request
>   routing loops because, as User Agent Clients, they can generate SIP
>   requests with new Max-Forwards values.  This document discusses the
>   difficulties associated with loop detection for B2BUAs, and
>   requirements for them to prevent infinite loops.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-b2bua-loop-dete=
ction-00.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-kaplan-dispatch-b2bua-loop-detec=
tion-00.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From fluffy@cisco.com  Mon Oct 24 19:59:15 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4AF21F8B21 for ; Mon, 24 Oct 2011 19:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.307
X-Spam-Level: 
X-Spam-Status: No, score=-106.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO2v4JT7tgag for ; Mon, 24 Oct 2011 19:59:14 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE8E21F8B1C for ; Mon, 24 Oct 2011 19:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=17581; q=dns/txt; s=iport; t=1319511554; x=1320721154; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Rj7wO3By4kkirjbiVdy/sT/ecKsMWCayullSMiViI2U=; b=goK4nlYMvmQ2zGfRrK8cWRlflthPP+L6zCAzxOPS1rEMUpeDzUKD/2BR W7XYMuF6O9/9IGg60zcFrNlTjLdhA7TUOADmbnl0Jx4iB9xYHfwuO6IRH FMLs5SazaLi297XMi5zwZuMe1i1pg8mJlf1y7uimfQCjlusCXMJDJpNui A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsEAAP8kpk6rRDoI/2dsb2JhbAA5CplUjH6CQ4EFgW4BAQEBAgEBAQEPASc0CwUHBAsOAwQBAQEnBycfCQgGEyKHXgiWHwGeSASFEYJOYQSIBowDhSyMTg
X-IronPort-AV: E=Sophos;i="4.69,402,1315180800"; d="scan'208";a="10007229"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 25 Oct 2011 02:59:13 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9P2xClm015497; Tue, 25 Oct 2011 02:59:12 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Mon, 24 Oct 2011 20:59:12 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A559464-17CB-436A-AD9A-C1FAAE583B5B@cisco.com>
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se><208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr><234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  
To: Andrew Allen 
X-Mailer: Apple Mail (2.1084)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	 and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 02:59:16 -0000

On Oct 24, 2011, at 4:59 PM, Andrew Allen wrote:

> Just to add to and correct some of Keith's comments.
>=20
> > As far as I understand, the use of the IMEI to do this (blacklisting =
/
> > whitelisting) happens on every cellphone already (be it according to =
3GPP
> > or 3GPP standards (where the IMEI is the MEID).
>=20
> Should be "according to 3GPP or 3GPP2 standards"
>=20
> One other correction/clarification is that:
>=20
> According to 3GPP TS 24.229 the Instance ID is not normally placed in =
SIP INVITE requests or responses to INVITE for the purposes of telephony =
calls.

So I looked at lasted version I could find of this and it actually does =
talk about IMEI. Which version of this is the right one to be reading?


> The exception to this is Emergency calls when the Instance ID =
containing the IMEI is placed in the Contact header field of the SIP =
INVITE request.

I assume it is in emergency call because un registered phones can make =
emergency call ?=20

> Other bodies (such as OMA for push to talk) may have specified =
including the instance ID in SIP INVITE request but (as specified in =
3GPP specifications that if this is included this is to be done) the =
Instance ID is removed by an intermediate server (e.g the PoC Server).
>=20
> Whitelist/Blacklist checking can be done based on the Instance ID =
containing the IMEI being included in the SIP REGISTER request (as I =
have indicated in a previous email)


Writing up the draft to talk about using this in a contact header to say =
when a UA puts it in or not, and when B2BUA & Proxies remove it, would =
really help people understand what the implications are.=20

>=20
> But basically I agree with the rest of Keith's comments
>=20
> Andrew
>=20
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =
On
> > Behalf Of DRAGE, Keith (Keith)
> > Sent: Monday, October 24, 2011 5:08 PM
> > To: Cullen Jennings; Worley, Dale R (Dale)
> > Cc: dispatch@ietf.org list
> > Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and =
draft-allen-
> > dispatch-imei-urn-as-instanceid
> >
> > Responding on the blacklisting / whitelisting issue.
> >
> > As far as I understand, the use of the IMEI to do this (blacklisting =
/
> > whitelisting) happens on every cellphone already (be it according to =
3GPP
> > or 3GPP standards (where the IMEI is the MEID).
> >
> > The degree to which it occurs is as a result of regulatory pressure.
> > Essentially the prime requirement is from law enforcement agencies =
who
> > want to identify the use of stolen phones, and prevent those stolen =
phones
> > having value, and from operators who want to prevent stolen phones
> > incurring network costs for which they will never be reimbursed. For =
the
> > existing non-IMS cellphones you will find the IMEI or MEID =
populating many
> > messages including those that establish new calls.
> >
> > For IMS phones the same IMEI / MEID is present in messages when you =
obtain
> > the data channel, but as far as I understand operators want it in =
messages
> > that get exchanged more frequently, and that means putting it in =
INVITE
> > messages at the SIP layer.
> >
> > So in conclusion, the usage in this respect is to lessen the =
incidence of
> > someone coming up behind you, putting a knife in your ribs, and =
making off
> > with your latest model of fancy cellphone. And for non-IMS usage its
> > probably been doing that for the last 10 years (depending on when
> > operators were pressured by law enforcement agencies to implement =
the EIR
> > (the online database against which EIRs are checked).
> >
> > Yes it will stop calls. Does someone whos stolen your phone have the =
right
> > to make calls?
> >
> > As regards IMEIs, it is associated with the hardware, not the =
software.
> > The hardware manufacturer applies for them from some designated =
authority
> > ultimately supervised by a joint group of GSMA and TIA/TTA. So you =
do not
> > have the ability to craft your own. I believe the same applies to =
MAC
> > addresses.
> >
> > I believe the way it is used in 3GPP the IMEI is not visible to any =
other
> > than the end user who owns the phone and the network. I do not =
believe it
> > is seen by any other user (barring someone of course deliberately
> > revealing it).
> >
> > While there are various databases around that attempt to correlate =
IMEI
> > values to a particular type of phone, these have all been reverse
> > engineered by people plugging in the values in phones they have. You =
will
> > need a sight more privileges to find the equivalent information from =
the
> > official allocation database, and there is no intention to make it =
any
> > more public.
> >
> > Regards
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =
On
> > > Behalf Of Cullen Jennings
> > > Sent: 24 October 2011 14:37
> > > To: Worley, Dale R (Dale)
> > > Cc: dispatch@ietf.org list
> > > Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and =
draft-allen-
> > > dispatch-imei-urn-as-instanceid
> > >
> > >
> > > Dale - sent in my role as an individual contributor. (all my =
emails are
> > in
> > > my role as an individual contributor unless they are clearly =
signed as
> > > some other role)
> > >
> > > In the past I have made the mistake of listing all my concerns =
with this
> > > draft then one or two would get discussed for a bit and rest =
ignored so
> > > this time I'm going to try and stick with a few high level ones =
and some
> > > minor ones. We can try to resolve theses a bit then we can move on =
the
> > > others. Lets start with the stuff from your email.
> > >
> > > Interoperability.
> > >
> > > I've asked multiple people does this happen in INVITEs or just =
REGISTERs
> > > and got mixed answers. It makes a big difference - at some level =
this is
> > a
> > > proposal to black list phones and / or part of a malware =
prevention
> > > systems. Or perhaps it is a proposal to white list phones and ones =
that
> > > don't have this won't work. You can say this going to be =
restricted to
> > > just the sets of people that want to use it but that is seldom how
> > > standards work out That might be true in the cases of if it only =
went
> > from
> > > a phone to the domain for it's AOR. However, if this will also be =
used
> > in
> > > INVITE cases, would it stop calls from any 3GPP phone to non 3GPP =
phone?
> > > Making sure that we did not have needless lack of interoperability
> > between
> > > classic IETF SIP and 3GPP style SIP has always been a goal. Even =
if this
> > > is only only on IMS phones, theses are now used well outside the =
mobile
> > > environment - we see them used on wireline and enterprise =
environments
> > so
> > > would there be a problem from other SIP devices
> > >  to theses. Could a soft phone get the required IMEI identifier so =
it
> > was
> > > not blacklisted? Could a small vendor get them? These are all =
things I
> > > wonder.
> > >
> > > It's impossible to answer any of the above questions without =
knowing
> > > something about how this blacklisting stuff works and what this
> > identifier
> > > is used for. This leads to my first issues. I want a description =
of how
> > > this works so we can decide if there are interoperability problems =
or
> > not.
> > > I am constantly told this is important to 3GPP yet I can't find a =
3GPP
> > > document that even has a reference to this draft or explains how =
it
> > works.
> > > So this is my most important question to you -  Do you think this =
is
> > > unreasonable that we should ask how this works and if there are
> > > interoperability problems? If this is important to 3GPP, could =
they
> > > provide a pointer to a document that has reference to it and =
defines how
> > > it is used.
> > >
> > > On a minor notes related to references - I'm not objecting based =
on
> > > process crap around the references but it would be really really =
nice if
> > > the drafts could be updated so that the reference pointed at a =
specific
> > > document - not a vague family of documents where I have no idea if =
I am
> > > reading the right one or not. I never know what to read when I see =
3GPP
> > > 24.237 but if you gave me a date and version, or even a link, it =
would
> > be
> > > easier. A reference should be something where we both know we are
> > reading
> > > the same document. I realize the 3GPP documents  have some =
examples that
> > > have this identifier in them but I could not find a description of =
how
> > it
> > > worked. I'd also like to point out that in 2007 I asked for the =
pointer
> > to
> > > the document that explains the GSMA allocation policy as you will
> > > eventually need that for IESG approval but the link in the draft =
is
> > still
> > > wrong. Yes, I can figure out how to find the right one but is =
really too
> > > much to ask that someone could have fixed this. Ag
> > >  ain, none of things in this paragraph matter to me on the big =
topic of
> > > how to proceed but it's hard to put this on top of ones priority =
list
> > when
> > > no one can bother to fix stuff that is clearly wrong.
> > >
> > > So let me be very clear on what I am looking for to start the
> > > interoperability discussion. We need to understand the =
specification for
> > > this to decide what interoperability problems there may or may not =
be.
> > My
> > > assumptions how how this works may be very wrong. Lets get the =
facts and
> > > make an informed decision.
> > >
> > >
> > > Privacy
> > >
> > > So what's the position of everyone that has been sending opinions =
of
> > this
> > > draft. Is the IMEI of my phone personal identifying information or =
now?
> > > Sort of hard to have a discussion without deciding that first.
> > >
> > >
> > > IPR
> > >
> > > On the topic of IPR. I think we need to sort out some of the =
simpler
> > > issues first and in the end I will probably rather have the IPR
> > discussion
> > > on the ietf list than here. To put it pretty bluntly, the IETF =
list is a
> > > more favorable environment for the arguments I will probably make =
around
> > > IPR. It always fascinates me me to see the proponents of this =
draft
> > > sending nasty grams to the chairs telling them do something that =
process
> > > wise they can't do but would effectively move the conversation =
from the
> > > dispatch list to the ietf list while at the same time the ADs and =
Chairs
> > > are trying to resolve the conversation in dispatch first which is
> > > typically much less concerned about IPR than the IETF is in =
general.  I
> > > will note that Gonzalo thinks my drafts runs into the Andrews's =
patents
> > > but I have been working on the assumption that it does not as =
Andrew
> > > commented on it and did not file any IPR disclosure or notify the =
WG.
> > >
> > >
> > > On a finally note, I get the feeling that you think the chairs on =
not
> > > doing something they should. Obviously if there was anything that
> > required
> > > making a call where the consensus was not obvious or anything I =
would
> > > leave that type of decision to Mary. I am participating in this
> > > conversation as one of the individuals in the WG and would leave =
any
> > > complex judgment call to Mary. If you think there is something =
where my
> > > individual opinions are causing the chairs not to do the right =
things,
> > > please, grab a phone and call me about it and we will figure out a =
way
> > > where everyone agrees the chairs are doing the right thing. I'm =
not a
> > fan
> > > of the current passive aggressive approach.
> > >
> > >
> > >
> > > On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:
> > >
> > > > Given that the decision to be made in this working group is =
whether to
> > > > assign these I-Ds for further work to be done on them, there are =
a
> > > > small number of questions in play (with assorted other issues to =
be
> > > > addressed during the technical refinement of the proposal):
> > > >
> > > > 1.  Does this proposal introduce any interoperability problems?
> > > > 2.  Does this proposal present any privacy concerns?
> > > > 3.  Does this proposal allow anyone to extract an unconscionable
> > > >    "tax" (through the use of IPR)?
> > > >
> > > > Here are my assessments of these issues:
> > > >
> > > > 1.  Does this proposal introduce any interoperability problems?
> > > >
> > > > I don't see what interoperability problems can result from the
> > > > introduction of an additional format of URN, as long as the =
format
> > > > adheres to the generic URN syntax.  RFC 5626 section 4.1 makes =
it
> > > > clear that a SIP element may receive a +sip.instance value which =
is in
> > > > a URN namespace that it does not recognize, so any properly
> > > > constructed SIP element should be able to handle +sip.instance =
values
> > > > in namespaces that it does not have prior knowledge of.
> > > >
> > > > (Certainly, the one product/project that I have detailed =
knowledge of
> > > > has always treated +sip.instance as a string.  Thereon hangs a =
tale:
> > > > If the +sip.instance is a UUID-based URN, and if the UUID is =
based on
> > > > a MAC address, the registrar extracts the MAC address so that =
the UA
> > > > can be addressed through a special URI that encodes its MAC =
address.
> > > > But it turns out that a popular make of UA formats its UUIDs
> > > > incorrectly, so that it was not recognized as a MAC-based UUID.  =
We've
> > > > had to add special code to the registrar to recognize this =
defective
> > > > URN format!)
> > > >
> > > > 2.  Does this proposal present any privacy concerns?
> > > >
> > > > There would be general privacy concerns if this or any other
> > > > +sip.instance value was present in dialog-forming requests or
> > > > responses, and so could be seen by the other end of phone calls. =
 But
> > > > as far as I can tell, no UA uses +sip.instance in INVITEs;
> > > > +sip.instance values are presented only in REGISTER messages.
> > > >
> > > > On the other hand, generated GRUU values are given in INVITEs, =
and the
> > > > GRUU can give information about the UA's +sip.instance and the =
AOR,
> > > > even if the GRUU is generated using a secret key.  However, the
> > > > problems resulting from this seem to be essentially the same =
when the
> > > > +sip.instance is derived from an IMEI as when it is derived from =
a MAC
> > > > address.
> > > >
> > > > In regard to registrations, given that the intended scope of
> > > > application of the proposal is entirely within paid wireless =
networks,
> > > > there can be no privacy between the UA and its registrar.
> > > >
> > > > 3.  Does this proposal allow anyone to extract an unconscionable
> > > >    "tax" (through the use of IPR)?
> > > >
> > > > Though this proposal may be encumbered by IPR claims, the only =
users
> > > > who would be *required* to use this URN format are products =
within the
> > > > GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS =
adopts this
> > > > as mandatory-to-implement.  Those users might be subjected to an
> > > > unconscionable tax, but the GSM/3GPP/IMS universe has its own
> > > > political/economic structure for deciding what licensed =
technology is
> > > > mandatory to implement and what licensing terms are considered
> > > > acceptable.  It seems to me that we can justly leave these =
questions
> > > > to GSM/3GPP/IMS.
> > > >
> > > > There is some concern that the IPR disclosures were filed =
"late".
> > > > However, as the latest IPR disclosure was filed in January 2011, =
the
> > > > working group is now even later, and the objection has expired.
> > > >
> > > > In summary, I don't see any of these issues as being =
particularly
> > > > problematic.  If I've overlooked an important aspect of this, I =
would
> > > > like to see some detailed information about it.
> > > >
> > > > Dale
> > > > _______________________________________________
> > > > dispatch mailing list
> > > > dispatch@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/dispatch
> > >
> > > _______________________________________________
> > > dispatch mailing list
> > > dispatch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>=20
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential =
information, privileged material (including material protected by the =
solicitor-client or other applicable privileges), or constitute =
non-public information. Any use of this information by anyone other than =
the intended recipient is prohibited. If you have received this =
transmission in error, please immediately reply to the sender and delete =
this information from your system. Use, dissemination, distribution, or =
reproduction of this transmission by unintended recipients is not =
authorized and may be unlawful.
>=20


From fluffy@cisco.com  Mon Oct 24 20:25:00 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C6B11E80F6 for ; Mon, 24 Oct 2011 20:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.317
X-Spam-Level: 
X-Spam-Status: No, score=-106.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa4xb1xHiUXR for ; Mon, 24 Oct 2011 20:24:58 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3511E80E5 for ; Mon, 24 Oct 2011 20:24:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=13958; q=dns/txt; s=iport; t=1319513098; x=1320722698; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=v1w3Qq6+Fx+G57rdMd9RCHKVv2ZRj0X72r5Dh6cIaSo=; b=J6YeU69/J8NqW6glXBFp7snOThU6+kHU+1SV3Pcv2ktKrs3V82wfrTsI ZylyRd+jxCDSfyCC1GPwMuER0Jxi4pepLONgD7NphjLKMeZiLuB5fOsie uhQZrpt2yF7dw4dD5OZmgoHuucfsy9IYAuZ5uIC5PfnxCj1roci00GMEd k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAGsrpk6rRDoI/2dsb2JhbAA5CqZSgkOBBYFuAQEBAQIBAQEBDwEnNAsFBwQLEQQBAQEnBycfCQgGEyKHXgiWFQGeRgSFEYJOYQSIBowDhSyMTg
X-IronPort-AV: E=Sophos;i="4.69,402,1315180800";  d="scan'208";a="9991225"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 25 Oct 2011 03:24:58 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9P3Ov9g027072; Tue, 25 Oct 2011 03:24:57 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Mon, 24 Oct 2011 21:24:57 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <796A71F1-B0AE-4858-9D8C-8BDAA21DF554@cisco.com>
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com> 
To: "DRAGE, Keith (Keith)" 
X-Mailer: Apple Mail (2.1084)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 03:25:00 -0000

Thanks Keith - that is good information.

On Oct 24, 2011, at 4:07 PM, DRAGE, Keith (Keith) wrote:

> Responding on the blacklisting / whitelisting issue.
>=20
> As far as I understand, the use of the IMEI to do this (blacklisting / =
whitelisting) happens on every cellphone already (be it according to =
3GPP or 3GPP standards (where the IMEI is the MEID).=20
>=20
> The degree to which it occurs is as a result of regulatory pressure. =
Essentially the prime requirement is from law enforcement agencies who =
want to identify the use of stolen phones, and prevent those stolen =
phones having value, and from operators who want to prevent stolen =
phones incurring network costs for which they will never be reimbursed. =
For the existing non-IMS cellphones you will find the IMEI or MEID =
populating many messages including those that establish new calls.
>=20
> For IMS phones the same IMEI / MEID is present in messages when you =
obtain the data channel, but as far as I understand operators want it in =
messages that get exchanged more frequently, and that means putting it =
in INVITE messages at the SIP layer.
>=20
> So in conclusion, the usage in this respect is to lessen the incidence =
of someone coming up behind you, putting a knife in your ribs, and =
making off with your latest model of fancy cellphone. And for non-IMS =
usage its probably been doing that for the last 10 years (depending on =
when operators were pressured by law enforcement agencies to implement =
the EIR (the online database against which EIRs are checked).

So for phones that are an expensive mobile + a cheap sim card, it seems =
like an identifier attached to the expensive part not the cheap part =
would work best. Thoughts?

>=20
> Yes it will stop calls. Does someone whos stolen your phone have the =
right to make calls?
>=20
> As regards IMEIs, it is associated with the hardware, not the =
software. The hardware manufacturer applies for them from some =
designated authority ultimately supervised by a joint group of GSMA and =
TIA/TTA. So you do not have the ability to craft your own. I believe the =
same applies to MAC addresses.
>=20
> I believe the way it is used in 3GPP the IMEI is not visible to any =
other than the end user who owns the phone and the network. I do not =
believe it is seen by any other user (barring someone of course =
deliberately revealing it).
>=20
> While there are various databases around that attempt to correlate =
IMEI values to a particular type of phone, these have all been reverse =
engineered by people plugging in the values in phones they have. You =
will need a sight more privileges to find the equivalent information =
from the official allocation database, and there is no intention to make =
it any more public.
>=20
> Regards
>=20
> Keith
>=20
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
>> Behalf Of Cullen Jennings
>> Sent: 24 October 2011 14:37
>> To: Worley, Dale R (Dale)
>> Cc: dispatch@ietf.org list
>> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and =
draft-allen-
>> dispatch-imei-urn-as-instanceid
>>=20
>>=20
>> Dale - sent in my role as an individual contributor. (all my emails =
are in
>> my role as an individual contributor unless they are clearly signed =
as
>> some other role)
>>=20
>> In the past I have made the mistake of listing all my concerns with =
this
>> draft then one or two would get discussed for a bit and rest ignored =
so
>> this time I'm going to try and stick with a few high level ones and =
some
>> minor ones. We can try to resolve theses a bit then we can move on =
the
>> others. Lets start with the stuff from your email.
>>=20
>> Interoperability.
>>=20
>> I've asked multiple people does this happen in INVITEs or just =
REGISTERs
>> and got mixed answers. It makes a big difference - at some level this =
is a
>> proposal to black list phones and / or part of a malware prevention
>> systems. Or perhaps it is a proposal to white list phones and ones =
that
>> don't have this won't work. You can say this going to be restricted =
to
>> just the sets of people that want to use it but that is seldom how
>> standards work out That might be true in the cases of if it only went =
from
>> a phone to the domain for it's AOR. However, if this will also be =
used in
>> INVITE cases, would it stop calls from any 3GPP phone to non 3GPP =
phone?
>> Making sure that we did not have needless lack of interoperability =
between
>> classic IETF SIP and 3GPP style SIP has always been a goal. Even if =
this
>> is only only on IMS phones, theses are now used well outside the =
mobile
>> environment - we see them used on wireline and enterprise =
environments so
>> would there be a problem from other SIP devices
>> to theses. Could a soft phone get the required IMEI identifier so it =
was
>> not blacklisted? Could a small vendor get them? These are all things =
I
>> wonder.
>>=20
>> It's impossible to answer any of the above questions without knowing
>> something about how this blacklisting stuff works and what this =
identifier
>> is used for. This leads to my first issues. I want a description of =
how
>> this works so we can decide if there are interoperability problems or =
not.
>> I am constantly told this is important to 3GPP yet I can't find a =
3GPP
>> document that even has a reference to this draft or explains how it =
works.
>> So this is my most important question to you -  Do you think this is
>> unreasonable that we should ask how this works and if there are
>> interoperability problems? If this is important to 3GPP, could they
>> provide a pointer to a document that has reference to it and defines =
how
>> it is used.
>>=20
>> On a minor notes related to references - I'm not objecting based on
>> process crap around the references but it would be really really nice =
if
>> the drafts could be updated so that the reference pointed at a =
specific
>> document - not a vague family of documents where I have no idea if I =
am
>> reading the right one or not. I never know what to read when I see =
3GPP
>> 24.237 but if you gave me a date and version, or even a link, it =
would be
>> easier. A reference should be something where we both know we are =
reading
>> the same document. I realize the 3GPP documents  have some examples =
that
>> have this identifier in them but I could not find a description of =
how it
>> worked. I'd also like to point out that in 2007 I asked for the =
pointer to
>> the document that explains the GSMA allocation policy as you will
>> eventually need that for IESG approval but the link in the draft is =
still
>> wrong. Yes, I can figure out how to find the right one but is really =
too
>> much to ask that someone could have fixed this. Ag
>> ain, none of things in this paragraph matter to me on the big topic =
of
>> how to proceed but it's hard to put this on top of ones priority list =
when
>> no one can bother to fix stuff that is clearly wrong.
>>=20
>> So let me be very clear on what I am looking for to start the
>> interoperability discussion. We need to understand the specification =
for
>> this to decide what interoperability problems there may or may not =
be. My
>> assumptions how how this works may be very wrong. Lets get the facts =
and
>> make an informed decision.
>>=20
>>=20
>> Privacy
>>=20
>> So what's the position of everyone that has been sending opinions of =
this
>> draft. Is the IMEI of my phone personal identifying information or =
now?
>> Sort of hard to have a discussion without deciding that first.
>>=20
>>=20
>> IPR
>>=20
>> On the topic of IPR. I think we need to sort out some of the simpler
>> issues first and in the end I will probably rather have the IPR =
discussion
>> on the ietf list than here. To put it pretty bluntly, the IETF list =
is a
>> more favorable environment for the arguments I will probably make =
around
>> IPR. It always fascinates me me to see the proponents of this draft
>> sending nasty grams to the chairs telling them do something that =
process
>> wise they can't do but would effectively move the conversation from =
the
>> dispatch list to the ietf list while at the same time the ADs and =
Chairs
>> are trying to resolve the conversation in dispatch first which is
>> typically much less concerned about IPR than the IETF is in general.  =
I
>> will note that Gonzalo thinks my drafts runs into the Andrews's =
patents
>> but I have been working on the assumption that it does not as Andrew
>> commented on it and did not file any IPR disclosure or notify the WG.
>>=20
>>=20
>> On a finally note, I get the feeling that you think the chairs on not
>> doing something they should. Obviously if there was anything that =
required
>> making a call where the consensus was not obvious or anything I would
>> leave that type of decision to Mary. I am participating in this
>> conversation as one of the individuals in the WG and would leave any
>> complex judgment call to Mary. If you think there is something where =
my
>> individual opinions are causing the chairs not to do the right =
things,
>> please, grab a phone and call me about it and we will figure out a =
way
>> where everyone agrees the chairs are doing the right thing. I'm not a =
fan
>> of the current passive aggressive approach.
>>=20
>>=20
>>=20
>> On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:
>>=20
>>> Given that the decision to be made in this working group is whether =
to
>>> assign these I-Ds for further work to be done on them, there are a
>>> small number of questions in play (with assorted other issues to be
>>> addressed during the technical refinement of the proposal):
>>>=20
>>> 1.  Does this proposal introduce any interoperability problems?
>>> 2.  Does this proposal present any privacy concerns?
>>> 3.  Does this proposal allow anyone to extract an unconscionable
>>>   "tax" (through the use of IPR)?
>>>=20
>>> Here are my assessments of these issues:
>>>=20
>>> 1.  Does this proposal introduce any interoperability problems?
>>>=20
>>> I don't see what interoperability problems can result from the
>>> introduction of an additional format of URN, as long as the format
>>> adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
>>> clear that a SIP element may receive a +sip.instance value which is =
in
>>> a URN namespace that it does not recognize, so any properly
>>> constructed SIP element should be able to handle +sip.instance =
values
>>> in namespaces that it does not have prior knowledge of.
>>>=20
>>> (Certainly, the one product/project that I have detailed knowledge =
of
>>> has always treated +sip.instance as a string.  Thereon hangs a tale:
>>> If the +sip.instance is a UUID-based URN, and if the UUID is based =
on
>>> a MAC address, the registrar extracts the MAC address so that the UA
>>> can be addressed through a special URI that encodes its MAC address.
>>> But it turns out that a popular make of UA formats its UUIDs
>>> incorrectly, so that it was not recognized as a MAC-based UUID.  =
We've
>>> had to add special code to the registrar to recognize this defective
>>> URN format!)
>>>=20
>>> 2.  Does this proposal present any privacy concerns?
>>>=20
>>> There would be general privacy concerns if this or any other
>>> +sip.instance value was present in dialog-forming requests or
>>> responses, and so could be seen by the other end of phone calls.  =
But
>>> as far as I can tell, no UA uses +sip.instance in INVITEs;
>>> +sip.instance values are presented only in REGISTER messages.
>>>=20
>>> On the other hand, generated GRUU values are given in INVITEs, and =
the
>>> GRUU can give information about the UA's +sip.instance and the AOR,
>>> even if the GRUU is generated using a secret key.  However, the
>>> problems resulting from this seem to be essentially the same when =
the
>>> +sip.instance is derived from an IMEI as when it is derived from a =
MAC
>>> address.
>>>=20
>>> In regard to registrations, given that the intended scope of
>>> application of the proposal is entirely within paid wireless =
networks,
>>> there can be no privacy between the UA and its registrar.
>>>=20
>>> 3.  Does this proposal allow anyone to extract an unconscionable
>>>   "tax" (through the use of IPR)?
>>>=20
>>> Though this proposal may be encumbered by IPR claims, the only users
>>> who would be *required* to use this URN format are products within =
the
>>> GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts =
this
>>> as mandatory-to-implement.  Those users might be subjected to an
>>> unconscionable tax, but the GSM/3GPP/IMS universe has its own
>>> political/economic structure for deciding what licensed technology =
is
>>> mandatory to implement and what licensing terms are considered
>>> acceptable.  It seems to me that we can justly leave these questions
>>> to GSM/3GPP/IMS.
>>>=20
>>> There is some concern that the IPR disclosures were filed "late".
>>> However, as the latest IPR disclosure was filed in January 2011, the
>>> working group is now even later, and the objection has expired.
>>>=20
>>> In summary, I don't see any of these issues as being particularly
>>> problematic.  If I've overlooked an important aspect of this, I =
would
>>> like to see some detailed information about it.
>>>=20
>>> Dale
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch


From fluffy@cisco.com  Mon Oct 24 21:20:24 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA7711E80DD for ; Mon, 24 Oct 2011 21:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.327
X-Spam-Level: 
X-Spam-Status: No, score=-106.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVg86q9JPRZ1 for ; Mon, 24 Oct 2011 21:20:21 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E398411E80D8 for ; Mon, 24 Oct 2011 21:20:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=661; q=dns/txt; s=iport; t=1319516422; x=1320726022; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NkLcdPkRUQ4QhWYMMujsWm6eWaJCgKsQN75M0haPwkU=; b=cfefwttEZu8vMiKywFKrqHCOsFnBnherqAC6KDu46Fp7h10Lu6emOlfp v91JwBnWuEegqK8gmv/FW/XjEUggNDmbLZomT95DBW/VXNRJNCP+EHrYT 9KfqK93t1LKICy9bpt/JFbbRzA1mfk4hlDxuE1KBlByoU2erNtk9LsOxm E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHY4pk6rRDoJ/2dsb2JhbABDqRaBBYFuAQEBAQIBEgEnPxALRlcGNYdelhsBnkqHYmEEiAaMA4UsjFA
X-IronPort-AV: E=Sophos;i="4.69,402,1315180800";  d="scan'208";a="9999536"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 25 Oct 2011 04:20:21 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9P4KLkT009438; Tue, 25 Oct 2011 04:20:21 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: 
Date: Mon, 24 Oct 2011 22:20:20 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E365A77-EC32-497A-95E5-BDBA3DC87ED4@cisco.com>
References:  <4EA5C42A.7030707@nostrum.com> 
To: "DOLLY, MARTIN C" 
X-Mailer: Apple Mail (2.1084)
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn	anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 04:20:24 -0000

On Oct 24, 2011, at 4:16 PM, DOLLY, MARTIN C wrote:

>=20
> The draft meets AT&T's business needs. (period)

Martin, it would be helpful if you could say a bit about what the needs =
are. Did Keith get it about right on the problem is stopping phones =
calls from stolen phones? If a phone has been reported stolen, and =
someone makes an emergency call on it, should that call be delivered or =
stopped? Whats your view on that. If people want to engage on this stuff =
I'm sure you can get to consensus - I very well may be in the rough on =
that consensus but you have something that people could make an informed =
decision about if.=20
=20


From HKaplan@acmepacket.com  Tue Oct 25 00:36:09 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30921F8AA8 for ; Tue, 25 Oct 2011 00:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWB7jrOsRSdv for ; Tue, 25 Oct 2011 00:36:09 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id C4BD621F8A7E for ; Tue, 25 Oct 2011 00:36:08 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 Oct 2011 03:36:05 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 25 Oct 2011 03:36:05 -0400
From: Hadriel Kaplan 
To: Cullen Jennings 
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMkujAbh5wFT7Ot0OapBvdROpRYA==
Date: Tue, 25 Oct 2011 07:36:04 +0000
Message-ID: <23BE5996-FCA3-4A24-BC59-779FAC5D7E2C@acmepacket.com>
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <796A71F1-B0AE-4858-9D8C-8BDAA21DF554@cisco.com>
In-Reply-To: <796A71F1-B0AE-4858-9D8C-8BDAA21DF554@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3377FA9073F0174BBB63ECA6AED365A9@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 07:36:09 -0000

On Oct 24, 2011, at 11:24 PM, Cullen Jennings wrote:

>> So in conclusion, the usage in this respect is to lessen the incidence o=
f someone coming up behind you, putting a knife in your ribs, and making of=
f with your latest model of fancy cellphone. And for non-IMS usage its prob=
ably been doing that for the last 10 years (depending on when operators wer=
e pressured by law enforcement agencies to implement the EIR (the online da=
tabase against which EIRs are checked).
>=20
> So for phones that are an expensive mobile + a cheap sim card, it seems l=
ike an identifier attached to the expensive part not the cheap part would w=
ork best. Thoughts?

The IMEI *is* attached to the expensive part.  It's not in the SIM - it's i=
n the phone.  If you have a GSM phone, you can probably see it on a sticker=
 under the battery, and its stuck to your phone not SIM.  Some have more th=
an one I think, because it's technically tied to the wireless transceiver s=
o I think dual-band phones have two.  But either way it represents your pho=
ne hardware, not your user identity, afaik.  It's a lot like a MAC address,=
 except you're not supposed to be able to change the IMEI.

And yes it really was created to detect stolen phones.  I don't know if sto=
len phones are allowed to make emergency calls (and that would be nationall=
y-specific regulation anyway); but in many countries un-registered phones a=
re allowed to make emergency calls, so in that case they won't get a SIP RE=
GISTER to indicate the IMEI, ergo they need it in an INVITE.

-hadriel


From keith.drage@alcatel-lucent.com  Tue Oct 25 03:00:31 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91921F8B74 for ; Tue, 25 Oct 2011 03:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.017
X-Spam-Level: 
X-Spam-Status: No, score=-106.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9-RhNmDMsA6 for ; Tue, 25 Oct 2011 03:00:29 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6C05F21F8B2B for ; Tue, 25 Oct 2011 03:00:29 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9P9xp99012940 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2011 12:00:21 +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 Oct 2011 11:59:56 +0200
From: "DRAGE, Keith (Keith)" 
To: Cullen Jennings 
Date: Tue, 25 Oct 2011 11:59:52 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySxa8zfH4DkEtTT96XegkERj11lQANG3pw
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <796A71F1-B0AE-4858-9D8C-8BDAA21DF554@cisco.com>
In-Reply-To: <796A71F1-B0AE-4858-9D8C-8BDAA21DF554@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 10:00:31 -0000

There still seems to be some confusion here so just to clarify.

The IMEI (or MEID) is an integral part of the hardware of a cellphone. You =
cannot buy one without at least the encoding for it, and in many, if not mo=
st, jurisdictions, you will not be able to use phone without one. There are=
 still phones being sold in some countries that have fraudulent IMEIs. The =
main example is India, where such phones are increasingly being rendered in=
operable by the operators based on regulatory and peer operator pressure. E=
I in both acronyms stands for equipment identifier. The phone is manufactur=
ed with its own unique value, and the phone manufacturer goes to the admini=
stration body and gets a set of unique values for the phones it is manufact=
uring.

This is the identifier we are talking about being used in an instance ID ge=
nerated by a cellphone.

When you go to an operator and buy a subscription to cellphone service, you=
 will get a UICC (in earlier 3GPP releases known as a SIM card, and in 3GPP=
2 known as a R-UIM, and in many earlier 3GPP2 phones some logical space in =
the phone memory with only the operator has access to).

There is an identity associated with this subscription, but that is called =
an IMSI. That identity may also be mapped into identities used at IMS (SIP)=
 level, where it is known as the private user identity and public user iden=
tity, or the operator can assign other unique values to represent these. Th=
is is the value(s) that is stored on the UICC. These values appear in vario=
us header fields such as the From, P-Preferred, and as a parameter in Autho=
rization.

An IMEI is not stored on the UICC.

So in conclusion, the IMEI is tied to the expensive part, i.e. the cellphon=
e, not to the cheap part, the UICC.

Regards

Keith



> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: 25 October 2011 04:25
> To: DRAGE, Keith (Keith)
> Cc: Worley, Dale R (Dale); dispatch@ietf.org list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
>
>
> Thanks Keith - that is good information.
>
> On Oct 24, 2011, at 4:07 PM, DRAGE, Keith (Keith) wrote:
>
> > Responding on the blacklisting / whitelisting issue.
> >
> > As far as I understand, the use of the IMEI to do this (blacklisting /
> whitelisting) happens on every cellphone already (be it according to 3GPP
> or 3GPP standards (where the IMEI is the MEID).
> >
> > The degree to which it occurs is as a result of regulatory pressure.
> Essentially the prime requirement is from law enforcement agencies who
> want to identify the use of stolen phones, and prevent those stolen phone=
s
> having value, and from operators who want to prevent stolen phones
> incurring network costs for which they will never be reimbursed. For the
> existing non-IMS cellphones you will find the IMEI or MEID populating man=
y
> messages including those that establish new calls.
> >
> > For IMS phones the same IMEI / MEID is present in messages when you
> obtain the data channel, but as far as I understand operators want it in
> messages that get exchanged more frequently, and that means putting it in
> INVITE messages at the SIP layer.
> >
> > So in conclusion, the usage in this respect is to lessen the incidence
> of someone coming up behind you, putting a knife in your ribs, and making
> off with your latest model of fancy cellphone. And for non-IMS usage its
> probably been doing that for the last 10 years (depending on when
> operators were pressured by law enforcement agencies to implement the EIR
> (the online database against which EIRs are checked).
>
> So for phones that are an expensive mobile + a cheap sim card, it seems
> like an identifier attached to the expensive part not the cheap part woul=
d
> work best. Thoughts?
>
> >
> > Yes it will stop calls. Does someone whos stolen your phone have the
> right to make calls?
> >
> > As regards IMEIs, it is associated with the hardware, not the software.
> The hardware manufacturer applies for them from some designated authority
> ultimately supervised by a joint group of GSMA and TIA/TTA. So you do not
> have the ability to craft your own. I believe the same applies to MAC
> addresses.
> >
> > I believe the way it is used in 3GPP the IMEI is not visible to any
> other than the end user who owns the phone and the network. I do not
> believe it is seen by any other user (barring someone of course
> deliberately revealing it).
> >
> > While there are various databases around that attempt to correlate IMEI
> values to a particular type of phone, these have all been reverse
> engineered by people plugging in the values in phones they have. You will
> need a sight more privileges to find the equivalent information from the
> official allocation database, and there is no intention to make it any
> more public.
> >
> > Regards
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> >> Behalf Of Cullen Jennings
> >> Sent: 24 October 2011 14:37
> >> To: Worley, Dale R (Dale)
> >> Cc: dispatch@ietf.org list
> >> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen=
-
> >> dispatch-imei-urn-as-instanceid
> >>
> >>
> >> Dale - sent in my role as an individual contributor. (all my emails ar=
e
> in
> >> my role as an individual contributor unless they are clearly signed as
> >> some other role)
> >>
> >> In the past I have made the mistake of listing all my concerns with
> this
> >> draft then one or two would get discussed for a bit and rest ignored s=
o
> >> this time I'm going to try and stick with a few high level ones and
> some
> >> minor ones. We can try to resolve theses a bit then we can move on the
> >> others. Lets start with the stuff from your email.
> >>
> >> Interoperability.
> >>
> >> I've asked multiple people does this happen in INVITEs or just
> REGISTERs
> >> and got mixed answers. It makes a big difference - at some level this
> is a
> >> proposal to black list phones and / or part of a malware prevention
> >> systems. Or perhaps it is a proposal to white list phones and ones tha=
t
> >> don't have this won't work. You can say this going to be restricted to
> >> just the sets of people that want to use it but that is seldom how
> >> standards work out That might be true in the cases of if it only went
> from
> >> a phone to the domain for it's AOR. However, if this will also be used
> in
> >> INVITE cases, would it stop calls from any 3GPP phone to non 3GPP
> phone?
> >> Making sure that we did not have needless lack of interoperability
> between
> >> classic IETF SIP and 3GPP style SIP has always been a goal. Even if
> this
> >> is only only on IMS phones, theses are now used well outside the mobil=
e
> >> environment - we see them used on wireline and enterprise environments
> so
> >> would there be a problem from other SIP devices
> >> to theses. Could a soft phone get the required IMEI identifier so it
> was
> >> not blacklisted? Could a small vendor get them? These are all things I
> >> wonder.
> >>
> >> It's impossible to answer any of the above questions without knowing
> >> something about how this blacklisting stuff works and what this
> identifier
> >> is used for. This leads to my first issues. I want a description of ho=
w
> >> this works so we can decide if there are interoperability problems or
> not.
> >> I am constantly told this is important to 3GPP yet I can't find a 3GPP
> >> document that even has a reference to this draft or explains how it
> works.
> >> So this is my most important question to you -  Do you think this is
> >> unreasonable that we should ask how this works and if there are
> >> interoperability problems? If this is important to 3GPP, could they
> >> provide a pointer to a document that has reference to it and defines
> how
> >> it is used.
> >>
> >> On a minor notes related to references - I'm not objecting based on
> >> process crap around the references but it would be really really nice
> if
> >> the drafts could be updated so that the reference pointed at a specifi=
c
> >> document - not a vague family of documents where I have no idea if I a=
m
> >> reading the right one or not. I never know what to read when I see 3GP=
P
> >> 24.237 but if you gave me a date and version, or even a link, it would
> be
> >> easier. A reference should be something where we both know we are
> reading
> >> the same document. I realize the 3GPP documents  have some examples
> that
> >> have this identifier in them but I could not find a description of how
> it
> >> worked. I'd also like to point out that in 2007 I asked for the pointe=
r
> to
> >> the document that explains the GSMA allocation policy as you will
> >> eventually need that for IESG approval but the link in the draft is
> still
> >> wrong. Yes, I can figure out how to find the right one but is really
> too
> >> much to ask that someone could have fixed this. Ag
> >> ain, none of things in this paragraph matter to me on the big topic of
> >> how to proceed but it's hard to put this on top of ones priority list
> when
> >> no one can bother to fix stuff that is clearly wrong.
> >>
> >> So let me be very clear on what I am looking for to start the
> >> interoperability discussion. We need to understand the specification
> for
> >> this to decide what interoperability problems there may or may not be.
> My
> >> assumptions how how this works may be very wrong. Lets get the facts
> and
> >> make an informed decision.
> >>
> >>
> >> Privacy
> >>
> >> So what's the position of everyone that has been sending opinions of
> this
> >> draft. Is the IMEI of my phone personal identifying information or now=
?
> >> Sort of hard to have a discussion without deciding that first.
> >>
> >>
> >> IPR
> >>
> >> On the topic of IPR. I think we need to sort out some of the simpler
> >> issues first and in the end I will probably rather have the IPR
> discussion
> >> on the ietf list than here. To put it pretty bluntly, the IETF list is
> a
> >> more favorable environment for the arguments I will probably make
> around
> >> IPR. It always fascinates me me to see the proponents of this draft
> >> sending nasty grams to the chairs telling them do something that
> process
> >> wise they can't do but would effectively move the conversation from th=
e
> >> dispatch list to the ietf list while at the same time the ADs and
> Chairs
> >> are trying to resolve the conversation in dispatch first which is
> >> typically much less concerned about IPR than the IETF is in general.  =
I
> >> will note that Gonzalo thinks my drafts runs into the Andrews's patent=
s
> >> but I have been working on the assumption that it does not as Andrew
> >> commented on it and did not file any IPR disclosure or notify the WG.
> >>
> >>
> >> On a finally note, I get the feeling that you think the chairs on not
> >> doing something they should. Obviously if there was anything that
> required
> >> making a call where the consensus was not obvious or anything I would
> >> leave that type of decision to Mary. I am participating in this
> >> conversation as one of the individuals in the WG and would leave any
> >> complex judgment call to Mary. If you think there is something where m=
y
> >> individual opinions are causing the chairs not to do the right things,
> >> please, grab a phone and call me about it and we will figure out a way
> >> where everyone agrees the chairs are doing the right thing. I'm not a
> fan
> >> of the current passive aggressive approach.
> >>
> >>
> >>
> >> On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:
> >>
> >>> Given that the decision to be made in this working group is whether t=
o
> >>> assign these I-Ds for further work to be done on them, there are a
> >>> small number of questions in play (with assorted other issues to be
> >>> addressed during the technical refinement of the proposal):
> >>>
> >>> 1.  Does this proposal introduce any interoperability problems?
> >>> 2.  Does this proposal present any privacy concerns?
> >>> 3.  Does this proposal allow anyone to extract an unconscionable
> >>>   "tax" (through the use of IPR)?
> >>>
> >>> Here are my assessments of these issues:
> >>>
> >>> 1.  Does this proposal introduce any interoperability problems?
> >>>
> >>> I don't see what interoperability problems can result from the
> >>> introduction of an additional format of URN, as long as the format
> >>> adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
> >>> clear that a SIP element may receive a +sip.instance value which is i=
n
> >>> a URN namespace that it does not recognize, so any properly
> >>> constructed SIP element should be able to handle +sip.instance values
> >>> in namespaces that it does not have prior knowledge of.
> >>>
> >>> (Certainly, the one product/project that I have detailed knowledge of
> >>> has always treated +sip.instance as a string.  Thereon hangs a tale:
> >>> If the +sip.instance is a UUID-based URN, and if the UUID is based on
> >>> a MAC address, the registrar extracts the MAC address so that the UA
> >>> can be addressed through a special URI that encodes its MAC address.
> >>> But it turns out that a popular make of UA formats its UUIDs
> >>> incorrectly, so that it was not recognized as a MAC-based UUID.  We'v=
e
> >>> had to add special code to the registrar to recognize this defective
> >>> URN format!)
> >>>
> >>> 2.  Does this proposal present any privacy concerns?
> >>>
> >>> There would be general privacy concerns if this or any other
> >>> +sip.instance value was present in dialog-forming requests or
> >>> responses, and so could be seen by the other end of phone calls.  But
> >>> as far as I can tell, no UA uses +sip.instance in INVITEs;
> >>> +sip.instance values are presented only in REGISTER messages.
> >>>
> >>> On the other hand, generated GRUU values are given in INVITEs, and th=
e
> >>> GRUU can give information about the UA's +sip.instance and the AOR,
> >>> even if the GRUU is generated using a secret key.  However, the
> >>> problems resulting from this seem to be essentially the same when the
> >>> +sip.instance is derived from an IMEI as when it is derived from a MA=
C
> >>> address.
> >>>
> >>> In regard to registrations, given that the intended scope of
> >>> application of the proposal is entirely within paid wireless networks=
,
> >>> there can be no privacy between the UA and its registrar.
> >>>
> >>> 3.  Does this proposal allow anyone to extract an unconscionable
> >>>   "tax" (through the use of IPR)?
> >>>
> >>> Though this proposal may be encumbered by IPR claims, the only users
> >>> who would be *required* to use this URN format are products within th=
e
> >>> GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts thi=
s
> >>> as mandatory-to-implement.  Those users might be subjected to an
> >>> unconscionable tax, but the GSM/3GPP/IMS universe has its own
> >>> political/economic structure for deciding what licensed technology is
> >>> mandatory to implement and what licensing terms are considered
> >>> acceptable.  It seems to me that we can justly leave these questions
> >>> to GSM/3GPP/IMS.
> >>>
> >>> There is some concern that the IPR disclosures were filed "late".
> >>> However, as the latest IPR disclosure was filed in January 2011, the
> >>> working group is now even later, and the objection has expired.
> >>>
> >>> In summary, I don't see any of these issues as being particularly
> >>> problematic.  If I've overlooked an important aspect of this, I would
> >>> like to see some detailed information about it.
> >>>
> >>> Dale
> >>> _______________________________________________
> >>> dispatch mailing list
> >>> dispatch@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dispatch
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch


From keith.drage@alcatel-lucent.com  Tue Oct 25 03:09:00 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7F721F8BAE for ; Tue, 25 Oct 2011 03:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.036
X-Spam-Level: 
X-Spam-Status: No, score=-106.036 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsQ3YV4kS1Ba for ; Tue, 25 Oct 2011 03:08:59 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 498B221F8BEB for ; Tue, 25 Oct 2011 03:08:59 -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 p9PA8feC020146 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2011 12:08:48 +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 Oct 2011 12:08:43 +0200
From: "DRAGE, Keith (Keith)" 
To: Hadriel Kaplan , Cullen Jennings 
Date: Tue, 25 Oct 2011 12:08:40 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMkujAbh5wFT7Ot0OapBvdROpRYJWM1A5w
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <796A71F1-B0AE-4858-9D8C-8BDAA21DF554@cisco.com> <23BE5996-FCA3-4A24-BC59-779FAC5D7E2C@acmepacket.com>
In-Reply-To: <23BE5996-FCA3-4A24-BC59-779FAC5D7E2C@acmepacket.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.69 on 155.132.188.80
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 10:09:00 -0000

Hadriel wrote:

> sticker under the battery, and its stuck to your phone not SIM.  Some hav=
e
> more than one I think, because it's technically tied to the wireless
> transceiver so I think dual-band phones have two.  But either way it

Phones supporting 3GPP and 3GPP2 standards have only one. The IMEI / MEID i=
s 15 characters of either decimal or hexadecimal numbers that do not overla=
p. The first two characters represent the allocation authority, and for 3GP=
P2 only phones the allocation authority (primarily TIA in this case) the fi=
rst characters will be hexadecimal and the remainder the characters are rea=
d as if they were hexadecimal.

3GPP only phones use only decimal characters, with the first two digits bei=
ng decimal.=20

Dual mode phones covering both standards have an IMEI for 3GPP use, which s=
ame value is also used as an MEID in 3GPP2 usage.

Note that this is specifically cell phone technology. Where one of the mode=
s is wireless LAN (where the WLAN is not tied to a specific cellphone opera=
tor as in I-WLAN) the IMEI / MEID does not apply.

Regards

Keith

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
> Sent: 25 October 2011 08:36
> To: Cullen Jennings
> Cc: DRAGE, Keith (Keith); dispatch@ietf.org list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
>=20
>=20
> On Oct 24, 2011, at 11:24 PM, Cullen Jennings wrote:
>=20
> >> So in conclusion, the usage in this respect is to lessen the incidence
> of someone coming up behind you, putting a knife in your ribs, and making
> off with your latest model of fancy cellphone. And for non-IMS usage its
> probably been doing that for the last 10 years (depending on when
> operators were pressured by law enforcement agencies to implement the EIR
> (the online database against which EIRs are checked).
> >
> > So for phones that are an expensive mobile + a cheap sim card, it seems
> like an identifier attached to the expensive part not the cheap part woul=
d
> work best. Thoughts?
>=20
> The IMEI *is* attached to the expensive part.  It's not in the SIM - it's
> in the phone.  If you have a GSM phone, you can probably see it on a
> sticker under the battery, and its stuck to your phone not SIM.  Some hav=
e
> more than one I think, because it's technically tied to the wireless
> transceiver so I think dual-band phones have two.  But either way it
> represents your phone hardware, not your user identity, afaik.  It's a lo=
t
> like a MAC address, except you're not supposed to be able to change the
> IMEI.
>=20
> And yes it really was created to detect stolen phones.  I don't know if
> stolen phones are allowed to make emergency calls (and that would be
> nationally-specific regulation anyway); but in many countries un-
> registered phones are allowed to make emergency calls, so in that case
> they won't get a SIP REGISTER to indicate the IMEI, ergo they need it in
> an INVITE.
>=20
> -hadriel


From keith.drage@alcatel-lucent.com  Tue Oct 25 03:47:05 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918EC21F8B4B for ; Tue, 25 Oct 2011 03:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.053
X-Spam-Level: 
X-Spam-Status: No, score=-106.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1pGLyOVPpsf for ; Tue, 25 Oct 2011 03:47:04 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id A13D721F8B37 for ; Tue, 25 Oct 2011 03:47:04 -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 p9PAioNR027780 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2011 12:46:56 +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 Oct 2011 12:46:38 +0200
From: "DRAGE, Keith (Keith)" 
To: Cullen Jennings , "DOLLY, MARTIN C" 
Date: Tue, 25 Oct 2011 12:46:36 +0200
Thread-Topic: [dispatch]	draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySzW+r7QlyNLs/R8G40WBxjk0krgANEtkQ
Message-ID: 
References:  <4EA5C42A.7030707@nostrum.com>  <0E365A77-EC32-497A-95E5-BDBA3DC87ED4@cisco.com>
In-Reply-To: <0E365A77-EC32-497A-95E5-BDBA3DC87ED4@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn	anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 10:47:05 -0000

In regard to the emergency call issue, different regulators make different =
decisions.=20

Specifically, you could potentially be precluded from making an emergency r=
egistration if your phone is a stolen one (but necessarily), as the IMEI in=
 the register request could be checked against the EIR to see if it is stol=
en. This applies for registration both at the IP connection level and the S=
IP (IMS) level).

If the regulator permits you then to make an emergency call from an unregis=
tered (and therefore unauthenticated) phone, the IMEI included in the emerg=
ency INVITE as an instance ID would not be checked by the operator against =
the EIR to see if it was stolen.

The PSAP might see that stolen IMEI value, and perform its own check, altho=
ugh such would likely be after the emergency event, rather than in real tim=
e. 3GPP does not make standards in this area.

If the regulator does not permit emergency calls from unregistered phones, =
and the operator has refused to authenticate your registration request beca=
use your phone is stolen, then tough.

The toolkit is there from 3GPP. How it gets used is up to the local regulat=
or, and what they require the local operator to do.

Regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Cullen Jennings
> Sent: 25 October 2011 05:20
> To: DOLLY, MARTIN C
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-
> dispatch-imei-urn-as-instanceid
>=20
>=20
> On Oct 24, 2011, at 4:16 PM, DOLLY, MARTIN C wrote:
>=20
> >
> > The draft meets AT&T's business needs. (period)
>=20
> Martin, it would be helpful if you could say a bit about what the needs
> are. Did Keith get it about right on the problem is stopping phones calls
> from stolen phones? If a phone has been reported stolen, and someone make=
s
> an emergency call on it, should that call be delivered or stopped? Whats
> your view on that. If people want to engage on this stuff I'm sure you ca=
n
> get to consensus - I very well may be in the rough on that consensus but
> you have something that people could make an informed decision about if.
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From atle.monrad@ericsson.com  Tue Oct 25 03:55:50 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED40C21F8B91 for ; Tue, 25 Oct 2011 03:55:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uENeYiW2JKke for ; Tue, 25 Oct 2011 03:55:49 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A13CE21F8B58 for ; Tue, 25 Oct 2011 03:55:48 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-4d-4ea695b3a1ec
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4F.4B.20773.3B596AE4; Tue, 25 Oct 2011 12:55:47 +0200 (CEST)
Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.187]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 25 Oct 2011 12:55:46 +0200
From: Atle Monrad 
To: "DRAGE, Keith (Keith)" , Cullen Jennings , "Worley, Dale R (Dale)" , "dwarren@gsm.org" 
Date: Tue, 25 Oct 2011 12:55:44 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri	and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySUgIjsISTdMFyQZ+NQZx+6F9d1wARQdvAABqlCHA=
Message-ID: <7A051DFAA46D0246A82293C7CEF621E9056D64D756@ESESSCMS0352.eemea.ericsson.se>
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com> 
In-Reply-To: 
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: nb-NO, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 10:55:51 -0000

Cullen, Adam, all

Keith has already given some good information on how the IMEI is used withi=
n 3GPP. Some few additions though

This functionality has been part of GSM since GSM phase_1 in the early 90s.=
 Archeologists can find such information at http://www.3gpp.org/ftp/Specs/h=
tml-info/0216.htm while more up-to-date people interested in 3GPP may find =
the (more or less) same service requirements at http://www.3gpp.org/ftp/Spe=
cs/html-info/22016.htm. As the equipment identity register and its function=
ality is from the early days of the specification of mobile systems, it is =
not described as extensive as some recently added features. I hope that the=
 discussions can continue based on this. To discuss and question these old =
and long-time-existing requirements from persons outside of 3GPP seems unne=
cessary and will not be too productive. I add Dan Warren who might clarify =
the requirements from the GSMA point of view.

On referencing, I assume that people interested in a feature will need to r=
ead the documentation in its context. If the context is 3GPP, the way 3GPP =
reference its specifications in its releases needs to be known by these per=
sons. It might of course be useful for external reviewers to understand thi=
s, but I see this to be more of an exercise for the reviewers and cannot re=
ally be held against the draft itself. Mistakes must obviously be fixed and=
 some additions might be needed in the draft though. Note also that TS 24.2=
29 and TS 23.003 reference the montemurro-draft since 3GPP Release 8.

I would also like to add that as I see it, a number of people with 3GPP-kno=
wledge would like to progress the draft with their +1, while Cullen raise a=
 number of questions admitting that he don't know the background and the fu=
nctionality of the feature. Based on this I am not really sure who give the=
 most relevant technical comments... People without concerns shouldn't need=
 to invent issues? Having said that, if there are some concerns over specif=
ic (or lack of) existing text, I am sure that this can be clarified.

At last, whether the UICC or the handset is cheapest is also a side-track. =
There are procedures to block/bar the subscription (the complete subscripti=
on or particular identified SIMs/UICCs of the subscriber) and there are oth=
er procedures to block/bar the equipment (identified by the IMEI). This dra=
ft is for the latter. That operators heavily subsidising handsets need to j=
ustify the need for such a functionality is a surprise to me.

/atle



________________________________


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management
Ericsson




-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of DRAGE, Keith (Keith)
Sent: 25. oktober 2011 00:08
To: Cullen Jennings; Worley, Dale R (Dale)
Cc: dispatch@ietf.org list
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-disp=
atch-imei-urn-as-instanceid

Responding on the blacklisting / whitelisting issue.

As far as I understand, the use of the IMEI to do this (blacklisting / whit=
elisting) happens on every cellphone already (be it according to 3GPP or 3G=
PP standards (where the IMEI is the MEID).

The degree to which it occurs is as a result of regulatory pressure. Essent=
ially the prime requirement is from law enforcement agencies who want to id=
entify the use of stolen phones, and prevent those stolen phones having val=
ue, and from operators who want to prevent stolen phones incurring network =
costs for which they will never be reimbursed. For the existing non-IMS cel=
lphones you will find the IMEI or MEID populating many messages including t=
hose that establish new calls.

For IMS phones the same IMEI / MEID is present in messages when you obtain =
the data channel, but as far as I understand operators want it in messages =
that get exchanged more frequently, and that means putting it in INVITE mes=
sages at the SIP layer.

So in conclusion, the usage in this respect is to lessen the incidence of s=
omeone coming up behind you, putting a knife in your ribs, and making off w=
ith your latest model of fancy cellphone. And for non-IMS usage its probabl=
y been doing that for the last 10 years (depending on when operators were p=
ressured by law enforcement agencies to implement the EIR (the online datab=
ase against which EIRs are checked).

Yes it will stop calls. Does someone whos stolen your phone have the right =
to make calls?

As regards IMEIs, it is associated with the hardware, not the software. The=
 hardware manufacturer applies for them from some designated authority ulti=
mately supervised by a joint group of GSMA and TIA/TTA. So you do not have =
the ability to craft your own. I believe the same applies to MAC addresses.

I believe the way it is used in 3GPP the IMEI is not visible to any other t=
han the end user who owns the phone and the network. I do not believe it is=
 seen by any other user (barring someone of course deliberately revealing i=
t).

While there are various databases around that attempt to correlate IMEI val=
ues to a particular type of phone, these have all been reverse engineered b=
y people plugging in the values in phones they have. You will need a sight =
more privileges to find the equivalent information from the official alloca=
tion database, and there is no intention to make it any more public.

Regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Cullen Jennings
> Sent: 24 October 2011 14:37
> To: Worley, Dale R (Dale)
> Cc: dispatch@ietf.org list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and
> draft-allen- dispatch-imei-urn-as-instanceid
>
>
> Dale - sent in my role as an individual contributor. (all my emails
> are in my role as an individual contributor unless they are clearly
> signed as some other role)
>
> In the past I have made the mistake of listing all my concerns with
> this draft then one or two would get discussed for a bit and rest
> ignored so this time I'm going to try and stick with a few high level
> ones and some minor ones. We can try to resolve theses a bit then we
> can move on the others. Lets start with the stuff from your email.
>
> Interoperability.
>
> I've asked multiple people does this happen in INVITEs or just
> REGISTERs and got mixed answers. It makes a big difference - at some
> level this is a proposal to black list phones and / or part of a
> malware prevention systems. Or perhaps it is a proposal to white list
> phones and ones that don't have this won't work. You can say this
> going to be restricted to just the sets of people that want to use it
> but that is seldom how standards work out That might be true in the
> cases of if it only went from a phone to the domain for it's AOR.
> However, if this will also be used in INVITE cases, would it stop calls f=
rom any 3GPP phone to non 3GPP phone?
> Making sure that we did not have needless lack of interoperability
> between classic IETF SIP and 3GPP style SIP has always been a goal.
> Even if this is only only on IMS phones, theses are now used well
> outside the mobile environment - we see them used on wireline and
> enterprise environments so would there be a problem from other SIP
> devices  to theses. Could a soft phone get the required IMEI
> identifier so it was not blacklisted? Could a small vendor get them?
> These are all things I wonder.
>
> It's impossible to answer any of the above questions without knowing
> something about how this blacklisting stuff works and what this
> identifier is used for. This leads to my first issues. I want a
> description of how this works so we can decide if there are interoperabil=
ity problems or not.
> I am constantly told this is important to 3GPP yet I can't find a 3GPP
> document that even has a reference to this draft or explains how it works=
.
> So this is my most important question to you -  Do you think this is
> unreasonable that we should ask how this works and if there are
> interoperability problems? If this is important to 3GPP, could they
> provide a pointer to a document that has reference to it and defines
> how it is used.
>
> On a minor notes related to references - I'm not objecting based on
> process crap around the references but it would be really really nice
> if the drafts could be updated so that the reference pointed at a
> specific document - not a vague family of documents where I have no
> idea if I am reading the right one or not. I never know what to read
> when I see 3GPP
> 24.237 but if you gave me a date and version, or even a link, it would
> be easier. A reference should be something where we both know we are
> reading the same document. I realize the 3GPP documents  have some
> examples that have this identifier in them but I could not find a
> description of how it worked. I'd also like to point out that in 2007
> I asked for the pointer to the document that explains the GSMA
> allocation policy as you will eventually need that for IESG approval
> but the link in the draft is still wrong. Yes, I can figure out how to
> find the right one but is really too much to ask that someone could
> have fixed this. Ag  ain, none of things in this paragraph matter to
> me on the big topic of how to proceed but it's hard to put this on top
> of ones priority list when no one can bother to fix stuff that is clearly=
 wrong.
>
> So let me be very clear on what I am looking for to start the
> interoperability discussion. We need to understand the specification
> for this to decide what interoperability problems there may or may not
> be. My assumptions how how this works may be very wrong. Lets get the
> facts and make an informed decision.
>
>
> Privacy
>
> So what's the position of everyone that has been sending opinions of
> this draft. Is the IMEI of my phone personal identifying information or n=
ow?
> Sort of hard to have a discussion without deciding that first.
>
>
> IPR
>
> On the topic of IPR. I think we need to sort out some of the simpler
> issues first and in the end I will probably rather have the IPR
> discussion on the ietf list than here. To put it pretty bluntly, the
> IETF list is a more favorable environment for the arguments I will
> probably make around IPR. It always fascinates me me to see the
> proponents of this draft sending nasty grams to the chairs telling
> them do something that process wise they can't do but would
> effectively move the conversation from the dispatch list to the ietf
> list while at the same time the ADs and Chairs are trying to resolve
> the conversation in dispatch first which is typically much less
> concerned about IPR than the IETF is in general.  I will note that
> Gonzalo thinks my drafts runs into the Andrews's patents but I have
> been working on the assumption that it does not as Andrew commented on it=
 and did not file any IPR disclosure or notify the WG.
>
>
> On a finally note, I get the feeling that you think the chairs on not
> doing something they should. Obviously if there was anything that
> required making a call where the consensus was not obvious or anything
> I would leave that type of decision to Mary. I am participating in
> this conversation as one of the individuals in the WG and would leave
> any complex judgment call to Mary. If you think there is something
> where my individual opinions are causing the chairs not to do the
> right things, please, grab a phone and call me about it and we will
> figure out a way where everyone agrees the chairs are doing the right
> thing. I'm not a fan of the current passive aggressive approach.
>
>
>
> On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:
>
> > Given that the decision to be made in this working group is whether
> > to assign these I-Ds for further work to be done on them, there are
> > a small number of questions in play (with assorted other issues to
> > be addressed during the technical refinement of the proposal):
> >
> > 1.  Does this proposal introduce any interoperability problems?
> > 2.  Does this proposal present any privacy concerns?
> > 3.  Does this proposal allow anyone to extract an unconscionable
> >    "tax" (through the use of IPR)?
> >
> > Here are my assessments of these issues:
> >
> > 1.  Does this proposal introduce any interoperability problems?
> >
> > I don't see what interoperability problems can result from the
> > introduction of an additional format of URN, as long as the format
> > adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
> > clear that a SIP element may receive a +sip.instance value which is
> > in a URN namespace that it does not recognize, so any properly
> > constructed SIP element should be able to handle +sip.instance
> > values in namespaces that it does not have prior knowledge of.
> >
> > (Certainly, the one product/project that I have detailed knowledge
> > of has always treated +sip.instance as a string.  Thereon hangs a tale:
> > If the +sip.instance is a UUID-based URN, and if the UUID is based
> > on a MAC address, the registrar extracts the MAC address so that the
> > UA can be addressed through a special URI that encodes its MAC address.
> > But it turns out that a popular make of UA formats its UUIDs
> > incorrectly, so that it was not recognized as a MAC-based UUID.
> > We've had to add special code to the registrar to recognize this
> > defective URN format!)
> >
> > 2.  Does this proposal present any privacy concerns?
> >
> > There would be general privacy concerns if this or any other
> > +sip.instance value was present in dialog-forming requests or
> > responses, and so could be seen by the other end of phone calls.
> > But as far as I can tell, no UA uses +sip.instance in INVITEs;
> > +sip.instance values are presented only in REGISTER messages.
> >
> > On the other hand, generated GRUU values are given in INVITEs, and
> > the GRUU can give information about the UA's +sip.instance and the
> > AOR, even if the GRUU is generated using a secret key.  However, the
> > problems resulting from this seem to be essentially the same when
> > the
> > +sip.instance is derived from an IMEI as when it is derived from a
> > +MAC
> > address.
> >
> > In regard to registrations, given that the intended scope of
> > application of the proposal is entirely within paid wireless
> > networks, there can be no privacy between the UA and its registrar.
> >
> > 3.  Does this proposal allow anyone to extract an unconscionable
> >    "tax" (through the use of IPR)?
> >
> > Though this proposal may be encumbered by IPR claims, the only users
> > who would be *required* to use this URN format are products within
> > the GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS
> > adopts this as mandatory-to-implement.  Those users might be
> > subjected to an unconscionable tax, but the GSM/3GPP/IMS universe
> > has its own political/economic structure for deciding what licensed
> > technology is mandatory to implement and what licensing terms are
> > considered acceptable.  It seems to me that we can justly leave
> > these questions to GSM/3GPP/IMS.
> >
> > There is some concern that the IPR disclosures were filed "late".
> > However, as the latest IPR disclosure was filed in January 2011, the
> > working group is now even later, and the objection has expired.
> >
> > In summary, I don't see any of these issues as being particularly
> > problematic.  If I've overlooked an important aspect of this, I
> > would like to see some detailed information about it.
> >
> > Dale
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From keith.drage@alcatel-lucent.com  Tue Oct 25 06:39:54 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B8F21F8B50 for ; Tue, 25 Oct 2011 06:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.067
X-Spam-Level: 
X-Spam-Status: No, score=-106.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stgPVKU-qY1Y for ; Tue, 25 Oct 2011 06:39:53 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id C769F21F8B48 for ; Tue, 25 Oct 2011 06:39:52 -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 p9PDdeNk016250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2011 15:39:41 +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; Tue, 25 Oct 2011 15:39:41 +0200
From: "DRAGE, Keith (Keith)" 
To: Cullen Jennings , Andrew Allen 
Date: Tue, 25 Oct 2011 15:39:39 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri	 and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySwheJi+Igw6qnQwC3IGRLcHuIXQAWJw+w
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se><208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr><234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>   <7A559464-17CB-436A-AD9A-C1FAAE583B5B@cisco.com>
In-Reply-To: <7A559464-17CB-436A-AD9A-C1FAAE583B5B@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	 and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 13:39:55 -0000

> So I looked at lasted version I could find of this and it actually does
> talk about IMEI. Which version of this is the right one to be reading?
>
3GPP is divided into releases, each of which supposedly encompasses a valid=
 set of features. In general features introduced in release x are also incl=
uded in release x+1.

Within releases, specs are updated, not to add new functionality, but to co=
rrect errors that may result in some catastrophic failure of a feature.

So the answer to the question above is the latest version of all releases f=
rom which the feature was introduced, where the release is identified by th=
e first digit of the triple x.y.z.

I believe this particular capability was introduced from release 8.

The text should be compatible in all releases, so looking at the latest ver=
sion of the latest release (11.1.0) should be sufficient.

Regards

Keith

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: 25 October 2011 03:59
> To: Andrew Allen
> Cc: DRAGE, Keith (Keith); Worley, Dale R (Dale); dispatch@ietf.org
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
>
>
> On Oct 24, 2011, at 4:59 PM, Andrew Allen wrote:
>
> > Just to add to and correct some of Keith's comments.
> >
> > > As far as I understand, the use of the IMEI to do this (blacklisting =
/
> > > whitelisting) happens on every cellphone already (be it according to
> 3GPP
> > > or 3GPP standards (where the IMEI is the MEID).
> >
> > Should be "according to 3GPP or 3GPP2 standards"
> >
> > One other correction/clarification is that:
> >
> > According to 3GPP TS 24.229 the Instance ID is not normally placed in
> SIP INVITE requests or responses to INVITE for the purposes of telephony
> calls.
>
> So I looked at lasted version I could find of this and it actually does
> talk about IMEI. Which version of this is the right one to be reading?
>
>
> > The exception to this is Emergency calls when the Instance ID containin=
g
> the IMEI is placed in the Contact header field of the SIP INVITE request.
>
> I assume it is in emergency call because un registered phones can make
> emergency call ?
>
> > Other bodies (such as OMA for push to talk) may have specified includin=
g
> the instance ID in SIP INVITE request but (as specified in 3GPP
> specifications that if this is included this is to be done) the Instance
> ID is removed by an intermediate server (e.g the PoC Server).
> >
> > Whitelist/Blacklist checking can be done based on the Instance ID
> containing the IMEI being included in the SIP REGISTER request (as I have
> indicated in a previous email)
>
>
> Writing up the draft to talk about using this in a contact header to say
> when a UA puts it in or not, and when B2BUA & Proxies remove it, would
> really help people understand what the implications are.
>
> >
> > But basically I agree with the rest of Keith's comments
> >
> > Andrew
> >
> > > -----Original Message-----
> > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> > > Behalf Of DRAGE, Keith (Keith)
> > > Sent: Monday, October 24, 2011 5:08 PM
> > > To: Cullen Jennings; Worley, Dale R (Dale)
> > > Cc: dispatch@ietf.org list
> > > Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-
> allen-
> > > dispatch-imei-urn-as-instanceid
> > >
> > > Responding on the blacklisting / whitelisting issue.
> > >
> > > As far as I understand, the use of the IMEI to do this (blacklisting =
/
> > > whitelisting) happens on every cellphone already (be it according to
> 3GPP
> > > or 3GPP standards (where the IMEI is the MEID).
> > >
> > > The degree to which it occurs is as a result of regulatory pressure.
> > > Essentially the prime requirement is from law enforcement agencies wh=
o
> > > want to identify the use of stolen phones, and prevent those stolen
> phones
> > > having value, and from operators who want to prevent stolen phones
> > > incurring network costs for which they will never be reimbursed. For
> the
> > > existing non-IMS cellphones you will find the IMEI or MEID populating
> many
> > > messages including those that establish new calls.
> > >
> > > For IMS phones the same IMEI / MEID is present in messages when you
> obtain
> > > the data channel, but as far as I understand operators want it in
> messages
> > > that get exchanged more frequently, and that means putting it in
> INVITE
> > > messages at the SIP layer.
> > >
> > > So in conclusion, the usage in this respect is to lessen the incidenc=
e
> of
> > > someone coming up behind you, putting a knife in your ribs, and makin=
g
> off
> > > with your latest model of fancy cellphone. And for non-IMS usage its
> > > probably been doing that for the last 10 years (depending on when
> > > operators were pressured by law enforcement agencies to implement the
> EIR
> > > (the online database against which EIRs are checked).
> > >
> > > Yes it will stop calls. Does someone whos stolen your phone have the
> right
> > > to make calls?
> > >
> > > As regards IMEIs, it is associated with the hardware, not the
> software.
> > > The hardware manufacturer applies for them from some designated
> authority
> > > ultimately supervised by a joint group of GSMA and TIA/TTA. So you do
> not
> > > have the ability to craft your own. I believe the same applies to MAC
> > > addresses.
> > >
> > > I believe the way it is used in 3GPP the IMEI is not visible to any
> other
> > > than the end user who owns the phone and the network. I do not believ=
e
> it
> > > is seen by any other user (barring someone of course deliberately
> > > revealing it).
> > >
> > > While there are various databases around that attempt to correlate
> IMEI
> > > values to a particular type of phone, these have all been reverse
> > > engineered by people plugging in the values in phones they have. You
> will
> > > need a sight more privileges to find the equivalent information from
> the
> > > official allocation database, and there is no intention to make it an=
y
> > > more public.
> > >
> > > Regards
> > >
> > > Keith
> > >
> > > > -----Original Message-----
> > > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]
> On
> > > > Behalf Of Cullen Jennings
> > > > Sent: 24 October 2011 14:37
> > > > To: Worley, Dale R (Dale)
> > > > Cc: dispatch@ietf.org list
> > > > Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-
> allen-
> > > > dispatch-imei-urn-as-instanceid
> > > >
> > > >
> > > > Dale - sent in my role as an individual contributor. (all my emails
> are
> > > in
> > > > my role as an individual contributor unless they are clearly signed
> as
> > > > some other role)
> > > >
> > > > In the past I have made the mistake of listing all my concerns with
> this
> > > > draft then one or two would get discussed for a bit and rest ignore=
d
> so
> > > > this time I'm going to try and stick with a few high level ones and
> some
> > > > minor ones. We can try to resolve theses a bit then we can move on
> the
> > > > others. Lets start with the stuff from your email.
> > > >
> > > > Interoperability.
> > > >
> > > > I've asked multiple people does this happen in INVITEs or just
> REGISTERs
> > > > and got mixed answers. It makes a big difference - at some level
> this is
> > > a
> > > > proposal to black list phones and / or part of a malware prevention
> > > > systems. Or perhaps it is a proposal to white list phones and ones
> that
> > > > don't have this won't work. You can say this going to be restricted
> to
> > > > just the sets of people that want to use it but that is seldom how
> > > > standards work out That might be true in the cases of if it only
> went
> > > from
> > > > a phone to the domain for it's AOR. However, if this will also be
> used
> > > in
> > > > INVITE cases, would it stop calls from any 3GPP phone to non 3GPP
> phone?
> > > > Making sure that we did not have needless lack of interoperability
> > > between
> > > > classic IETF SIP and 3GPP style SIP has always been a goal. Even if
> this
> > > > is only only on IMS phones, theses are now used well outside the
> mobile
> > > > environment - we see them used on wireline and enterprise
> environments
> > > so
> > > > would there be a problem from other SIP devices
> > > >  to theses. Could a soft phone get the required IMEI identifier so
> it
> > > was
> > > > not blacklisted? Could a small vendor get them? These are all thing=
s
> I
> > > > wonder.
> > > >
> > > > It's impossible to answer any of the above questions without knowin=
g
> > > > something about how this blacklisting stuff works and what this
> > > identifier
> > > > is used for. This leads to my first issues. I want a description of
> how
> > > > this works so we can decide if there are interoperability problems
> or
> > > not.
> > > > I am constantly told this is important to 3GPP yet I can't find a
> 3GPP
> > > > document that even has a reference to this draft or explains how it
> > > works.
> > > > So this is my most important question to you -  Do you think this i=
s
> > > > unreasonable that we should ask how this works and if there are
> > > > interoperability problems? If this is important to 3GPP, could they
> > > > provide a pointer to a document that has reference to it and define=
s
> how
> > > > it is used.
> > > >
> > > > On a minor notes related to references - I'm not objecting based on
> > > > process crap around the references but it would be really really
> nice if
> > > > the drafts could be updated so that the reference pointed at a
> specific
> > > > document - not a vague family of documents where I have no idea if =
I
> am
> > > > reading the right one or not. I never know what to read when I see
> 3GPP
> > > > 24.237 but if you gave me a date and version, or even a link, it
> would
> > > be
> > > > easier. A reference should be something where we both know we are
> > > reading
> > > > the same document. I realize the 3GPP documents  have some examples
> that
> > > > have this identifier in them but I could not find a description of
> how
> > > it
> > > > worked. I'd also like to point out that in 2007 I asked for the
> pointer
> > > to
> > > > the document that explains the GSMA allocation policy as you will
> > > > eventually need that for IESG approval but the link in the draft is
> > > still
> > > > wrong. Yes, I can figure out how to find the right one but is reall=
y
> too
> > > > much to ask that someone could have fixed this. Ag
> > > >  ain, none of things in this paragraph matter to me on the big topi=
c
> of
> > > > how to proceed but it's hard to put this on top of ones priority
> list
> > > when
> > > > no one can bother to fix stuff that is clearly wrong.
> > > >
> > > > So let me be very clear on what I am looking for to start the
> > > > interoperability discussion. We need to understand the specificatio=
n
> for
> > > > this to decide what interoperability problems there may or may not
> be.
> > > My
> > > > assumptions how how this works may be very wrong. Lets get the fact=
s
> and
> > > > make an informed decision.
> > > >
> > > >
> > > > Privacy
> > > >
> > > > So what's the position of everyone that has been sending opinions o=
f
> > > this
> > > > draft. Is the IMEI of my phone personal identifying information or
> now?
> > > > Sort of hard to have a discussion without deciding that first.
> > > >
> > > >
> > > > IPR
> > > >
> > > > On the topic of IPR. I think we need to sort out some of the simple=
r
> > > > issues first and in the end I will probably rather have the IPR
> > > discussion
> > > > on the ietf list than here. To put it pretty bluntly, the IETF list
> is a
> > > > more favorable environment for the arguments I will probably make
> around
> > > > IPR. It always fascinates me me to see the proponents of this draft
> > > > sending nasty grams to the chairs telling them do something that
> process
> > > > wise they can't do but would effectively move the conversation from
> the
> > > > dispatch list to the ietf list while at the same time the ADs and
> Chairs
> > > > are trying to resolve the conversation in dispatch first which is
> > > > typically much less concerned about IPR than the IETF is in general=
.
> I
> > > > will note that Gonzalo thinks my drafts runs into the Andrews's
> patents
> > > > but I have been working on the assumption that it does not as Andre=
w
> > > > commented on it and did not file any IPR disclosure or notify the
> WG.
> > > >
> > > >
> > > > On a finally note, I get the feeling that you think the chairs on
> not
> > > > doing something they should. Obviously if there was anything that
> > > required
> > > > making a call where the consensus was not obvious or anything I
> would
> > > > leave that type of decision to Mary. I am participating in this
> > > > conversation as one of the individuals in the WG and would leave an=
y
> > > > complex judgment call to Mary. If you think there is something wher=
e
> my
> > > > individual opinions are causing the chairs not to do the right
> things,
> > > > please, grab a phone and call me about it and we will figure out a
> way
> > > > where everyone agrees the chairs are doing the right thing. I'm not
> a
> > > fan
> > > > of the current passive aggressive approach.
> > > >
> > > >
> > > >
> > > > On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:
> > > >
> > > > > Given that the decision to be made in this working group is
> whether to
> > > > > assign these I-Ds for further work to be done on them, there are =
a
> > > > > small number of questions in play (with assorted other issues to
> be
> > > > > addressed during the technical refinement of the proposal):
> > > > >
> > > > > 1.  Does this proposal introduce any interoperability problems?
> > > > > 2.  Does this proposal present any privacy concerns?
> > > > > 3.  Does this proposal allow anyone to extract an unconscionable
> > > > >    "tax" (through the use of IPR)?
> > > > >
> > > > > Here are my assessments of these issues:
> > > > >
> > > > > 1.  Does this proposal introduce any interoperability problems?
> > > > >
> > > > > I don't see what interoperability problems can result from the
> > > > > introduction of an additional format of URN, as long as the forma=
t
> > > > > adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
> > > > > clear that a SIP element may receive a +sip.instance value which
> is in
> > > > > a URN namespace that it does not recognize, so any properly
> > > > > constructed SIP element should be able to handle +sip.instance
> values
> > > > > in namespaces that it does not have prior knowledge of.
> > > > >
> > > > > (Certainly, the one product/project that I have detailed knowledg=
e
> of
> > > > > has always treated +sip.instance as a string.  Thereon hangs a
> tale:
> > > > > If the +sip.instance is a UUID-based URN, and if the UUID is base=
d
> on
> > > > > a MAC address, the registrar extracts the MAC address so that the
> UA
> > > > > can be addressed through a special URI that encodes its MAC
> address.
> > > > > But it turns out that a popular make of UA formats its UUIDs
> > > > > incorrectly, so that it was not recognized as a MAC-based UUID.
> We've
> > > > > had to add special code to the registrar to recognize this
> defective
> > > > > URN format!)
> > > > >
> > > > > 2.  Does this proposal present any privacy concerns?
> > > > >
> > > > > There would be general privacy concerns if this or any other
> > > > > +sip.instance value was present in dialog-forming requests or
> > > > > responses, and so could be seen by the other end of phone calls.
> But
> > > > > as far as I can tell, no UA uses +sip.instance in INVITEs;
> > > > > +sip.instance values are presented only in REGISTER messages.
> > > > >
> > > > > On the other hand, generated GRUU values are given in INVITEs, an=
d
> the
> > > > > GRUU can give information about the UA's +sip.instance and the
> AOR,
> > > > > even if the GRUU is generated using a secret key.  However, the
> > > > > problems resulting from this seem to be essentially the same when
> the
> > > > > +sip.instance is derived from an IMEI as when it is derived from =
a
> MAC
> > > > > address.
> > > > >
> > > > > In regard to registrations, given that the intended scope of
> > > > > application of the proposal is entirely within paid wireless
> networks,
> > > > > there can be no privacy between the UA and its registrar.
> > > > >
> > > > > 3.  Does this proposal allow anyone to extract an unconscionable
> > > > >    "tax" (through the use of IPR)?
> > > > >
> > > > > Though this proposal may be encumbered by IPR claims, the only
> users
> > > > > who would be *required* to use this URN format are products withi=
n
> the
> > > > > GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts
> this
> > > > > as mandatory-to-implement.  Those users might be subjected to an
> > > > > unconscionable tax, but the GSM/3GPP/IMS universe has its own
> > > > > political/economic structure for deciding what licensed technolog=
y
> is
> > > > > mandatory to implement and what licensing terms are considered
> > > > > acceptable.  It seems to me that we can justly leave these
> questions
> > > > > to GSM/3GPP/IMS.
> > > > >
> > > > > There is some concern that the IPR disclosures were filed "late".
> > > > > However, as the latest IPR disclosure was filed in January 2011,
> the
> > > > > working group is now even later, and the objection has expired.
> > > > >
> > > > > In summary, I don't see any of these issues as being particularly
> > > > > problematic.  If I've overlooked an important aspect of this, I
> would
> > > > > like to see some detailed information about it.
> > > > >
> > > > > Dale
> > > > > _______________________________________________
> > > > > dispatch mailing list
> > > > > dispatch@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/dispatch
> > > >
> > > > _______________________________________________
> > > > dispatch mailing list
> > > > dispatch@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/dispatch
> > > _______________________________________________
> > > dispatch mailing list
> > > dispatch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dispatch
> >
> > ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-publi=
c
> information. Any use of this information by anyone other than the intende=
d
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
> >


From adam@nostrum.com  Tue Oct 25 08:10:59 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9273621F84CD for ; Tue, 25 Oct 2011 08:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx95aG0CozQc for ; Tue, 25 Oct 2011 08:10:58 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C5D5321F84BC for ; Tue, 25 Oct 2011 08:10:58 -0700 (PDT)
Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9PFAqfi048593 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Oct 2011 10:10:53 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4EA6D17C.3050107@nostrum.com>
Date: Tue, 25 Oct 2011 10:10:52 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 15:10:59 -0000

On 10/24/11 17:07, Oct 24, DRAGE, Keith (Keith) wrote:
> I believe the way it is used in 3GPP the IMEI is not visible to any other than the end user who owns the phone and the network. I do not believe it is seen by any other user (barring someone of course deliberately revealing it).

That's the real concern. If what you say is true, then I agree that 
there is no problem. Also, if what you say is true, there is certainly 
no harm in including that fact as an important security property in the 
document itself.

In the spirit of "send text," I would propose extending the first 
paragraph of the "Security Considerations" section in 
draft-montemurro-gsma-imei-uri by adding:

     Further, because IMEIs can generally be correlated to a user,
     they should be treated as any other personally identifiable
     information. In particular, the IMEI SHOULD NOT be included in
     messages intended to convey any level of anonymity.
     Further, because IMEIs can loosely be correlated to a user,
     they should be treated as any other personally identifiable
     information. In particular, the IMEI SHOULD NOT be included in
     messages intended to convey any level of anonymity.

The other major outstanding issue is interoperability. The main issue, I 
believe, is whether you will end up with systems that only accept IMEI 
URNs when use of the protocol in a broader context requires the use of 
general URNs or even URIs.

The "Community considerations" section of draft-montemurro-gsma-imei-uri 
currently deals exclusively with the ability for general-purpose 
Internet implementations to deal with 3GPP-specific identifiers. We need 
text that addresses the complementary issue of 3GPP implementations 
dealing with general-purpose Internet identifiers.

I would propose adding text to the end of this section, along the lines of:

     Conversely, Internet implementations will not generally posses
     IMEI identifiers. The identifiers generated by such implementations
     will typically be URNs within namespaces other than "gsma," and
     may, depending on context, even be non-URN URIs. Implementations
     are advised to correctly process URIs other than "gsma"-namespaced
     URNs, so as to aid in interoperability.


/a

From aallen@rim.com  Tue Oct 25 08:20:50 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7335F21F8B94 for ; Tue, 25 Oct 2011 08:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.343
X-Spam-Level: 
X-Spam-Status: No, score=-5.343 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8A49SJ4-wuw for ; Tue, 25 Oct 2011 08:20:49 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 53E6D21F8B92 for ; Tue, 25 Oct 2011 08:20:44 -0700 (PDT)
X-AuditID: 0a41282f-b7b96ae00000702f-a4-4ea6d3ca4b52
Received: from XHT102CNC.rim.net (xht102cnc.rim.net [10.65.12.215]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 21.8E.28719.AC3D6AE4; Tue, 25 Oct 2011 15:20:43 +0000 (GMT)
Received: from XCT102ADS.rim.net (10.67.111.43) by XHT102CNC.rim.net (10.65.12.215) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 25 Oct 2011 11:20:43 -0400
Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 10:20:41 -0500
From: Andrew Allen 
To: Adam Roach , "DRAGE, Keith (Keith)" 
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri	and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMkplwK9cWE1Ok1Um/mLi8u637fJWNfzAA//+tjyA=
Date: Tue, 25 Oct 2011 15:20:41 +0000
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <4EA6D17C.3050107@nostrum.com>
In-Reply-To: <4EA6D17C.3050107@nostrum.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.70.110.251]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsXC5chzXff05WV+Bk8WMFvs+buI3WLppAWs Fk8bzzI6MHu0PtvL6rFkyU8mj1k7n7AEMEc1MNok5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTtdJJDwjzvj5sbHzAUXJSt2v5rM1MB4RqSLkZNDQsBE4vmi 86wQtpjEhXvr2boYuTiEBHqZJLre3WWBcJYxSly92w3lbGGUaPoKkuHkYBNQllj+ewYjiC0i ECPRMv04mM0MZF+Y8osNxBYWyJC48v4TG0RNpsTxmb0sELaVxM+5N8DqWQRUJdb8WckOYvMK uEnc3fYH6ox9bBLzJzWD3ccpoC2x48VUsEGMArISu89eZ4JYJi5x68l8JogfBCSW7DnPDGGL Srx8/A/qN0WJJ42bWSDqdSQW7IY4iBlo5rKFr5khFgtKnJz5BKxGSEBaYsfJNYwTGCVmIVkx C0n7LCTts5C0L2BkWcUomJtRbGBmkJyXrFeUmauXl1qyiRGccDT0dzD27dU6xCjAwajEwxsE TERCrIllxZW5hxglOJiVRHhbTwCFeFMSK6tSi/Lji0pzUosPMVoAg2gisxR3cj4wGeaVxBsb GKBwlMR5eS9l+AkJpAPTWHZqakFqEUwrEwenVAOjwOHr0n6WnQqc2RKr7zL6TFv7/O+1i5dK T95fuDfl7rx7mVcSxSVDOvdq2Ff6JXE/MLos3Phmz1K/i+G7LUqata6nz+oX1POzPvh1auMk zvWOAfG3l51acdnpP2PzZNtrdg0qKU4f7R0vNa60sdnItjk9tdLOw/1J0gZOlRlfGRZuarpm eJlRiaU4I9FQi7moOBEANmNFLVEDAAA=
Cc: "dispatch@ietf.org list" , Michael Montemurro 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 15:20:50 -0000

Adam

We are quite happy to add the text you propose. I think this text is perfect=
ly aligned with the current 3GPP usage. 

Do you however agree that this text would be better in the draft-allen-dispa=
tch-imei-urn-as-instanceid which specified the usage of the IMEI URN in SIP=
 rather than in the draft-montemurro-gsma-imei-urn which only defines the UR=
N.

Andrew

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Adam Roach
> Sent: Tuesday, October 25, 2011 10:11 AM
> To: DRAGE, Keith (Keith)
> Cc: dispatch@ietf.org list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
> 
> On 10/24/11 17:07, Oct 24, DRAGE, Keith (Keith) wrote:
> > I believe the way it is used in 3GPP the IMEI is not visible to any
> other than the end user who owns the phone and the network. I do not
> believe it is seen by any other user (barring someone of course
> deliberately revealing it).
> 
> That's the real concern. If what you say is true, then I agree that
> there is no problem. Also, if what you say is true, there is certainly
> no harm in including that fact as an important security property in the
> document itself.
> 
> In the spirit of "send text," I would propose extending the first
> paragraph of the "Security Considerations" section in
> draft-montemurro-gsma-imei-uri by adding:
> 
>      Further, because IMEIs can generally be correlated to a user,
>      they should be treated as any other personally identifiable
>      information. In particular, the IMEI SHOULD NOT be included in
>      messages intended to convey any level of anonymity.
>      Further, because IMEIs can loosely be correlated to a user,
>      they should be treated as any other personally identifiable
>      information. In particular, the IMEI SHOULD NOT be included in
>      messages intended to convey any level of anonymity.
> 
> The other major outstanding issue is interoperability. The main issue, I
> believe, is whether you will end up with systems that only accept IMEI
> URNs when use of the protocol in a broader context requires the use of
> general URNs or even URIs.
> 
> The "Community considerations" section of draft-montemurro-gsma-imei-uri
> currently deals exclusively with the ability for general-purpose
> Internet implementations to deal with 3GPP-specific identifiers. We need
> text that addresses the complementary issue of 3GPP implementations
> dealing with general-purpose Internet identifiers.
> 
> I would propose adding text to the end of this section, along the lines
> of:
> 
>      Conversely, Internet implementations will not generally posses
>      IMEI identifiers. The identifiers generated by such implementations
>      will typically be URNs within namespaces other than "gsma," and
>      may, depending on context, even be non-URN URIs. Implementations
>      are advised to correctly process URIs other than "gsma"-namespaced
>      URNs, so as to aid in interoperability.
> 
> 
> /a
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From adam@nostrum.com  Tue Oct 25 12:15:58 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1955E21F8ABB for ; Tue, 25 Oct 2011 12:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3afrrCwZpDcH for ; Tue, 25 Oct 2011 12:15:57 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 87F0C21F87C9 for ; Tue, 25 Oct 2011 12:15:57 -0700 (PDT)
Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9PJFr6N079398 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Oct 2011 14:15:54 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4EA70AE7.6050007@nostrum.com>
Date: Tue, 25 Oct 2011 14:15:51 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Andrew Allen 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <4EA6D17C.3050107@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: "dispatch@ietf.org list" , Michael Montemurro 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Oct 2011 19:15:58 -0000

On 10/25/11 10:20, Oct 25, Andrew Allen wrote:
> Do you however agree that this text would be better in the draft-allen-dispatch-imei-urn-as-instanceid which specified the usage of the IMEI URN in SIP rather than in the draft-montemurro-gsma-imei-urn which only defines the URN.
>

As far as my memory goes, instance IDs in normal usage only go between a 
UE and its registrar. The privacy issue doesn't arise in this case. So 
the note about not transmitting IMEIs in purportedly anonymous messages 
wouldn't make much sense there. Right? Or am I forgetting about some use 
of instance IDs that can make it to another user?

As far as interop goes, this does apply to the instance ID case, but it 
*also* applies to every other situation in which one might think of 
using an IMEI URN. It would seem to address the situation more broadly 
to put the interop discussion in the URN draft, then.

Is there some reason you would prefer one document over the other?

/a

From atle.monrad@ericsson.com  Wed Oct 26 02:44:23 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5FA21F8A97 for ; Wed, 26 Oct 2011 02:44:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEgm6SEfTBuA for ; Wed, 26 Oct 2011 02:44:23 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF1C21F8A66 for ; Wed, 26 Oct 2011 02:44:22 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-71-4ea7d6746b21
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 31.A9.20773.476D7AE4; Wed, 26 Oct 2011 11:44:21 +0200 (CEST)
Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.187]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 26 Oct 2011 11:44:20 +0200
From: Atle Monrad 
To: Andrew Allen , Adam Roach , "DRAGE, Keith (Keith)" 
Date: Wed, 26 Oct 2011 11:44:19 +0200
Thread-Topic: [dispatch]	draft-montemurro-gsma-imei-uri	and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AQHMkplwK9cWE1Ok1Um/mLi8u637fJWNfzAA//+tjyCAATBZcA==
Message-ID: <7A051DFAA46D0246A82293C7CEF621E9056D64D8AC@ESESSCMS0352.eemea.ericsson.se>
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <4EA6D17C.3050107@nostrum.com> 
In-Reply-To: 
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: nb-NO, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org list" , Michael Montemurro 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 09:44:23 -0000

Adam

Thanks for concrete and constructive proposals.

I have no strong preference for in which draft to place the added text.

You proposed text start off with "IMEIs can generally be correlated to a us=
er" ... IMEI SHOULD NOT ...   "IMEIs can loosely be correlated to a user" .=
.. IMEI SHOULD NOT ...

I think I would have used the same phrase throughout, and IMHO, the "loosel=
y correlated" is the better of the two. As the subscription is decoupled fr=
om the physical handset in 3GPP, it is just a educated assumption that the =
handset will be used by the same subscriber all the time ;-)

my 2 cents for now
cheers
/atle

________________________________=20


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management=20
Ericsson

=20


-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Andrew Allen
Sent: 25. oktober 2011 17:21
To: Adam Roach; DRAGE, Keith (Keith)
Cc: dispatch@ietf.org list; Michael Montemurro
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-disp=
atch-imei-urn-as-instanceid

Adam

We are quite happy to add the text you propose. I think this text is perfec=
tly aligned with the current 3GPP usage.=20

Do you however agree that this text would be better in the draft-allen-disp=
atch-imei-urn-as-instanceid which specified the usage of the IMEI URN in SI=
P rather than in the draft-montemurro-gsma-imei-urn which only defines the =
URN.

Andrew

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20
> Behalf Of Adam Roach
> Sent: Tuesday, October 25, 2011 10:11 AM
> To: DRAGE, Keith (Keith)
> Cc: dispatch@ietf.org list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and=20
> draft-allen- dispatch-imei-urn-as-instanceid
>=20
> On 10/24/11 17:07, Oct 24, DRAGE, Keith (Keith) wrote:
> > I believe the way it is used in 3GPP the IMEI is not visible to any
> other than the end user who owns the phone and the network. I do not=20
> believe it is seen by any other user (barring someone of course=20
> deliberately revealing it).
>=20
> That's the real concern. If what you say is true, then I agree that=20
> there is no problem. Also, if what you say is true, there is certainly=20
> no harm in including that fact as an important security property in=20
> the document itself.
>=20
> In the spirit of "send text," I would propose extending the first=20
> paragraph of the "Security Considerations" section in=20
> draft-montemurro-gsma-imei-uri by adding:
>=20
>      Further, because IMEIs can generally be correlated to a user,
>      they should be treated as any other personally identifiable
>      information. In particular, the IMEI SHOULD NOT be included in
>      messages intended to convey any level of anonymity.
>      Further, because IMEIs can loosely be correlated to a user,
>      they should be treated as any other personally identifiable
>      information. In particular, the IMEI SHOULD NOT be included in
>      messages intended to convey any level of anonymity.
>=20
> The other major outstanding issue is interoperability. The main issue,=20
> I believe, is whether you will end up with systems that only accept=20
> IMEI URNs when use of the protocol in a broader context requires the=20
> use of general URNs or even URIs.
>=20
> The "Community considerations" section of=20
> draft-montemurro-gsma-imei-uri currently deals exclusively with the=20
> ability for general-purpose Internet implementations to deal with=20
> 3GPP-specific identifiers. We need text that addresses the=20
> complementary issue of 3GPP implementations dealing with general-purpose =
Internet identifiers.
>=20
> I would propose adding text to the end of this section, along the=20
> lines
> of:
>=20
>      Conversely, Internet implementations will not generally posses
>      IMEI identifiers. The identifiers generated by such implementations
>      will typically be URNs within namespaces other than "gsma," and
>      may, depending on context, even be non-URN URIs. Implementations
>      are advised to correctly process URIs other than "gsma"-namespaced
>      URNs, so as to aid in interoperability.
>=20
>=20
> /a
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From keith.drage@alcatel-lucent.com  Wed Oct 26 04:05:55 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD5321F8B2A for ; Wed, 26 Oct 2011 04:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.109
X-Spam-Level: 
X-Spam-Status: No, score=-106.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0pH+lIGks8D for ; Wed, 26 Oct 2011 04:05:54 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3066421F8ACC for ; Wed, 26 Oct 2011 04:05:54 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9QB5Xuv017996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Oct 2011 13:05:47 +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; Wed, 26 Oct 2011 13:05:44 +0200
From: "DRAGE, Keith (Keith)" 
To: Adam Roach 
Date: Wed, 26 Oct 2011 13:05:42 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcyTKFIVuT/yRw1uRjO8Fcax0dkZYQApW2gA
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <4EA6D17C.3050107@nostrum.com>
In-Reply-To: <4EA6D17C.3050107@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.69 on 155.132.188.13
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 11:05:55 -0000

I guess the only comment I have on the proposed text is on:

>      may, depending on context, even be non-URN URIs. Implementations
>      are advised to correctly process URIs other than "gsma"-namespaced
>      URNs, so as to aid in interoperability.

And what "correctly process" means.

Generally in IMS all instance IDs in all forms will be correctly processed =
- all that is required for operation is that it is a unique identifier. How=
ever if you have an IMEI you are supposed to use it, and if you have access=
ed over a 3GPP access technology where you would have been required to prov=
ide one and the same IMEI, you should not change horses in midstream and de=
cide at the SIP level that the equipment has a different identifier.

The end result is that if you use IMEI at the access transport level, and t=
hen fail to use IMEI at the SIP level, the instance ID may have been correc=
tly processed, but you may be denied service at some point from then on bas=
ed on EIR checks.

Keith

> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: 25 October 2011 16:11
> To: DRAGE, Keith (Keith)
> Cc: Cullen Jennings; Worley, Dale R (Dale); dispatch@ietf.org list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
>=20
> On 10/24/11 17:07, Oct 24, DRAGE, Keith (Keith) wrote:
> > I believe the way it is used in 3GPP the IMEI is not visible to any
> other than the end user who owns the phone and the network. I do not
> believe it is seen by any other user (barring someone of course
> deliberately revealing it).
>=20
> That's the real concern. If what you say is true, then I agree that
> there is no problem. Also, if what you say is true, there is certainly
> no harm in including that fact as an important security property in the
> document itself.
>=20
> In the spirit of "send text," I would propose extending the first
> paragraph of the "Security Considerations" section in
> draft-montemurro-gsma-imei-uri by adding:
>=20
>      Further, because IMEIs can generally be correlated to a user,
>      they should be treated as any other personally identifiable
>      information. In particular, the IMEI SHOULD NOT be included in
>      messages intended to convey any level of anonymity.
>      Further, because IMEIs can loosely be correlated to a user,
>      they should be treated as any other personally identifiable
>      information. In particular, the IMEI SHOULD NOT be included in
>      messages intended to convey any level of anonymity.
>=20
> The other major outstanding issue is interoperability. The main issue, I
> believe, is whether you will end up with systems that only accept IMEI
> URNs when use of the protocol in a broader context requires the use of
> general URNs or even URIs.
>=20
> The "Community considerations" section of draft-montemurro-gsma-imei-uri
> currently deals exclusively with the ability for general-purpose
> Internet implementations to deal with 3GPP-specific identifiers. We need
> text that addresses the complementary issue of 3GPP implementations
> dealing with general-purpose Internet identifiers.
>=20
> I would propose adding text to the end of this section, along the lines
> of:
>=20
>      Conversely, Internet implementations will not generally posses
>      IMEI identifiers. The identifiers generated by such implementations
>      will typically be URNs within namespaces other than "gsma," and
>      may, depending on context, even be non-URN URIs. Implementations
>      are advised to correctly process URIs other than "gsma"-namespaced
>      URNs, so as to aid in interoperability.
>=20
>=20
> /a

From adam@nostrum.com  Wed Oct 26 04:44:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416D421F8A70 for ; Wed, 26 Oct 2011 04:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BP0EuyHUgjr for ; Wed, 26 Oct 2011 04:44:46 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D127A21F8A69 for ; Wed, 26 Oct 2011 04:44:46 -0700 (PDT)
Received: from [192.168.0.159] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9QBiJp4006324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Oct 2011 06:44:21 -0500 (CDT) (envelope-from adam@nostrum.com)
References:  <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>   <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET> <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <4EA6D17C.3050107@nostrum.com>  <7A051DFAA46D0246A82293C7CEF621E9056D64D8AC@ESESSCMS0352.eemea.ericsson.se>
In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E9056D64D8AC@ESESSCMS0352.eemea.ericsson.se>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: 
X-Mailer: iPad Mail (9A334)
From: Adam Roach 
Date: Wed, 26 Oct 2011 06:44:20 -0500
To: Atle Monrad 
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: "dispatch@ietf.org list" , Michael Montemurro 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 11:44:47 -0000

On Oct 26, 2011, at 4:44, Atle Monrad  wrote:

> Adam
>=20
> Thanks for concrete and constructive proposals.
>=20
> I have no strong preference for in which draft to place the added text.
>=20
> You proposed text start off with "IMEIs can generally be correlated to a u=
ser" ... IMEI SHOULD NOT ...   "IMEIs can loosely be correlated to a user" .=
.. IMEI SHOULD NOT ...
>=20
> I think I would have used the same phrase throughout, and IMHO, the "loose=
ly correlated" is the better of the two.

Whoops... I had edited the text several times, and somehow managed to paste i=
n the final and second-to-final versions right next to each other. "Loosely"=
 was the version I meant to include.=20

/a=

From pkyzivat@alum.mit.edu  Wed Oct 26 07:04:10 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B807C21F899D for ; Wed, 26 Oct 2011 07:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level: 
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE2K6vtK+yyG for ; Wed, 26 Oct 2011 07:04:09 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id B65BA21F8B3D for ; Wed, 26 Oct 2011 07:04:07 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id pNyA1h0061ZXKqc53S43vk; Wed, 26 Oct 2011 14:04:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id pS431h00H0tdiYw3hS43xN; Wed, 26 Oct 2011 14:04:03 +0000
Message-ID: <4EA81351.4020609@alum.mit.edu>
Date: Wed, 26 Oct 2011 10:04:01 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dispatch@ietf.org
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <4EA6D17C.3050107@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 14:04:10 -0000

On 10/26/11 7:05 AM, DRAGE, Keith (Keith) wrote:
> I guess the only comment I have on the proposed text is on:
>
>>       may, depending on context, even be non-URN URIs. Implementations
>>       are advised to correctly process URIs other than "gsma"-namespaced
>>       URNs, so as to aid in interoperability.
>
> And what "correctly process" means.
>
> Generally in IMS all instance IDs in all forms will be correctly processed - all that is required for operation is that it is a unique identifier. However if you have an IMEI you are supposed to use it, and if you have accessed over a 3GPP access technology where you would have been required to provide one and the same IMEI, you should not change horses in midstream and decide at the SIP level that the equipment has a different identifier.
>
> The end result is that if you use IMEI at the access transport level, and then fail to use IMEI at the SIP level, the instance ID may have been correctly processed, but you may be denied service at some point from then on based on EIR checks.

IIUC, you are saying:

- when connected over an IMS transport (which is tied to an IMEI)
   a device clearly *has* an IMEI, and is expected to use an
   instance id containing it.

- when connected over a non-IMS transport (which is the only
   option for a non-IMS device), another form of instance id will
   be ok.

Do I have that right?

	Thanks,
	Paul

> Keith
>
>> -----Original Message-----
>> From: Adam Roach [mailto:adam@nostrum.com]
>> Sent: 25 October 2011 16:11
>> To: DRAGE, Keith (Keith)
>> Cc: Cullen Jennings; Worley, Dale R (Dale); dispatch@ietf.org list
>> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
>> dispatch-imei-urn-as-instanceid
>>
>> On 10/24/11 17:07, Oct 24, DRAGE, Keith (Keith) wrote:
>>> I believe the way it is used in 3GPP the IMEI is not visible to any
>> other than the end user who owns the phone and the network. I do not
>> believe it is seen by any other user (barring someone of course
>> deliberately revealing it).
>>
>> That's the real concern. If what you say is true, then I agree that
>> there is no problem. Also, if what you say is true, there is certainly
>> no harm in including that fact as an important security property in the
>> document itself.
>>
>> In the spirit of "send text," I would propose extending the first
>> paragraph of the "Security Considerations" section in
>> draft-montemurro-gsma-imei-uri by adding:
>>
>>       Further, because IMEIs can generally be correlated to a user,
>>       they should be treated as any other personally identifiable
>>       information. In particular, the IMEI SHOULD NOT be included in
>>       messages intended to convey any level of anonymity.
>>       Further, because IMEIs can loosely be correlated to a user,
>>       they should be treated as any other personally identifiable
>>       information. In particular, the IMEI SHOULD NOT be included in
>>       messages intended to convey any level of anonymity.
>>
>> The other major outstanding issue is interoperability. The main issue, I
>> believe, is whether you will end up with systems that only accept IMEI
>> URNs when use of the protocol in a broader context requires the use of
>> general URNs or even URIs.
>>
>> The "Community considerations" section of draft-montemurro-gsma-imei-uri
>> currently deals exclusively with the ability for general-purpose
>> Internet implementations to deal with 3GPP-specific identifiers. We need
>> text that addresses the complementary issue of 3GPP implementations
>> dealing with general-purpose Internet identifiers.
>>
>> I would propose adding text to the end of this section, along the lines
>> of:
>>
>>       Conversely, Internet implementations will not generally posses
>>       IMEI identifiers. The identifiers generated by such implementations
>>       will typically be URNs within namespaces other than "gsma," and
>>       may, depending on context, even be non-URN URIs. Implementations
>>       are advised to correctly process URIs other than "gsma"-namespaced
>>       URNs, so as to aid in interoperability.
>>
>>
>> /a
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>


From dworley@avaya.com  Wed Oct 26 11:42:23 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D701A21F8564 for ; Wed, 26 Oct 2011 11:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.168
X-Spam-Level: 
X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVeQA50X37be for ; Wed, 26 Oct 2011 11:42:22 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id EDBA721F8558 for ; Wed, 26 Oct 2011 11:42:21 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANZTqE6HCzI1/2dsb2JhbABCqUyBBYFuAQEBAQIBEig6BQULAgEIDQEHIRAyJQEBBA4FCBEJh14ImSKbeogJYQSZVowv
X-IronPort-AV: E=Sophos;i="4.69,410,1315195200"; d="scan'208";a="274590446"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Oct 2011 14:42:19 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Oct 2011 14:31:39 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 26 Oct 2011 14:42:18 -0400
From: "Worley, Dale R (Dale)" 
To: Cullen Jennings 
Date: Wed, 26 Oct 2011 14:41:55 -0400
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySUfimWdq2grxFTYq9xRx9wqrm7ABvPZsl
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>
In-Reply-To: <234F9B2D-1FE7-417C-80A9-36497A9275CD@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: "dispatch@ietf.org list" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 18:42:24 -0000

> From: Cullen Jennings [fluffy@cisco.com]

[Cullen's paragraphs re-ordered]

> [...]   I get the feeling that you think the chairs on not
> doing something they should.  [...]
> If you think there is something where my individual opinions
> are causing the chairs not to do the right things, please, grab a
> phone and call me about it and we will figure out a way where everyone
> agrees the chairs are doing the right thing. I'm not a fan of the
> current passive aggressive approach.

I've been trying to be as un-passive as possible, though my day job
has gotten in the way.  (Somehow my boss thinks I shouldn't devote
100% of my time to the IETF!)  I've sent two messages "formally
requesting" action (msg03768.html, msg03833.html).  I do feel that the
chairs have not been taking action in the face of a solid consensus.
If I am correct, it's a matter for the entire WG to consider.

Though, I may be entirely mistaken as to whether the chairs are in a
position to do anything at all, which would be rather ironic.  I've
got to check that out.

> Interoperability.
>=20
> I've asked multiple people does this happen in INVITEs or just
> REGISTERs and got mixed answers.

It looks like (msg03902.html), in the 3GPP world, phones have to
present a sip.instance URN in some INVITEs, but that's a constraint on
life in 3GPP, not a general constraint on SIP.  It also appears that
the sip.instance is stripped from the INVITEs before it reaches any
other UA.

In addition, as long as a sip.instance URN is unique to the phone, it
presents essentially the same privacy considerations -- excepting if a
"receiver" of the URN has a database providing more owner information
about URNs.  So replacing an IMEI-based URN with a MAC-based URN does
not improve privacy at all.  (Presumably any 3GPP database containing
IMEIs of phones could easily include their MACs as well.)

*If* a network enforces a restriction that a UA present a sip.instance
URN in INVITEs, that has interesting privacy considerations, and
should be documented for the edification of the masses, *but* I can
see no reason that defining a new URN scheme will increase or decrease
any privacy concern.

To repeat from my message of 20 Sept. (msg03779.html):
- However, the problems resulting from this seem to be essentially the
- same when the +sip.instance is derived from an IMEI as when it is
- derived from a MAC address.

> It makes a big difference - at some
> level this is a proposal to black list phones and / or part of a
> malware prevention systems. Or perhaps it is a proposal to white list
> phones and ones that don't have this won't work. You can say this
> going to be restricted to just the sets of people that want to use it
> but that is seldom how standards work out That might be true in the
> cases of if it only went from a phone to the domain for it's
> AOR. However, if this will also be used in INVITE cases, would it stop
> calls from any 3GPP phone to non 3GPP phone? Making sure that we did
> not have needless lack of interoperability between classic IETF SIP
> and 3GPP style SIP has always been a goal. Even if this is only only
> on IMS phones, theses are now used well outside the mobile environment
> - we see them used on wireline and enterprise environments so would
> there be a problem from other SIP devices to theses. Could a soft
> phone get the required IMEI identifier so it was not blacklisted?
> Could a small vendor get them? These are all things I wonder.

I'm having trouble following you here.  But it seems to me that if a
*any* service provider wants to whitelist or blacklist phones based on
any particular characteristic or for any particular type of service,
it won't be hard for them to do so.  And anyone who wants to
whitelist/blacklist will do so by maintaining a database of
identifiers.  Preventing any particular *type* of identifier from
being used isn't going to stop anyone.

To repeat from my message of 20 Sept. (msg03779.html):
- However, the problems resulting from this seem to be essentially the
- same when the +sip.instance is derived from an IMEI as when it is
- derived from a MAC address.

> It's impossible to answer any of the above questions without knowing
> something about how this blacklisting stuff works and what this
> identifier is used for.  [...]

It doesn't seem to me that any of those questions need answering by us
at this time:  In practice, any service provider can be as restrictive
about usage as it is willing to expend the effort to enforce.

> So this is my most
> important question to you - Do you think this is unreasonable that we
> should ask how this works and if there are interoperability problems?

Well, I'm not exactly sure what you mean by the "this" that works, but
I haven't seen any reason to believe that we need to know how "this"
works, in that "this" and its potential problems are essentially
independent of the sip.instance *scheme*, and is probably confined
entirely to particular walled-gardens.

> On a minor notes related to references - I'm not objecting based on
> process crap around the references but it would be really really nice
> if the drafts could be updated so that the reference pointed at a
> specific document - not a vague family of documents where I have no
> idea if I am reading the right one or not. I never know what to read
> when I see 3GPP 24.237 but if you gave me a date and version, or even
> a link, it would be easier.

A valid point, although I find that if I feed "3GPP 24.237" into
Google, the top hit is
http://www.3gpp.org/ftp/Specs/html-info/24237.htm, which leads to a
page titled "IP Multimedia (IM) Core Network (CN) subsystem IP
Multimedia Subsystem (IMS) service continuity; Stage 3" with a bunch
of download links.  It looks like the documents require registration
to download, but are free-of-charge.  So I think the references can be
cleaned up at the editorial stage.

> So let me be very clear on what I am looking for to start the
> interoperability discussion. We need to understand the specification
> for this to decide what interoperability problems there may or may not
> be. My assumptions how how this works may be very wrong. Lets get the
> facts and make an informed decision.

I can't imagine how the URN *scheme* that 3GPP prefers to use is going
to make any significant difference in interoperability with UAs
outside the 3GPP access network.

> Privacy
>=20
> So what's the position of everyone that has been sending opinions of
> this draft. Is the IMEI of my phone personal identifying information
> or now? Sort of hard to have a discussion without deciding that first.

The IMEI is undoubtedly personal identifying information to the same
degree that the MAC address is.  Indeed, any sip.instance URN is
supposed to be unique to a particular UA, and so constitutes personal
identifying information.  Creating a new URN scheme for IMEIs isn't
going to change the privacy situation.

To repeat from my message of 20 Sept. (msg03779.html):
- However, the problems resulting from this seem to be essentially the
- same when the +sip.instance is derived from an IMEI as when it is
- derived from a MAC address.

> IPR
>=20
> On the topic of IPR. I think we need to sort out some of the simpler
> issues first and in the end I will probably rather have the IPR
> discussion on the ietf list than here. To put it pretty bluntly, the
> IETF list is a more favorable environment for the arguments I will
> probably make around IPR. It always fascinates me me to see the
> proponents of this draft sending nasty grams to the chairs telling
> them do something that process wise they can't do but would
> effectively move the conversation from the dispatch list to the ietf
> list while at the same time the ADs and Chairs are trying to resolve
> the conversation in dispatch first which is typically much less
> concerned about IPR than the IETF is in general.  I will note that
> Gonzalo thinks my drafts runs into the Andrews's patents but I have
> been working on the assumption that it does not as Andrew commented on
> it and did not file any IPR disclosure or notify the WG.

When you get around to formulating an objection, we can talk about it.

But as far as I can tell, any URI problems will be confined to the
3GPP walled garden, and they already have a system for dealing with
it.

To repeat from my message of 20 Sept. (msg03779.html):
- Though this proposal may be encumbered by IPR claims, the only users
- who would be *required* to use this URN format are products within the
- GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts this
- as mandatory-to-implement.  Those users might be subjected to an
- unconscionable tax, but the GSM/3GPP/IMS universe has its own
- political/economic structure for deciding what licensed technology is
- mandatory to implement and what licensing terms are considered
- acceptable.  It seems to me that we can justly leave these questions
- to GSM/3GPP/IMS.

So, at this point, I don't think we've identified any serious problems
that need to be investigated realtive to advancing the definition of
an IMEI-based URN.

Dale

From dworley@avaya.com  Wed Oct 26 11:52:01 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1335021F8498 for ; Wed, 26 Oct 2011 11:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.456
X-Spam-Level: 
X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-3dHOsMcdG0 for ; Wed, 26 Oct 2011 11:52:00 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 432F021F8491 for ; Wed, 26 Oct 2011 11:52:00 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAExWqE6HCzI1/2dsb2JhbABCqUyBBYFuAQEBAQIBEig/BQsCAQgNCCEQMiUBAQQOBQgTB4demTebeYgJYQSZVowv
X-IronPort-AV: E=Sophos;i="4.69,410,1315195200"; d="scan'208";a="274591968"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Oct 2011 14:51:59 -0400
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Oct 2011 14:41:19 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 26 Oct 2011 14:51:57 -0400
From: "Worley, Dale R (Dale)" 
To: Adam Roach 
Date: Wed, 26 Oct 2011 14:49:54 -0400
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcySh8XS5c5GfaHCRGSoBa606TemzQBiEaq0
Message-ID: 
References: , <4EA5C42A.7030707@nostrum.com>
In-Reply-To: <4EA5C42A.7030707@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: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 18:52:01 -0000

> From: Adam Roach [adam@nostrum.com]
>=20
> (I can't find the remaining five voices of support you mention, but I
> suspect they have similar technical content.)

Technical content isn't needed when expressing the desirability of
constructing a solution to a problem.

Dale

From keith.drage@alcatel-lucent.com  Wed Oct 26 12:10:38 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ECD21F85C7 for ; Wed, 26 Oct 2011 12:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.116
X-Spam-Level: 
X-Spam-Status: No, score=-106.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob3ib6OA63yQ for ; Wed, 26 Oct 2011 12:10:28 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E6CB821F8498 for ; Wed, 26 Oct 2011 12:10:26 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9QJAN1F030299 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Oct 2011 21:10:23 +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; Wed, 26 Oct 2011 21:10:23 +0200
From: "DRAGE, Keith (Keith)" 
To: Paul Kyzivat , "dispatch@ietf.org" 
Date: Wed, 26 Oct 2011 21:10:21 +0200
Thread-Topic: [dispatch] draft-montemurro-gsma-imei-uri	and draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcyT6EIu8txP9if1QK+N5XIvrx9F6gAKkGlA
Message-ID: 
References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <4EA6D17C.3050107@nostrum.com>  <4EA81351.4020609@alum.mit.edu>
In-Reply-To: <4EA81351.4020609@alum.mit.edu>
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.69 on 155.132.188.80
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	and	draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 19:10:38 -0000

Not quite.

IMS supports a number of access technologies, some of them 3GPP specific an=
d some not (e.g. TISPAN, Cablelabs)

When using a 3GPP access technology, you will have had to use an IMEI, and =
you are expected to continue to use to in IMS SIP when accessing over that =
3GPP access technology.

For a non-3GPP access technology, you will probably not have an IMEI, and t=
he general rules specified by IETF for instance IDs apply, i.e. use some ap=
propriate unique identifier.

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: 26 October 2011 15:04
> To: dispatch@ietf.org
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
>=20
> On 10/26/11 7:05 AM, DRAGE, Keith (Keith) wrote:
> > I guess the only comment I have on the proposed text is on:
> >
> >>       may, depending on context, even be non-URN URIs. Implementations
> >>       are advised to correctly process URIs other than "gsma"-
> namespaced
> >>       URNs, so as to aid in interoperability.
> >
> > And what "correctly process" means.
> >
> > Generally in IMS all instance IDs in all forms will be correctly
> processed - all that is required for operation is that it is a unique
> identifier. However if you have an IMEI you are supposed to use it, and i=
f
> you have accessed over a 3GPP access technology where you would have been
> required to provide one and the same IMEI, you should not change horses i=
n
> midstream and decide at the SIP level that the equipment has a different
> identifier.
> >
> > The end result is that if you use IMEI at the access transport level,
> and then fail to use IMEI at the SIP level, the instance ID may have been
> correctly processed, but you may be denied service at some point from the=
n
> on based on EIR checks.
>=20
> IIUC, you are saying:
>=20
> - when connected over an IMS transport (which is tied to an IMEI)
>    a device clearly *has* an IMEI, and is expected to use an
>    instance id containing it.
>=20
> - when connected over a non-IMS transport (which is the only
>    option for a non-IMS device), another form of instance id will
>    be ok.
>=20
> Do I have that right?
>=20
> 	Thanks,
> 	Paul
>=20
> > Keith
> >
> >> -----Original Message-----
> >> From: Adam Roach [mailto:adam@nostrum.com]
> >> Sent: 25 October 2011 16:11
> >> To: DRAGE, Keith (Keith)
> >> Cc: Cullen Jennings; Worley, Dale R (Dale); dispatch@ietf.org list
> >> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen=
-
> >> dispatch-imei-urn-as-instanceid
> >>
> >> On 10/24/11 17:07, Oct 24, DRAGE, Keith (Keith) wrote:
> >>> I believe the way it is used in 3GPP the IMEI is not visible to any
> >> other than the end user who owns the phone and the network. I do not
> >> believe it is seen by any other user (barring someone of course
> >> deliberately revealing it).
> >>
> >> That's the real concern. If what you say is true, then I agree that
> >> there is no problem. Also, if what you say is true, there is certainly
> >> no harm in including that fact as an important security property in th=
e
> >> document itself.
> >>
> >> In the spirit of "send text," I would propose extending the first
> >> paragraph of the "Security Considerations" section in
> >> draft-montemurro-gsma-imei-uri by adding:
> >>
> >>       Further, because IMEIs can generally be correlated to a user,
> >>       they should be treated as any other personally identifiable
> >>       information. In particular, the IMEI SHOULD NOT be included in
> >>       messages intended to convey any level of anonymity.
> >>       Further, because IMEIs can loosely be correlated to a user,
> >>       they should be treated as any other personally identifiable
> >>       information. In particular, the IMEI SHOULD NOT be included in
> >>       messages intended to convey any level of anonymity.
> >>
> >> The other major outstanding issue is interoperability. The main issue,
> I
> >> believe, is whether you will end up with systems that only accept IMEI
> >> URNs when use of the protocol in a broader context requires the use of
> >> general URNs or even URIs.
> >>
> >> The "Community considerations" section of draft-montemurro-gsma-imei-
> uri
> >> currently deals exclusively with the ability for general-purpose
> >> Internet implementations to deal with 3GPP-specific identifiers. We
> need
> >> text that addresses the complementary issue of 3GPP implementations
> >> dealing with general-purpose Internet identifiers.
> >>
> >> I would propose adding text to the end of this section, along the line=
s
> >> of:
> >>
> >>       Conversely, Internet implementations will not generally posses
> >>       IMEI identifiers. The identifiers generated by such
> implementations
> >>       will typically be URNs within namespaces other than "gsma," and
> >>       may, depending on context, even be non-URN URIs. Implementations
> >>       are advised to correctly process URIs other than "gsma"-
> namespaced
> >>       URNs, so as to aid in interoperability.
> >>
> >>
> >> /a
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From pkyzivat@alum.mit.edu  Wed Oct 26 12:22:40 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB37621F8B79 for ; Wed, 26 Oct 2011 12:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level: 
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXVbD9B3+EIn for ; Wed, 26 Oct 2011 12:22:40 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id D2B0A21F8B77 for ; Wed, 26 Oct 2011 12:22:39 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta15.westchester.pa.mail.comcast.net with comcast id pXDK1h0010SCNGk5FXNg7L; Wed, 26 Oct 2011 19:22:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta09.westchester.pa.mail.comcast.net with comcast id pXNf1h01M0tdiYw3VXNfNe; Wed, 26 Oct 2011 19:22:40 +0000
Message-ID: <4EA85DFD.8000208@alum.mit.edu>
Date: Wed, 26 Oct 2011 15:22:37 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" 
References: <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr>  <234F9B2D-1FE7-417C-80A9-36497A9275CD@cisco.com>  <4EA6D17C.3050107@nostrum.com>  <4EA81351.4020609@alum.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri	and draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 19:22:40 -0000

Thanks Keith.

On 10/26/11 3:10 PM, DRAGE, Keith (Keith) wrote:
> Not quite.
>
> IMS supports a number of access technologies, some of them 3GPP specific and some not (e.g. TISPAN, Cablelabs)
>
> When using a 3GPP access technology, you will have had to use an IMEI, and you are expected to continue to use to in IMS SIP when accessing over that 3GPP access technology.
>
> For a non-3GPP access technology, you will probably not have an IMEI, and the general rules specified by IETF for instance IDs apply, i.e. use some appropriate unique identifier.
>
> Keith
>
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
>> Behalf Of Paul Kyzivat
>> Sent: 26 October 2011 15:04
>> To: dispatch@ietf.org
>> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
>> dispatch-imei-urn-as-instanceid
>>
>> On 10/26/11 7:05 AM, DRAGE, Keith (Keith) wrote:
>>> I guess the only comment I have on the proposed text is on:
>>>
>>>>        may, depending on context, even be non-URN URIs. Implementations
>>>>        are advised to correctly process URIs other than "gsma"-
>> namespaced
>>>>        URNs, so as to aid in interoperability.
>>>
>>> And what "correctly process" means.
>>>
>>> Generally in IMS all instance IDs in all forms will be correctly
>> processed - all that is required for operation is that it is a unique
>> identifier. However if you have an IMEI you are supposed to use it, and if
>> you have accessed over a 3GPP access technology where you would have been
>> required to provide one and the same IMEI, you should not change horses in
>> midstream and decide at the SIP level that the equipment has a different
>> identifier.
>>>
>>> The end result is that if you use IMEI at the access transport level,
>> and then fail to use IMEI at the SIP level, the instance ID may have been
>> correctly processed, but you may be denied service at some point from then
>> on based on EIR checks.
>>
>> IIUC, you are saying:
>>
>> - when connected over an IMS transport (which is tied to an IMEI)
>>     a device clearly *has* an IMEI, and is expected to use an
>>     instance id containing it.
>>
>> - when connected over a non-IMS transport (which is the only
>>     option for a non-IMS device), another form of instance id will
>>     be ok.
>>
>> Do I have that right?
>>
>> 	Thanks,
>> 	Paul
>>
>>> Keith
>>>
>>>> -----Original Message-----
>>>> From: Adam Roach [mailto:adam@nostrum.com]
>>>> Sent: 25 October 2011 16:11
>>>> To: DRAGE, Keith (Keith)
>>>> Cc: Cullen Jennings; Worley, Dale R (Dale); dispatch@ietf.org list
>>>> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
>>>> dispatch-imei-urn-as-instanceid
>>>>
>>>> On 10/24/11 17:07, Oct 24, DRAGE, Keith (Keith) wrote:
>>>>> I believe the way it is used in 3GPP the IMEI is not visible to any
>>>> other than the end user who owns the phone and the network. I do not
>>>> believe it is seen by any other user (barring someone of course
>>>> deliberately revealing it).
>>>>
>>>> That's the real concern. If what you say is true, then I agree that
>>>> there is no problem. Also, if what you say is true, there is certainly
>>>> no harm in including that fact as an important security property in the
>>>> document itself.
>>>>
>>>> In the spirit of "send text," I would propose extending the first
>>>> paragraph of the "Security Considerations" section in
>>>> draft-montemurro-gsma-imei-uri by adding:
>>>>
>>>>        Further, because IMEIs can generally be correlated to a user,
>>>>        they should be treated as any other personally identifiable
>>>>        information. In particular, the IMEI SHOULD NOT be included in
>>>>        messages intended to convey any level of anonymity.
>>>>        Further, because IMEIs can loosely be correlated to a user,
>>>>        they should be treated as any other personally identifiable
>>>>        information. In particular, the IMEI SHOULD NOT be included in
>>>>        messages intended to convey any level of anonymity.
>>>>
>>>> The other major outstanding issue is interoperability. The main issue,
>> I
>>>> believe, is whether you will end up with systems that only accept IMEI
>>>> URNs when use of the protocol in a broader context requires the use of
>>>> general URNs or even URIs.
>>>>
>>>> The "Community considerations" section of draft-montemurro-gsma-imei-
>> uri
>>>> currently deals exclusively with the ability for general-purpose
>>>> Internet implementations to deal with 3GPP-specific identifiers. We
>> need
>>>> text that addresses the complementary issue of 3GPP implementations
>>>> dealing with general-purpose Internet identifiers.
>>>>
>>>> I would propose adding text to the end of this section, along the lines
>>>> of:
>>>>
>>>>        Conversely, Internet implementations will not generally posses
>>>>        IMEI identifiers. The identifiers generated by such
>> implementations
>>>>        will typically be URNs within namespaces other than "gsma," and
>>>>        may, depending on context, even be non-URN URIs. Implementations
>>>>        are advised to correctly process URIs other than "gsma"-
>> namespaced
>>>>        URNs, so as to aid in interoperability.
>>>>
>>>>
>>>> /a
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>


From pkyzivat@alum.mit.edu  Wed Oct 26 14:13:23 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42A921F8509 for ; Wed, 26 Oct 2011 14:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.314
X-Spam-Level: 
X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRthoAUoDAVx for ; Wed, 26 Oct 2011 14:13:22 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3A021F84F5 for ; Wed, 26 Oct 2011 14:13:22 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id pXoi1h00727AodY51ZDNib; Wed, 26 Oct 2011 21:13:22 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id pZDM1h01R0tdiYw3fZDNBZ; Wed, 26 Oct 2011 21:13:22 +0000
Message-ID: <4EA877EF.5030401@alum.mit.edu>
Date: Wed, 26 Oct 2011 17:13:19 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Avasarala, Ranjit" 
References: <1F2A2C70609D9E41844A2126145FC0980442ADCB@HKGMBOXPRD22.polycom.com> <4EA07E7E.5060302@alum.mit.edu> <1F2A2C70609D9E41844A2126145FC0980442AF70@HKGMBOXPRD22.polycom.com>
In-Reply-To: <1F2A2C70609D9E41844A2126145FC0980442AF70@HKGMBOXPRD22.polycom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 21:13:23 -0000

Inline

On 10/24/11 4:50 AM, Avasarala, Ranjit wrote:
> Hi Paul
>
> My comments inline
>
> Regards
> Ranjit
>
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Friday, October 21, 2011 1:33 AM
> To: dispatch@ietf.org
> Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt
>
> Ranjit,
>
> I have just started to look at this version. It seems to be an
> improvement. Before I do a thorough review I'll bring up a few things
> that jumped out at me:
>
> Section 6.5:
>
>      All subscribers of "comm-div-info" event package who wish to add
>      filter criteria to their subscription requests MUST support the
>      application/comm-div-info-filter+xml" data format as described in
>      Section 8.1.1 while the notifiers SHALL support the "application/
>      comm-div-info+xml" data format as described in Section 8.1.2.  The
>      SUBSCRIBE request MAY contain an Accept header field.  If no such
>      header field is present, it has a default value of "application/
>      comm-div-info-ntfy+xml" (assuming Event header has a value of "comm-
>      div-info-ntfy").  If the Accept header field is present, it MUST
>      contain the value "application/comm-div-info-ntfy+xml" only.
>
> I think I know what you want to say, but this doesn't say it. What I
> think you are trying to say (or ought to be trying to say) is:
>
> - the subscriber that wants a filter has to encode it according
>     to the filter xml schema and indicate the content-type accordingly.
>
> - the notifier MUST be capable of accepting the filter xml, in case
>     a subscriber wants to use one.
>
> - the subscriber must always Accept receiving a notify xml
>     in the notify.
>
> - the notifier MUST encode notifications according to the notify
>     xml schema and indicate the content type accordingly.
>
> - The default Accept for a subscribe to this package is the
>     notify xml.
>
> If I have that right, we can discuss how to write a paragraph that says
> it concisely and clearly.
> 
> that seems "right". Except for:
>
> - the notifier MUST be capable of accepting the filter xml, in case
>     a subscriber wants to use one.
>
> In my opinion a notifier must always support the filter as it can't predict if a suberiber wants to use a filter.
> 

> I *think* that you are trying to allow notifiers that don't support
> filtering. I question the wisdom of that. And if you really want that, I
> think it would be helpful to consider what that means. Does it mean that
> the notifier ignores the presence of the filter document? Or does it
> mean that it recognizes the presence of the filter but chooses not to
> honor the filter? Could that refusal be partial? (I.e. it understands
> the document but chooses to not apply certain filter criteria?)
>
>   I am okay requiring the support for filters in the notifier

OK. That is simpler and cleaner.

> What about a subscriber that feels it needs the filter? It might choose
> not to subscribe if it can't have the filter. But then it either needs
> the subscribe to fail in that case, or else it needs a way to tell that
> the filter isn't being honored.
>
> I would think it better to have the subscribe rejected with a 415 if the
> notifier doesn't support filtering, or else have the notify indicate
> that the requested filter is not being applied.
>
>   I am okay requiring the support for filters in the notifier. If still not supported, sending a 415 is sufficient (and subscription for this event then fails).
>
> Section 6.11:
>
> I appreciate your having provided a state diagram. But I don't
> understand it.
>
>      +------------+  Diversion  +---------------+
>      |            +--+--------->+               |
>      |   IDLE     |  ^          |   DIVERSION   |
>      |            |  |  +------>+   DETECTED    |
>      +------------+  |  |       +--+----+-------+
>                      |  | no match      |  |filter
>                      +------------------+  |match
>                         |                  v
>                         |          +-------+-------+
>                         |          |   DIVERSION   |
>                         |          |    NOTIFIED   |
>                         |          +-----+---------+
>                         |    Diversion   |
>                         +----------------+
>
> As I read this, what I conclude is:
>
> - the subscriber will not learn about any diversions which occurred
>     prior to the subscription. (This may be what you intend.
>     at least its easy.)
>   Correct
>
> - the first diversion after subscribing moves to
>     DIVERSION DETECTED state.
>   Correct
>
> - upon entry to DIVERSION DETECTED, a filter match is
>     attempted. (Presumably this always succeeds if there
>     is no filter.)
>
>   well if we require the support of a filter then we shouldn't get here "if there is no filter" as then there was a 415 response?

I was assuming that if no filter is present, then there is no filtering 
- everything is selected for notification. (Otherwise it is a query 
rather than a filter.)

Do you intend that if there is no filter there will be no notifications?

Or are you expecting to return a 415 if no filter is present? It can't 
be used that way. (A missing body is not an unsupported media type.) I 
don't know of any good way to indicate that an expected body part is 
missing. You'd be better off defining *some* default behavior in the 
absence of a filter.

> - its unclear what happens if the filter fails to match.
>     The transition for that connects to the Diversion
>     transition. That would seem to create an infinite loop.
>     I expect the "no match" transition ought to go to IDLE.
>
>   well, we should transition to DIVERSION_DETECTED per "no match". The diversion did occur and was detected but no notification was sent. I would like to somehow express that the state machine stops at DIVERSION_DETECTED in this case. IDLE could be read as "NOTHING DETECTED" e.g. because there is no subscription so no need to detect anything.

I'm not understanding what you are trying to achieve.
But you need some state for the state machine to stall in while awaiting 
a diversion to occur. I thought that state was IDLE.

To clarify what you intend, you should enhance your diagram to include 
actions as well as states and events. And transitions should only occur 
based on events.

> - if the filter match succeeds, DIVERSION NOTIFIED state
>     is entered. No action is indicated. I suppose its implied
>     that a notification is sent.
>   we clarify that a notification is sent
>
>   Then apparently the subscription
>     remains in this state until another diversion occurs.
>     Then the transition is back to DIVERSION DETECTED, and
>     things repeat.
>
>   yes. So, I am not sure how to address the comment but perhaps the below diagram would capture the situation?

What diagram are you referring to?

> Upon detecting the first diversion, we enter the state machine, we attempt to match filters, then we're stuck in a state until we can satisfy the transition condition of detecting a next transition
> I'm also puzzling over:
>
>      The subscriber could receive, as part of the notification
>      information, the state the FSM was in prior to detecting the
>      diversion.
>
>      o  [IDLE]: meaning that there have been no missed diversions since
>         setting the present "filter".
>
>      o  [DIVERSION_NOTIFIED]: meaning that there have been no missed
>         diversions.
> actually, "notifications or diversions" are not missed due to all diversions matching filters

>      o  [DIVERSION_DETECTED]: meaning that there have been some missed
>         diversions.
> actually, "notifications or diversions" are missed due to diversions having failed to match any filters
>
> I don't get how that would work. It isn't going to report the missing of
> diversions that occurred prior to the subscribe, because the
> subscription always starts in the IDLE state.
>   Correct
>
> And I don't know how you
> miss diversions after the subscription is established.
>   see clarification.

I *thought* "missed" was referring to diversions occurring before the 
subscription was established. But I guess you mean it as diversions that 
were not requested to be notified.

If that is what you are interested in, I think you could accomplish it 
in a more straightforward way. Just have an element in the notification 
that indicates whether there have been unnotified diversions. (Or a 
count of unnotified diversions.)

	Thanks,
	Paul

> On 10/20/11 1:23 PM, Avasarala, Ranjit wrote:
>> Hi all
>> I have uploaded updated version of
>> draft-avasarala-dispatch-comm-div-notification-08.txt incorporating the
>> following comments
>>
>>   1. Updated the state information to reflect the CDIVN state and state
>>      diagram
>>   2. Added text to support subscription forking.
>>
>> _http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-08.txt_
>> Please review and comment
>> Thanks
>> Regards
>> Ranjit
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>


From fluffy@cisco.com  Thu Oct 27 08:22:47 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B957721F8B1A for ; Thu, 27 Oct 2011 08:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.351
X-Spam-Level: 
X-Spam-Status: No, score=-106.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLfOkLuMPPmw for ; Thu, 27 Oct 2011 08:22:47 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E979221F8B0E for ; Thu, 27 Oct 2011 08:22:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1852; q=dns/txt; s=iport; t=1319728967; x=1320938567; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6nIcOxDCEZ9zIJAM431q5ymyP8RutiW5IiJ8yYL52tE=; b=Y447COFy+xOHXrfN8jMwtfxubWw15Q5ReeG9A3x8yFyUvcuZiX40BcBW dSC8a5f7HAakIAI33GyZrEm3x5T4cWBIwbQvLdSTYKB1oA6/WdrCFszyS 7F8cU33Iz0OFIJ8zBVdZTwwqY86PZrCerBZSYJkEzPVLnmJW7Suulz0cy Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAJx2qU6rRDoH/2dsb2JhbAA6CaldgQWBcgEBAQMBAQEBDwEnNAsQCw4KLicwBhMih2AIljYBnl4EhVCCTWEEiAaMB4UtjFE
X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208";a="10697835"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Oct 2011 15:22:44 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9RFMhMA022111; Thu, 27 Oct 2011 15:22:43 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com>
Date: Thu, 27 Oct 2011 09:22:43 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>   <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com>
To: Hadriel Kaplan 
X-Mailer: Apple Mail (2.1084)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Oct 2011 15:22:47 -0000

As Hadriel points out, including it does not improve the security and by =
not including it, it makes it easier to provide alternative methods to =
get the certificate in the future. Some people preferred an HTTP =
approach, other SIP, and in the P2PSIP case you might want to do if very =
differently. I don't think it's a big deal one way or the other, but not =
signing as many things as possible make some types of extensions and =
changes easier. =20

On separate note, much of the design of 4474 was done to meet B2BUA use =
cases yet none of that is written down in any coherent form. I can =
certainly see value in a WG such as straw documenting some of the ways =
that B2BUA can use and work with 4474.=20


On Oct 18, 2011, at 7:48 AM, Hadriel Kaplan wrote:

>=20
> On Oct 18, 2011, at 3:00 AM, Olle E. Johansson wrote:
>=20
>> Seems like there are some issues to discuss here. Also, why is not =
the Identity-Info header signed? It points to where
>> the certificate exists, but can easily be changed by middlemen unless =
I've missed something.
>=20
> It doesn't matter if the Identity-Info header is changed by a =
middleman.  Doing so doesn't help the middleman lie about anything. =20
>=20
> Either the middleman modifies the Identity-Info to point to a =
different certificate, which will correctly invalidate the 4474 =
signature (which a middleman can do any number of other ways).  Or the =
middleman can point to a different location for the same certificate so =
the signature remains valid, but that still doesn't help the middleman =
do anything since it can't change the SIP message without invalidating =
the signature.
>=20
> -hadriel
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From oej@edvina.net  Thu Oct 27 08:37:24 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D321F8B53 for ; Thu, 27 Oct 2011 08:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g2PERTuW5yf for ; Thu, 27 Oct 2011 08:37:23 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7B59621F8B48 for ; Thu, 27 Oct 2011 08:37:23 -0700 (PDT)
Received: from [IPv6:2620::2ef0:710:75a4:949:2ce4:dc63] (unknown [IPv6:2620:0:2ef0:710:75a4:949:2ce4:dc63]) by smtp7.webway.se (Postfix) with ESMTPA id 629E0754BCD5; Thu, 27 Oct 2011 15:37:16 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" 
In-Reply-To: <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com>
Date: Thu, 27 Oct 2011 17:37:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>   <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com>
To: Cullen Jennings 
X-Mailer: Apple Mail (2.1251.1)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Oct 2011 15:37:24 -0000

27 okt 2011 kl. 17:22 skrev Cullen Jennings:

>=20
> As Hadriel points out, including it does not improve the security and =
by not including it, it makes it easier to provide alternative methods =
to get the certificate in the future. Some people preferred an HTTP =
approach, other SIP, and in the P2PSIP case you might want to do if very =
differently. I don't think it's a big deal one way or the other, but not =
signing as many things as possible make some types of extensions and =
changes easier. =20
>=20
> On separate note, much of the design of 4474 was done to meet B2BUA =
use cases yet none of that is written down in any coherent form. I can =
certainly see value in a WG such as straw documenting some of the ways =
that B2BUA can use and work with 4474.=20
Agree.
>=20
>=20
> On Oct 18, 2011, at 7:48 AM, Hadriel Kaplan wrote:
>=20
>>=20
>> On Oct 18, 2011, at 3:00 AM, Olle E. Johansson wrote:
>>=20
>>> Seems like there are some issues to discuss here. Also, why is not =
the Identity-Info header signed? It points to where
>>> the certificate exists, but can easily be changed by middlemen =
unless I've missed something.
>>=20
>> It doesn't matter if the Identity-Info header is changed by a =
middleman.  Doing so doesn't help the middleman lie about anything. =20
>>=20
>> Either the middleman modifies the Identity-Info to point to a =
different certificate, which will correctly invalidate the 4474 =
signature (which a middleman can do any number of other ways).  Or the =
middleman can point to a different location for the same certificate so =
the signature remains valid, but that still doesn't help the middleman =
do anything since it can't change the SIP message without invalidating =
the signature.
>>=20

Well, my current network object to hate is the SSL HTTP Proxys. In SIP, =
that would mean a proxy that rips out identity and identity-info and =
resigns with another certificate, that is approved in the ua's.

After reading your responses, I ACK that signing identity-info doesn't =
matter. Need to put my thinking hat on again, I suppose.

/O


From HKaplan@acmepacket.com  Thu Oct 27 10:54:26 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CDD11E8082 for ; Thu, 27 Oct 2011 10:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKeoG3skYacE for ; Thu, 27 Oct 2011 10:54:26 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 67CB611E807F for ; Thu, 27 Oct 2011 10:54:26 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 27 Oct 2011 13:54:24 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 13:54:25 -0400
From: Hadriel Kaplan 
To: Cullen Jennings 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMlNF2VslcF9uX30eEyeueNb7iCw==
Date: Thu, 27 Oct 2011 17:54:24 +0000
Message-ID: <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>   <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com>
In-Reply-To: <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Oct 2011 17:54:27 -0000

On Oct 27, 2011, at 11:22 AM, Cullen Jennings wrote:

> On separate note, much of the design of 4474 was done to meet B2BUA use c=
ases yet none of that is written down in any coherent form. I can certainly=
 see value in a WG such as straw documenting some of the ways that B2BUA ca=
n use and work with 4474.=20

Oh that'll be fun.  Should we start by going back to the massive email thre=
ads five years ago and hitting "re-send"? =20
:)

The STRAW concept is to document what very little needs to be passed from t=
he UAS to UAC side of B2BUAs to make something work.  I'm not sure a STRAW =
is big enough for 4474 - probably needs a PIPE (Providing Identity by Passi=
ng Everything).  ;)

-hadriel


From oej@edvina.net  Mon Oct 31 01:59:35 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE8921F87FC for ; Mon, 31 Oct 2011 01:59:35 -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=0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmAIbb82f5ok for ; Mon, 31 Oct 2011 01:59:34 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id C0E4A21F87D9 for ; Mon, 31 Oct 2011 01:59:34 -0700 (PDT)
Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 9098D754BCD5; Mon, 31 Oct 2011 08:59:31 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" 
In-Reply-To: <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com>
Date: Mon, 31 Oct 2011 09:59:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>   <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com>
To: Hadriel Kaplan 
X-Mailer: Apple Mail (2.1251.1)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 08:59:35 -0000

27 okt 2011 kl. 19:54 skrev Hadriel Kaplan:

>=20
> On Oct 27, 2011, at 11:22 AM, Cullen Jennings wrote:
>=20
>> On separate note, much of the design of 4474 was done to meet B2BUA =
use cases yet none of that is written down in any coherent form. I can =
certainly see value in a WG such as straw documenting some of the ways =
that B2BUA can use and work with 4474.=20
>=20
> Oh that'll be fun.  Should we start by going back to the massive email =
threads five years ago and hitting "re-send"? =20
> :)
;-)
I would appreciate any pointers if you can memorize some keywords and =
find them though. Would be good to get some background reading.


>=20
> The STRAW concept is to document what very little needs to be passed =
from the UAS to UAC side of B2BUAs to make something work.  I'm not sure =
a STRAW is big enough for 4474 - probably needs a PIPE (Providing =
Identity by Passing Everything).  ;)

Right :-)


/O=

From keith.drage@alcatel-lucent.com  Mon Oct 31 09:16:54 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746971F0C41; Mon, 31 Oct 2011 09:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.138
X-Spam-Level: 
X-Spam-Status: No, score=-106.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuDGyHXcYYv4; Mon, 31 Oct 2011 09:16:54 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id AB7FF1F0C3B; Mon, 31 Oct 2011 09:16:53 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9VGGosE012922 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 31 Oct 2011 17:16:50 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 31 Oct 2011 17:16:50 +0100
From: "DRAGE, Keith (Keith)" 
To: "dispatch@ietf.org" , "rai@ietf.org" 
Date: Mon, 31 Oct 2011 17:16:48 +0100
Thread-Topic: New bfcpbis working group
Thread-Index: AcyX6H2KggHOJu7bTOalHmotLtbwsw==
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-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: [dispatch] New bfcpbis working group
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 16:16:54 -0000

This is just a mail to indicate that there will shortly be a new bfcpbis wo=
rking group, with its associated mailing list.

That mailing list is still being put together, and that delay is holding up=
 posting the charter page. We will post to these lists when the mailing lis=
t comes together, hopefully fairly shortly.

This is also to confirm that bfcpbis will meet at Taipai, and a slot has be=
en allocated on the agenda.

Regards

Keith

From HKaplan@acmepacket.com  Mon Oct 31 10:06:07 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60D111E816B for ; Mon, 31 Oct 2011 10:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level: 
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFCuM5KX2qUL for ; Mon, 31 Oct 2011 10:06:05 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDC511E8151 for ; Mon, 31 Oct 2011 10:06:04 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 31 Oct 2011 13:06:01 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 13:06:01 -0400
From: Hadriel Kaplan 
To: "Olle E. Johansson" 
Thread-Topic: [dispatch] BEHAVE for B2BUAs charter proposal
Thread-Index: AQHMl+9d1Xiq4DcqmES9yjeEyaZPcA==
Date: Mon, 31 Oct 2011 17:06:00 +0000
Message-ID: <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>   <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7F586519D623C745AB3118495B10982F@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 17:06:07 -0000

On Oct 31, 2011, at 4:59 AM, Olle E. Johansson wrote:

>=20
> 27 okt 2011 kl. 19:54 skrev Hadriel Kaplan:
>=20
>>=20
>> On Oct 27, 2011, at 11:22 AM, Cullen Jennings wrote:
>>=20
>>> On separate note, much of the design of 4474 was done to meet B2BUA use=
 cases yet none of that is written down in any coherent form. I can certain=
ly see value in a WG such as straw documenting some of the ways that B2BUA =
can use and work with 4474.=20
>>=20
>> Oh that'll be fun.  Should we start by going back to the massive email t=
hreads five years ago and hitting "re-send"? =20
>> :)
> ;-)
> I would appreciate any pointers if you can memorize some keywords and fin=
d them though. Would be good to get some background reading.

Some thread starting points spanning a few years:
http://www.ietf.org/mail-archive/web/sip/current/msg14996.html
http://www.ietf.org/mail-archive/web/sip/current/msg23939.html
http://www.ietf.org/mail-archive/web/sip/current/msg24361.html
http://www.ietf.org/mail-archive/web/sip/current/msg27169.html

I'm sure there are many more email threads.

Some drafts about the problems with 4474 and/or attempts to solve them, whi=
ch probably spurred email threads and thus can be used to search for them:
draft-elwell-sip-e2e-identity-important-03
draft-rosenberg-sip-identity-coexistence-00
draft-rosenberg-sip-rfc4474-concerns-00
draft-wing-sip-identity-media-02
draft-fischer-sip-e2e-sec-media-00
draft-kaplan-sip-uris-change-00
draft-kaplan-sip-asserter-identity-01
draft-kaplan-sip-baiting-attack-02

phone-number issues relevant to identity/4474:
draft-elwell-sip-e164-problem-statement-01
draft-schwartz-sip-e164-ownership-01
draft-wing-sip-e164-rrc-01
draft-darilion-sip-e164-enum-00


From keith.drage@alcatel-lucent.com  Mon Oct 31 10:54:41 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6976D1F0CA2; Mon, 31 Oct 2011 10:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.142
X-Spam-Level: 
X-Spam-Status: No, score=-106.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or52Zbk+EXdW; Mon, 31 Oct 2011 10:54:38 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3903E1F0CA0; Mon, 31 Oct 2011 10:54:36 -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 p9VHsY0G012516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 31 Oct 2011 18:54:34 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 31 Oct 2011 18:54:34 +0100
From: "DRAGE, Keith (Keith)" 
To: "dispatch@ietf.org" , "rai@ietf.org" 
Date: Mon, 31 Oct 2011 18:54:32 +0100
Thread-Topic: New bfcpbis working group
Thread-Index: AcyX6H2KggHOJu7bTOalHmotLtbwswADXoLA
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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [dispatch] New bfcpbis working group
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 17:54:41 -0000

The mailing list has just been established and you can subscribe by visitin=
g the web page below:

https://www.ietf.org/mailman/listinfo/bfcpbis

regards

Keith

> -----Original Message-----
> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: 31 October 2011 16:17
> To: dispatch@ietf.org; rai@ietf.org
> Subject: [RAI] New bfcpbis working group
>=20
> This is just a mail to indicate that there will shortly be a new bfcpbis
> working group, with its associated mailing list.
>=20
> That mailing list is still being put together, and that delay is holding
> up posting the charter page. We will post to these lists when the mailing
> list comes together, hopefully fairly shortly.
>=20
> This is also to confirm that bfcpbis will meet at Taipai, and a slot has
> been allocated on the agenda.
>=20
> Regards
>=20
> Keith
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www.ietf.org/mailman/listinfo/rai

From oej@edvina.net  Mon Oct 31 11:36:44 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0E11E813E for ; Mon, 31 Oct 2011 11:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwN3WUX6W0f2 for ; Mon, 31 Oct 2011 11:36:44 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id D8FEF11E8090 for ; Mon, 31 Oct 2011 11:36:43 -0700 (PDT)
Received: from [IPv6:2001:470:1f15:d79:650f:ca60:aee0:22cf] (unknown [IPv6:2001:470:1f15:d79:650f:ca60:aee0:22cf]) by smtp7.webway.se (Postfix) with ESMTPA id C8376754BCD5; Mon, 31 Oct 2011 18:36:40 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" 
In-Reply-To: <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com>
Date: Mon, 31 Oct 2011 19:36:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net>
References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net>   <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com>  <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com>
To: Hadriel Kaplan 
X-Mailer: Apple Mail (2.1251.1)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] BEHAVE for B2BUAs charter proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 18:36:44 -0000

31 okt 2011 kl. 18:06 skrev Hadriel Kaplan:

>=20
> On Oct 31, 2011, at 4:59 AM, Olle E. Johansson wrote:
>=20
>>=20
>> 27 okt 2011 kl. 19:54 skrev Hadriel Kaplan:
>>=20
>>>=20
>>> On Oct 27, 2011, at 11:22 AM, Cullen Jennings wrote:
>>>=20
>>>> On separate note, much of the design of 4474 was done to meet B2BUA =
use cases yet none of that is written down in any coherent form. I can =
certainly see value in a WG such as straw documenting some of the ways =
that B2BUA can use and work with 4474.=20
>>>=20
>>> Oh that'll be fun.  Should we start by going back to the massive =
email threads five years ago and hitting "re-send"? =20
>>> :)
>> ;-)
>> I would appreciate any pointers if you can memorize some keywords and =
find them though. Would be good to get some background reading.
>=20
> Some thread starting points spanning a few years:
> http://www.ietf.org/mail-archive/web/sip/current/msg14996.html
> http://www.ietf.org/mail-archive/web/sip/current/msg23939.html
> http://www.ietf.org/mail-archive/web/sip/current/msg24361.html
> http://www.ietf.org/mail-archive/web/sip/current/msg27169.html
>=20
> I'm sure there are many more email threads.
>=20
> Some drafts about the problems with 4474 and/or attempts to solve =
them, which probably spurred email threads and thus can be used to =
search for them:
> draft-elwell-sip-e2e-identity-important-03
> draft-rosenberg-sip-identity-coexistence-00
> draft-rosenberg-sip-rfc4474-concerns-00
> draft-wing-sip-identity-media-02
> draft-fischer-sip-e2e-sec-media-00
> draft-kaplan-sip-uris-change-00
> draft-kaplan-sip-asserter-identity-01
> draft-kaplan-sip-baiting-attack-02
>=20
> phone-number issues relevant to identity/4474:
> draft-elwell-sip-e164-problem-statement-01
> draft-schwartz-sip-e164-ownership-01
> draft-wing-sip-e164-rrc-01
> draft-darilion-sip-e164-enum-00

Thank you. Seems like I need to get stuck in an airport again...

/O :-)=

From eckelcu@cisco.com  Mon Oct 31 16:27:09 2011
Return-Path: 
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB2C21F8B0D; Mon, 31 Oct 2011 16:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.236
X-Spam-Level: 
X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.363,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ccvu0bex11x; Mon, 31 Oct 2011 16:27:09 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 14CF721F8B05; Mon, 31 Oct 2011 16:27:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=527; q=dns/txt; s=iport; t=1320103629; x=1321313229; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=mWznAOR7Gcms8OB4yGUrT7/9Fk/rVOjEIgPcFGT+sRs=; b=kEr/eO6TvRKw1n2jwjnExJfDY6NxZfnVHfJ3WfIPvnUWx6y3QeGTXmhe 7Y/L9sNxhw09PpYV+kV21OOFJ6Ms2MhrghhC8YJiKu53z95mbDcgJefUW kUyaQAbOmqDK3TZF2JnMEwqHbgRpRISQjRt8xPh8hp2mXcwcsluEsLx1k 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EADQur06rRDoG/2dsb2JhbABDqTaBBYF0AQEDAQEBDwEdCjQdASoCBBgHJjEBBAEaGodolXMBnjqIIWEEiAaRPoxJ
X-IronPort-AV: E=Sophos;i="4.69,435,1315180800"; d="scan'208";a="11530860"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2011 23:27:08 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9VNR8NV019582; Mon, 31 Oct 2011 23:27:08 GMT
Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 31 Oct 2011 16:27:08 -0700
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, 31 Oct 2011 16:27:07 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: update posted for draft-sandbakken-dispatch-bfcp-udp
Thread-Index: AcyYJJsyRUyCaindT3e3Ur4sYTqcIA==
From: "Charles Eckel (eckelcu)" 
To: "DISPATCH list" , 
X-OriginalArrivalTime: 31 Oct 2011 23:27:08.0823 (UTC) FILETIME=[9BDF0270:01CC9824]
Subject: [dispatch] update posted for draft-sandbakken-dispatch-bfcp-udp
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 23:27:09 -0000

The corresponding update has been posted and is available at:

http://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-03

I am sending this announcement to both dispatch as well as bfcpbis as
most of you have likely not yet subscribed to the bfcpbis alias as it
was created today only.

Please post comments on the draft to the bfcpbis alias.
The mailing list has just been established and you can subscribe by
visiting the web page below:

https://www.ietf.org/mailman/listinfo/bfcpbis

Cheers,
Charles