From john.elwell@siemens-enterprise.com Wed Apr 1 23:06:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBF93A6971 for ; Wed, 1 Apr 2009 23:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcNTE1Tf+Wg8 for ; Wed, 1 Apr 2009 23:06:09 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 653C93A6C05 for ; Wed, 1 Apr 2009 23:06:09 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHG00J6GMBXWT@siemenscomms.co.uk> for ecrit@ietf.org; Thu, 02 Apr 2009 07:07:09 +0100 (BST) Date: Thu, 02 Apr 2009 07:07:06 +0100 From: "Elwell, John" To: ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Use of SIPPING config framework for configuring location Thread-Index: AcmzWT/KSouvYTawTxek+3hQB7A6kA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 06:06:10 -0000 We had a SIPPING WG ad hoc meeting during IETF 74, in which the SIP Forum UA-config work was presented. It aims to provide a simple profile of the SIPPING configuration framework and datasets. The question arose whether the configuration data obtained from the SIP configuration server should have the possibility to contain the geographic location of the SIP UA. Effectively this would make it another LCP. Does this sound reasonable? Can this be done without impact on the ECRIT framework and Phone BCP? John From James.Winterbottom@andrew.com Wed Apr 1 23:33:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E639D3A6C31 for ; Wed, 1 Apr 2009 23:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPRx5aAsAh-r for ; Wed, 1 Apr 2009 23:33:27 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 1E1AE3A68C3 for ; Wed, 1 Apr 2009 23:33:27 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_02_01_54_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 02 Apr 2009 01:54:43 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 01:34:27 -0500 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: Thu, 2 Apr 2009 01:34:26 -0500 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzWT/KSouvYTawTxek+3hQB7A6kAAA5uJw References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> From: "Winterbottom, James" To: "Elwell, John" , X-OriginalArrivalTime: 02 Apr 2009 06:34:27.0776 (UTC) FILETIME=[12568400:01C9B35D] Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 06:33:28 -0000 John,=0D=0A=0D=0AIf you have to do something in the SIPPING framework then = it would be=0D=0Afar better to provide a LIS URI and then do a HELD look up= as per Phone=0D=0ABCP or framework. This would mean what you are providing= is another LIS=0D=0Adiscovery technique rather than yet another LCP.=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf E= lwell, John=0D=0ASent: Thursday, 2 April 2009 5:07 PM=0D=0ATo: ecrit@ietf.o= rg=0D=0ASubject: [Ecrit] Use of SIPPING config framework for configuring=0D= =0Alocation=0D=0A=0D=0AWe had a SIPPING WG ad hoc meeting during IETF 74, i= n which the SIP=0D=0AForum UA-config work was presented. It aims to provide= a simple profile=0D=0Aof the SIPPING configuration framework and datasets.=0D= =0A=0D=0AThe question arose whether the configuration data obtained from th= e SIP=0D=0Aconfiguration server should have the possibility to contain the=0D= =0Ageographic location of the SIP UA. Effectively this would make it=0D=0Aa= nother LCP. Does this sound reasonable=3F Can this be done without impact=0D= =0Aon the ECRIT framework and Phone BCP=3F=0D=0A=0D=0AJohn=0D=0A=0D=0A_____= __________________________________________=0D=0AEcrit mailing list=0D=0AEcr= it@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A---= ---------------------------------------------------------------------------= ------------------=0D=0AThis message is for the designated recipient only a= nd may=0D=0Acontain privileged, proprietary, or otherwise private informati= on. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A From john.elwell@siemens-enterprise.com Wed Apr 1 23:55:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CFF3A6867 for ; Wed, 1 Apr 2009 23:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFRR6AFl77wd for ; Wed, 1 Apr 2009 23:55:21 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 4D4833A6C43 for ; Wed, 1 Apr 2009 23:55:20 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHG00065OLWKE@siemenscomms.co.uk> for ecrit@ietf.org; Thu, 02 Apr 2009 07:56:20 +0100 (BST) Date: Thu, 02 Apr 2009 07:56:18 +0100 From: "Elwell, John" In-reply-to: To: "Winterbottom, James" , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA64CD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzWT/KSouvYTawTxek+3hQB7A6kAAA5uJwAADL8UA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 06:55:32 -0000 James, Thanks. That sounds like a good suggestion. We will give it consideration. John =20 > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: 02 April 2009 07:34 > To: Elwell, John; ecrit@ietf.org > Subject: RE: [Ecrit] Use of SIPPING config framework for=20 > configuring location >=20 > John, >=20 > If you have to do something in the SIPPING framework then it would be > far better to provide a LIS URI and then do a HELD look up as=20 > per Phone > BCP or framework. This would mean what you are providing is=20 > another LIS > discovery technique rather than yet another LCP. >=20 > Cheers > James >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Thursday, 2 April 2009 5:07 PM > To: ecrit@ietf.org > Subject: [Ecrit] Use of SIPPING config framework for configuring > location >=20 > We had a SIPPING WG ad hoc meeting during IETF 74, in which the SIP > Forum UA-config work was presented. It aims to provide a=20 > simple profile > of the SIPPING configuration framework and datasets. >=20 > The question arose whether the configuration data obtained=20 > from the SIP > configuration server should have the possibility to contain the > geographic location of the SIP UA. Effectively this would make it > another LCP. Does this sound reasonable? Can this be done=20 > without impact > on the ECRIT framework and Phone BCP? >=20 > John >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 From jmpolk@cisco.com Thu Apr 2 00:04:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094453A6A87 for ; Thu, 2 Apr 2009 00:04:46 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fTKEcGR7XTx for ; Thu, 2 Apr 2009 00:04:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AF7303A6919 for ; Thu, 2 Apr 2009 00:04:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,312,1235952000"; d="scan'208";a="40794271" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2009 07:05:45 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3275juc018399; Thu, 2 Apr 2009 03:05:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3275jMc004035; Thu, 2 Apr 2009 07:05:45 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 03:05:45 -0400 Received: from jmpolk-wxp01.cisco.com ([10.86.253.254]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 03:05:44 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Apr 2009 02:05:42 -0500 To: "Elwell, John" , "Winterbottom, James" , ecrit@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001BA64CD@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA64CD@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Apr 2009 07:05:44.0757 (UTC) FILETIME=[711B1650:01C9B361] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2766; t=1238655945; x=1239519945; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Use=20of=20SIPPING=20config=2 0framework=20for=20configuring=0A=20=20location |Sender:=20 |To:=20=22Elwell,=20John=22=20,=0A=20=20=20=20=20=20=20=20=22Winterbottom,=20James= 22=20,=20ecrit@ietf.org; bh=E4Q6lTkjhBs73IY2c6U7en7WT5y/DPmcBvns+3YAu5k=; b=XnSgxrCoUC6fa/RhCp+bUmv4WCbZBmsxsPNbIvdTKas6v8dOk5I43JUYCQ LVqiVXsKSPiEBxjdbdsxcq8cVKTfA8gy4Adg3M4MUcct1F/b2/W3IaSBpsV8 JVZt5XW+0c; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 07:04:46 -0000 John Or, you can use SIP and not have to implement HELD. HELD doesn't need to go into every device, and I'd be surprised that it ends up in every device. Some devices may end up only supporting SIP, and using the Geolocation header is a fine way of getting either a location URI or a PIDF-LO. James At 01:56 AM 4/2/2009, Elwell, John wrote: >James, > >Thanks. That sounds like a good suggestion. We will give it >consideration. > >John > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: 02 April 2009 07:34 > > To: Elwell, John; ecrit@ietf.org > > Subject: RE: [Ecrit] Use of SIPPING config framework for > > configuring location > > > > John, > > > > If you have to do something in the SIPPING framework then it would be > > far better to provide a LIS URI and then do a HELD look up as > > per Phone > > BCP or framework. This would mean what you are providing is > > another LIS > > discovery technique rather than yet another LCP. > > > > Cheers > > James > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Elwell, John > > Sent: Thursday, 2 April 2009 5:07 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] Use of SIPPING config framework for configuring > > location > > > > We had a SIPPING WG ad hoc meeting during IETF 74, in which the SIP > > Forum UA-config work was presented. It aims to provide a > > simple profile > > of the SIPPING configuration framework and datasets. > > > > The question arose whether the configuration data obtained > > from the SIP > > configuration server should have the possibility to contain the > > geographic location of the SIP UA. Effectively this would make it > > another LCP. Does this sound reasonable? Can this be done > > without impact > > on the ECRIT framework and Phone BCP? > > > > John > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From john.elwell@siemens-enterprise.com Thu Apr 2 00:08:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A583A6A87 for ; Thu, 2 Apr 2009 00:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5X+faNya3oY for ; Thu, 2 Apr 2009 00:08:44 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BECBC3A6800 for ; Thu, 2 Apr 2009 00:08:44 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHG001AAP8869@siemenscomms.co.uk> for ecrit@ietf.org; Thu, 02 Apr 2009 08:09:44 +0100 (BST) Date: Thu, 02 Apr 2009 08:09:41 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , "Winterbottom, James" , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA64DB@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzYXPxECvVaFO1TWGI8q0y1+yLLAAAFwiQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA64CD@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 07:08:45 -0000 Yes, I was also wondering whether a LIS URI had to be a HELD URI, or whether it could just be an HTTP(S) URI, for example? John=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 02 April 2009 08:06 > To: Elwell, John; Winterbottom, James; ecrit@ietf.org > Subject: Re: [Ecrit] Use of SIPPING config framework for=20 > configuring location >=20 > John >=20 > Or, you can use SIP and not have to implement HELD. HELD doesn't need=20 > to go into every device, and I'd be surprised that it ends up in=20 > every device. Some devices may end up only supporting SIP, and using=20 > the Geolocation header is a fine way of getting either a location URI=20 > or a PIDF-LO. >=20 > James >=20 > At 01:56 AM 4/2/2009, Elwell, John wrote: > >James, > > > >Thanks. That sounds like a good suggestion. We will give it > >consideration. > > > >John > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: 02 April 2009 07:34 > > > To: Elwell, John; ecrit@ietf.org > > > Subject: RE: [Ecrit] Use of SIPPING config framework for > > > configuring location > > > > > > John, > > > > > > If you have to do something in the SIPPING framework then=20 > it would be > > > far better to provide a LIS URI and then do a HELD look up as > > > per Phone > > > BCP or framework. This would mean what you are providing is > > > another LIS > > > discovery technique rather than yet another LCP. > > > > > > Cheers > > > James > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Elwell, John > > > Sent: Thursday, 2 April 2009 5:07 PM > > > To: ecrit@ietf.org > > > Subject: [Ecrit] Use of SIPPING config framework for configuring > > > location > > > > > > We had a SIPPING WG ad hoc meeting during IETF 74, in=20 > which the SIP > > > Forum UA-config work was presented. It aims to provide a > > > simple profile > > > of the SIPPING configuration framework and datasets. > > > > > > The question arose whether the configuration data obtained > > > from the SIP > > > configuration server should have the possibility to contain the > > > geographic location of the SIP UA. Effectively this would make it > > > another LCP. Does this sound reasonable? Can this be done > > > without impact > > > on the ECRIT framework and Phone BCP? > > > > > > John > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 From James.Winterbottom@andrew.com Thu Apr 2 00:56:24 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FED3A68C3 for ; Thu, 2 Apr 2009 00:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l18YmT4mqHh for ; Thu, 2 Apr 2009 00:56:23 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4CC8F3A6C8F for ; Thu, 2 Apr 2009 00:56:23 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_02_03_17_38 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 02 Apr 2009 03:17:38 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 02:57:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 02:56:30 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzYXPxECvVaFO1TWGI8q0y1+yLLAAAFwiQAAGuGWs= References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA64CD@GBNTHT12009MSX.gb002.siemens.net> A<0D5F89FAC29E2C41B98A6A762007F5D001BA64DB@GBNTHT12009MSX.gb002.siemens.net> From: "Winterbottom, James" To: "Elwell, John" , "James M. Polk" , X-OriginalArrivalTime: 02 Apr 2009 07:57:23.0042 (UTC) FILETIME=[A7D3DC20:01C9B368] Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 07:56:24 -0000 There is no such thing as "HELD URI" in that sense John, it is HTTPS. If yo= u direct a HELD request at the URI though you will get the HELD semantics i= f it is a LIS at the other end.=0D=0A=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=0D=0ASent= : Thu 4/2/2009 2:09 AM=0D=0ATo: James M. Polk; Winterbottom, James; ecrit@i= etf.org=0D=0ASubject: RE: [Ecrit] Use of SIPPING config framework for confi= guring location=0D=0A=20=0D=0AYes, I was also wondering whether a LIS URI = had to be a HELD URI, or=0D=0Awhether it could just be an HTTP(S) URI, for = example=3F=0D=0A=0D=0AJohn=20=0D=0A=0D=0A> -----Original Message-----=0D=0A= > From: James M. Polk [mailto:jmpolk@cisco.com]=20=0D=0A> Sent: 02 April 20= 09 08:06=0D=0A> To: Elwell, John; Winterbottom, James; ecrit@ietf.org=0D=0A= > Subject: Re: [Ecrit] Use of SIPPING config framework for=20=0D=0A> config= uring location=0D=0A>=20=0D=0A> John=0D=0A>=20=0D=0A> Or, you can use SIP a= nd not have to implement HELD. HELD doesn't need=20=0D=0A> to go into every= device, and I'd be surprised that it ends up in=20=0D=0A> every device. So= me devices may end up only supporting SIP, and using=20=0D=0A> the Geolocat= ion header is a fine way of getting either a location URI=20=0D=0A> or a PI= DF-LO.=0D=0A>=20=0D=0A> James=0D=0A>=20=0D=0A> At 01:56 AM 4/2/2009, Elwell= , John wrote:=0D=0A> >James,=0D=0A> >=0D=0A> >Thanks. That sounds like a go= od suggestion. We will give it=0D=0A> >consideration.=0D=0A> >=0D=0A> >John=0D= =0A> >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Wint= erbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A> > > Sent: 02 = April 2009 07:34=0D=0A> > > To: Elwell, John; ecrit@ietf.org=0D=0A> > > Sub= ject: RE: [Ecrit] Use of SIPPING config framework for=0D=0A> > > configurin= g location=0D=0A> > >=0D=0A> > > John,=0D=0A> > >=0D=0A> > > If you have to= do something in the SIPPING framework then=20=0D=0A> it would be=0D=0A> > = > far better to provide a LIS URI and then do a HELD look up as=0D=0A> > > = per Phone=0D=0A> > > BCP or framework. This would mean what you are providi= ng is=0D=0A> > > another LIS=0D=0A> > > discovery technique rather than yet= another LCP.=0D=0A> > >=0D=0A> > > Cheers=0D=0A> > > James=0D=0A> > >=0D=0A= > > >=0D=0A> > > -----Original Message-----=0D=0A> > > From: ecrit-bounces@= ietf.org=20=0D=0A> [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0A> > > Of = Elwell, John=0D=0A> > > Sent: Thursday, 2 April 2009 5:07 PM=0D=0A> > > To:= ecrit@ietf.org=0D=0A> > > Subject: [Ecrit] Use of SIPPING config framework= for configuring=0D=0A> > > location=0D=0A> > >=0D=0A> > > We had a SIPPING= WG ad hoc meeting during IETF 74, in=20=0D=0A> which the SIP=0D=0A> > > Fo= rum UA-config work was presented. It aims to provide a=0D=0A> > > simple pr= ofile=0D=0A> > > of the SIPPING configuration framework and datasets.=0D=0A= > > >=0D=0A> > > The question arose whether the configuration data obtained=0D= =0A> > > from the SIP=0D=0A> > > configuration server should have the possi= bility to contain the=0D=0A> > > geographic location of the SIP UA. Effecti= vely this would make it=0D=0A> > > another LCP. Does this sound reasonable=3F= Can this be done=0D=0A> > > without impact=0D=0A> > > on the ECRIT framewo= rk and Phone BCP=3F=0D=0A> > >=0D=0A> > > John=0D=0A> > >=0D=0A> > > ______= _________________________________________=0D=0A> > > Ecrit mailing list=0D=0A= > > > Ecrit@ietf.org=0D=0A> > > https://www.ietf.org/mailman/listinfo/ecrit=0D= =0A> > >=0D=0A> > > -------------------------------------------------------= -------=0D=0A> > > ----------------------------------=0D=0A> > > This messa= ge is for the designated recipient only and may=0D=0A> > > contain privileg= ed, proprietary, or otherwise private information.=0D=0A> > > If you have r= eceived it in error, please notify the sender=0D=0A> > > immediately and de= lete the original. Any unauthorized use of=0D=0A> > > this email is prohib= ited.=0D=0A> > > ----------------------------------------------------------= ----=0D=0A> > > ----------------------------------=0D=0A> > > [mf2]=0D=0A> = > >=0D=0A> > >=0D=0A> >_______________________________________________=0D=0A= > >Ecrit mailing list=0D=0A> >Ecrit@ietf.org=0D=0A> >https://www.ietf.org/m= ailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A=0D=0A=0D=0A----------------= ---------------------------------------------------------------------------= -----=0D=0AThis message is for the designated recipient only and may=0D=0Ac= ontain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A From James.Winterbottom@andrew.com Thu Apr 2 00:58:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAE13A683E for ; Thu, 2 Apr 2009 00:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHraS-Nffcqa for ; Thu, 2 Apr 2009 00:58:13 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 978A53A6BDB for ; Thu, 2 Apr 2009 00:58:06 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_02_03_19_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 02 Apr 2009 03:19:22 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 02:59:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 02:57:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzYXJDbTqxzu/wTrK/XEIWRxS3UgAB0kTL References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA64CD@GBNTHT12009MSX.gb002.siemens.net> From: "Winterbottom, James" To: "James M. Polk" , "Elwell, John" , X-OriginalArrivalTime: 02 Apr 2009 07:59:07.0371 (UTC) FILETIME=[E60333B0:01C9B368] Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 07:58:14 -0000 =0D=0AJames,=0D=0A=0D=0AYour proposal is counter to what framework and BCP = profess.=20=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A-----Original Message--= ---=0D=0AFrom: James M. Polk [mailto:jmpolk@cisco.com]=0D=0ASent: Thu 4/2/2= 009 2:05 AM=0D=0ATo: Elwell, John; Winterbottom, James; ecrit@ietf.org=0D=0A= Subject: Re: [Ecrit] Use of SIPPING config framework for configuring locat= ion=0D=0A=20=0D=0AJohn=0D=0A=0D=0AOr, you can use SIP and not have to imple= ment HELD. HELD doesn't need=20=0D=0Ato go into every device, and I'd be su= rprised that it ends up in=20=0D=0Aevery device. Some devices may end up on= ly supporting SIP, and using=20=0D=0Athe Geolocation header is a fine way o= f getting either a location URI=20=0D=0Aor a PIDF-LO.=0D=0A=0D=0AJames=0D=0A=0D= =0AAt 01:56 AM 4/2/2009, Elwell, John wrote:=0D=0A>James,=0D=0A>=0D=0A>Than= ks. That sounds like a good suggestion. We will give it=0D=0A>consideration= =2E=0D=0A>=0D=0A>John=0D=0A>=0D=0A>=0D=0A> > -----Original Message-----=0D=0A= > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A>= > Sent: 02 April 2009 07:34=0D=0A> > To: Elwell, John; ecrit@ietf.org=0D=0A= > > Subject: RE: [Ecrit] Use of SIPPING config framework for=0D=0A> > confi= guring location=0D=0A> >=0D=0A> > John,=0D=0A> >=0D=0A> > If you have to do= something in the SIPPING framework then it would be=0D=0A> > far better to= provide a LIS URI and then do a HELD look up as=0D=0A> > per Phone=0D=0A> = > BCP or framework. This would mean what you are providing is=0D=0A> > anot= her LIS=0D=0A> > discovery technique rather than yet another LCP.=0D=0A> >=0D= =0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> > -----Original Messa= ge-----=0D=0A> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.or= g] On Behalf=0D=0A> > Of Elwell, John=0D=0A> > Sent: Thursday, 2 April 2009= 5:07 PM=0D=0A> > To: ecrit@ietf.org=0D=0A> > Subject: [Ecrit] Use of SIPPI= NG config framework for configuring=0D=0A> > location=0D=0A> >=0D=0A> > We = had a SIPPING WG ad hoc meeting during IETF 74, in which the SIP=0D=0A> > F= orum UA-config work was presented. It aims to provide a=0D=0A> > simple pro= file=0D=0A> > of the SIPPING configuration framework and datasets.=0D=0A> >=0D= =0A> > The question arose whether the configuration data obtained=0D=0A> > = from the SIP=0D=0A> > configuration server should have the possibility to c= ontain the=0D=0A> > geographic location of the SIP UA. Effectively this wou= ld make it=0D=0A> > another LCP. Does this sound reasonable=3F Can this be = done=0D=0A> > without impact=0D=0A> > on the ECRIT framework and Phone BCP=3F=0D= =0A> >=0D=0A> > John=0D=0A> >=0D=0A> > ____________________________________= ___________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > ht= tps://www.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> > ---------------= -----------------------------------------------=0D=0A> > ------------------= ----------------=0D=0A> > This message is for the designated recipient only= and may=0D=0A> > contain privileged, proprietary, or otherwise private inf= ormation.=0D=0A> > If you have received it in error, please notify the send= er=0D=0A> > immediately and delete the original. Any unauthorized use of=0D= =0A> > this email is prohibited.=0D=0A> > ---------------------------------= -----------------------------=0D=0A> > ----------------------------------=0D= =0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A>______________________________________= _________=0D=0A>Ecrit mailing list=0D=0A>Ecrit@ietf.org=0D=0A>https://www.i= etf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A=0D=0A---------------------= ---------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A From john.elwell@siemens-enterprise.com Thu Apr 2 01:09:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7411F28C0DB for ; Thu, 2 Apr 2009 01:09:40 -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=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK2t0NKhs4o0 for ; Thu, 2 Apr 2009 01:09:39 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 35DC23A6BEF for ; Thu, 2 Apr 2009 01:09:38 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHG0055VS1P3R@siemenscomms.co.uk> for ecrit@ietf.org; Thu, 02 Apr 2009 09:10:37 +0100 (BST) Date: Thu, 02 Apr 2009 09:10:33 +0100 From: "Elwell, John" In-reply-to: To: "Winterbottom, James" , "James M. Polk" , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA6526@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzYXPxECvVaFO1TWGI8q0y1+yLLAAAFwiQAAGuGWsAAHmaMA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA64CD@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D001BA64DB@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 08:09:40 -0000 OK, understood. John=20 > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: 02 April 2009 08:57 > To: Elwell, John; James M. Polk; ecrit@ietf.org > Subject: RE: [Ecrit] Use of SIPPING config framework for=20 > configuring location >=20 > There is no such thing as "HELD URI" in that sense John, it=20 > is HTTPS. If you direct a HELD request at the URI though you=20 > will get the HELD semantics if it is a LIS at the other end. >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thu 4/2/2009 2:09 AM > To: James M. Polk; Winterbottom, James; ecrit@ietf.org > Subject: RE: [Ecrit] Use of SIPPING config framework for=20 > configuring location > =20 > Yes, I was also wondering whether a LIS URI had to be a HELD URI, or > whether it could just be an HTTP(S) URI, for example? >=20 > John=20 >=20 > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > > Sent: 02 April 2009 08:06 > > To: Elwell, John; Winterbottom, James; ecrit@ietf.org > > Subject: Re: [Ecrit] Use of SIPPING config framework for=20 > > configuring location > >=20 > > John > >=20 > > Or, you can use SIP and not have to implement HELD. HELD=20 > doesn't need=20 > > to go into every device, and I'd be surprised that it ends up in=20 > > every device. Some devices may end up only supporting SIP,=20 > and using=20 > > the Geolocation header is a fine way of getting either a=20 > location URI=20 > > or a PIDF-LO. > >=20 > > James > >=20 > > At 01:56 AM 4/2/2009, Elwell, John wrote: > > >James, > > > > > >Thanks. That sounds like a good suggestion. We will give it > > >consideration. > > > > > >John > > > > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: 02 April 2009 07:34 > > > > To: Elwell, John; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Use of SIPPING config framework for > > > > configuring location > > > > > > > > John, > > > > > > > > If you have to do something in the SIPPING framework then=20 > > it would be > > > > far better to provide a LIS URI and then do a HELD look up as > > > > per Phone > > > > BCP or framework. This would mean what you are providing is > > > > another LIS > > > > discovery technique rather than yet another LCP. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org=20 > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Elwell, John > > > > Sent: Thursday, 2 April 2009 5:07 PM > > > > To: ecrit@ietf.org > > > > Subject: [Ecrit] Use of SIPPING config framework for configuring > > > > location > > > > > > > > We had a SIPPING WG ad hoc meeting during IETF 74, in=20 > > which the SIP > > > > Forum UA-config work was presented. It aims to provide a > > > > simple profile > > > > of the SIPPING configuration framework and datasets. > > > > > > > > The question arose whether the configuration data obtained > > > > from the SIP > > > > configuration server should have the possibility to contain the > > > > geographic location of the SIP UA. Effectively this=20 > would make it > > > > another LCP. Does this sound reasonable? Can this be done > > > > without impact > > > > on the ECRIT framework and Phone BCP? > > > > > > > > John > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private=20 > information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > [mf2] > > > > > > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 From mlinsner@cisco.com Thu Apr 2 05:50:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E183A684B for ; Thu, 2 Apr 2009 05:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I671wOsaR-YA for ; Thu, 2 Apr 2009 05:50:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 77A853A6885 for ; Thu, 2 Apr 2009 05:50:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,314,1235952000"; d="scan'208";a="40807134" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2009 12:51:27 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n32CpRtK004994; Thu, 2 Apr 2009 08:51:27 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n32CpR1v011688; Thu, 2 Apr 2009 12:51:27 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 08:51:27 -0400 Received: from [10.116.195.122] ([10.116.195.122]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 08:51:26 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 02 Apr 2009 08:51:23 -0400 From: Marc Linsner To: "Elwell, John" , Message-ID: Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzWT/KSouvYTawTxek+3hQB7A6kAAOHpHU In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2009 12:51:26.0980 (UTC) FILETIME=[BC6F2440:01C9B391] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1246; t=1238676687; x=1239540687; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Use=20of=20SIPPING=20config=2 0framework=20for=20configuring=20location |Sender:=20 |To:=20=22Elwell,=20John=22=20,=20; bh=bcRvCWrmZv6iUr5VyoOZYHOBvkHk4KDbKE38Aka/Mjg=; b=f+cUqQxarlRRp3Dl4fTySwbv1pSlinZ2n66f7vus30dbtgAfJPQRJukUBl j8rWkjgudkvH53fUhZxKn9g+uwkrwhZKBQIidIJPib57h86+LNiBKkC/imvT fETj7nIBB4; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:50:27 -0000 John, 1) You probably should propose this idea to GeoPriv. Regardless of impact to ECRIT Framework and PhoneBCP, GeoPriv should vet the privacy and security impact. 2) I'm curious what you believe would be the relationship between SIP and the access network such that SIP would even know how/where to determine the UA location information? SIP by itself has no idea of geographic location, nor visibility to the layers that do know. Thanks, -Marc- On 4/2/09 2:07 AM, "Elwell, John" wrote: > We had a SIPPING WG ad hoc meeting during IETF 74, in which the SIP > Forum UA-config work was presented. It aims to provide a simple profile > of the SIPPING configuration framework and datasets. > > The question arose whether the configuration data obtained from the SIP > configuration server should have the possibility to contain the > geographic location of the SIP UA. Effectively this would make it > another LCP. Does this sound reasonable? Can this be done without impact > on the ECRIT framework and Phone BCP? > > John > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Peter.Dawes@vodafone.com Thu Apr 2 06:28:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968FB3A6A5D for ; Thu, 2 Apr 2009 06:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idVkCbePn8HY for ; Thu, 2 Apr 2009 06:28:11 -0700 (PDT) Received: from mo2.vodafone.com (mo2.vodafone.com [195.232.246.85]) by core3.amsl.com (Postfix) with ESMTP id 0E4713A683D for ; Thu, 2 Apr 2009 06:27:46 -0700 (PDT) Received: from mi2.vodafone.com (mi2.vodafone.com [195.232.246.139]) by mo2.vodafone.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n32DSaHt032192; Thu, 2 Apr 2009 15:28:36 +0200 Received: from avoexs01.internal.vodafone.com ([145.230.4.134]) by mi2.vodafone.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n32DS9Nx012706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 2 Apr 2009 15:28:34 +0200 Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 15:28:33 +0200 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: Thu, 2 Apr 2009 15:28:11 +0200 Message-ID: In-Reply-To: <003001c9afba$44702d70$211ea8c0@GunnarH> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distordedreference Thread-Index: AcmvLd81tlepZceYSYeGbih7J01RLgAhEWXwAPjl8JA= From: "Dawes, Peter, VF-Group" To: "Gunnar Hellstrom" , , "Brian Rosen" X-OriginalArrivalTime: 02 Apr 2009 13:28:33.0328 (UTC) FILETIME=[EB70E300:01C9B396] Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distordedreference X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:28:12 -0000 Hello Brian, I have been reading http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-09.txt to understand how it works, and I have some questions and comments about the draft text. I also spotted some editorial corrections, so I have put them at the bottom of this e-mail. Thanks for the very readable draft. Best Regards, Peter QUESTIONS/COMMENTS ------------------ [Page 2]/1. Terminology/"Location conveyance: Location conveyance delivers location information to another element." Is this 'location information' physical location or some other kind of location information? Also, maybe "to another element" should be deleted.=20 [Page 3]/2. Introduction "Such citizen/ visitor-to-authority calls can be distinguished from those that are created by responders (authority-to-authority) using public communications infrastructure often involving some kind of priority access as defined in Emergency Telecommunications Service (ETS) in IP Telephony [RFC4190]. They also can be distinguished from emergency warning systems that are authority-to-citizen." Does "can be distinguished" mean that by looking at the signalling you can tell whether the call is visitor-to-authority etc., or does it mean that the draft only applies to visitor-to-authority calls? [Page 6]/3. Overview of how emergency calls are placed " o The phone gets location via a Location Configuration Protocol (LCP), for example from the DHCP server in civic [RFC4776] and/or geo [RFC3825] forms, a HELD server" Should the ", a HELD server" be removed, or is a DHCP server also a HELD server? [Page 7]/3. Overview of how emergency calls are placed "o The phone obtains the local emergency dial string(s) from the LoST [RFC5222] server for its current location. It also receives and caches the PSAP URI obtained from the LoST server. . . . "o It refreshes its location via DHCP and updates the PSAP's URI by querying the LoST mapping server with its location." Does this mean that the dial strings and PSAP URI are initially pushed in some way from the LoST server, or does the phone query the LoST server in both cases? [Page 7]/3. Overview of how emergency calls are placed "o The proxy recognizes the call as an emergency call and routes the call using normal SIP routing mechanisms to the URI specified." Maybe this bullet should give a hint why the proxy needs to recognize the call as an emergency one. It could say "The proxy recognizes the call as an emergency call, e.g., to allow it to take remedial action if the phone location had not been included by the phone, and routes the call using normal SIP routing mechanisms to the URI specified." [Page 10]/3. Overview of how emergency calls are placed "A proxy in the PSAP chooses an available call taker and extends the call to its UA." Isn't this a function of a registrar and not a proxy? [Page 12]/5. Identifying an emergency call "For devices that are mobile or nomadic, an issue arises of whether the home or visited dial strings should be used. Many users would prefer that their home dialing sequences work no matter where they are. However, local laws and regulations may require that the visited dialing sequence(s) work. Therefore, the visited dial string must work. Devices may have a way to be configured or learn home dial strings." The last sentence doesn't seem to fit in with the rest of the paragraph. Is this paragraph making the point that a mobile or nomadic device must always query for the correct dial strings for its current location before making an emergency call? [Page 18]/6.3 Who adds location, endpoint or proxy "Proxy insertion of location complicates dial string recognition." I don't understand how Proxy insertion of location relates to dial string recognition. Should the sentence above be deleted?=20 [Page 26][Page 27]/8. Routing the call to the PSAP "There is no mechanism provided in [I-D.ietf-sip-location-conveyance] for a proxy to request the endpoint supply its location, because that would open the endpoint to an attack by any proxy on the path to get it to reveal location. The proxy can attempt to redirect a call to the service URN which, if the device recognizes the significance, would include location in the redirected call from the device." The paragraph above indicates that a proxy cannot request location from an endpoint, and then seems to describe a way to do it by redirecting the call to a service URN. Is this contradictory? [Page 27]/8. Routing the call to the PSAP "In order for the ESRP to route on media choice, the initial INVITE request has to supply an SDP offer." [Page 28]/9.2. SIP signaling requirements for User Agents "To enable media sensitive routing, the call should include an SDP offer." Enabling the ESRP to route on SDP seems to differ from normal SIP practice. I would have thought that using caller prefs only (e.g., audio, video) is normal. Also, since the ESRP doesn't know what the terminating end of the call will answer in terms of SDP, I would have thought that routing on the SDP in the offer might choose the wrong destination. [Page 28]/9.3. SIP signaling requirements for proxy servers "They should recognize emergency dial strings, inserting the Route header with the appropriate service URN." "They should query LoST with the location and put the resulting URI in the Request URI." I think that 9.3 has URN and URI the wrong way around. The PSAP URI goes in the Route header field and the service URN goes in the request URI.=20 GENERAL ------- The draft uses "end system" and "endpoint" in various locations, would it be better to use endpoint throughout? RFC3261 always says "header field" (e.g., "Via header field") and not just "header".=20 =20 EDITORIALS ---------- [Page 2]/1. Terminology/"Nomadic device (user): A nomadic user agent is connected to the network temporarily, for relatively short durations, but does not move significantly during the during the emergency call. Examples include a laptop using an IEEE 802.11 hotspot or a desk IP phone that is moved occasionally from one cubicle to another." "during the" is repeated. [Page 3]/1. Terminology/"RoutinglLocation: The routing location of a device is used for routing an emergency call and may not be as precise as the Dispatch Location." Space needed in "RoutinglLocation": [Page 3]/2. Introduction/"This document discusses how end device and applications create emergency calls," "device" should be "devices" [Page 14]/6.1. Types of location information "Jurisdictional refers to a civic location using actual political subdivisions, especially for the community name. Postal refers to a civic location for mail delivery." Needs colon after Jurisdictional and Postal. [Page 19]/6.4. Location and references to location "When location is transmitted by value, the location information is available to entity in the call path." "entity" should be "entities" [Page 20]/6.5 End system location configuration "Normally, mobile devices will acquire its location at call time for use in an emergency call routing. See Section 6.8 for a further discussion on location updates for dispatch location." "mobile devices" should be "a mobile device" [page 29]/11. Mid-call behavior "Therefore a PSAP may need to a REFER request [RFC3515] a call to a bridge for conferencing." should say "Therefore a PSAP may need to send a REFER request [RFC3515] to redirect a call to a bridge for conferencing." Also, "Requiring UI manipulation..." should say "Requiring URI manipulation..." [Page 30]/12. Call termination "i.e with a BYE request." should be "i.e., with a BYE request." [Page 31]/15. Testing "<> includes a description of an automated test procedure that validates routing, signaling and media path continuity." Is something missing from inside the "<>"?=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Gunnar Hellstrom Sent: 28 March 2009 15:31 To: ecrit@ietf.org; Brian Rosen Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distordedreference Brian, A minor editorial: I noticed that the reference to RFC 4103 in section 9.1 was distorded in editing. It looks like this now:=20 xref target=3D"RFC4103"/> It should look like this: [RFC4103] /Gunnar -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, March 27, 2009 11:45 PM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-09.txt Pages : 37 Date : 2009-03-27 The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Thu Apr 2 09:38:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DCC3A69A8 for ; Thu, 2 Apr 2009 09:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm5QSYf32t-f for ; Thu, 2 Apr 2009 09:38:13 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id AD2293A6CE0 for ; Thu, 2 Apr 2009 09:38:00 -0700 (PDT) Received: from col-dhcp33-244-176.bbn.com ([128.33.244.176]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LpPwQ-0001rF-Dj; Thu, 02 Apr 2009 12:38:58 -0400 Message-ID: <49D4D3A4.1070900@bbn.com> Date: Thu, 02 Apr 2009 11:03:00 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA64CD@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D001BA64DB@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA6526@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001BA6526@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:38:14 -0000 Also, to make it even simpler, an empty POST request counts as a HELD request. --Richard Elwell, John wrote: > OK, understood. > > John > >> -----Original Message----- >> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >> Sent: 02 April 2009 08:57 >> To: Elwell, John; James M. Polk; ecrit@ietf.org >> Subject: RE: [Ecrit] Use of SIPPING config framework for >> configuring location >> >> There is no such thing as "HELD URI" in that sense John, it >> is HTTPS. If you direct a HELD request at the URI though you >> will get the HELD semantics if it is a LIS at the other end. >> >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thu 4/2/2009 2:09 AM >> To: James M. Polk; Winterbottom, James; ecrit@ietf.org >> Subject: RE: [Ecrit] Use of SIPPING config framework for >> configuring location >> >> Yes, I was also wondering whether a LIS URI had to be a HELD URI, or >> whether it could just be an HTTP(S) URI, for example? >> >> John >> >>> -----Original Message----- >>> From: James M. Polk [mailto:jmpolk@cisco.com] >>> Sent: 02 April 2009 08:06 >>> To: Elwell, John; Winterbottom, James; ecrit@ietf.org >>> Subject: Re: [Ecrit] Use of SIPPING config framework for >>> configuring location >>> >>> John >>> >>> Or, you can use SIP and not have to implement HELD. HELD >> doesn't need >>> to go into every device, and I'd be surprised that it ends up in >>> every device. Some devices may end up only supporting SIP, >> and using >>> the Geolocation header is a fine way of getting either a >> location URI >>> or a PIDF-LO. >>> >>> James >>> >>> At 01:56 AM 4/2/2009, Elwell, John wrote: >>>> James, >>>> >>>> Thanks. That sounds like a good suggestion. We will give it >>>> consideration. >>>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >>>>> Sent: 02 April 2009 07:34 >>>>> To: Elwell, John; ecrit@ietf.org >>>>> Subject: RE: [Ecrit] Use of SIPPING config framework for >>>>> configuring location >>>>> >>>>> John, >>>>> >>>>> If you have to do something in the SIPPING framework then >>> it would be >>>>> far better to provide a LIS URI and then do a HELD look up as >>>>> per Phone >>>>> BCP or framework. This would mean what you are providing is >>>>> another LIS >>>>> discovery technique rather than yet another LCP. >>>>> >>>>> Cheers >>>>> James >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>>> Of Elwell, John >>>>> Sent: Thursday, 2 April 2009 5:07 PM >>>>> To: ecrit@ietf.org >>>>> Subject: [Ecrit] Use of SIPPING config framework for configuring >>>>> location >>>>> >>>>> We had a SIPPING WG ad hoc meeting during IETF 74, in >>> which the SIP >>>>> Forum UA-config work was presented. It aims to provide a >>>>> simple profile >>>>> of the SIPPING configuration framework and datasets. >>>>> >>>>> The question arose whether the configuration data obtained >>>>> from the SIP >>>>> configuration server should have the possibility to contain the >>>>> geographic location of the SIP UA. Effectively this >> would make it >>>>> another LCP. Does this sound reasonable? Can this be done >>>>> without impact >>>>> on the ECRIT framework and Phone BCP? >>>>> >>>>> John >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> -------------------------------------------------------------- >>>>> ---------------------------------- >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private >> information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>>>> -------------------------------------------------------------- >>>>> ---------------------------------- >>>>> [mf2] >>>>> >>>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> -------------------------------------------------------------- >> ---------------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> -------------------------------------------------------------- >> ---------------------------------- >> [mf2] >> >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From john.elwell@siemens-enterprise.com Thu Apr 2 12:14:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE1A3A6D5E for ; Thu, 2 Apr 2009 12:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msHVbUrDju+T for ; Thu, 2 Apr 2009 12:14:15 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 157D13A6CE0 for ; Thu, 2 Apr 2009 12:14:15 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHH00L5UMTFVE@siemenscomms.co.uk> for ecrit@ietf.org; Thu, 02 Apr 2009 20:15:16 +0100 (BST) Date: Thu, 02 Apr 2009 20:15:12 +0100 From: "Elwell, John" In-reply-to: To: Marc Linsner , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA69F3@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzWT/KSouvYTawTxek+3hQB7A6kAAOHpHUAA1UOdA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:14:16 -0000 Marc,=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com]=20 > Sent: 02 April 2009 13:51 > To: Elwell, John; ecrit@ietf.org > Subject: Re: [Ecrit] Use of SIPPING config framework for=20 > configuring location >=20 > John, >=20 > 1) You probably should propose this idea to GeoPriv. =20 > Regardless of impact > to ECRIT Framework and PhoneBCP, GeoPriv should vet the=20 > privacy and security > impact. [JRE] Thanks. Done. >=20 > 2) I'm curious what you believe would be the relationship=20 > between SIP and > the access network such that SIP would even know how/where to=20 > determine the > UA location information? SIP by itself has no idea of=20 > geographic location, > nor visibility to the layers that do know. [JRE] I know in some proprietary enterprise solutions the configuration server has access to location information, e.g., from LAN switches. I guess in that case the configuration server could behave as a LIS. John >=20 > Thanks, >=20 > -Marc- >=20 >=20 >=20 >=20 > On 4/2/09 2:07 AM, "Elwell, John" > wrote: >=20 > > We had a SIPPING WG ad hoc meeting during IETF 74, in which the SIP > > Forum UA-config work was presented. It aims to provide a=20 > simple profile > > of the SIPPING configuration framework and datasets. > >=20 > > The question arose whether the configuration data obtained=20 > from the SIP > > configuration server should have the possibility to contain the > > geographic location of the SIP UA. Effectively this would make it > > another LCP. Does this sound reasonable? Can this be done=20 > without impact > > on the ECRIT framework and Phone BCP? > >=20 > > John > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 From br@brianrosen.net Thu Apr 2 12:38:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284023A6D49 for ; Thu, 2 Apr 2009 12:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cneCF8TSwtfC for ; Thu, 2 Apr 2009 12:38:17 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 225E928C259 for ; Thu, 2 Apr 2009 12:38:17 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LpSkl-0002t6-5x; Thu, 02 Apr 2009 14:39:07 -0500 From: "Brian Rosen" To: "'Elwell, John'" , "'Marc Linsner'" , References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA69F3@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001BA69F3@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 2 Apr 2009 15:39:14 -0400 Message-ID: <025501c9b3ca$b6406910$22c13b30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmzWT/KSouvYTawTxek+3hQB7A6kAAOHpHUAA1UOdAAAMv9cA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:38:18 -0000 I think you could configure location if you were really sure you knew what the location was. That, in general, is difficult, but possible in enterprise. It means that the the config server has to be able to figure out where the phone is plugged into the Ethernet infrastructure/WiFi/... Often a tough thing to get into the SIP configuration server. I do think that providing a local LIS is not a bad idea, although again, if, say, the phone was in a home office you DO NOT want to tell it that the LIS it should use is in HQ. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Elwell, John Sent: Thursday, April 02, 2009 3:15 PM To: Marc Linsner; ecrit@ietf.org Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location Marc, > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: 02 April 2009 13:51 > To: Elwell, John; ecrit@ietf.org > Subject: Re: [Ecrit] Use of SIPPING config framework for > configuring location > > John, > > 1) You probably should propose this idea to GeoPriv. > Regardless of impact > to ECRIT Framework and PhoneBCP, GeoPriv should vet the > privacy and security > impact. [JRE] Thanks. Done. > > 2) I'm curious what you believe would be the relationship > between SIP and > the access network such that SIP would even know how/where to > determine the > UA location information? SIP by itself has no idea of > geographic location, > nor visibility to the layers that do know. [JRE] I know in some proprietary enterprise solutions the configuration server has access to location information, e.g., from LAN switches. I guess in that case the configuration server could behave as a LIS. John > > Thanks, > > -Marc- > > > > > On 4/2/09 2:07 AM, "Elwell, John" > wrote: > > > We had a SIPPING WG ad hoc meeting during IETF 74, in which the SIP > > Forum UA-config work was presented. It aims to provide a > simple profile > > of the SIPPING configuration framework and datasets. > > > > The question arose whether the configuration data obtained > from the SIP > > configuration server should have the possibility to contain the > > geographic location of the SIP UA. Effectively this would make it > > another LCP. Does this sound reasonable? Can this be done > without impact > > on the ECRIT framework and Phone BCP? > > > > John > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@andrew.com Thu Apr 2 17:33:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0BF3A6C68 for ; Thu, 2 Apr 2009 17:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of8NDsF7LZNh for ; Thu, 2 Apr 2009 17:33:26 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 080F43A69BB for ; Thu, 2 Apr 2009 17:33:25 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_02_19_54_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 02 Apr 2009 19:54:43 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 19:34:27 -0500 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: Thu, 2 Apr 2009 19:34:25 -0500 Message-ID: In-Reply-To: <025501c9b3ca$b6406910$22c13b30$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Use of SIPPING config framework for configuring location Thread-Index: AcmzWT/KSouvYTawTxek+3hQB7A6kAAOHpHUAA1UOdAAAMv9cAAKUgYg References: <0D5F89FAC29E2C41B98A6A762007F5D001BA64C0@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D001BA69F3@GBNTHT12009MSX.gb002.siemens.net> <025501c9b3ca$b6406910$22c13b30$@net> From: "Dawson, Martin" To: "Brian Rosen" , "Elwell, John" , "Marc Linsner" , X-OriginalArrivalTime: 03 Apr 2009 00:34:27.0306 (UTC) FILETIME=[F1DE1CA0:01C9B3F3] Subject: Re: [Ecrit] Use of SIPPING config framework for configuring location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:33:27 -0000 That's right...=0D=0A=0D=0ATypically - given a LIS has more utility than ju= st SIP/VoIP - it's the=0D=0Akind of infrastructure that the SIP server woul= d want to take advantage=0D=0Aof. That's whether it's by value, by referenc= e, or by trusted TPQ and as=0D=0Aopposed to the SIP server trying to take o= n some part of the role of the=0D=0ALIS or, even, the discovery mechanism.=0D= =0A=0D=0AThis topic may fall into the "just because you can do it, should y= ou=3F"=0D=0Acategory.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Origin= al Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@iet= f.org] On Behalf=0D=0AOf Brian Rosen=0D=0ASent: Friday, 3 April 2009 6:39 A= M=0D=0ATo: 'Elwell, John'; 'Marc Linsner'; ecrit@ietf.org=0D=0ASubject: Re:= [Ecrit] Use of SIPPING config framework for configuring=0D=0Alocation=0D=0A=0D= =0AI think you could configure location if you were really sure you knew=0D= =0Awhat=0D=0Athe location was. That, in general, is difficult, but possibl= e in=0D=0Aenterprise. It means that the the config server has to be able t= o=0D=0Afigure=0D=0Aout where the phone is plugged into the Ethernet infrast= ructure/WiFi/...=0D=0AOften a tough thing to get into the SIP configuration= server. I do=0D=0Athink=0D=0Athat providing a local LIS is not a bad idea= , although again, if, say,=0D=0Athe=0D=0Aphone was in a home office you DO = NOT want to tell it that the LIS it=0D=0Ashould=0D=0Ause is in HQ.=0D=0A=0D= =0ABrian=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@iet= f.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf=0D=0AElwell, John=0D= =0ASent: Thursday, April 02, 2009 3:15 PM=0D=0ATo: Marc Linsner; ecrit@ietf= =2Eorg=0D=0ASubject: Re: [Ecrit] Use of SIPPING config framework for config= uring=0D=0Alocation=0D=0A=0D=0AMarc,=20=0D=0A=0D=0A> -----Original Message-= ----=0D=0A> From: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D=0A> Sent: = 02 April 2009 13:51=0D=0A> To: Elwell, John; ecrit@ietf.org=0D=0A> Subject:= Re: [Ecrit] Use of SIPPING config framework for=20=0D=0A> configuring loca= tion=0D=0A>=20=0D=0A> John,=0D=0A>=20=0D=0A> 1) You probably should propose= this idea to GeoPriv. =20=0D=0A> Regardless of impact=0D=0A> to ECRIT Fram= ework and PhoneBCP, GeoPriv should vet the=20=0D=0A> privacy and security=0D= =0A> impact.=0D=0A[JRE] Thanks. Done.=0D=0A=0D=0A>=20=0D=0A> 2) I'm curious= what you believe would be the relationship=20=0D=0A> between SIP and=0D=0A= > the access network such that SIP would even know how/where to=20=0D=0A> d= etermine the=0D=0A> UA location information=3F SIP by itself has no idea o= f=20=0D=0A> geographic location,=0D=0A> nor visibility to the layers that d= o know.=0D=0A[JRE] I know in some proprietary enterprise solutions the conf= iguration=0D=0Aserver has access to location information, e.g., from LAN sw= itches. I=0D=0Aguess in that case the configuration server could behave as = a LIS.=0D=0A=0D=0AJohn=0D=0A=0D=0A=0D=0A>=20=0D=0A> Thanks,=0D=0A>=20=0D=0A= > -Marc-=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> On 4/2/09 2:07 AM, = "Elwell, John" =0D=0A> wrote:=0D=0A> =0D= =0A> > We had a SIPPING WG ad hoc meeting during IETF 74, in which the SIP=0D= =0A> > Forum UA-config work was presented. It aims to provide a=20=0D=0A> s= imple profile=0D=0A> > of the SIPPING configuration framework and datasets.=0D= =0A> >=20=0D=0A> > The question arose whether the configuration data obtain= ed=20=0D=0A> from the SIP=0D=0A> > configuration server should have the pos= sibility to contain the=0D=0A> > geographic location of the SIP UA. Effecti= vely this would make it=0D=0A> > another LCP. Does this sound reasonable=3F= Can this be done=20=0D=0A> without impact=0D=0A> > on the ECRIT framework = and Phone BCP=3F=0D=0A> >=20=0D=0A> > John=0D=0A> >=20=0D=0A> > ___________= ____________________________________=0D=0A> > Ecrit mailing list=0D=0A> > E= crit@ietf.org=0D=0A> > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A> =0D= =0A>=20=0D=0A>=20=0D=0A_______________________________________________=0D=0A= Ecrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/li= stinfo/ecrit=0D=0A=0D=0A_______________________________________________=0D=0A= Ecrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/li= stinfo/ecrit=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A From Martin.Thomson@andrew.com Thu Apr 2 22:49:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2313A67DB for ; Thu, 2 Apr 2009 22:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaDUB1dN7v1B for ; Thu, 2 Apr 2009 22:49:37 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 42BE43A6881 for ; Thu, 2 Apr 2009 22:49:37 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_03_01_10_55 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 03 Apr 2009 01:10:55 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 00:50:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 3 Apr 2009 00:50:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-barnes-ecrit-rough-loc-02 Thread-Index: Acm0IBxHOMt9nC1RTWOfWEUwU/wxaw== From: "Thomson, Martin" To: "ECRIT" X-OriginalArrivalTime: 03 Apr 2009 05:50:38.0542 (UTC) FILETIME=[1D9AFEE0:01C9B420] Subject: [Ecrit] Comments on draft-barnes-ecrit-rough-loc-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 05:49:38 -0000 UmljaGFyZCwgTWF0dCwNCg0KVGhpcyBpcyBteSByZXZpZXcgb2YgZHJhZnQtYmFybmVzLWVjcml0 LXJvdWdoLWxvYy0wMi4gIEkgaGF2ZW4ndCByZWFsbHkgZG9uZSBhIHByb3BlciByZXZpZXcgb2Yg dGhpcyBkb2N1bWVudCBiZWZvcmUuICBTbywgZXZlbiB0aG91Z2ggSSd2ZSBiZWVuIGF3YXJlIG9m IGl0IGFuZCB0aGUgZ2VuZXJhbCBwcmluY2lwbGUsIHRoaXMgaXMgbXkgZmlyc3QgcHJvcGVyIHJl dmlldy4NCg0KVGhpcyBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIG1vc3RseSBjbGVhciBh bmQgZWFzaWx5IHVuZGVyc3RhbmRhYmxlLg0KDQpUaGVyZSBhcmUgc29tZSBpc3N1ZXMgdGhhdCBt ZWFuIHRoYXQgdGhpcyBkb2N1bWVudCBjb3VsZCB1c2Ugc29tZSBhZGRpdGlvbmFsIHdvcmsuDQoN ClRoZSBpbnRyb2R1Y3RvcnkgdGV4dCBpbiB0aGlzIGRvY3VtZW50IGltcGxpZXMgbGFyZ2VyIHNj b3BlIHRoYW4gaXMgYWN0dWFsbHkgZGVsaXZlcmVkLiAgSW4gbWFueSBjYXNlcywgc3RhdGVtZW50 cyBhcmUgcHJlZmFjZWQgd2l0aCAiaWYgcHJlY2lzZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBh dmFpbGFibGUiIG9yIHNpbWlsYXIsIGJ1dCBubyBndWlkYW5jZSBpcyBnaXZlbiB3aGVyZSB0aGUg bG9jYXRpb24gaW5mb3JtYXRpb24gaXMgbm90ICJwcmVjaXNlIi4NCg0KQXMgdGhlIGRvY3VtZW50 IGlzIHJlYWQsIEkgaW5mZXIgdGhhdCB0aGUgZ29hbCBvZiB0aGUgZG9jdW1lbnQgaXMgdG8gZGVz Y3JpYmUgaG93IHRvIHByb3ZpZGUgZGVncmFkZWQgbG9jYXRpb24gaW5mb3JtYXRpb24gd2l0aG91 dCByZXN1bHRpbmcgaW4gcm91dGluZyBmYWlsdXJlcyBmb3IgZW1lcmdlbmN5IGNhbGxpbmcuICBJ IHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBtaWdodCBiZSBhIGRlc2lyZSB0byB3ZWFzZWwgYXJvdW5k IHRoaXMgaXNzdWUsIGJ1dCBpdCBpcyBiZXR0ZXIgdG8gY2xlYXJseSBkZWZpbmUgdGhlIHNjb3Bl IG9mIHRoZSBkb2N1bWVudCB1cCBmcm9udC4NCg0KSSBkb24ndCB0aGluayB0aGF0IHlvdSBjYW4g YXZvaWQgZGlzY3Vzc2lvbiBvZiB3aGVyZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBjcm9zc2VzIGEg c2VydmljZSBib3VuZGFyeS4gIEluIHRoZSBjb250ZXh0IG9mIGEgbW9yZSBsaW1pdGVkIHNjb3Bl LCBpdCBjb3VsZCBiZSBzaWduaWZpY2FudGx5IGVhc2llciB0byBtYW5hZ2UuDQoNCihBcyBhbiBh c2lkZTogSW4gcmVhZGluZyB0aGlzIGRvY3VtZW50IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGl0 cyBhZHZlcnRpc2VkIHNjb3BlLCBJIGJlbGlldmUgdGhhdCB0aGVyZSBhcmUgc2hvcnRjb21pbmdz IGluIExvU1Qgd2l0aCByZXNwZWN0IHRvIGxvdyBxdWFsaXR5IGlucHV0IGxvY2F0aW9uLiAgQSBz aW5nbGUgTG9TVCBzZXJ2ZXIgaXMgYWJsZSB0byBwcm92aWRlIG11bHRpcGxlIG1hcHBpbmdzLCBi dXQgaXQgcHJvdmlkZXMgbm8gbWVhbnMgdG8gZGlzdGluZ3Vpc2ggdGhlbS4gIEZ1cnRoZXJtb3Jl LCBpdCBpcyB1bmFibGUgdG8gcHJvdmlkZSBhIHJlZGlyZWN0IHRvIG11bHRpcGxlIHNlcnZlcnMg d2hlcmUgYW4gYW1iaWd1aXR5IHNwYW5zIHJlZ2lvbnMgY292ZXJlZCBieSBkaWZmZXJlbnQgc2Vy dmVycy4gIFRoaXMgaGFzIG9ubHkgYSBwZXJpcGhlcmFsIGltcGFjdCBvbiB0aGlzIGRvY3VtZW50 IC0gdGhlIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudCB3b3VsZCBlZmZlY3Rp dmVseSB3b3JrIGFyb3VuZCB0aGlzIGxpbWl0YXRpb24uKQ0KDQpJIGRvbid0IGtub3cgdGhhdCBm aWx0ZXIgaXMgdGhlIHJpZ2h0IHdvcmQgdG8gdXNlIGZvciB3aGF0IHRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzLiAgRmlsdGVyLCB0byBtZSwgaW1wbGllcyB0aGF0IHRoZSBpbmZvcm1hdGlvbiBpcyBy ZWZpbmVkIHNvbWVob3csIHdoZXJlIHRoZSBvcHBvc2l0ZSBpcyB0cnVlLiAgIk1hc2siIG1pZ2h0 IGJlIGEgYmV0dGVyIGZpdC4NCg0KKEFsbW9zdCBlZGl0b3JpYWwgY29tbWVudCkgT24gbWVjaGFu aXNtLCBJIHRoaW5rIHRoYXQgdGhlcmUgYXJlIHR3byBtZXRob2RzIHRoYXQgY291bGQgYmUgdXNl ZCBoZXJlLiAgVGhlIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1vcmUgY29tcGxleCBtZWNoYW5pc20g dGhhdCBpcyBlbXBsb3llZCBhaGVhZCBvZiB0aW1lLiAgVGhlcmUgYXJlIG9idmlvdXMgYmVuZWZp dHMgdG8gdGhpcyBhcHByb2FjaCwgYnV0IGl0IG1pZ2h0IGFsc28gYmUgdmlhYmxlIHRvIGFwcGx5 IHRoZSBtZXRob2QgYWZ0ZXIgZGVyaXZpbmcgbG9jYXRpb24gaW5mb3JtYXRpb24uICBGcm9tIG15 IHBlcnNwZWN0aXZlLCBkZXNjcmliaW5nIHRoZSBtZXRob2QgZnJvbSB0aGUgcGVyc3BlY3RpdmUg b2YgdGhlIGluaXRpYWwgcmVxdWVzdCB3b3VsZCBhbHNvIGZsb3cgYmV0dGVyLiAgWW91IHRoZW4g ZGVzY3JpYmUgdGhlIGFzc2VtYmx5IG9mIHRoZSB3aWRlIGFyZWEgZmlsdGVyL21hc2sgYXMgYW4g b3B0aW1pc2F0aW9uLiAgQnkgYWxsIG1lYW5zIGNoYXJhY3RlcmlzZSB0aGUgb3B0aW1pc2F0aW9u IGFzIGltcG9ydGFudCAgb3IgZXZlbiBuZWNlc3NhcnkuDQoNCkl0J3MgdW5jbGVhciB0byBtZSBo b3cgdHdvIHJlZ2lvbnMgZGVmaW5lZCB1c2luZyBjaXZpYyBhZGRyZXNzZXMgY2FuIGJlIGludGVy c2VjdGVkLiAgRm9yIHRoYXQgbWF0dGVyLCBJJ20gbm90IHN1cmUgdGhhdCBJIGtub3cgaG93IHRv IGV4cHJlc3MgYSBjaXZpYyBhZGRyZXNzIHJlZ2lvbiBzdWNjaW5jdGx5LCBidXQgdGhhdCdzIGEg TG9TVCBwcm9ibGVtLiAgSSBkb24ndCB0aGluayB0aGF0IHRoZSBhbGdvcml0aG0gYXMgZGVzY3Jp YmVkIGluIDMuMi4yIGlzIGltcGxlbWVudGFibGUuDQoNCk9uIGRpc2N1c3Npb24gb2YgZW1lcmdl bmN5IGFuZCBub24tZW1lcmdlbmN5IHNlcnZpY2VzLCBJIHRoaW5rIHRoYXQgb25lIHBvaW50IG5l ZWRzIHRvIGJlIG1hZGUgY2xlYXJlciB1cCBmcm9udC4gIFRoZSBsb2NhdGlvbiByZWZlcmVuY2Ug aXMgcHJvdmlkZWQgc28gdGhhdCBhdXRob3JpemVkIHNlcnZpY2VzIGNhbiByZXRyaWV2ZSBsb2Nh dGlvbiBpbmZvcm1hdGlvbiBzdWl0YWJsZSB0byB0aGVpciBuZWVkcy4gIFRoaXMgZG9jdW1lbnQg YXNzdW1lcyB0aGF0IGVtZXJnZW5jeSBzZXJ2aWNlcyB3aWxsIGFsd2F5cyBiZSBhdXRob3JpemVk LiAgVGhhdCdzIHByb2JhYmx5IGFuIGFzc3VtcHRpb24gd29ydGggc3RhdGluZy4NCg0KRm9sbG93 aW5nIHVwIG9uIG5vbi1lbWVyZ2VuY3ksIHRoZXJlIGlzIGEgc3VnZ2VzdGlvbiB0aGF0IHRoZXJl IGNvdWxkIGJlIGFub3RoZXIgcHJvdG9jb2wgZm9yIGRpc2NvdmVyaW5nIHdoYXQgdGhlIGF1dGhv cml6YXRpb24gcG9saWN5IGlzIGZvciBhIGdpdmVuIGxvY2F0aW9uIHJlZmVyZW5jZS4gIEknZCBw cmVmZXIgdG8gc2VlIHRoYXQgdGhpcyBiZSBsZWZ0IHVuc3RhdGVkLiAgSW4gdGhlIGNhc2VzIHdl J3JlIHRhbGtpbmcgYWJvdXQsIHRoaXMgaXMgcHJvYmFibHkgc29tZXRoaW5nIHRoYXQgZ29lcyB3 aXRoIHRoZSBzdGFuZGFyZCB0ZXJtcyBvZiBzZXJ2aWNlIGFncmVlbWVudCBiZXR3ZWVuIHByb3Zp ZGVyIGFuZCB0aGVpciBjdXN0b21lcnM7IEkgc2VlIGxpdHRsZSBwb2ludCBpbiBpbXBseWluZyB0 aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3IgYSBwcm90b2NvbCBmb3IgdGhpcyBpbnRlcmFjdGlvbi4g IEFsc28gcmVtb3ZlIHRoZSB1bnByb3ZhYmxlIHN0YXRlbWVudDogIk5vbi1lbWVyZ2VuY3kgTEJT cyB3aWxsIGdlbmVyYWxseSByZXF1aXJlIG1vcmUgcHJlY2lzZSBpbmZvcm1hdGlvbiB0aGFuIGlz IHJlcXVpcmVkIGZvciBlbWVyZ2VuY3kgY2FsbCByb3V0aW5nLiINCg0KSW4gdGhlIHNlY3VyaXR5 IHNlY3Rpb24geW91IHRhbGsgYWJvdXQgcmVwZWF0ZWQgcmFuZG9taXphdGlvbi4gIFRoYXQncyB0 aGUgc3ViamVjdCBvZiBhIG5vdGUgaW4gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRob21zb24tZ2VvcHJpdi11bmNlcnRhaW50eS0wMiNzZWN0aW9uLTQuNC4xPi4gIFRoZXJlIGlz IGEgdHJhZGUtb2ZmIGJldHdlZW4gdXNpbmcgYSBmaXhlZCBvZmZzZXQsIHdoaWNoIG1pZ2h0IGJl IHJldmVhbGVkIHdoZW4gdGhlIGxvY2F0aW9uIGNoYW5nZXMsIGFuZCBhIHJhbmRvbWl6ZWQgb2Zm c2V0LCB3aGljaCBtaWdodCByZXZlYWwgdGhlIG9yaWdpbmFsIGFyZWEgaWYgcmVwZWF0ZWQgcmVx dWVzdHMgYXJlIG1hZGUgd2hpbGUgdGhlIHRhcmdldCBpcyBzdGF0aW9uYXJ5Lg0KDQpQdXJlbHkg ZWRpdG9yaWFsDQoNCiJwcmVjaXNlIiBpc24ndCBhIHRlcnJpYmxlIHdvcmQsIGJ1dCBpdCBtaWdo dCBiZSBwcnVkZW50IHRvIG1ha2UgaXQgY2xlYXIgd2hhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQu ICBXaGVyZSB5b3UgdGFsayBhYm91dCAicHJlY2lzZSBlbm91Z2giIG9yICJwcmVjaXNlIGluZm9y bWF0aW9uIiwgeW91IGFyZSBhY3R1YWxseSByZWZlcnJpbmcgdG8gbG9jYXRpb24gaW5mb3JtYXRp b24gdGhhdCBoYXMgYSByZWdpb24gb2YgdW5jZXJ0YWludHkgdGhhdCBpcyBlbnRpcmVseSBjb250 YWluZWQgd2l0aCBhIHJlZ2lvbiBvZiBpbnRlcmVzdCAodGhlIHNlcnZpY2UgYm91bmRhcnkpLg0K PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRob21zb24tZ2VvcHJpdi11bmNlcnRh aW50eT4NCg0KU2VjdGlvbiAzIG1lbnRpb25zIHR3bywgYnV0IGxpc3RzIHRocmVlLg0KDQpzL2Nv dXJzZS9jb2Fyc2UvIGluIG9uZSBwbGFjZQ0Kcy9zZXJ2dWNlL3NlcnZpY2UvZw0KDQpTZWN0aW9u IDMuMi4xIGlzIHF1aXRlIGRpZmZpY3VsdCB0byByZWFkIG9uIHRoZSBmaXJzdCBwYXNzLiAgWWVz LCBpdCBpcyBzdWNjaW5jdCBhbmQgY29ycmVjdCwgYnV0IGl0IGRvZXMgc3VmZmVyIGEgbGl0dGxl IGZyb20gYmVpbmcgYSBsaXR0bGUgdG9vIHRlcnNlLiAgVVJJIGFuZCBVUk4gYXJlIGVhc2lseSBj b25mdXNlZCwgc28gbWlnaHQgSSBzdWdnZXN0IHRoYXQgZWFjaCBpcyBwcmVmYWNlZCBhY2NvcmRp bmdseSB0byBkaXN0aW5ndWlzaCB0aGVtOiAgIm1hcHBlZC9yZXN1bHRpbmcgVVJJIiBhbmQgInNl cnZpY2UgVVJOIiBtaWdodCBiZSBlYXNpZXIgdG8gdW5kZXJzdGFuZC4gIEV4cGFuZGluZyB0aGUg YWxnb3JpdGhtIGEgbGl0dGxlIG1pZ2h0IGhlbHAgcmVhZGFiaWxpdHkgYXMgd2VsbC4NCg0KQWxz bywgeW91IG1lbnRpb24gaXRlcmF0aW9uIHRocm91Z2ggdGhlIHNldCBvZiBVUkkgdHVwbGVzICho eXBlbiBvciBuby1oeXBlbikgYnV0IGRvbid0IG1lbnRpb24gdGhhdCB5b3UgYXJlIGNvbXB1dGlu ZyB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZSBzZXJ2aWNlIHJlZ2lvbnMgdGhhdCBjb3JyZXNwb25k IHRvIGVhY2ggVVJJIGluIHRoZSB0dXBsZS4gIEluaXRpYWxseSwgaXQgd2FzIGNvbmZ1c2luZyBi ZWNhdXNlIG15IG5hdHVyYWwgaW5jbGluYXRpb24gd2FzIHRvIHRoaW5rIG9mIHRoZSBVUkkgYW5k IHNlcnZpY2UgcmVnaW9uIGFzIHRoZSB0dXBsZS4NCg0KLS1NYXJ0aW4NCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNp Z25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJp ZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVs eSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlz IGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClttZjJdDQo= From hannes.tschofenig@nsn.com Tue Apr 7 04:50:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFF13A6AF3 for ; Tue, 7 Apr 2009 04:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WjiZY7As5yt for ; Tue, 7 Apr 2009 04:50:55 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4C91D3A6AF7 for ; Tue, 7 Apr 2009 04:50:55 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n37Bq0OX002967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Apr 2009 13:52:00 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n37Bq0Mo002235 for ; Tue, 7 Apr 2009 13:52:00 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 13:51:59 +0200 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, 7 Apr 2009 14:53:23 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45013E7F66@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting Minutes - IETF#74 ECRIT Thread-Index: Acm3d3QlcigmrsdrQG2ODdIT9dw6oQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 07 Apr 2009 11:51:59.0986 (UTC) FILETIME=[4267CD20:01C9B777] Subject: [Ecrit] Meeting Minutes - IETF#74 ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 11:50:56 -0000 Roger put the minutes together:=20 http://www.ietf.org/proceedings/09mar/minutes/ecrit.txt Ciao Hannes From MILANPA@nortel.com Thu Apr 9 08:18:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596DB3A6C02 for ; Thu, 9 Apr 2009 08:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.857 X-Spam-Level: X-Spam-Status: No, score=-4.857 tagged_above=-999 required=5 tests=[AWL=-1.743, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00JdH1SdOX1l for ; Thu, 9 Apr 2009 08:18:13 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 34A363A6BDA for ; Thu, 9 Apr 2009 08:18:13 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n39FIeX18445 for ; Thu, 9 Apr 2009 15:18:40 GMT 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_01C9B926.6F7150F5" Date: Thu, 9 Apr 2009 16:18:27 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E90094B37B8@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps for draft-patel-ecrit-sos-parameter Thread-Index: Acm5Jm56Sd3CvLpSTLe8Y9AKyhflbg== From: "Milan Patel" To: Subject: [Ecrit] Next steps for draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 15:18:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B926.6F7150F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 what are the next steps for this draft? http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 I have not received any further comments since the expert review carreid about by Gonzalo Camarillo.=20 Best regards, Milan Milan Patel=20 Carrier Networks Core Standards=20 Nortel=20 milanpa@nortel.com=20 Telephone +44 162 843 2381 / ESN 560 2381=20 Mobile +44 774 053 9261 / ESN 748 9261=20 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV =20 ------_=_NextPart_001_01C9B926.6F7150F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
what = are the next=20 steps for this draft? ht= tp://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04
I have = not received=20 any further comments since the expert review carreid about by Gonzalo = Camarillo.=20
Best=20 regards,
Milan

Milan Patel
Carrier Networks Core=20 Standards
Nortel =
milanpa@nortel.com
Telephone +44=20 162 843 2381 / ESN 560 2381 =
Mobile +44 774 053 9261 / ESN = 748=20 9261

For the = Companies listed=20 below, The Institute of Chartered Accountants in England and Wales = authorises A=20 R Bloom, S Harris and C Hill to act as Insolvency Practitioners under = section=20 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered = Certified=20 Accountants authorises A M Hudson to act as an Insolvency Practitioner = under=20 section 390(2)(a) of the Insolvency Act 1986.

The affairs, = business and=20 property of the Companies are being managed by the Joint Administrators, = A R=20 Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies = only=20 and without personal liability.

The Companies = are Nortel=20 Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks = France=20 SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel = Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel=20 Networks (Austria) GmbH; Nortel = Networks sro;=20 Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; = Nortel=20 Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; = Nortel=20 Networks AB; Nortel Networks International Finance & Holding=20 BV

 
------_=_NextPart_001_01C9B926.6F7150F5-- From Hannes.Tschofenig@gmx.net Fri Apr 10 00:45:55 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651C23A6B48 for ; Fri, 10 Apr 2009 00:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3mMjACMWQ2Y for ; Fri, 10 Apr 2009 00:45:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 225D83A684E for ; Fri, 10 Apr 2009 00:45:53 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2009 07:47:00 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp006) with SMTP; 10 Apr 2009 09:47:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/Ipd647Z/bioL+qwyHc2rmizy0r7V8Vz0F31baw woxBAN/hzAx9dn From: "Hannes Tschofenig" To: "'Milan Patel'" , References: <0913B6CD18F370498CD65864CF254E90094B37B8@zharhxm1.corp.nortel.com> Date: Fri, 10 Apr 2009 10:48:24 +0300 Message-ID: <00b101c9b9b0$bb0c7bf0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0913B6CD18F370498CD65864CF254E90094B37B8@zharhxm1.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm5Jm56Sd3CvLpSTLe8Y9AKyhflbgAihCeQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Subject: Re: [Ecrit] Next steps for draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 07:45:55 -0000 Hi Milan, Marc and I have scheduled a chat with our new responsible AD, Cullen, about this document. Our plan is to have him as the AD shepherding the document since Jon left the IESG. I understood that the current version is ready to go forward. Ciao Hannes ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Milan Patel Sent: 09 April, 2009 18:18 To: ecrit@ietf.org Subject: [Ecrit] Next steps for draft-patel-ecrit-sos-parameter Folks, what are the next steps for this draft? http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 I have not received any further comments since the expert review carreid about by Gonzalo Camarillo. Best regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV From Hannes.Tschofenig@gmx.net Mon Apr 13 12:33:19 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BDD3A6924 for ; Mon, 13 Apr 2009 12:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl5qwgkGPWco for ; Mon, 13 Apr 2009 12:33:19 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7CB463A6894 for ; Mon, 13 Apr 2009 12:33:18 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 19:34:28 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp045) with SMTP; 13 Apr 2009 21:34:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18jfDwoc5EjLKkc4cWsZOuM7zwS7mnsiy2Ngc2S7D +ogp9mUFEZHKM4 From: "Hannes Tschofenig" To: Date: Mon, 13 Apr 2009 22:35:54 +0300 Message-ID: <014201c9bc6f$0fe69050$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm8bw8zcW1FeCyGTtyV7ENIIELs+w== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 Subject: [Ecrit] Confirming HUM regarding draft-schulzrinne-ecrit-psap-callback-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:33:19 -0000 Hi all, at the IETF#74 ECRIT meeting we had a presentation about the "Marking of Calls initiated by Public Safety Answering Points (PSAPs)" document: http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-00 The group was in favor of turning this document into a working group item. If you have objections or if you weren't at the meeting and would like to express your support for it please let us know by the 24th April 2009. Ciao Hannes & Marc From Hannes.Tschofenig@gmx.net Mon Apr 13 12:33:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83243A6EAE for ; Mon, 13 Apr 2009 12:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksqwO2YgQTp9 for ; Mon, 13 Apr 2009 12:33:32 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 97D5D3A6894 for ; Mon, 13 Apr 2009 12:33:31 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 19:34:41 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp023) with SMTP; 13 Apr 2009 21:34:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+GhlUZpCaGsoCiDk36CCjkUQLGEmszf9zfXaK+UU 8S1B9wOcjGaEsl From: "Hannes Tschofenig" To: Date: Mon, 13 Apr 2009 22:36:07 +0300 Message-ID: <014301c9bc6f$17d84150$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0144_01C9BC88.3D257950" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm8bxdE7AehiPVwQr62hCvhr/rvpQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67,0.67 Subject: [Ecrit] Confirming HUM regarding draft-schulzrinne-ecrit-unauthenticated-access-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:33:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0144_01C9BC88.3D257950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, at the IETF#74 ECRIT meeting we had a presentation about the "Extensions for Unauthenticated & Unauthorized Devices" document: http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-04 The group was in favor of turning this document into a working group item. If you have objections or if you weren't at the meeting and would like to express your support for it please let us know by the 24th April 2009. Ciao Hannes & Marc ------=_NextPart_000_0144_01C9BC88.3D257950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirming HUM regarding = draft-schulzrinne-ecrit-unauthenticated-access-04

Hi all,

at the IETF#74 ECRIT meeting we = had a presentation about the "Extensions for Unauthenticated & = Unauthorized Devices" document:

http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-a= ccess-04

The group was in favor of turning = this document into a working group item.

If you have objections or if you = weren't at the meeting and would like to express your support for it = please let us know by the 24th April 2009.

Ciao
Hannes & Marc


------=_NextPart_000_0144_01C9BC88.3D257950-- From Hannes.Tschofenig@gmx.net Mon Apr 13 12:33:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E11A3A6EB5 for ; Mon, 13 Apr 2009 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRGD2PXMtxVT for ; Mon, 13 Apr 2009 12:33:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 439983A6894 for ; Mon, 13 Apr 2009 12:33:56 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2009 19:35:06 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp064) with SMTP; 13 Apr 2009 21:35:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/NCj1fUZTNPg8RkhwNKSizNQDpzzjFbBFOvWxvWX Mn3bWohlhd/TKQ From: "Hannes Tschofenig" To: Date: Mon, 13 Apr 2009 22:36:32 +0300 Message-ID: <014801c9bc6f$26882c60$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm8byW/IARCAeBSQqyHORnEKim56w== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Subject: [Ecrit] Confirming HUM regarding draft-forte-ecrit-service-urn-policy-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:33:57 -0000 Hi all, at the IETF#74 ECRIT meeting we had a presentation about the "Policy for defining new Service-Identifying Labels" document: http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy-00.txt The group was in favor of turning this document into a working group item. If you have objections or if you weren't at the meeting and would like to express your support for it please let us know by the 24th April 2009. Ciao Hannes & Marc From bernard_aboba@hotmail.com Mon Apr 13 18:46:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB3B3A6A6A for ; Mon, 13 Apr 2009 18:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSAOOsFgXSNc for ; Mon, 13 Apr 2009 18:46:29 -0700 (PDT) Received: from blu0-omc4-s3.blu0.hotmail.com (blu0-omc4-s3.blu0.hotmail.com [65.55.111.142]) by core3.amsl.com (Postfix) with ESMTP id 190D43A69F1 for ; Mon, 13 Apr 2009 18:46:29 -0700 (PDT) Received: from BLU137-W29 ([65.55.111.135]) by blu0-omc4-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 18:47:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_57d7abb0-9e72-4817-bcd0-33af3e94a2a1_" X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: Hannes Tschofenig , Date: Mon, 13 Apr 2009 18:47:40 -0700 Importance: Normal In-Reply-To: <014301c9bc6f$17d84150$0201a8c0@nsnintra.net> References: <014301c9bc6f$17d84150$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Apr 2009 01:47:40.0312 (UTC) FILETIME=[FED8E180:01C9BCA2] Subject: Re: [Ecrit] Confirming HUM regarding draft-schulzrinne-ecrit-unauthenticated-access-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 01:46:30 -0000 --_57d7abb0-9e72-4817-bcd0-33af3e94a2a1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support adopting this as an ECRIT WG work item.=20 From: Hannes.Tschofenig@gmx.net To: ecrit@ietf.org Date: Mon=2C 13 Apr 2009 22:36:07 +0300 Subject: [Ecrit] Confirming HUM regarding draft-schulzrinne-ecrit-unauthent= icated-access-04 Confirming HUM regarding draft-schulzrinne-ecrit-unauthenticated-access-04 Hi all=2C=20 at the IETF#74 ECRIT meeting we had a presentation about the "Extensions fo= r Unauthenticated & Unauthorized Devices" document: http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-0= 4 The group was in favor of turning this document into a working group item.= =20 If you have objections or if you weren't at the meeting and would like to e= xpress your support for it please let us know by the 24th April 2009.=20 Ciao Hannes & Marc=20 --_57d7abb0-9e72-4817-bcd0-33af3e94a2a1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support adopting this as an ECRIT WG work item.


From: Hannes.Tschofenig@gmx.net
To: ecrit@ietf.org
Date: Mo= n=2C 13 Apr 2009 22:36:07 +0300
Subject: [Ecrit] Confirming HUM regardin= g draft-schulzrinne-ecrit-unauthenticated-access-04

Confirming HUM regarding draft-schulzrinne-ecrit-unauthenticated-acc= ess-04 Hi all=2C
at the IETF#74 ECRIT meeting we had a= presentation about the "Extensions for Unauthenticated &=3B Unauthorize= d Devices" document:
ht= tp://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-04<= /font>
The group was in favor of turning thi= s document into a working group item.
If you have objections or if you were= n't at the meeting and would like to express your support for it please let= us know by the 24th April 2009.
Ciao
Hannes &=3B Marc

= --_57d7abb0-9e72-4817-bcd0-33af3e94a2a1_-- From robinsg@huawei.com Mon Apr 13 22:59:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C7D3A693E for ; Mon, 13 Apr 2009 22:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5MWtYQhGvQa for ; Mon, 13 Apr 2009 22:59:08 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 87BED3A67D1 for ; Mon, 13 Apr 2009 22:59:08 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI200GYMU0644@szxga03-in.huawei.com> for ecrit@ietf.org; Tue, 14 Apr 2009 14:00:06 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI2004G2U06C3@szxga03-in.huawei.com> for ecrit@ietf.org; Tue, 14 Apr 2009 14:00:06 +0800 (CST) Received: from [127.0.0.1] ([10.85.202.194]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI2003DHU0598@szxml04-in.huawei.com> for ecrit@ietf.org; Tue, 14 Apr 2009 14:00:06 +0800 (CST) Date: Tue, 14 Apr 2009 14:00:05 +0800 From: Robins George In-reply-to: To: Bernard Aboba Message-id: <49E42665.4040602@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) References: <014301c9bc6f$17d84150$0201a8c0@nsnintra.net> Cc: Hannes Tschofenig , ecrit@ietf.org Subject: Re: [Ecrit] Confirming HUM regarding draft-schulzrinne-ecrit-unauthenticated-access-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 05:59:09 -0000 +1 Bernard Aboba wrote: > I support adopting this as an ECRIT WG work item. > > > > > ------------------------------------------------------------------------ > From: Hannes.Tschofenig@gmx.net > To: ecrit@ietf.org > Date: Mon, 13 Apr 2009 22:36:07 +0300 > Subject: [Ecrit] Confirming HUM regarding > draft-schulzrinne-ecrit-unauthenticated-access-04 > > Hi all, > at the IETF#74 ECRIT meeting we had a presentation about the > "Extensions for Unauthenticated & Unauthorized Devices" document: > _http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-04_ > > The group was in favor of turning this document into a working group > item. > If you have objections or if you weren't at the meeting and would like > to express your support for it please let us know by the 24th April 2009. > Ciao > Hannes & Marc > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From robinsg@huawei.com Mon Apr 13 22:59:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE073A6DC9 for ; Mon, 13 Apr 2009 22:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWtkFy9ssS5r for ; Mon, 13 Apr 2009 22:59:51 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A3B453A67D1 for ; Mon, 13 Apr 2009 22:59:51 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI200G2HU1G44@szxga03-in.huawei.com> for ecrit@ietf.org; Tue, 14 Apr 2009 14:00:52 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI200GTDU1G6X@szxga03-in.huawei.com> for ecrit@ietf.org; Tue, 14 Apr 2009 14:00:52 +0800 (CST) Received: from [127.0.0.1] ([10.85.202.194]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI200KZ9U1F38@szxml06-in.huawei.com> for ecrit@ietf.org; Tue, 14 Apr 2009 14:00:52 +0800 (CST) Date: Tue, 14 Apr 2009 14:00:51 +0800 From: Robins George In-reply-to: <014801c9bc6f$26882c60$0201a8c0@nsnintra.net> To: Hannes Tschofenig Message-id: <49E42693.8070701@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) References: <014801c9bc6f$26882c60$0201a8c0@nsnintra.net> Cc: ecrit@ietf.org Subject: Re: [Ecrit] Confirming HUM regarding draft-forte-ecrit-service-urn-policy-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 05:59:52 -0000 I support. Hannes Tschofenig wrote: > Hi all, > > at the IETF#74 ECRIT meeting we had a presentation about the "Policy for > defining new Service-Identifying Labels" document: > http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy-00.txt > > The group was in favor of turning this document into a working group item. > > If you have objections or if you weren't at the meeting and would like to > express your support for it please let us know by the 24th April 2009. > > Ciao > Hannes & Marc > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > From Martin.Thomson@andrew.com Thu Apr 16 18:26:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227C33A68D8 for ; Thu, 16 Apr 2009 18:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DruzFRaU0BmW for ; Thu, 16 Apr 2009 18:26:24 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 494753A6802 for ; Thu, 16 Apr 2009 18:26:23 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_16_20_32_40 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 16 Apr 2009 20:32:40 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 20:12:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 16 Apr 2009 20:12:05 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-framework-09: review Thread-Index: Acm++YW5EbAvtfvrS5aYUJl3HCyGNQ== From: "Thomson, Martin" To: , , , X-OriginalArrivalTime: 17 Apr 2009 01:12:07.0441 (UTC) FILETIME=[86CBD810:01C9BEF9] Cc: ECRIT Subject: [Ecrit] draft-ietf-ecrit-framework-09: review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 01:26:26 -0000 R2VuZXJhbCBjb21tZW50czogIFRoaXMgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCBpdCBj b252ZXlzIHRoZSBhcmNoaXRlY3R1cmUgY2xlYXJseSBhbmQgcmF0aW9uYWxseS4gIEl0IGlzIGEg bGl0dGxlIHdvcmR5IGluIHBsYWNlcywgYW5kIGl0IGNvdWxkIHByb2JhYmx5IGJlIHNob3J0ZW5l ZDsgaG93ZXZlciwgSSBzZWUgbm8gaGFybSBpbiBwdWJsaXNoaW5nIGFzIGlzLg0KDQpUaGlzIHdh cyBnb2luZyB0byBiZSBqdXN0IGEgZmV3IG5pdHMsIGJ1dCBzb21lIG9mIHRoZXNlIGFyZSBhIGxp dHRsZSBtb3JlIHNlcmlvdXMuICBPZiBjb3Vyc2UsIG5vbmUgYXJlIGFsbCBUSEFUIHNlcmlvdXMu DQoNCn5+DQoNClNlY3Rpb24gMywgUGFnZSA3OiB0aGUgc2Vjb25kIHN0ZXAgb2YgdGhlIHByb2Nl ZHVyYWwgb3ZlcnZpZXcgY2FuIGJlIGNoYW5nZWQgdG86DQoNCiAgICJvIFRoZSBwaG9uZSBnZXRz IGl0cyBsb2NhdGlvbi4gIFRoaXMgbWlnaHQgYmUgdmlhIGEgTG9jYXRpb24gQ29uZmlndXJhdGlv biBQcm90b2NvbCAoTENQKSAuLi4gW0xMRFBdLiAgQWx0ZXJuYXRpdmVseSBhIHBob25lIG1pZ2h0 IGJlIGFibGUgdG8gZGV0ZXJtaW5lIGl0cyBsb2NhdGlvbiBhdXRvbm9tb3VzbHksIGZvciBleGFt cGxlIHVzaW5nIGEgR2xvYmFsIFBvc2l0aW9uIFN5c3RlbSAoR1BTKS4iDQoNCiAoc3VnZ2VzdGlv bjogZm9yIHRoZSBiZW5lZml0IG9mIGRpc2N1c3Npb24gcmVsYXRpbmcgdG8gdGhpcyBvdmVydmll dywgaXQgbWlnaHQgYmUgaGVscGZ1bCB0byBudW1iZXIgbGlzdHMgb2YgdGhpcyBzb3J0LCByYXRo ZXIgdGhhbiB1c2UgYnVsbGV0cykNCg0KUGFnZSA4IChzYW1lIGxpc3QpOiB0aGUgZmlmdGggc3Rl cCAodGhpcmQgb24gdGhlIHBhZ2UpIG5lZWQgbm90IHJlZmVyZW5jZSBESENQLiAgU3VnZ2VzdCBj aGFuZ2UgdG86DQoNCiAgICJvIFRoZSBwaG9uZSByZWZyZXNoZXMgaXRzIGxvY2F0aW9uIGFuZCB1 cGRhdGVzIHRoZSBQU0FQJ3MgVVJJIC4uLiAgIg0KDQpQYWdlIDksIEZpZ3VyZSAxOiBJIGRvbid0 IGtub3cgd2hhdCBpbmZlcmVuY2UgeW91IGV4cGVjdCBmb2xrcyB0byBtYWtlIGZyb20gdGhlIGFz c29jaWF0aW9uIG9mIHRoZSBMSVMgYW5kIFNJUCByZWdpc3RyYXIsIChkb3R0ZWQgbGluZSkgYnV0 IGl0J3MgdGhlIHdyb25nIG9uZS4gIFN1Y2ggYSBncm91cGluZyBjYW4gb25seSBpbXBseSBwaHlz aWNhbCBwcm94aW1pdHkgb3Igb3BlcmF0aW9uIGJ5IHRoZSBzYW1lIGVudGl0eSwgbmVpdGhlciBv ZiB3aGljaCBpcyBuZWNlc3NhcmlseSB0cnVlLiAgSSBhbHNvIGNhbm5vdCBzZWUgd2h5IHRoZSBM b1NUIHNlcnZlciBpc24ndCBzaW1pbGFybHkgZ3JvdXBlZC4gIEknZCBzdWdnZXN0IHJlbW92YWwg b2YgYW55IGdyb3VwaW5nLiAgVGhpcyBleHRlbmRzIHRvIHRoZSBsaXN0IG9uIFBhZ2UgMTAgdGhh dCBncm91cHMgdGhlc2UuDQoNClNlY3Rpb24gNiwgUGFnZSAxMzogdGhlIGNvbmNlcHQgb2YgdmFs aWRpdHkgd2l0aCBsb2NhdGlvbiBpcyBub3Qgd2VsbCBlbm91Z2ggdW5kZXJzdG9vZCB0byB0aHJv dyBvdXQgYSBwaHJhc2UgbGlrZSAidW5pcXVlLCB2YWxpZCBsb2NhdGlvbiIgd2l0aG91dCBleHBs YW5hdGlvbi4gIFJlYWRlcnMgbWlnaHQgbG9vayBmb3Igb3RoZXIgaGlkZGVuIG1lYW5pbmcgaW4g dGhlIHdvcmRzIGNob3NlbiBoZXJlLiAgQ2FuIHlvdSBjbGFyaWZ5IHRoYXQgdGhlIGdvYWwgaW4g dGhpcyBpbnN0YW5jZSBpcyB0byBoYXZlIGxvY2F0aW9uIGluZm9ybWF0aW9uIHRoYXQgY2FuIGJl IHN1Y2Nlc3NmdWxseSB1c2VkIHRvIHJvdXRlIGFuZCBkaXNwYXRjaC4gIEknbSBhbHNvIG5vdCBj ZXJ0YWluIHRoYXQgdW5pcXVlIGlzIHRoZSB0ZXJtIHlvdSBhcmUgbG9va2luZyBmb3I6IHVuYW1i aWd1b3VzIG1pZ2h0IGJlIGJldHRlci4gIFN1Z2dlc3QgeW91IGVpdGhlciBkZWZpbmUgd2hhdCB5 b3UgbWVhbiwgcmVmZXJlbmNlIDYuMTAsIG9yIGJvdGg6DQoNCiAgICJJdCBpcyBmcmVxdWVudGx5 IHRoZSBjYXNlIHRoYXQgYSBjYWxsZXIgcmVwb3J0aW5nIGFuIGVtZXJnZW5jeSBpcyB1bmFibGUg dG8gcHJvdmlkZSBhIHZhbGlkIGxvY2F0aW9uIChzZWUgU2VjdGlvbiA2LjEwKSB0aGF0IGNhbiBi ZSB1c2VkIGZvciByb3V0aW5nIGFuZCBkaXNwYXRjaC4iDQoNClNlY3Rpb24gNiwgUGFnZSAxMzog V2hpbGUgdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmU6ICJvdmVybG9hZCBhcnJhbmdlbWVudHMgYmV0 d2VlbiBQU0FQcyB0byBoYW5kbGUgZWFjaCBvdGhlcnMnIGNhbGxzIiwgaXMgcGVyaGFwcyBpbnRl cmVzdGluZywgdGhpcyBpcyBhY3R1YWxseSBpcnJlbGV2YW50IGluIHRoaXMgY29udGV4dCBhbmQg Y291bGQgYmUgcmVtb3ZlZC4NCg0KUGFnZSAxNDogcy9cLiBpZi9cLiAgSWYvDQoNClBhZ2UgMTQ6 IEF2b2lkIG1ha2luZyBzdGF0ZW1lbnRzIHRoYXQgY291bGQgYmUgcHJvdmVuIHJpZGljdWxvdXMg aW4gaGluZHNpZ2h0IHN1Y2ggYXM6ICAiVGhlIGFjdHVhbCByZXF1aXJlbWVudCBpcyBtb3JlIHN0 cmluZ2VudCB0aGFuIGF2YWlsYWJsZSB0ZWNobm9sb2d5IGNhbiBkZWxpdmVyIiAgQWxzbywgdGhl IHNlbnRlbmNlIG9uICJkZW1pc2luZyIgZm9sbG93aW5nIHRoaXMgbWlnaHQgYmUgdHJ1ZSBpbiBz b21lIGNhc2VzLCBidXQgdGhlIHN0YXRlbWVudCBpcyBvbmx5IGxvb3NlbHkgbGlua2VkIHRvIHRo ZSBxdWFsaWZpY2F0aW9uIGFib3V0IGxvY2FsIHJlZ3VsYXRpb24uICBJIHRoaW5rIHRoYXQgeW91 IGNhbiBtYWtlIHRoaXMgbWVzc2FnZSBhIGxvdCBjbGVhcmVyIHdpdGhvdXQgZmFsbGluZyBpbnRv IHRoZSB0d2luIHRyYXBzIG9mIGRhdGluZyB0aGUgZG9jdW1lbnQgb3IgcmVmZXJlbmNpbmcgdW5y ZWFsaXN0aWMgcmVndWxhdGlvbiBmcm9tIGEgc3BlY2lmaWMganVyaXNkaWN0aW9uLiAgVGhlIGxl YWQtaW4gc3RhdGVtZW50IG1pZ2h0IGJlIHN1ZmZpY2llbnQuICBJdCBtaWdodCBhbHNvIGJlIHBy dWRlbnQgdG8gcG9pbnQgb3V0IHRoYXQgdGhlcmUgYXJlIHdoYXQgbWlnaHQgYmUgZGVzaXJlZCAo M2NtKSBhbmQgd2hhdCBtaWdodCBiZSBzZXR0bGVkIGZvciAoMTAwbSkuICBDZXJ0YWlubHksIG1l bnRpb24gdGhhdCBlbWVyZ2VuY3kgY2FsbCBzeXN0ZW1zIGFyZSBoaWdobHkgZGVtYW5kaW5nIG9m IGFjY3VyYWN5Og0KDQogICJFbWVyZ2VuY3kgY2FsbCBzeXN0ZW1zIGRlbWFuZCBhIHZlcnkgaGln aCBsZXZlbCBvZiBhY2N1cmFjeSBmcm9tIGxvY2F0aW9uLiAgUmVndWxhdGlvbiBvbiBsb2NhdGlv biBhY2N1cmFjeSBjYW4gYmUgZXhjZWVkaW5nbHkgc3RyaW5nZW50LCByZXF1aXJpbmcgdGhlIGJl c3QgYXZhaWxhYmxlIGxvY2F0aW9uIHRlY2hub2xvZ3kuICBTb21ldGltZXMsIGEgc21hbGwgZXJy b3IgY2FuIG1ha2UgYSBzaWduaWZpY2FudCBkaWZmZXJlbmNlIGluIHRoZSB0aW1lIHRha2VuIHRv IHJlc3BvbmQgdG8gYW4gZW1lcmdlbmN5LiAgRm9yIGV4YW1wbGUsIGluIGFuIGFwYXJ0bWVudCBj b21wbGV4LCBhbiBlcnJvciBvZiBhcyBzbWFsbCBhcyAzY20gY2FuIG1lYW4gdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiBvbmUgYXBhcnRtZW50IGFuZCBhbm90aGVyLiAgSGlnaGx5IGFjY3VyYXRlIGxv Y2F0aW9uIGluZm9ybWF0aW9uIGNhbiBtYWtlIGEgc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnQgaW4g dGhlIGFiaWxpdHkgb2YgZW1lcmdlbmN5IHNlcnZpY2VzIHRvIHJlc3BvbmQgdG8gYW4gZW1lcmdl bmN5LiINCg0KU2VjdGlvbiA2LjEsIFBhZ2UgMTY6IEEgY2VsbCB0b3dlciBpZGVudGlmaWVyIGlz IE5PVCBsb2NhdGlvbiBpbmZvcm1hdGlvbi4gIEl0J3MgbG9jYXRpb24tcmVsYXRlZCBtZWFzdXJl bWVudCBkYXRhLiAgSW4gZ2VuZXJhbCwgdGhlc2UgdGhpbmdzIGRvbid0IG1vdmUsIGJ1dCB0aGF0 J3MgYmVnaW5uaW5nIHRvIGJlIGEgZGFuZ2Vyb3VzIGFzc3VtcHRpb24uICBTZWFyY2ggZm9yICJw b3J0YWJsZSBjZWxsIHRvd2VyIiwgb3IgZXZlbiBsb29rIHRvIGZlbXRvY2VsbHMgKGFsdGhvdWdo IHRoZXJlIGFyZSBlZmZvcnRzIHRvIG1ha2UgdGhlc2UgZWZmZWN0aXZlbHkgbm9uLXBvcnRhYmxl LCBzb21lIG9mIGl0IGFtYXppbmdseSBpbmdlbmlvdXMpLg0KDQpTZWN0aW9uIDYuMjogSXQgd291 bGQgYmUgc2Vuc2libGUgdG8gaW5kaWNhdGUgYWxvbmcgd2l0aCAidGhlIG9yZGVyIG9mIHRoZSBs b2NhdGlvbnMgc2hvdWxkIGJlIHRoZSBzZW5kZXIncyBiZXN0IGF0dGVtcHQgdG8gZ3VpZGUgdGhl IHJlY2lwaWVudCBvZiB3aGljaCBvbmUocykgdG8gdXNlIiB0aGF0IHRoZSBfZmlyc3RfIGxvY2F0 aW9uIHNob3VsZCBiZSB0aGUgImJlc3QiLiAgUmVmZXJlbmNlIFNlY3Rpb24gNi45Lg0KDQpTZWN0 aW9uIDYuMi4xOiBBbm90aGVyIHN0YXRlbWVudCBvZiB3aGF0IGlzIGp1cmlzZGljdGlvbmFsIHBv bGljeTogDQoNCiAgIkFzIGFuIGFzaWRlLCBub3JtYWxseSwgaWYgYW4gZW1lcmdlbmN5DQogICBj YWxsZXIgaW5zaXN0cyB0aGF0IGhlIGlzIGF0IGEgbG9jYXRpb24gZGlmZmVyZW50IGZyb20gd2hh dCBhbnkNCiAgIGF1dG9tYXRpYyBsb2NhdGlvbiBkZXRlcm1pbmF0aW9uIHN5c3RlbSByZXBvcnRz IGhlIGlzLCByZXNwb25kZXJzDQogICB3aWxsIGFsd2F5cyBiZSBzZW50IHRvIHRoZSB1c2VyJ3Mg c2VsZi1kZWNsYXJlZCBsb2NhdGlvbi4gIA0KDQpUaGlzIGlzIG5vdCByZWFsbHkgc29tZXRoaW5n IHRoYXQgdGhlIElFVEYgaXMgcXVhbGlmaWVkIHRvIHN0YXRlLiAgQWxsIHRoYXQgbmVlZHMgdG8g YmUgc2FpZCBpcyB0aGF0ICJ0aGUgcG9saWN5IG9uIHdoZXRoZXIgdXNlci1lbnRlcmVkIGxvY2F0 aW9uIGlzIGFjY2VwdGVkIGlzIG9uZSBzZXQgYnkganVyaXNkaWN0aW9ucyIgYW5kIG1heWJlICJz b21lIGp1cmlzZGljdGlvbnMgd2lsbCBhbHdheXMgcmVzcGVjdCBhIHVzZXIncyBzZWxmLWRlY2xh cmVkIGxvY2F0aW9uLCBzb21ldGltZXMgYWJvdmUgdGhhdCB3aGljaCBpcyByZXBvcnRlZCBieSBh dXRvbWF0ZWQgc3lzdGVtcyIuDQoNClNlY3Rpb24gNi4yLjI6IEFub3RoZXIgc3RhdGVtZW50IGJl aW5nIG1hZGUgd2l0aG91dCBzdWZmaWNpZW50IGF1dGhvcml0eToNCg0KICAgIlRoZSB0aHJlc2hv bGQgZm9yIHdoZW4gaW50ZXJpb3IgbG9jYXRpb24gaXMgbmVlZGVkIGlzIGFwcHJveGltYXRlbHkN CiAgIDY1MCBzcXVhcmUgbWV0ZXJzLiINCg0KU2VjdGlvbiA2LjIuMzogbWlub3IgY29ycmVjdGlv bjogQS1HUFMgaXNuJ3QgbmVjZXNzYXJpbHkgcHJvdmlkZWQgYnkgdGhlIGFjY2VzcyBuZXR3b3Jr LCBhbHRob3VnaCB0aGlzIGlzIGltcGxpZWQgYnkgdGhlIHN0YXRlbWVudCBoZXJlLiAgSXQncyBh bHNvIHBvc3NpYmx5IHdvcnRoIG5vdGluZyB0aGF0IHdpdGggYXNzaXN0YW5jZSwgR1BTIG1pZ2h0 IGJlIGFibGUgdG8gbWVldCB0aGUgdGltaW5nIHJlcXVpcmVtZW50cyBmb3Igcm91dGluZy4NCg0K U2VjdGlvbiA2LjIuMzogU3VnZ2VzdCB0aGF0IHlvdSB1c2UgdGhlIG1vcmUgZ2VuZXJpYyBHbG9i YWwgTmF2aWdhdGlvbiBTYXRlbGxpdGUgU3lzdGVtIChHTlNTKSByYXRoZXIgdGhhbiBHUFMuDQoN ClNlY3Rpb24gNi4yLjM6IFN1Z2dlc3QgdGhhdCB5b3UgbWVudGlvbiB0aGUgcG9zc2liaWxpdHkg b2Ygb3RoZXIgYXV0b25vbW91cyBwb3NpdGlvbmluZyBzeXN0ZW1zLiAgVGhlcmUgYXJlIGNlcnRh aW5seSBvdGhlciBwb3NzaWJpbGl0aWVzLCBzdWNoIGFzIHRoZSBzaG9ydCByYW5nZSBiZWFjb24g YXJyYW5nZW1lbnQgbWVudGlvbmVkIGluIFNlY3Rpb24gNi4yLjQuDQoNClNlY3Rpb24gNi40OiBz L2F2YWlsYWJsZSB0byBlbnRpdHkgaW4gdGhlIGNhbGwgcGF0aC9hdmFpbGFibGUgdG8gZW50aXRp ZXMgaW4gdGhlIGNhbGwgcGF0aC8NCg0KU2VjdGlvbiA2LjY6IENvbnRpbnVpbmcgdGhlIHRoZW1l IGZyb20gYWJvdmUgcmVnYXJkaW5nIGNlbGwgaWRlbnRpZmllcnMsIHRoZSBmb2xsb3dpbmcgc3Rh dGVtZW50IGlzIHRydWUgb2YgY2hvaWNlcyBtYWRlIGhpc3RvcmljYWxseSBpbiAzZ3BwLCBidXQg ZXZlbiB0aGVyZSB0aGlzIGlzIG5vIGxvbmdlciB0cnVlIHdpdGggSlNURC0wMzZCOg0KDQogICAi SW4gbW9iaWxlIGhhbmRzZXRzLCByb3V0aW5nIGlzIG9mdGVuIGFjY29tcGxpc2hlZCB3aXRoIHRo ZSBjZWxsDQogICBzaXRlIGFuZCBzZWN0b3Igb2YgdGhlIHRvd2VyIHNlcnZpbmcgdGhlIGNhbGws Ig0KDQpCZXR0ZXIgdG8gc2ltcGx5IHN0YXRlIHRoYXQgcm91dGluZyBpcyBhY2NvbXBsaXNoZWQg YmFzZWQgb24gbG9jYXRpb24gaW5mb3JtYXRpb24gdGhhdCBpcyBkZXJpdmVkIGZyb20gY2VsbCB0 b3dlciBhbmQgc2VjdG9yLiAgVGhlIGtleSB0aGluZyBoZXJlIGlzIHRpbWVsaW5lc3M7IGFsbCB0 aGlzIHNlZW1zIHRvIGRvIGlzIGltcGx5IHRoYXQgc3BlY2lhbCBleGNlcHRpb25zIGV4aXN0LiAg RXZlbiBpZiBzdWNoIHByb3Zpc2lvbnMgZG8gZXhpc3QsIHRoZXkgYXJlIGxpa2VseSB0byBiZSBp bmNvbnNpc3RlbnRseSBzdXBwb3J0ZWQuDQoNClNlY3Rpb24gNi42OiB3aGVyZSBkb2VzIHRoZSAz IHNlY29uZHMgY29tZSBmcm9tPyAgU2VlbXMgYSBsaXR0bGUgYXJiaXRyYXJ5IHRvIG1lLiAgSW4g V2lraXBlZGlhIHBhcmxhbmNlOiBbY2l0YXRpb24gbmVlZGVkXS4NCg0KU2VjdGlvbiA2Ljg6IHRo ZSBQU0FQIF9zaG91bGRfIHVzZSAiZW1lcmdlbmN5RGlzcGF0Y2giLiAgQWZ0ZXIgYWxsLCBpZiB0 aGUgb3BlcmF0b3Iga25vd3MgdGhhdCB0aGlzIHNvbWV0aW1lcyB0YWtlcyAzMCBzZWNvbmRzIGFu ZCB0aGV5IGFyZW4ndCB3aWxsaW5nIHRvIHdhaXQgdGhhdCBsb25nLCB0aGV5IHNob3VsZCBiZSBh YmxlIHRvIHdpbmQgdGhlIHRpbWUgYmFjayB0byAxMCBzZWNvbmRzIG9yIHdoYXRldmVyIGlzIG1v c3QgYXBwcm9wcmlhdGUuDQoNClNlY3Rpb24gNi45OiBzLyJkZXJpdmVkIi8iRGVyaXZlZCIvIGFu ZCByZWZlcmVuY2UgdGhlIElBTkEgcmVnaXN0cnkgcmF0aGVyIHRoYW4gNDExOSwgd2hpY2ggbWFr ZXMgbm8gbWVudGlvbiBvZiB0aGlzIHBhcnRpY3VsYXIgdGFnLg0KDQpTZWN0aW9uIDYuMTE6IENh biBJIHN1Z2dlc3QgdGhhdCB0aGlzIHNlY3Rpb24gYWxzbyBzdGF0ZSB0aGF0IHRoZSBkZWZhdWx0 IGxvY2F0aW9uIHNob3VsZCBoYXZlIGFwcHJvcHJpYXRlIHVuY2VydGFpbnR5LiAgVW5jZXJ0YWlu dHkgbWlnaHQgYmUgYWxsIHRoZSBtYXJraW5nIG5lY2Vzc2FyeSBpbiBzb21lIGNhc2VzLCBidXQg aWYgdGhpcyBpcyBub3QgdGhlIGNhc2UsIHlvdSBoYXZlIHByb3ZpZGVkIG5vIG1lYW5zIHRvIG1h cmsgbG9jYXRpb25zIGFzIGEgZmFsbGJhY2suICBXZSBjYW4gZGViYXRlIHRoZSBtZXJpdHMgb2Yg YSBtYXJraW5nIHNvbWUgb3RoZXIgdGltZSwgYnV0IHRoZSB0ZXh0IGhlcmUgaW1wbGllcyB0aGF0 IHRoZXJlIGlzIGEgbWFya2luZywgd2hlcmUgSSBhbSBub3QgYXdhcmUgb2Ygb25lLg0KDQpTZWN0 aW9uIDc6IENhbiBJIHN1Z2dlc3QgdGhhdCB5b3Ugc2VwYXJhdGUgTElTIGFuZCBMb1NUIGRpc2Nv dmVyeSBhIGxpdHRsZSBtb3JlLiAgTm90ZSB0aGF0IExJUyBkaXNjb3ZlcnkgaXMgbmVjZXNzYXJ5 LCBidXQgTG9TVCBkaXNjb3ZlcnkgaXNuJ3QsIHNpbmNlIHRoZSBzeXN0ZW0gb2YgZm9yZXN0IGd1 aWRlcyBzaG91bGQgYmUgYWJsZSB0byBlbnN1cmUgdGhhdCBhIHJlcXVlc3QgdG8gYW55IExvU1Qg c2VydmVyIHJlc3VsdHMgaW4gYSBzdWNjZXNzZnVsIHJlc3VsdC4gIFRoZXJlZm9yZSwgc3RhdGlj IGNvbmZpZ3VyYXRpb24gb2YgYSBMb1NUIHNlcnZlciBpcyBxdWl0ZSByZWFzb25hYmxlLCB3aGVy ZWFzIHdlIGFkdmlzZSBhZ2FpbnN0IHN0YXRpYyBjb25maWd1cmF0aW9uIGZvciBhIExJUy4NCg0K U2VjdGlvbiA3OiAiVGhlIGVuZHBvaW50IGNhbiBhbHNvIGRvIGEgRE5TIFNSViBxdWVyeSB0byBm aW5kIGEgTG9TVCBzZXJ2ZXIuIiBUbyB3aGljaCBkb21haW4/ICBBbHNvIG5vdGUgdGhhdCBMb1NU IGRpc2NvdmVyeSBpbiA1MjIyIGFuZCA1MjIzIGRvZXNuJ3QgdXNlIFNSViByZWNvcmRzIGF0IGFs bC4NCg0KU2VjdGlvbiA5LjE6IHRoZSBmaXJzdCBzZW50ZW5jZSBoZXJlIGRvZXNuJ3QgcGFyc2Ug cGFydGljdWxhcmx5IHdlbGwsIGV2ZW4gd2hlbiBJIGFsbG93IGZvciAgdGhlIG1pc3NpbmcgJzwn Lg0KDQpTZWN0aW9uIDE0OiBUaGUgb3JkZXJpbmcgZ29lczogdGV4dCwgdm9pY2UsIHRleHQsIHZp ZGVvLiAgU3VnZ2VzdCB0aGF0IHlvdSBtb3ZlIHRoZSBzdGF0ZW1lbnQgb24gcmVhbCB0aW1lIHRl eHQgYWZ0ZXIgZy43MTEuDQoNClNlY3Rpb24gMTU6ICI8PiIgc291bmRzIGxpa2UgYSBtaWdodHkg aW50ZXJlc3RpbmcgZG9jdW1lbnQuDQoNCn5+DQoNCi0tTWFydGluDQoNCg0KDQoNCg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMg Zm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmls ZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy DQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQg dXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= From mlinsner@cisco.com Fri Apr 24 11:22:34 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1237F3A6A24 for ; Fri, 24 Apr 2009 11:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=-1.789, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, TVD_SPACED_SUBJECT_WORD3=2.412] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSumP0D2q2ha for ; Fri, 24 Apr 2009 11:22:31 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 288BE3A6A02 for ; Fri, 24 Apr 2009 11:22:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208,217";a="73226919" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2009 18:23:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3OINo6x018978 for ; Fri, 24 Apr 2009 11:23:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OINn0i011551 for ; Fri, 24 Apr 2009 18:23:49 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 14:23:49 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 14:23:49 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 24 Apr 2009 14:23:48 -0400 From: Marc Linsner To: ECRIT Message-ID: Thread-Topic: PhoneBCP Thread-Index: AcnFCc9L9nD8ewW6UUCN5n36AHW7fw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3323427829_1326337" X-OriginalArrivalTime: 24 Apr 2009 18:23:49.0348 (UTC) FILETIME=[D0198240:01C9C509] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1742; t=1240597430; x=1241461430; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20PhoneBCP |Sender:=20; bh=p3hhSzdkZxANhPqrW/yfpXPWgc3WL71TJmkPZuiWVXM=; b=uFh8Y4RVmVRmaqpc1/DouPXgggcUtk6vMZcpaGOk7vTPUngiHn4jXVdDT4 TROch8PDpEqk7pkzw+oGMyuIAA9DuGjEJTHJRLqkGn/ajL9HaGCzJDmZSv/M o0PIQh2H98; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:22:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3323427829_1326337 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt At the San Francisco meeting and ensuing list threads, the last issue aroun= d PhoneBCP was whether or not to include an =8Capplicability statement=B9. The hum during the meeting was inconclusive. The draft editor has included tex= t in this latest version in an attempt to compromise on this issue. Please review this version and respond by Friday May 1 to the list as to your acceptance of this change. Thanks, Marc, Hannes, & Roger --B_3323427829_1326337 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable PhoneBCP http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt

At the San Francisco meeting and ensuing list threads, the last issue aroun= d PhoneBCP was whether or not to include an ‘applicability statement&#= 8217;.  The hum during the meeting was inconclusive.  The draft ed= itor has included text in this latest version in an attempt to compromise on= this issue.

Please review this version and respond by Friday May 1 to the list as to yo= ur acceptance of this change.

Thanks,

Marc, Hannes, & Roger --B_3323427829_1326337-- From mlinsner@cisco.com Fri Apr 24 11:35:28 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CA63A6CFA for ; Fri, 24 Apr 2009 11:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.691 X-Spam-Level: X-Spam-Status: No, score=-5.691 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAGFe659bCaF for ; Fri, 24 Apr 2009 11:35:27 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9E2543A6A24 for ; Fri, 24 Apr 2009 11:35:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208,217";a="42591767" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Apr 2009 18:36:45 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3OIajwp023442 for ; Fri, 24 Apr 2009 14:36:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OIaj7I000372 for ; Fri, 24 Apr 2009 18:36:45 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 14:36:45 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 14:36:45 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 24 Apr 2009 14:36:44 -0400 From: Marc Linsner To: ECRIT Message-ID: Thread-Topic: draft-wolf-ecrit-lost-servicelistboundary-01 Thread-Index: AcnFC53U9qWUb22WbkuXKSDiYc2ckQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3323428605_1344952" X-OriginalArrivalTime: 24 Apr 2009 18:36:45.0713 (UTC) FILETIME=[9ED96810:01C9C50B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=875; t=1240598206; x=1241462206; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20draft-wolf-ecrit-lost-servicelistboundary-01 |Sender:=20 |To:=20ECRIT=20; bh=kLUPxD1xEU20a6FDtGdvdD5ahDudkDyl5g+gIGlD0DU=; b=pbZWXBWhoLdn9EsMcRHDk+Ajzx0p5HbEVB02/MhfEYJO+JGtBTP6WeCZwv EBte8FVpzC/zPK/umvNGBHDN8J3boBayIfswpns9bp50BGTuqfDNK9vfAhY6 ny8YR0IQ0F; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:35:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3323428605_1344952 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, Please review this draft to and respond by Friday May 1 if you find this valuable for ECRIT to work on. Thanks, -Marc- --B_3323428605_1344952 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable draft-wolf-ecrit-lost-servicelistboundary-01 All,

Please review this draft to and respond by Friday May 1 if you find this va= luable for ECRIT to work on.

Thanks,

-Marc-

 --B_3323428605_1344952-- From bs7652@att.com Fri Apr 24 11:42:34 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6723A69D6 for ; Fri, 24 Apr 2009 11:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.842 X-Spam-Level: X-Spam-Status: No, score=-105.842 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SF4DTBNU9JT for ; Fri, 24 Apr 2009 11:42:29 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 5791B3A69C6 for ; Fri, 24 Apr 2009 11:42:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1240598626!23499130!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 29027 invoked from network); 24 Apr 2009 18:43:46 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Apr 2009 18:43:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3OIhkXN030004; Fri, 24 Apr 2009 14:43:46 -0400 Received: from 01GAF5142010623.AD.BLS.COM (01GAF5142010623.ad.bls.com [139.76.131.87]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n3OIhe8F029487; Fri, 24 Apr 2009 14:43:40 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 24 Apr 2009 14:43:40 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 24 Apr 2009 14:43:40 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C50C.962ACF51" Date: Fri, 24 Apr 2009 14:43:34 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP thread-index: AcnFCc9L9nD8ewW6UUCN5n36AHW7fwAAG+8Q References: From: "Stark, Barbara" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 24 Apr 2009 18:43:40.0809 (UTC) FILETIME=[96440790:01C9C50C] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:42:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C50C.962ACF51 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I assume you're referring to the following paragraph in the introduction: " This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement - can be and are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. Calls in this case may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider), but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here." =20 Yes, I accept this. Barbara =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Friday, April 24, 2009 2:24 PM To: ECRIT Subject: [Ecrit] PhoneBCP =20 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt=20 At the San Francisco meeting and ensuing list threads, the last issue around PhoneBCP was whether or not to include an 'applicability statement'. The hum during the meeting was inconclusive. The draft editor has included text in this latest version in an attempt to compromise on this issue. Please review this version and respond by Friday May 1 to the list as to your acceptance of this change. Thanks, Marc, Hannes, & Roger=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 ------_=_NextPart_001_01C9C50C.962ACF51 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PhoneBCP

I assume you’re referring to the following = paragraph in the introduction:

“   This document focuses on the =
case in which all three steps in the

   emergency calling process -- location configuration, call = routing,

   and call placement - can be and are performed by the = calling

   endpoint, with the endpoint's Access Service Provider supporting = the

   process by providing location information.  Calls in this case may = be

   routed via an application-layer Communications Service = Provider

   (e.g., a Voice Service Provider), but need not be.  The = underlying

   protocols can also be used to support other models in which parts = of

   the process are delegated to the Communications Service = Provider.

   This document does not address in detail either these models = or

   interoperability issues between them and the model described = here.”

 

Yes, I accept this.

Barbara

 

From:= = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Friday, April 24, 2009 2:24 PM
To: ECRIT
Subject: [Ecrit] PhoneBCP

 

http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt=

At the San Francisco meeting and ensuing list threads, the last issue = around PhoneBCP was whether or not to include an ‘applicability statement’.  The hum during the meeting was inconclusive. =  The draft editor has included text in this latest version in an attempt to compromise on this issue.

Please review this version and respond by Friday May 1 to the list as to = your acceptance of this change.

Thanks,

Marc, Hannes, & Roger

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA623

 ------_=_NextPart_001_01C9C50C.962ACF51-- From hardie@qualcomm.com Fri Apr 24 13:35:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FCB83A68D5 for ; Fri, 24 Apr 2009 13:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjyuufZYJO25 for ; Fri, 24 Apr 2009 13:35:17 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5381C3A68B0 for ; Fri, 24 Apr 2009 13:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1240605396; x=1272141396; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20|Date:=20Fri,=2024=20Apr=202009=2013:36:33=20-0700 |To:=20Marc=20Linsner=20,=20ECRIT=20< ecrit@ietf.org>|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20PhoneBCP|Content-Type:=20t ext/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3D McAfee=3Bi=3D"5300,2777,5595"=3B=20a=3D"17430438"; bh=FNnIiC8o3v6W1ngSp9XP0hXpe3zkr5irwZAjMerEG7k=; b=AZ93ux7debxdSu+GpDxnXLkmnZo8N+sdt8kp4VQ/ArqglFvFqid7H+zU H94fhHlgiOmXBofitU/G3GAWmJPLvbKOMxphNAfrIg00150ovKhLF/MYr sEwNBNbZvk4aOxd4O18M5OWI/BGZa1aaLgllsk9Brk6K14qEraIoYLOA4 M=; X-IronPort-AV: E=McAfee;i="5300,2777,5595"; a="17430438" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Apr 2009 13:36:35 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3OKaZwI010188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2009 13:36:35 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3OKaZYo021375 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Apr 2009 13:36:35 -0700 (PDT) Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 24 Apr 2009 13:36:35 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 24 Apr 2009 13:36:34 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Fri, 24 Apr 2009 13:36:33 -0700 To: Marc Linsner , ECRIT From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 20:35:18 -0000 At 11:23 AM -0700 4/24/09, Marc Linsner wrote: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt > >At the San Francisco meeting and ensuing list threads, the last issue around PhoneBCP was whether or not to include an 'applicability statement'. The hum during the meeting was inconclusive. The draft editor has included text in this latest version in an attempt to compromise on this issue. > >Please review this version and respond by Friday May 1 to the list as to your acceptance of this change. > >Thanks, > >Marc, Hannes, & Roger I support the current draft going forward to publication requested. regards, Ted > >Content-Type: text/plain; name="ATT00001.txt" >Content-Description: ATT00001.txt >Content-Disposition: attachment; filename="ATT00001.txt"; size=194; > creation-date="Fri, 24 Apr 2009 11:24:11 GMT"; > modification-date="Fri, 24 Apr 2009 11:24:11 GMT" > >Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) (003FF52C) From rbarnes@bbn.com Fri Apr 24 19:31:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39113A68C7 for ; Fri, 24 Apr 2009 19:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2r56GyMtSx0 for ; Fri, 24 Apr 2009 19:31:39 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0DAD93A6C1E for ; Fri, 24 Apr 2009 19:31:05 -0700 (PDT) Received: from [128.89.254.100] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LxXgl-0004kO-EX; Fri, 24 Apr 2009 22:32:23 -0400 Message-ID: <49F27637.7050201@bbn.com> Date: Fri, 24 Apr 2009 22:32:23 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 02:31:40 -0000 +1 Ted Hardie wrote: > At 11:23 AM -0700 4/24/09, Marc Linsner wrote: >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt >> >> At the San Francisco meeting and ensuing list threads, the last issue around PhoneBCP was whether or not to include an 'applicability statement'. The hum during the meeting was inconclusive. The draft editor has included text in this latest version in an attempt to compromise on this issue. >> >> Please review this version and respond by Friday May 1 to the list as to your acceptance of this change. >> >> Thanks, >> >> Marc, Hannes, & Roger > > I support the current draft going forward to publication requested. > > regards, > Ted > > > >> Content-Type: text/plain; name="ATT00001.txt" >> Content-Description: ATT00001.txt >> Content-Disposition: attachment; filename="ATT00001.txt"; size=194; >> creation-date="Fri, 24 Apr 2009 11:24:11 GMT"; >> modification-date="Fri, 24 Apr 2009 11:24:11 GMT" >> >> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) (003FF52C) > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From James.Winterbottom@andrew.com Sat Apr 25 02:04:51 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B27628C0CF for ; Sat, 25 Apr 2009 02:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFNHJTMKiYPo for ; Sat, 25 Apr 2009 02:04:50 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4E4F83A6C1E for ; Sat, 25 Apr 2009 02:04:49 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_25_04_26_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 25 Apr 2009 04:26:51 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Apr 2009 04:06:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 03:51:20 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnFTimNAHgqVpUYQG+aUwBx8n7MqwANNc3n References: <49F27637.7050201@bbn.com> From: "Winterbottom, James" To: "Richard Barnes" , "Ted Hardie" X-OriginalArrivalTime: 25 Apr 2009 09:06:08.0684 (UTC) FILETIME=[12671EC0:01C9C585] Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 09:04:51 -0000 So is this turning into a list "hum" as to whether we should have an applic= ability statement or not=3F=0D=0A=0D=0AISTM that this would be an appropria= te course of action given the lack on consensus at the actually meeting.=0D= =0A=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A-----Original Message----= -=0D=0AFrom: ecrit-bounces@ietf.org on behalf of Richard Barnes=0D=0ASent: = Fri 4/24/2009 9:32 PM=0D=0ATo: Ted Hardie=0D=0ACc: ECRIT=0D=0ASubject: Re: = [Ecrit] PhoneBCP=0D=0A=20=0D=0A+1=0D=0A=0D=0A=0D=0ATed Hardie wrote:=0D=0A>= At 11:23 AM -0700 4/24/09, Marc Linsner wrote:=0D=0A>> http://www.ietf.org/inte= rnet-drafts/draft-ietf-ecrit-phonebcp-09.txt=0D=0A>>=0D=0A>> At the San Fra= ncisco meeting and ensuing list threads, the last issue around PhoneBCP was= whether or not to include an 'applicability statement'. The hum during th= e meeting was inconclusive. The draft editor has included text in this lat= est version in an attempt to compromise on this issue.=0D=0A>>=0D=0A>> Plea= se review this version and respond by Friday May 1 to the list as to your a= cceptance of this change.=0D=0A>>=0D=0A>> Thanks,=0D=0A>>=0D=0A>> Marc, Han= nes, & Roger=0D=0A>=20=0D=0A> I support the current draft going forward to = publication requested.=0D=0A>=20=0D=0A> =09=09=09=09regards,=0D=0A> =09=09=09= =09=09Ted=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>> Content-Type: text/plain; n= ame=3D"ATT00001.txt"=0D=0A>> Content-Description: ATT00001.txt=0D=0A>> Cont= ent-Disposition: attachment; filename=3D"ATT00001.txt"; size=3D194;=0D=0A>>= =09creation-date=3D"Fri, 24 Apr 2009 11:24:11 GMT";=0D=0A>> =09modificatio= n-date=3D"Fri, 24 Apr 2009 11:24:11 GMT"=0D=0A>>=0D=0A>> Attachment convert= ed: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) (003FF52C)=0D=0A>=20=0D=0A> = _______________________________________________=0D=0A> Ecrit mailing list=0D= =0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A= >=20=0D=0A_______________________________________________=0D=0AEcrit mailin= g list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D= =0A=0D=0A=0D=0A------------------------------------------------------------= ------------------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0A[mf2]=0D= =0A From br@brianrosen.net Sat Apr 25 11:03:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12E43A6C91 for ; Sat, 25 Apr 2009 11:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zHtfSPsDsey for ; Sat, 25 Apr 2009 11:03:52 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E95A93A6B9F for ; Sat, 25 Apr 2009 11:03:51 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LxmFJ-0006yQ-FL; Sat, 25 Apr 2009 13:05:01 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Richard Barnes'" , "'Ted Hardie'" References: <49F27637.7050201@bbn.com> In-Reply-To: Date: Sat, 25 Apr 2009 14:04:47 -0400 Message-ID: <058701c9c5d0$53c5ef40$fb51cdc0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnFTimNAHgqVpUYQG+aUwBx8n7MqwANNc3nABM9GjA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 18:03:52 -0000 Actually, I think the list hum is whether or not you accept the change, as proposed, and consider the document ready to send to the IESG. It's kind of a combination of is an applicability statement acceptable, and is this particular one acceptable (and are you otherwise okay with the document, which is implied in Marc's message, but I think important to recognize). Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Saturday, April 25, 2009 4:51 AM To: Richard Barnes; Ted Hardie Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP So is this turning into a list "hum" as to whether we should have an applicability statement or not? ISTM that this would be an appropriate course of action given the lack on consensus at the actually meeting. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Richard Barnes Sent: Fri 4/24/2009 9:32 PM To: Ted Hardie Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP +1 Ted Hardie wrote: > At 11:23 AM -0700 4/24/09, Marc Linsner wrote: >> http:/ /www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt >> >> At the San Francisco meeting and ensuing list threads, the last issue around PhoneBCP was whether or not to include an 'applicability statement'. The hum during the meeting was inconclusive. The draft editor has included text in this latest version in an attempt to compromise on this issue. >> >> Please review this version and respond by Friday May 1 to the list as to your acceptance of this change. >> >> Thanks, >> >> Marc, Hannes, & Roger > > I support the current draft going forward to publication requested. > > regards, > Ted > > > >> Content-Type: text/plain; name="ATT00001.txt" >> Content-Description: ATT00001.txt >> Content-Disposition: attachment; filename="ATT00001.txt"; size=194; >> creation-date="Fri, 24 Apr 2009 11:24:11 GMT"; >> modification-date="Fri, 24 Apr 2009 11:24:11 GMT" >> >> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) (003FF52C) > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Sat Apr 25 14:58:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6043A6DEC for ; Sat, 25 Apr 2009 14:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+YxG6W7V3sG for ; Sat, 25 Apr 2009 14:58:37 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 924033A6D82 for ; Sat, 25 Apr 2009 14:58:37 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_25_17_20_39 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 25 Apr 2009 17:20:39 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Apr 2009 16:59:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 16:57:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnFTimNAHgqVpUYQG+aUwBx8n7MqwANNc3nABM9GjAACDpT8g== References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> From: "Winterbottom, James" To: "Brian Rosen" , "Richard Barnes" , "Ted Hardie" X-OriginalArrivalTime: 25 Apr 2009 21:59:55.0304 (UTC) FILETIME=[2AD32280:01C9C5F1] Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 21:58:38 -0000 My point is that because there was no consensus at the IETF, in fact the do= cument should have remained unchanged.=0D=0A=0D=0AI want a hum first as to = whether the applicability statement is required at all. As I have stated mo= re then one I don't believe it is, and no reasonable argument has yet been = provided to changed my mind.=0D=0A=0D=0ASo let us first establish with a cl= ear consensus that the applicability statement is required.=0D=0A=0D=0AI HU= M against the inclusion of an applicability statement.=0D=0A=0D=0A=0D=0A---= --Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=0D= =0ASent: Sat 4/25/2009 1:04 PM=0D=0ATo: Winterbottom, James; 'Richard Barne= s'; 'Ted Hardie'=0D=0ACc: 'ECRIT'=0D=0ASubject: RE: [Ecrit] PhoneBCP=0D=0A =0D= =0AActually, I think the list hum is whether or not you accept the change, = as=0D=0Aproposed, and consider the document ready to send to the IESG. It'= s kind of=0D=0Aa combination of is an applicability statement acceptable, a= nd is this=0D=0Aparticular one acceptable (and are you otherwise okay with = the document,=0D=0Awhich is implied in Marc's message, but I think importan= t to recognize).=0D=0A=0D=0ABrian=0D=0A=0D=0A=0D=0A-----Original Message---= --=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beh= alf Of=0D=0AWinterbottom, James=0D=0ASent: Saturday, April 25, 2009 4:51 AM=0D= =0ATo: Richard Barnes; Ted Hardie=0D=0ACc: ECRIT=0D=0ASubject: Re: [Ecrit] = PhoneBCP=0D=0A=0D=0ASo is this turning into a list "hum" as to whether we s= hould have an=0D=0Aapplicability statement or not=3F=0D=0A=0D=0AISTM that t= his would be an appropriate course of action given the lack on=0D=0Aconsens= us at the actually meeting.=0D=0A=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org on behalf o= f Richard Barnes=0D=0ASent: Fri 4/24/2009 9:32 PM=0D=0ATo: Ted Hardie=0D=0A= Cc: ECRIT=0D=0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=20=0D=0A+1=0D=0A=0D=0A=0D= =0ATed Hardie wrote:=0D=0A> At 11:23 AM -0700 4/24/09, Marc Linsner wrote:=0D= =0A>>=0D=0Ahttp:/=0D=0A/www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-0= 9.txt=0D=0A>>=0D=0A>> At the San Francisco meeting and ensuing list threads= , the last issue=0D=0Aaround PhoneBCP was whether or not to include an 'app= licability statement'.=0D=0AThe hum during the meeting was inconclusive. T= he draft editor has included=0D=0Atext in this latest version in an attempt= to compromise on this issue.=0D=0A>>=0D=0A>> Please review this version an= d respond by Friday May 1 to the list as to=0D=0Ayour acceptance of this ch= ange.=0D=0A>>=0D=0A>> Thanks,=0D=0A>>=0D=0A>> Marc, Hannes, & Roger=0D=0A> =0D= =0A> I support the current draft going forward to publication requested.=0D= =0A>=20=0D=0A> =09=09=09=09regards,=0D=0A> =09=09=09=09=09Ted=0D=0A>=20=0D=0A= >=20=0D=0A>=20=0D=0A>> Content-Type: text/plain; name=3D"ATT00001.txt"=0D=0A= >> Content-Description: ATT00001.txt=0D=0A>> Content-Disposition: attachmen= t; filename=3D"ATT00001.txt"; size=3D194;=0D=0A>> =09creation-date=3D"Fri, = 24 Apr 2009 11:24:11 GMT";=0D=0A>> =09modification-date=3D"Fri, 24 Apr 2009= 11:24:11 GMT"=0D=0A>>=0D=0A>> Attachment converted: Macintosh HD:ATT00001 = 5171.txt (TEXT/ttxt)=0D=0A(003FF52C)=0D=0A>=20=0D=0A> _____________________= __________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D= =0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A___________= ____________________________________=0D=0AEcrit mailing list=0D=0AEcrit@iet= f.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A---= -------------------------------------------------------------------------=0D= =0A--------------------=0D=0AThis message is for the designated recipient o= nly and may=0D=0Acontain privileged, proprietary, or otherwise private info= rmation. =20=0D=0AIf you have received it in error, please notify the sende= r=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0At= his email is prohibited.=0D=0A---------------------------------------------= -------------------------------=0D=0A--------------------=0D=0A[mf2]=0D=0A=0D= =0A_______________________________________________=0D=0AEcrit mailing list=0D= =0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A=0D=0A=0D=0A------------------------------------------------------------= ------------------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0A[mf2]=0D= =0A From rbarnes@bbn.com Sat Apr 25 18:25:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98CD3A6C2E for ; Sat, 25 Apr 2009 18:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-Ek-ZHJQWj5 for ; Sat, 25 Apr 2009 18:25:14 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C46553A69EB for ; Sat, 25 Apr 2009 18:25:14 -0700 (PDT) Received: from [128.89.254.121] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Lxt8Z-0005cz-E9; Sat, 25 Apr 2009 21:26:31 -0400 Message-ID: <49F3B846.8020102@bbn.com> Date: Sat, 25 Apr 2009 21:26:30 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Winterbottom, James" References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 01:25:25 -0000 I don't think there are separate hums necessary at this point. If you don't think there should be any modification, just hum against the modification. --Richard Winterbottom, James wrote: > My point is that because there was no consensus at the IETF, in fact the document should have remained unchanged. > > I want a hum first as to whether the applicability statement is required at all. As I have stated more then one I don't believe it is, and no reasonable argument has yet been provided to changed my mind. > > So let us first establish with a clear consensus that the applicability statement is required. > > I HUM against the inclusion of an applicability statement. > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Sat 4/25/2009 1:04 PM > To: Winterbottom, James; 'Richard Barnes'; 'Ted Hardie' > Cc: 'ECRIT' > Subject: RE: [Ecrit] PhoneBCP > > Actually, I think the list hum is whether or not you accept the change, as > proposed, and consider the document ready to send to the IESG. It's kind of > a combination of is an applicability statement acceptable, and is this > particular one acceptable (and are you otherwise okay with the document, > which is implied in Marc's message, but I think important to recognize). > > Brian > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Saturday, April 25, 2009 4:51 AM > To: Richard Barnes; Ted Hardie > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP > > So is this turning into a list "hum" as to whether we should have an > applicability statement or not? > > ISTM that this would be an appropriate course of action given the lack on > consensus at the actually meeting. > > > Cheers > James > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > Sent: Fri 4/24/2009 9:32 PM > To: Ted Hardie > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP > > +1 > > > Ted Hardie wrote: >> At 11:23 AM -0700 4/24/09, Marc Linsner wrote: > http:/ > /www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt >>> At the San Francisco meeting and ensuing list threads, the last issue > around PhoneBCP was whether or not to include an 'applicability statement'. > The hum during the meeting was inconclusive. The draft editor has included > text in this latest version in an attempt to compromise on this issue. >>> Please review this version and respond by Friday May 1 to the list as to > your acceptance of this change. >>> Thanks, >>> >>> Marc, Hannes, & Roger >> I support the current draft going forward to publication requested. >> >> regards, >> Ted >> >> >> >>> Content-Type: text/plain; name="ATT00001.txt" >>> Content-Description: ATT00001.txt >>> Content-Disposition: attachment; filename="ATT00001.txt"; size=194; >>> creation-date="Fri, 24 Apr 2009 11:24:11 GMT"; >>> modification-date="Fri, 24 Apr 2009 11:24:11 GMT" >>> >>> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) > (003FF52C) >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ---------------------------------------------------------------------------- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------------- > -------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > From James.Winterbottom@andrew.com Sat Apr 25 19:20:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF6028C143 for ; Sat, 25 Apr 2009 19:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR7roafclw+h for ; Sat, 25 Apr 2009 19:20:05 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8EE6E28C122 for ; Sat, 25 Apr 2009 19:20:05 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_25_21_42_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 25 Apr 2009 21:42:07 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Apr 2009 21:21:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 21:19:05 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnGDgnLOzFhw5XDR0uBGytHIM61ogAB1Xz6 References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <49F3B846.8020102@bbn.com> From: "Winterbottom, James" To: "Richard Barnes" X-OriginalArrivalTime: 26 Apr 2009 02:21:24.0210 (UTC) FILETIME=[B2243520:01C9C615] Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 02:20:06 -0000 =0D=0ANo, that is totally inconsistent with what occurs in other groups, Ge= opriv being a prime example.=0D=0A=0D=0AIf there is no consensus at the mee= ting for a change, then the change is not to be made until the consensus is= reached.=0D=0A=0D=0AThere needs to be a hum on this list as to whether any= change is required at all.=0D=0A=0D=0AIf that hum is in favour of a change= , then we can hum on the wording.=0D=0A=0D=0AAt this point I would like the= chairs and ADs to comment on this.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A= -----Original Message-----=0D=0AFrom: Richard Barnes [mailto:rbarnes@bbn.co= m]=0D=0ASent: Sat 4/25/2009 8:26 PM=0D=0ATo: Winterbottom, James=0D=0ACc: B= rian Rosen; Ted Hardie; ECRIT=0D=0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=20=0D= =0AI don't think there are separate hums necessary at this point. If you =0D= =0Adon't think there should be any modification, just hum against the=20=0D= =0Amodification.=0D=0A--Richard=0D=0A=0D=0AWinterbottom, James wrote:=0D=0A= > My point is that because there was no consensus at the IETF, in fact the = document should have remained unchanged.=0D=0A>=20=0D=0A> I want a hum firs= t as to whether the applicability statement is required at all. As I have s= tated more then one I don't believe it is, and no reasonable argument has y= et been provided to changed my mind.=0D=0A>=20=0D=0A> So let us first estab= lish with a clear consensus that the applicability statement is required.=0D= =0A>=20=0D=0A> I HUM against the inclusion of an applicability statement.=0D= =0A>=20=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: Brian Rose= n [mailto:br@brianrosen.net]=0D=0A> Sent: Sat 4/25/2009 1:04 PM=0D=0A> To: = Winterbottom, James; 'Richard Barnes'; 'Ted Hardie'=0D=0A> Cc: 'ECRIT'=0D=0A= > Subject: RE: [Ecrit] PhoneBCP=0D=0A> =20=0D=0A> Actually, I think the lis= t hum is whether or not you accept the change, as=0D=0A> proposed, and cons= ider the document ready to send to the IESG. It's kind of=0D=0A> a combina= tion of is an applicability statement acceptable, and is this=0D=0A> partic= ular one acceptable (and are you otherwise okay with the document,=0D=0A> w= hich is implied in Marc's message, but I think important to recognize).=0D=0A= >=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A= > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of=0D= =0A> Winterbottom, James=0D=0A> Sent: Saturday, April 25, 2009 4:51 AM=0D=0A= > To: Richard Barnes; Ted Hardie=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecri= t] PhoneBCP=0D=0A>=20=0D=0A> So is this turning into a list "hum" as to whe= ther we should have an=0D=0A> applicability statement or not=3F=0D=0A>=20=0D= =0A> ISTM that this would be an appropriate course of action given the lack= on=0D=0A> consensus at the actually meeting.=0D=0A>=20=0D=0A>=20=0D=0A> Ch= eers=0D=0A> James=0D=0A>=20=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A= > From: ecrit-bounces@ietf.org on behalf of Richard Barnes=0D=0A> Sent: Fri= 4/24/2009 9:32 PM=0D=0A> To: Ted Hardie=0D=0A> Cc: ECRIT=0D=0A> Subject: R= e: [Ecrit] PhoneBCP=0D=0A> =20=0D=0A> +1=0D=0A>=20=0D=0A>=20=0D=0A> Ted Har= die wrote:=0D=0A>> At 11:23 AM -0700 4/24/09, Marc Linsner wrote:=0D=0A> http:/=0D= =0A> /www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt=0D=0A>>= > At the San Francisco meeting and ensuing list threads, the last issue=0D=0A= > around PhoneBCP was whether or not to include an 'applicability statement= '.=0D=0A> The hum during the meeting was inconclusive. The draft editor ha= s included=0D=0A> text in this latest version in an attempt to compromise o= n this issue.=0D=0A>>> Please review this version and respond by Friday May= 1 to the list as to=0D=0A> your acceptance of this change.=0D=0A>>> Thanks= ,=0D=0A>>>=0D=0A>>> Marc, Hannes, & Roger=0D=0A>> I support the current dra= ft going forward to publication requested.=0D=0A>>=0D=0A>> =09=09=09=09rega= rds,=0D=0A>> =09=09=09=09=09Ted=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>>> Content-Ty= pe: text/plain; name=3D"ATT00001.txt"=0D=0A>>> Content-Description: ATT0000= 1.txt=0D=0A>>> Content-Disposition: attachment; filename=3D"ATT00001.txt"; = size=3D194;=0D=0A>>> =09creation-date=3D"Fri, 24 Apr 2009 11:24:11 GMT";=0D= =0A>>> =09modification-date=3D"Fri, 24 Apr 2009 11:24:11 GMT"=0D=0A>>>=0D=0A= >>> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt)=0D=0A>= (003FF52C)=0D=0A>> _______________________________________________=0D=0A>>= Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A>> https://www.ietf.org/mai= lman/listinfo/ecrit=0D=0A>>=0D=0A> ________________________________________= _______=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.= ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A> ----------------= ------------------------------------------------------------=0D=0A> -------= -------------=0D=0A> This message is for the designated recipient only and = may=0D=0A> contain privileged, proprietary, or otherwise private informatio= n. =20=0D=0A> If you have received it in error, please notify the sender=0D= =0A> immediately and delete the original. Any unauthorized use of=0D=0A> t= his email is prohibited.=0D=0A> -------------------------------------------= ---------------------------------=0D=0A> --------------------=0D=0A> [mf2]=0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Ecrit= mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/mailman/lis= tinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> --------------------------= ----------------------------------------------------------------------=0D=0A= > This message is for the designated recipient only and may=0D=0A> contain = privileged, proprietary, or otherwise private information. =20=0D=0A> If yo= u have received it in error, please notify the sender=0D=0A> immediately an= d delete the original. Any unauthorized use of=0D=0A> this email is prohib= ited.=0D=0A> --------------------------------------------------------------= ----------------------------------=0D=0A> [mf2]=0D=0A>=20=0D=0A>=20=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A From bernard_aboba@hotmail.com Sun Apr 26 08:09:43 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFB13A6E1A for ; Sun, 26 Apr 2009 08:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDE9sbaUR7z0 for ; Sun, 26 Apr 2009 08:09:42 -0700 (PDT) Received: from blu0-omc2-s19.blu0.hotmail.com (blu0-omc2-s19.blu0.hotmail.com [65.55.111.94]) by core3.amsl.com (Postfix) with ESMTP id 1EDB43A6E0B for ; Sun, 26 Apr 2009 08:09:42 -0700 (PDT) Received: from BLU137-W16 ([65.55.111.73]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 08:11:01 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b2d3647b-aff5-4b7b-9431-f2d294f700cf_" X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: , Date: Sun, 26 Apr 2009 08:11:01 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2009 15:11:01.0987 (UTC) FILETIME=[363DCB30:01C9C681] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 15:09:43 -0000 --_b2d3647b-aff5-4b7b-9431-f2d294f700cf_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The document in question does not have an applicability statement section. = Looking at the diffs from -08=2C the only text change that would appear to= qualify is the following: This document focuses on the case in which all three steps in the emergency calling process -- location configuration=2C call routing=2C and call placement - can be and are performed by the calling endpoint=2C with the endpoint's Access Service Provider supporting the process by providing location information. Calls in this case may be routed via an application-layer Communications Service Provider (e.g.=2C a Voice Service Provider)=2C but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here. While this statement is accurate as far as it goes=2C in practice it subst= antially reduces the applicability of the document.=20 That's a pretty major change -- so as a matter of process=2C it would proba= bly have been better to obtain consensus *before* inserting this text.=20 However=2C I do think that the proposed text fairly describes the architect= ural assumptions. The question of how widely those assumptions hold will u= ltimately be determined in the marketplace=2C not in the IETF.=20 Date: Fri=2C 24 Apr 2009 14:23:48 -0400 From: mlinsner@cisco.com To: ecrit@ietf.org Subject: [Ecrit] PhoneBCP PhoneBCP http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt=20 At the San Francisco meeting and ensuing list threads=2C the last issue aro= und PhoneBCP was whether or not to include an =91applicability statement=92= . The hum during the meeting was inconclusive. The draft editor has inclu= ded text in this latest version in an attempt to compromise on this issue. Please review this version and respond by Friday May 1 to the list as to yo= ur acceptance of this change. Thanks=2C Marc=2C Hannes=2C & Roger= --_b2d3647b-aff5-4b7b-9431-f2d294f700cf_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The document in question does not have an applicability statement section.&= nbsp=3B Looking at the diffs from -08=2C the only text change that would ap= pear to qualify is the following:
   This document focuses on the c=
ase in which all three steps in the
   emergency calling process -- loca=
tion configuration=2C call routing=2C
   and call placement - can be and=
 are performed by the calling
   endpoint=2C with the endpoint's Access =
Service Provider supporting the
   process by providing location informa=
tion.  Calls in this case may be
   routed via an application-layer Comm=
unications Service Provider
   (e.g.=2C a Voice Service Provider)=2C but=
 need not be.  The underlying
   protocols can also be used to support o=
ther models in which parts of
   the process are delegated to the Commun=
ications Service Provider.
   This document does not address in detail e=
ither these models or
   interoperability issues between them and the mo=
del described here.
While this statement is accurate as far as it = goes=2C =3B in practice it substantially reduces the applicability of t= he document.

That's a pretty major change -- so as a matter of proc= ess=2C it would probably have been better to obtain consensus *before* inse= rting this text.

However=2C I do think that the proposed text fairl= y describes the architectural assumptions. =3B The question of how wide= ly those assumptions hold will ultimately be determined in the =3B mark= etplace=2C not in the IETF.





Date: Fri=2C 24 Apr 2009 14:23:48 -0400
From: mlinsner@cisco.co= m
To: ecrit@ietf.org
Subject: [Ecrit] PhoneBCP

PhoneBCP http://www.ietf.org/internet-drafts/draft-ietf-ecrit-= phonebcp-09.txt

At the San Francisco meeting and ensuing list threads=2C the last issue aro= und PhoneBCP was whether or not to include an =91applicability statement=92= .  =3BThe hum during the meeting was inconclusive.  =3BThe draft ed= itor has included text in this latest version in an attempt to compromise o= n this issue.

Please review this version and respond by Friday May 1 to the list as to yo= ur acceptance of this change.

Thanks=2C

Marc=2C Hannes=2C &=3B Roger = --_b2d3647b-aff5-4b7b-9431-f2d294f700cf_-- From Hannes.Tschofenig@gmx.net Sun Apr 26 09:46:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE163A6C8C for ; Sun, 26 Apr 2009 09:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QvTBLphFMOM for ; Sun, 26 Apr 2009 09:46:10 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E87D43A6957 for ; Sun, 26 Apr 2009 09:46:09 -0700 (PDT) Received: (qmail invoked by alias); 26 Apr 2009 16:47:28 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 26 Apr 2009 18:47:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19lerAcf45l6r0ASOlV/bFEx6BUwT2NYebNStKAsx KMe2jORy7p+qhw From: "Hannes Tschofenig" To: "'Marc Linsner'" , "'ECRIT'" References: Date: Sun, 26 Apr 2009 19:49:02 +0300 Message-ID: <021d01c9c68e$e7b34130$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnFC53U9qWUb22WbkuXKSDiYc2ckQBgzaLg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.00 Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 16:46:11 -0000 I think it is a useful document to work on. ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: 24 April, 2009 21:37 To: ECRIT Subject: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 All, Please review this draft to and respond by Friday May 1 if you find this valuable for ECRIT to work on. Thanks, -Marc- From drage@alcatel-lucent.com Mon Apr 27 01:06:48 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD763A6853 for ; Mon, 27 Apr 2009 01:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WmaDd4TKYEO for ; Mon, 27 Apr 2009 01:06:47 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id B39B33A67D2 for ; Mon, 27 Apr 2009 01:06:45 -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.13.8/8.13.8/ICT) with ESMTP id n3R87jRA013133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Apr 2009 10:07:48 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 27 Apr 2009 10:07:46 +0200 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , Brian Rosen , Richard Barnes , Ted Hardie Date: Mon, 27 Apr 2009 10:07:44 +0200 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnFTimNAHgqVpUYQG+aUwBx8n7MqwANNc3nABM9GjAACDpT8gBHiFLg Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> 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.57 on 155.132.188.13 Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 08:06:48 -0000 I hum for the applicability statement. I would also note that if we go the way you want to go, we have a hum for w= hether the document is acceptable without this. Having had the discussion t= o agree an applicability statement, I warn that I will hum against a docume= nt without it. You need some form of consensus to get the document out of the WG. regards Keith=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Winterbottom, James > Sent: Saturday, April 25, 2009 10:58 PM > To: Brian Rosen; Richard Barnes; Ted Hardie > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > My point is that because there was no consensus at the IETF,=20 > in fact the document should have remained unchanged. >=20 > I want a hum first as to whether the applicability statement=20 > is required at all. As I have stated more then one I don't=20 > believe it is, and no reasonable argument has yet been=20 > provided to changed my mind. >=20 > So let us first establish with a clear consensus that the=20 > applicability statement is required. >=20 > I HUM against the inclusion of an applicability statement. >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Sat 4/25/2009 1:04 PM > To: Winterbottom, James; 'Richard Barnes'; 'Ted Hardie' > Cc: 'ECRIT' > Subject: RE: [Ecrit] PhoneBCP > =20 > Actually, I think the list hum is whether or not you accept=20 > the change, as proposed, and consider the document ready to=20 > send to the IESG. It's kind of a combination of is an=20 > applicability statement acceptable, and is this particular=20 > one acceptable (and are you otherwise okay with the document,=20 > which is implied in Marc's message, but I think important to=20 > recognize). >=20 > Brian >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Winterbottom, James > Sent: Saturday, April 25, 2009 4:51 AM > To: Richard Barnes; Ted Hardie > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > So is this turning into a list "hum" as to whether we should=20 > have an applicability statement or not? >=20 > ISTM that this would be an appropriate course of action given=20 > the lack on consensus at the actually meeting. >=20 >=20 > Cheers > James >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > Sent: Fri 4/24/2009 9:32 PM > To: Ted Hardie > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP > =20 > +1 >=20 >=20 > Ted Hardie wrote: > > At 11:23 AM -0700 4/24/09, Marc Linsner wrote: > >> > -09.txt>http:/ > /www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt > >> > >> At the San Francisco meeting and ensuing list threads, the=20 > last issue > around PhoneBCP was whether or not to include an=20 > 'applicability statement'. > The hum during the meeting was inconclusive. The draft=20 > editor has included text in this latest version in an attempt=20 > to compromise on this issue. > >> > >> Please review this version and respond by Friday May 1 to=20 > the list as=20 > >> to > your acceptance of this change. > >> > >> Thanks, > >> > >> Marc, Hannes, & Roger > >=20 > > I support the current draft going forward to publication requested. > >=20 > > regards, > > Ted > >=20 > >=20 > >=20 > >> Content-Type: text/plain; name=3D"ATT00001.txt" > >> Content-Description: ATT00001.txt > >> Content-Disposition: attachment; filename=3D"ATT00001.txt"; size=3D194= ; > >> creation-date=3D"Fri, 24 Apr 2009 11:24:11 GMT"; > >> modification-date=3D"Fri, 24 Apr 2009 11:24:11 GMT" > >> > >> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) > (003FF52C) > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > -------------------------------------------------------------- > -------------- > -------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > -------------- > -------------------- > [mf2] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From mlinsner@cisco.com Mon Apr 27 05:21:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A063A6C9B for ; Mon, 27 Apr 2009 05:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4VmGzR-UYp3 for ; Mon, 27 Apr 2009 05:21:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4E2CB3A6AF9 for ; Mon, 27 Apr 2009 05:21:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,254,1238976000"; d="scan'208";a="159206794" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2009 12:22:52 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3RCMq0J014677; Mon, 27 Apr 2009 05:22:52 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3RCMnxT013132; Mon, 27 Apr 2009 12:22:52 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 08:22:51 -0400 Received: from [10.116.195.116] ([10.116.195.116]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 08:22:50 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 27 Apr 2009 08:22:49 -0400 From: Marc Linsner To: "Winterbottom, James" Message-ID: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnGDgnLOzFhw5XDR0uBGytHIM61ogAB1Xz6AEdgQo8= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2009 12:22:51.0017 (UTC) FILETIME=[E1F7B790:01C9C732] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6654; t=1240834972; x=1241698972; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20PhoneBCP |Sender:=20; bh=XDoqWgjPvqg/zE0mKk33oY+ss4ezu5oXy8TxF5Lbhuk=; b=Tu3Xb99mFvf1yQV/swnk4vBFOQzt0lFZkEnLyJW+8PjR7Ur3q83HqwMWJp ljBqevTOomEIyF3syyXY2GH4vvW80g7YdcPKCQb1G/yB1zVPIM1+iFcbfQvz HvPgFIdsH3J04iUjY1knSFNW2mjppv2Gyl37iHPa/x0S9+HZ4O3rA=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:21:36 -0000 James, This is a consolidated hum. If you don't agree that we need an applicability statement, hum against it. If you agree that we need an applicability statement, but don't like the current text, hum against it. If you agree with the statement as written, hum for it. If consensus is against the statement, it will be taken out of the draft. -Marc- On 4/25/09 10:19 PM, "Winterbottom, James" wrote: > > No, that is totally inconsistent with what occurs in other groups, Geopriv > being a prime example. > > If there is no consensus at the meeting for a change, then the change is not > to be made until the consensus is reached. > > There needs to be a hum on this list as to whether any change is required at > all. > > If that hum is in favour of a change, then we can hum on the wording. > > At this point I would like the chairs and ADs to comment on this. > > Cheers > James > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Sat 4/25/2009 8:26 PM > To: Winterbottom, James > Cc: Brian Rosen; Ted Hardie; ECRIT > Subject: Re: [Ecrit] PhoneBCP > > I don't think there are separate hums necessary at this point. If you > don't think there should be any modification, just hum against the > modification. > --Richard > > Winterbottom, James wrote: >> My point is that because there was no consensus at the IETF, in fact the >> document should have remained unchanged. >> >> I want a hum first as to whether the applicability statement is required at >> all. As I have stated more then one I don't believe it is, and no reasonable >> argument has yet been provided to changed my mind. >> >> So let us first establish with a clear consensus that the applicability >> statement is required. >> >> I HUM against the inclusion of an applicability statement. >> >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Sat 4/25/2009 1:04 PM >> To: Winterbottom, James; 'Richard Barnes'; 'Ted Hardie' >> Cc: 'ECRIT' >> Subject: RE: [Ecrit] PhoneBCP >> >> Actually, I think the list hum is whether or not you accept the change, as >> proposed, and consider the document ready to send to the IESG. It's kind of >> a combination of is an applicability statement acceptable, and is this >> particular one acceptable (and are you otherwise okay with the document, >> which is implied in Marc's message, but I think important to recognize). >> >> Brian >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Winterbottom, James >> Sent: Saturday, April 25, 2009 4:51 AM >> To: Richard Barnes; Ted Hardie >> Cc: ECRIT >> Subject: Re: [Ecrit] PhoneBCP >> >> So is this turning into a list "hum" as to whether we should have an >> applicability statement or not? >> >> ISTM that this would be an appropriate course of action given the lack on >> consensus at the actually meeting. >> >> >> Cheers >> James >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org on behalf of Richard Barnes >> Sent: Fri 4/24/2009 9:32 PM >> To: Ted Hardie >> Cc: ECRIT >> Subject: Re: [Ecrit] PhoneBCP >> >> +1 >> >> >> Ted Hardie wrote: >>> At 11:23 AM -0700 4/24/09, Marc Linsner wrote: >> http:/ >> /www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt >>>> At the San Francisco meeting and ensuing list threads, the last issue >> around PhoneBCP was whether or not to include an 'applicability statement'. >> The hum during the meeting was inconclusive. The draft editor has included >> text in this latest version in an attempt to compromise on this issue. >>>> Please review this version and respond by Friday May 1 to the list as to >> your acceptance of this change. >>>> Thanks, >>>> >>>> Marc, Hannes, & Roger >>> I support the current draft going forward to publication requested. >>> >>> regards, >>> Ted >>> >>> >>> >>>> Content-Type: text/plain; name="ATT00001.txt" >>>> Content-Description: ATT00001.txt >>>> Content-Disposition: attachment; filename="ATT00001.txt"; size=194; >>>> creation-date="Fri, 24 Apr 2009 11:24:11 GMT"; >>>> modification-date="Fri, 24 Apr 2009 11:24:11 GMT" >>>> >>>> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) >> (003FF52C) >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> ---------------------------------------------------------------------------- >> -------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ---------------------------------------------------------------------------- >> -------------------- >> [mf2] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> ----------------------------------------------------------------------------- >> ------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ----------------------------------------------------------------------------- >> ------------------- >> [mf2] >> >> > > > ------------------------------------------------------------------------------ > ------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------ > ------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Mon Apr 27 05:32:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379443A6AB3 for ; Mon, 27 Apr 2009 05:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.585 X-Spam-Level: X-Spam-Status: No, score=-5.585 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V88EEhokNPT8 for ; Mon, 27 Apr 2009 05:32:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 9B42C3A69CC for ; Mon, 27 Apr 2009 05:32:03 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3RCXIXC004183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2009 14:33:18 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3RCXGcl028569; Mon, 27 Apr 2009 14:33:18 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 14:33:17 +0200 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, 27 Apr 2009 15:34:52 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45014D4A6D@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnGDgnLOzFhw5XDR0uBGytHIM61ogAB1Xz6AEdgQo8AAF6OsA== References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Marc Linsner" , "Winterbottom, James" X-OriginalArrivalTime: 27 Apr 2009 12:33:17.0951 (UTC) FILETIME=[57A640F0:01C9C734] Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:32:05 -0000 I hum against the applicability statement. I cannot see why we need one. =20 Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Marc Linsner >Sent: 27 April, 2009 15:23 >To: Winterbottom, James >Cc: ECRIT >Subject: Re: [Ecrit] PhoneBCP > >James, > >This is a consolidated hum. > >If you don't agree that we need an applicability statement,=20 >hum against it. > >If you agree that we need an applicability statement, but=20 >don't like the current text, hum against it. > >If you agree with the statement as written, hum for it. > >If consensus is against the statement, it will be taken out of=20 >the draft. > >-Marc-=20 > > >On 4/25/09 10:19 PM, "Winterbottom, James"=20 > >wrote: > >>=20 >> No, that is totally inconsistent with what occurs in other groups,=20 >> Geopriv being a prime example. >>=20 >> If there is no consensus at the meeting for a change, then=20 >the change=20 >> is not to be made until the consensus is reached. >>=20 >> There needs to be a hum on this list as to whether any change is=20 >> required at all. >>=20 >> If that hum is in favour of a change, then we can hum on the wording. >>=20 >> At this point I would like the chairs and ADs to comment on this. >>=20 >> Cheers >> James >>=20 >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Sat 4/25/2009 8:26 PM >> To: Winterbottom, James >> Cc: Brian Rosen; Ted Hardie; ECRIT >> Subject: Re: [Ecrit] PhoneBCP >> =20 >> I don't think there are separate hums necessary at this=20 >point. If you=20 >> don't think there should be any modification, just hum against the=20 >> modification. >> --Richard >>=20 >> Winterbottom, James wrote: >>> My point is that because there was no consensus at the=20 >IETF, in fact=20 >>> the document should have remained unchanged. >>>=20 >>> I want a hum first as to whether the applicability statement is=20 >>> required at all. As I have stated more then one I don't believe it=20 >>> is, and no reasonable argument has yet been provided to=20 >changed my mind. >>>=20 >>> So let us first establish with a clear consensus that the=20 >>> applicability statement is required. >>>=20 >>> I HUM against the inclusion of an applicability statement. >>>=20 >>>=20 >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Sat 4/25/2009 1:04 PM >>> To: Winterbottom, James; 'Richard Barnes'; 'Ted Hardie' >>> Cc: 'ECRIT' >>> Subject: RE: [Ecrit] PhoneBCP >>> =20 >>> Actually, I think the list hum is whether or not you accept the=20 >>> change, as proposed, and consider the document ready to send to the=20 >>> IESG. It's kind of a combination of is an applicability statement=20 >>> acceptable, and is this particular one acceptable (and are you=20 >>> otherwise okay with the document, which is implied in=20 >Marc's message, but I think important to recognize). >>>=20 >>> Brian >>>=20 >>>=20 >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >>> Behalf Of Winterbottom, James >>> Sent: Saturday, April 25, 2009 4:51 AM >>> To: Richard Barnes; Ted Hardie >>> Cc: ECRIT >>> Subject: Re: [Ecrit] PhoneBCP >>>=20 >>> So is this turning into a list "hum" as to whether we=20 >should have an=20 >>> applicability statement or not? >>>=20 >>> ISTM that this would be an appropriate course of action given the=20 >>> lack on consensus at the actually meeting. >>>=20 >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org on behalf of Richard Barnes >>> Sent: Fri 4/24/2009 9:32 PM >>> To: Ted Hardie >>> Cc: ECRIT >>> Subject: Re: [Ecrit] PhoneBCP >>> =20 >>> +1 >>>=20 >>>=20 >>> Ted Hardie wrote: >>>> At 11:23 AM -0700 4/24/09, Marc Linsner wrote: >>>=20 >>> >http:/=20 >>> /www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt >>>>> At the San Francisco meeting and ensuing list threads, the last=20 >>>>> issue >>> around PhoneBCP was whether or not to include an=20 >'applicability statement'. >>> The hum during the meeting was inconclusive. The draft editor has=20 >>> included text in this latest version in an attempt to=20 >compromise on this issue. >>>>> Please review this version and respond by Friday May 1 to=20 >the list=20 >>>>> as to >>> your acceptance of this change. >>>>> Thanks, >>>>>=20 >>>>> Marc, Hannes, & Roger >>>> I support the current draft going forward to publication requested. >>>>=20 >>>> regards, >>>> Ted >>>>=20 >>>>=20 >>>>=20 >>>>> Content-Type: text/plain; name=3D"ATT00001.txt" >>>>> Content-Description: ATT00001.txt >>>>> Content-Disposition: attachment; filename=3D"ATT00001.txt";=20 >size=3D194;=20 >>>>> creation-date=3D"Fri, 24 Apr 2009 11:24:11 GMT";=20 >>>>> modification-date=3D"Fri, 24 Apr 2009 11:24:11 GMT" >>>>>=20 >>>>> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) >>> (003FF52C) >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>>=20 >--------------------------------------------------------------------- >>> ------- >>> -------------------- >>> This message is for the designated recipient only and may contain=20 >>> privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender=20 >>> immediately and delete the original. Any unauthorized use of this=20 >>> email is prohibited. >>>=20 >--------------------------------------------------------------------- >>> ------- >>> -------------------- >>> [mf2] >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>>=20 >>>=20 >--------------------------------------------------------------------- >>> -------- >>> ------------------- >>> This message is for the designated recipient only and may contain=20 >>> privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender=20 >>> immediately and delete the original. Any unauthorized use of this=20 >>> email is prohibited. >>>=20 >--------------------------------------------------------------------- >>> -------- >>> ------------------- >>> [mf2] >>>=20 >>>=20 >>=20 >>=20 >>=20 >---------------------------------------------------------------------- >> -------- >> ------------------ >> This message is for the designated recipient only and may contain=20 >> privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender=20 >immediately=20 >> and delete the original. Any unauthorized use of this email is=20 >> prohibited. >>=20 >---------------------------------------------------------------------- >> -------- >> ------------------ >> [mf2] >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From hgs@cs.columbia.edu Mon Apr 27 06:41:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D946D3A6929 for ; Mon, 27 Apr 2009 06:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9PAr+LVMAQ0 for ; Mon, 27 Apr 2009 06:41:40 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id D83D63A6838 for ; Mon, 27 Apr 2009 06:41:39 -0700 (PDT) Received: from 181-115.mm.internet2.edu (181-115.mm.internet2.edu [206.196.181.115]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3RDgtXB001765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2009 09:42:56 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45014D4A6D@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 09:42:55 -0400 References: <3D3C75174CB95F42AD6BCC56E5555B45014D4A6D@FIESEXC015.nsn-intra.net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:41:40 -0000 +1 On Apr 27, 2009, at 8:34 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I hum against the applicability statement. I cannot see why we need > one. > > > Ciao > Hannes > From randy@qualcomm.com Mon Apr 27 17:24:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA9D3A6835 for ; Mon, 27 Apr 2009 17:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.483 X-Spam-Level: X-Spam-Status: No, score=-103.483 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfBmu8ykCPYu for ; Mon, 27 Apr 2009 17:24:11 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E9ECC3A6B42 for ; Mon, 27 Apr 2009 17:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1240878332; x=1272414332; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E @FRMRSSXCHMBSB3.dc-m.alcatel-=0D=0A=20lucent.com> |References:=20=09<49F27637.705 0201@bbn.com>=0D=0A=20=0D=0A=20<058701c9c5d0$53c5ef40$ fb51cdc0$@net>=0D=0A=20=0D=0A=20<28B7C3AA2A7ABA4A841F1 1217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-=0D=0A=20 lucent.com>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-Note:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20Mo n,=2027=20Apr=202009=2017:25:22=20-0700|To:=20ECRIT=20|From:=20Randall=20Gellens=20|Subject:=20Re:=20[Ecrit]=20PhoneBCP|MIME-Version: =201.0|Content-Type:=20text/plain=3B=20charset=3D"us-asci i"=3B=20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5598"=3B=20 a=3D"17514344"; bh=Stcsv3gypBMx5+iovB7H+cfvjCMHqQSvG0u6D1OvIRI=; b=likOtDLKmJWKTeKJ6o41GwROFHFURdtvs9ML+VNPKFRdIhmtn4iwS3y8 XU7mzgCAXkDnSDO8fMVtCtym4q1XnegGOVbk2sF0A5e7PJ/B/NlFf9WDD TfOWb19VQQz/poYadGr5Pdyneb+ztuFjn9yumtrHxqjK3aOVkGSsgRIbE M=; X-IronPort-AV: E=McAfee;i="5300,2777,5598"; a="17514344" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2009 17:25:32 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3S0PVsu030319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Apr 2009 17:25:32 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3S0PVhR006148 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 27 Apr 2009 17:25:31 -0700 (PDT) Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 27 Apr 2009 17:25:29 -0700 Received: from [172.28.171.53] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 27 Apr 2009 17:25:28 -0700 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 27 Apr 2009 17:25:22 -0700 To: ECRIT From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 00:24:11 -0000 I hum for the text, which doesn't constrain the use of the protocols, but merely describes the assumptions under which it works. As such, it is useful and helpful. Even for those who think the assumptions are obvious, it does no harm to state them. We had a lot of debate on this in SFO, and the text in this version was discussed on the mailing list in the days during and following the meeting. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One's need for loneliness is not satisfied if one sits at a table alone. There must be empty chairs as well. --Karl Kraus From James.Winterbottom@andrew.com Mon Apr 27 17:26:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71BB3A6BC5 for ; Mon, 27 Apr 2009 17:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4qZwG-hS4W0 for ; Mon, 27 Apr 2009 17:26:38 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B161D3A6FEA for ; Mon, 27 Apr 2009 17:26:03 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_27_19_48_10 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 27 Apr 2009 19:48:09 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 19:27:24 -0500 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, 27 Apr 2009 19:27:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnHl9kc8IksP+GUQOG+ckdpy/Hu1gAAB3oA References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Winterbottom, James" To: "Randall Gellens" , "ECRIT" X-OriginalArrivalTime: 28 Apr 2009 00:27:24.0529 (UTC) FILETIME=[1A333610:01C9C798] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 00:26:38 -0000 I am sorry that that time was spent debating the text, since procedure=0D=0A= would dictate that before text be considered consensus on whether it is=0D=0A= needed must be reached. Since the former did not occur, the latter is=0D=0A= kind of moot.=0D=0A=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Ra= ndall Gellens=0D=0ASent: Tuesday, 28 April 2009 10:25 AM=0D=0ATo: ECRIT=0D=0A= Subject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0AI hum for the text, which doesn't = constrain the use of the protocols,=20=0D=0Abut merely describes the assump= tions under which it works. As such,=20=0D=0Ait is useful and helpful. Ev= en for those who think the assumptions=20=0D=0Aare obvious, it does no harm= to state them.=0D=0A=0D=0AWe had a lot of debate on this in SFO, and the t= ext in this version=20=0D=0Awas discussed on the mailing list in the days d= uring and following=20=0D=0Athe meeting.=0D=0A--=20=0D=0ARandall Gellens=0D= =0AOpinions are personal; facts are suspect; I speak for myself only=0D= =0A-------------- Randomly selected tag: ---------------=0D=0AOne's need fo= r loneliness is not satisfied if one sits at a table alone.=0D=0AThere must= be empty chairs as well. --Karl Kraus=0D=0A________= _______________________________________=0D=0AEcrit mailing list=0D=0AEcrit@= ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------= ---------------------------------------------------------------------------= ---------------=0D=0AThis message is for the designated recipient only and = may=0D=0Acontain privileged, proprietary, or otherwise private information.= =20=0D=0AIf you have received it in error, please notify the sender=0D=0Ai= mmediately and delete the original. Any unauthorized use of=0D=0Athis emai= l is prohibited.=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0A[mf2]=0D=0A From rbarnes@bbn.com Mon Apr 27 21:41:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3113A7007 for ; Mon, 27 Apr 2009 21:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkIAma90cM-1 for ; Mon, 27 Apr 2009 21:41:06 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 497923A697D for ; Mon, 27 Apr 2009 21:40:48 -0700 (PDT) Received: from [128.89.254.135] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Lyf8y-0002Cv-AM; Tue, 28 Apr 2009 00:42:08 -0400 Message-ID: <49F6891E.7080706@bbn.com> Date: Tue, 28 Apr 2009 00:42:06 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Randall Gellens References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 04:41:07 -0000 Ok, we clearly need to revise the text, since that's a pretty serious misunderstanding. The text doesn't constrain the use of the protocols at all -- in fact it says "they underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider". For example, in the 3GPP model, an E-CSCF could do everything on behalf of the endpoint, but could still use SIP for calling, LoST for PSAP URI discovery, and HELD for location retreival. The point of the current text is just that those scenarios aren't discussed in this draft, not that the overall model doesn't apply to those scenarios. --Richard Randall Gellens wrote: > I hum for the text, which doesn't constrain the use of the protocols, > but merely describes the assumptions under which it works. As such, it > is useful and helpful. Even for those who think the assumptions are > obvious, it does no harm to state them. > > We had a lot of debate on this in SFO, and the text in this version was > discussed on the mailing list in the days during and following the meeting. From sedge@qualcomm.com Mon Apr 27 22:41:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9727E3A6883 for ; Mon, 27 Apr 2009 22:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.463 X-Spam-Level: X-Spam-Status: No, score=-105.463 tagged_above=-999 required=5 tests=[AWL=1.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3Lp6HsWQ+CT for ; Mon, 27 Apr 2009 22:41:09 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 1990D3A6F95 for ; Mon, 27 Apr 2009 22:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1240897324; x=1272433324; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20R ichard=20Barnes=20,=20"Gellens,=20Randal l"=20,=0D=0A=20=20=20=20=20=20=20=20E CRIT=20|Date:=20Mon,=2027=20Apr=202009=20 22:42:00=20-0700|Subject:=20RE:=20[Ecrit]=20PhoneBCP |Thread-Topic:=20[Ecrit]=20PhoneBCP|Thread-Index:=20AcnHu 8GIGqsMJy5ZQFmAuQlFWecLywABf2YA|Message-ID:=20<1288E74A73 964940B132A0B9EA8D8ABC5926A334@NASANEXMB04.na.qualcomm.co m>|References:=20=0D=0A=09<49F27637.7 050201@bbn.com>=0D=0A=09=0D=0A=09<058701c9c5d0$53c5ef4 0$fb51cdc0$@net>=0D=0A=09=0D=0A=09<28B7C3AA2A7ABA4A841 F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-=0D=0A =09lucent.com>=09 =0D=0A=20<49F6891E.7080706@bbn.com>|In-Reply-To:=20<49F68 91E.7080706@bbn.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5598"=3B=20a=3D"17531441"; bh=fWhPCUtuTRLQAf+J7bnSj2UlosQHN//vQAyX+IuOdB8=; b=kCJFuxpnXhkzRitSulvlVxRvM7gpbX+5yoW8LVjSNF8c48JzVvllO2hK Cci4tIMujYUQfsc5RV3vRqh4Fn/lzXwjAQ5dTXjHOneskrydzyyAvjs+d 86FSggHbYrVROX5N8faOv1otdtmGrPci5YavTOcqeljFioFX8s2+25Bib U=; X-IronPort-AV: E=McAfee;i="5300,2777,5598"; a="17531441" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2009 22:42:04 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3S5g3pO005721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2009 22:42:03 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3S5g2Jt009739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Apr 2009 22:42:02 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Mon, 27 Apr 2009 22:42:02 -0700 From: "Edge, Stephen" To: Richard Barnes , "Gellens, Randall" , ECRIT Date: Mon, 27 Apr 2009 22:42:00 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnHu8GIGqsMJy5ZQFmAuQlFWecLywABf2YA Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A334@NASANEXMB04.na.qualcomm.com> References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> In-Reply-To: <49F6891E.7080706@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 05:41:10 -0000 All The statement "The underlying protocols can also be used to support other m= odels in which parts of the process are delegated to the Communications Ser= vice Provider" seems applicable to the 3GPP/3GPP2 solution - e.g. because i= t does not say that all the protocols must be used, nor does it say that ot= her protocols must not be used, but is consistent with a selection of some = subset. (That is also applicable to the preferred Ecrit solution which allo= ws choice of LCP in the network.)=20 So I support the current applicability statement and, based on the very lon= g discussion that it took to get to that, foresee a possibly equally long d= iscussion ahead if this issue has to be restarted. Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= ichard Barnes Sent: Monday, April 27, 2009 9:42 PM To: Gellens, Randall Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP Ok, we clearly need to revise the text, since that's a pretty serious=20 misunderstanding. The text doesn't constrain the use of the protocols=20 at all -- in fact it says "they underlying protocols can also be used to=20 support other models in which parts of the process are delegated to the=20 Communications Service Provider". For example, in the 3GPP model, an=20 E-CSCF could do everything on behalf of the endpoint, but could still=20 use SIP for calling, LoST for PSAP URI discovery, and HELD for location=20 retreival. The point of the current text is just that those scenarios aren't=20 discussed in this draft, not that the overall model doesn't apply to=20 those scenarios. --Richard Randall Gellens wrote: > I hum for the text, which doesn't constrain the use of the protocols,=20 > but merely describes the assumptions under which it works. As such, it=20 > is useful and helpful. Even for those who think the assumptions are=20 > obvious, it does no harm to state them. >=20 > We had a lot of debate on this in SFO, and the text in this version was=20 > discussed on the mailing list in the days during and following the meetin= g. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Mon Apr 27 23:04:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54733A6A32 for ; Mon, 27 Apr 2009 23:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ml5inpxgUrb for ; Mon, 27 Apr 2009 23:04:11 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id F12943A6A12 for ; Mon, 27 Apr 2009 23:04:10 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_28_01_26_17 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 28 Apr 2009 01:26:17 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 01:05:31 -0500 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, 28 Apr 2009 01:05:30 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A334@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnHu8GIGqsMJy5ZQFmAuQlFWecLywABf2YAAAEk4RA= References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F6891E.7080706@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A334@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Edge, Stephen" , "Richard Barnes" , "Gellens, Randall" , "ECRIT" X-OriginalArrivalTime: 28 Apr 2009 06:05:31.0943 (UTC) FILETIME=[5670EB70:01C9C7C7] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 06:04:12 -0000 =0D=0AThe discussion for the need of an applicability statement was NEVER=0D= =0Aresolved, as NO consensus was reached. So no applicability statement=0D=0A= should ever have been added to the document.=0D=0A=0D=0AA number of people = decided to construct an applicability statement and=0D=0Ahave attempted to = now have it ratified without the need for an=0D=0Aapplicability statement b= eing clearly demonstrated or agreed to by the=0D=0Aworking group.=0D=0A=0D=0A= If, and only if, a consensus to include an applicability statement is=0D=0A= reached should the wording included by Brian be looked at. I still=0D=0Aveh= emently oppose the inclusion of any applicability statement and I=0D=0Adon'= t want to consider any wording until a consensus is reached on us=0D=0Arequ= iring an applicability statement.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf=0D=0AOf Edge, Stephen=0D=0ASent: Tuesday, 28= April 2009 3:42 PM=0D=0ATo: Richard Barnes; Gellens, Randall; ECRIT=0D=0AS= ubject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0AAll=0D=0A=0D=0AThe statement "The u= nderlying protocols can also be used to support=0D=0Aother models in which = parts of the process are delegated to the=0D=0ACommunications Service Provi= der" seems applicable to the 3GPP/3GPP2=0D=0Asolution - e.g. because it doe= s not say that all the protocols must be=0D=0Aused, nor does it say that ot= her protocols must not be used, but is=0D=0Aconsistent with a selection of = some subset. (That is also applicable to=0D=0Athe preferred Ecrit solution = which allows choice of LCP in the network.)=0D=0A=0D=0A=0D=0ASo I support t= he current applicability statement and, based on the very=0D=0Along discuss= ion that it took to get to that, foresee a possibly equally=0D=0Along discu= ssion ahead if this issue has to be restarted.=0D=0A=0D=0AKind Regards=0D=0A=0D= =0AStephen=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.or= g [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Richard Barnes=0D=0ASen= t: Monday, April 27, 2009 9:42 PM=0D=0ATo: Gellens, Randall=0D=0ACc: ECRIT=0D= =0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0AOk, we clearly need to revise t= he text, since that's a pretty serious=20=0D=0Amisunderstanding. The text = doesn't constrain the use of the protocols=20=0D=0Aat all -- in fact it say= s "they underlying protocols can also be used to=0D=0A=0D=0Asupport other m= odels in which parts of the process are delegated to the=20=0D=0ACommunicat= ions Service Provider". For example, in the 3GPP model, an=20=0D=0AE-CSCF = could do everything on behalf of the endpoint, but could still=20=0D=0Ause = SIP for calling, LoST for PSAP URI discovery, and HELD for location=20=0D=0A= retreival.=0D=0A=0D=0AThe point of the current text is just that those scen= arios aren't=20=0D=0Adiscussed in this draft, not that the overall model do= esn't apply to=20=0D=0Athose scenarios.=0D=0A=0D=0A--Richard=0D=0A=0D=0A=0D= =0ARandall Gellens wrote:=0D=0A> I hum for the text, which doesn't constrai= n the use of the protocols,=20=0D=0A> but merely describes the assumptions = under which it works. As such,=0D=0Ait=20=0D=0A> is useful and helpful. E= ven for those who think the assumptions are=20=0D=0A> obvious, it does no h= arm to state them.=0D=0A>=20=0D=0A> We had a lot of debate on this in SFO, = and the text in this version=0D=0Awas=20=0D=0A> discussed on the mailing li= st in the days during and following the=0D=0Ameeting.=0D=0A________________= _______________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D= =0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A_______________________= ________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ah= ttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A---------------------= ---------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A From Martin.Dawson@andrew.com Tue Apr 28 00:11:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711453A705B for ; Tue, 28 Apr 2009 00:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4ngZKAzJ1OK for ; Tue, 28 Apr 2009 00:11:21 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BE6473A7077 for ; Tue, 28 Apr 2009 00:11:16 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_28_02_33_22 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 28 Apr 2009 02:33:22 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 02:12:36 -0500 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, 28 Apr 2009 02:12:34 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnHPhdCC9dC5/SxRDmbBRTcfUXD1QAkf0WQ References: <3D3C75174CB95F42AD6BCC56E5555B45014D4A6D@FIESEXC015.nsn-intra.net> From: "Dawson, Martin" To: "Henning Schulzrinne" , "Tschofenig, Hannes (NSN - FI/Espoo)" X-OriginalArrivalTime: 28 Apr 2009 07:12:36.0872 (UTC) FILETIME=[B57C5880:01C9C7D0] Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:11:22 -0000 +1 - and, quite particularly, on the basis that it isn't an=0D=0A"applicabi= lity statement" it's a statement that effectively says that=0D=0Athere are = some domains where the framework is applicable but there'll be=0D=0Aaspects= to the domain that aren't specifically described by the=0D=0Aframework and= that... well... you'll just have to think about.=0D=0A=0D=0ASince this is = a truism, its presence is a tautology and unnecessary.=0D=0A=0D=0AHaving sa= id all that - and given the motives driving the creation of=0D=0Athis "soun= d bite" are transparent, I'd rather let the people playing=0D=0Apolitics ha= ve their way with the document since, clearly, the threat is=0D=0Athat they= 'll just stonewall it indefinitely otherwise. Hopefully common=0D=0Asense w= ill out in time regardless.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----= Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounc= es@ietf.org] On Behalf=0D=0AOf Henning Schulzrinne=0D=0ASent: Monday, 27 Ap= ril 2009 11:43 PM=0D=0ATo: Tschofenig, Hannes (NSN - FI/Espoo)=0D=0ACc: ECR= IT=0D=0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0A+1=0D=0A=0D=0AOn Apr 27, 2= 009, at 8:34 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:=0D=0A=0D=0A> I = hum against the applicability statement. I cannot see why we need =20=0D=0A= > one.=0D=0A>=0D=0A>=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=0D=0A=0D=0A__________= _____________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ie= tf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0AThis message is for the designated recipient only and ma= y=0D=0Acontain privileged, proprietary, or otherwise private information. =0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A From hannes.tschofenig@nsn.com Tue Apr 28 00:43:03 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BB03A706B for ; Tue, 28 Apr 2009 00:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.602 X-Spam-Level: X-Spam-Status: No, score=-5.602 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCE-+Yot709m for ; Tue, 28 Apr 2009 00:43:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A34E53A6CEF for ; Tue, 28 Apr 2009 00:43:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3S7iLGp008305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Apr 2009 09:44:21 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3S7iKdl005210 for ; Tue, 28 Apr 2009 09:44:20 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 09:44:20 +0200 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, 28 Apr 2009 10:45:54 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45014D4DC6@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Status Update (April 2009) Thread-Index: AcnH1VxgjUhJdWioSce/NAUIC6+8wA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 28 Apr 2009 07:44:20.0569 (UTC) FILETIME=[242D7490:01C9C7D5] Subject: [Ecrit] ECRIT Status Update (April 2009) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:43:03 -0000 ECRIT Status Update (April 2009) =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 0) WG Management and Virtual Interim Meeting Marc and Hannes requested a discussion slot with Cullen and Robert to talk about the next steps for the group.=20 In particular, it would be important to understand whether re-chartering or milestone updates are required for adding new work to the group and when new items can be added.=20 Action item:=20 - Cullen and Robert to provide time and date for a discussion slot.=20 - Hannes will query the list whether there is interest in having another virtual interim meeting.=20 1) draft-ietf-ecrit-framework / draft-ietf-ecrit-phonebcp The documents got blocked based on the discussion about an applicability statement.=20 Marc started a HUM on the list regarding the applicability statement, see=20 http://www.ietf.org/mail-archive/web/ecrit/current/msg06245.html Action item: Summarize discussion after the deadline Deadline: Beginning of May 2) draft-ietf-ecrit-lost-sync Two implementation activities are ongoing. Authors would like to wait for the results of these implementation efforts (e.g., are the error codes complete in the document) Action item: Hannes and Henning to verify results of the=20 Deadline: May 2009 3) draft-patel-ecrit-sos-parameter Cullen is now document shepherd of the document. Expert review by Gonzalo provided to the list; updated draft by Milan followed=20 Action item: Milan to ping Gonzalo to confirm that his expert review comments got appropriately addressed 4) draft-ietf-ecrit-location-hiding-req Yesterday, Cullen has put the document in "In Last Call" state. =20 Action item: No action from the working group; last call will be announced.=20 5) draft-ietf-ecrit-specifying-holes Document is in "Publication Requested" state since October 2008.=20 Action item: Document is waiting AD review by Cullen.=20 6) draft-ietf-ecrit-mapping-arch Document has been updated in March 2009 to address the comments raised by Cullen.=20 Action item: Document is waiting for Cullen to confirm that his DISCUSS has been addressed.=20 7) draft-ietf-ecrit-local-emergency-rph-namespace Document has been updated for the San Francisco IETF. No open issues known.=20 Action item: Marc, as the PROTO shepherd, will find a few reviewers for the document and to start a WGLC.=20 Deadline: May 2009 7) draft-barnes-ecrit-rough-loc Document was discussed during the virtual interim meeting and also at the San Francisco IETF meeting.=20 Technical direction has been proposed and is waiting to get documented in draft-barnes-ecrit-rough-loc Action item: Richard and Matt to update the document.=20 Deadline: May 2009 8) draft-forte-ecrit-service-urn-policy-00.txt The group agreed to make the document a new ECRIT WG item.=20 Confirmation of the HUM on the list: http://www.ietf.org/mail-archive/web/ecrit/current/msg06240.html.=20 Action item: None; waiting to become a draft-ietf-.. document and to issue a WGLC shortly afterwards since the content of the draft was discussed in the group already.=20 9) draft-schulzrinne-ecrit-unauthenticated-access The group agreed to make the document a new ECRIT WG item.=20 Confirmation of the HUM on the list: http://www.ietf.org/mail-archive/web/ecrit/current/msg06242.html.=20 Action item: Authors to improve the readability of the document.=20 Deadline: May 2009 10) draft-schulzrinne-ecrit-psap-callback The group agreed to make the document a new ECRIT WG item.=20 Confirmation of the HUM on the list: http://www.ietf.org/mail-archive/web/ecrit/current/msg06238.html Action item: Hannes to poll the group regarding the preferred assumptions.=20 Deadline: May 2009 11) draft-wolf-ecrit-lost-servicelistboundary At the virtual interim meeting in Feb 2009 we have asked for feedback regarding the document and also during the IETF meeting in San Francisco and we got a few supporters. Marc started a HUM on the mailing list, see http://www.ietf.org/mail-archive/web/ecrit/current/msg06246.html, and the deadline for responses is May 1st.=20 Action item: Group to respond to the HUM.=20 12) draft-rosen-ecrit-premature-disconnect-rqmts The work on this topic got stuck again and the chairs are trying to determine ways forward. The chairs have tried to find an independent editor for the document but so far everyone rejected. =20 Action item: Marc & Hannes to determine a way forward and propose a plan to the ECRIT WG. Deadline: May 2009 13) Misc=20 If you have time left please read and comment the following documents:=20 * Labels for Common Location-Based Services http://tools.ietf.org/id/draft-forte-ecrit-service-classification-02.txt * Location-to-Service Translation Protocol (LoST) Extensions http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-02.txt * Shelter Service And Classification http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-01.txt * Civic Location Format Extension for Utility and Lamp Post Numbers http://tools.ietf.org/id/draft-george-ecrit-lamp-post-00.txt * Best Current Practice for IP-based In-Vehicle Emergency Calls http://tools.ietf.org/id/draft-rosen-ecrit-ecall-02.txt * Trustworthy Location Information http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location-01. txt From MILANPA@nortel.com Tue Apr 28 06:35:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D5828C218 for ; Tue, 28 Apr 2009 06:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.871, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qWukNkza00r for ; Tue, 28 Apr 2009 06:35:00 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 723583A67B4 for ; Tue, 28 Apr 2009 06:35:00 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3SDZR201330; Tue, 28 Apr 2009 13:35:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 14:35:43 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> In-Reply-To: <49B4F019.2020904@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Thread-Index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBw References: <499D6530.9040208@ericsson.com> <0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com> <49B4F019.2020904@ericsson.com> From: "Milan Patel" To: "Gonzalo Camarillo" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:35:02 -0000 Hi Gonzalo, Version 4 of draft-patel-ecrit-sos-parameter addresses all the comments you provided in the expert review. Please can you confirm that you are OK with its contents and that all the issues you had previously highlighted are now resolved. http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 Best regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: 09 March 2009 10:32 To: Patel, Milan (MOP:EP10) Cc: ecrit@ietf.org; Hannes Tschofenig Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi, the problem with this text is that it specifies behavior for entities that will not implement this specification. The new section should describe how a legacy registrar will handle, following regular SIP rules, a REGISTER request with the sos parameter. However, it cannot specify extra behavior for such a legacy registrar. That is the whole point of backwards compatibility: to support unchanged legacy applications that will not implement the new functionality. In any case, I believe you can use most of the text you proposed below.=20 It just needs to be rephrased so that it is more descriptive and non normative. Thanks, Gonzalo Milan Patel wrote: > Folks, >=20 > In response to Gonzalo's comment on backwards compatibility, I propose > a subclause "4.3 Backwards compatibility issues" as follows: >=20 > ---------------------------------------------------------------------- > -- > ---------------------------------- > 4.3 Backwards compatibility issues > The backwards compatibility scenario considered in this document is=20 > where the registrar does not support the "sos" URI parameter. In this=20 > case, if the registrar receives a REGISTER request that includes the=20 > "sos" URI parameter in the Contact header, the registrar MUST proceed=20 > with registration procedures and silently ignore the URI-parameter in=20 > accordance with RFC 3261. This ensures the user is registered and thus > can successfully initiate an emergency call. >=20 > The drawback of proceeding with registration is if the=20 > address-of-record is barred or has roaming restrictions applied, then=20 > these restrictions will not be lifted and thus registration will be=20 > unsuccessful. This may limit the UAC's ability to successfully place an emergency call. >=20 > If registration is successful, the registrar shall return a 200 (OK)=20 > response to the UAC and does not include the "sos" URI parameter in=20 > the Contact header. The UAC is aware of its registered contact address > and address-of-record, however, cannot distinguish between this=20 > registration and a non-emergency registration. > ---------------------------------------------------------------------- > -- > -------------------------------------- >=20 > Comments/feedback/suggestions for improvement are appreciated. I will=20 > address Gonzalo's other comments in version -04 of the draft as well. >=20 > Best regards, > Milan >=20 > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 /=20 > ESN 748 9261 >=20 > For the Companies listed below, The Institute of Chartered Accountants > in England and Wales authorises A R Bloom, S Harris and C Hill to act=20 > as Insolvency Practitioners under section 390(2)(a) of the Insolvency=20 > Act > 1986 and the Association of Chartered Certified Accountants authorises > A M Hudson to act as an Insolvency Practitioner under section=20 > 390(2)(a) of the Insolvency Act 1986. >=20 > The affairs, business and property of the Companies are being managed=20 > by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill > who act as agents of the Companies only and without personal liability. >=20 > The Companies are Nortel Networks UK Limited; Nortel Networks SA;=20 > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel=20 > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo;=20 > Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel=20 > Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel > Networks Romania SRL; Nortel Networks AB; Nortel Networks=20 > International Finance & Holding BV >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Gonzalo Camarillo > Sent: 19 February 2009 13:57 > To: ecrit@ietf.org > Subject: [Ecrit] Expert review of=20 > draft-patel-ecrit-sos-parameter-03.txt >=20 > Folks, >=20 > I have been asked to perform an expert review of the following draft: >=20 > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt >=20 > The approach taken by the draft seems OK in general. I have a few=20 > comments though: >=20 > The requirement in Section 3 is too specific because it already=20 > assumes that the solution will be an indication in the SIP header=20 > fields. The requirement does not need to make that assumption. I would > remove "by providing an appropriate indication in the SIP header fields". >=20 > In Section 5, the reference to RFC 2234 should be replaced with one to > RFC 5234. >=20 > Also in Section 5, the formal syntax should be rewritten so that it is > compatible with the ABNF in RFC 3261. RFC 3261 already defines=20 > uri-parameter as follows: >=20 > uri-parameter =3D transport-param / user-param / method-param > / ttl-param / maddr-param / lr-param /=20 > other-param >=20 > other-param =3D pname [ "=3D" pvalue ] > pname =3D 1*paramchar > pvalue =3D 1*paramchar >=20 > This document should simply define a new value for pname. >=20 > The document does not talk about backwards compatibility. What happens > if the registrar does not understand the 'sos' parameter? Will it do=20 > the right thing? Will the UAC detect the failure? Is there a need to=20 > define an option tag?... the document should address these points. >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bs7652@att.com Tue Apr 28 06:58:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1160A3A6A2B for ; Tue, 28 Apr 2009 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.871 X-Spam-Level: X-Spam-Status: No, score=-105.871 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wa3GxXIwzDl for ; Tue, 28 Apr 2009 06:58:21 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 114DA3A70C4 for ; Tue, 28 Apr 2009 06:58:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-7.tower-146.messagelabs.com!1240927178!2204241!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 7681 invoked from network); 28 Apr 2009 13:59:39 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-7.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Apr 2009 13:59:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3SDxbq7017939; Tue, 28 Apr 2009 09:59:38 -0400 Received: from 01GAF5142010623.AD.BLS.COM (01GAF5142010623.ad.bls.com [139.76.131.87]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n3SDxVhB017374; Tue, 28 Apr 2009 09:59:32 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 28 Apr 2009 09:59:32 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 28 Apr 2009 09:59:31 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Date: Tue, 28 Apr 2009 09:59:30 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP thread-index: AcnHl9wZQPN/zTfxRdaAPkbQJARhJwAb6CJw References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Stark, Barbara" To: "Randall Gellens" , "ECRIT" X-OriginalArrivalTime: 28 Apr 2009 13:59:31.0367 (UTC) FILETIME=[8DA8A370:01C9C809] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:58:22 -0000 I agree with this view, except I would say the text describes the assumptions under which the BCP was created, rather than the assumptions under which it works. As such, I really wish people would stop referring to the proposed text as an "applicability statement".=20 It isn't.=20 The proposed text has no title or header within the document (other than being part of "Introduction"), and needs to be read without any preconceived notion about what the motives were behind the text. That is how most people will be reading the text. As such, I continue to support the inclusion of the text. It does no harm. It may be useful. Some of the people humming against this are exactly the people who I thought would want to try to get this document done and finished. I'm surprised that they are prolonging our combined agony. Since the text is *not* an applicability statement (no matter that our illustrious chair may have called it such), and it does no harm, can't we please just let the text be and move on? Please? Pretty please? Barbara > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Randall Gellens > Sent: Monday, April 27, 2009 8:25 PM > To: ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > I hum for the text, which doesn't constrain the use of the protocols, > but merely describes the assumptions under which it works. As such, > it is useful and helpful. Even for those who think the assumptions > are obvious, it does no harm to state them. >=20 > We had a lot of debate on this in SFO, and the text in this version > was discussed on the mailing list in the days during and following > the meeting. > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > One's need for loneliness is not satisfied if one sits at a table > alone. > There must be empty chairs as well. --Karl Kraus > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 From rbarnes@bbn.com Tue Apr 28 07:43:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9783A6D18 for ; Tue, 28 Apr 2009 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7u678a5YQ4K for ; Tue, 28 Apr 2009 07:43:51 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 938AD3A684E for ; Tue, 28 Apr 2009 07:43:51 -0700 (PDT) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LyoYa-00026K-AH; Tue, 28 Apr 2009 10:45:12 -0400 Message-ID: <49F71677.2070007@bbn.com> Date: Tue, 28 Apr 2009 10:45:11 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:43:52 -0000 I think this document is useful. It fills a gap in the logical structure of LoST, and enables a more complete, automatic client processing model. --Richard Marc Linsner wrote: > All, > > Please review this draft to and respond by Friday May 1 if you find this > valuable for ECRIT to work on. > > Thanks, > > -Marc- > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Tue Apr 28 08:12:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AEB3A6CA9 for ; Tue, 28 Apr 2009 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNS4y01P1YDJ for ; Tue, 28 Apr 2009 08:12:47 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id E73953A70FC for ; Tue, 28 Apr 2009 08:12:46 -0700 (PDT) Received: from new-host.home (pool-96-242-40-88.nwrknj.fios.verizon.net [96.242.40.88] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3SFE4eL024848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2009 11:14:04 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: "Stark, Barbara" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 11:14:04 -0400 References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:12:48 -0000 Barbara, with all due respect, the delay is due to the people insisting that the text be added at the last minute. It is clear that the text has ulterior motives to restrict the applicability of the document. This should be patently obvious from the origin of this whole text-adding effort. Henning On Apr 28, 2009, at 9:59 AM, Stark, Barbara wrote: > > As such, I continue to support the inclusion of the text. It does no > harm. It may be useful. > Some of the people humming against this are exactly the people who I > thought would want to try to get this document done and finished. I'm > surprised that they are prolonging our combined agony. > Since the text is *not* an applicability statement (no matter that our > illustrious chair may have called it such), and it does no harm, can't > we please just let the text be and move on? > Please? Pretty please? > Barbara > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> Of Randall Gellens >> Sent: Monday, April 27, 2009 8:25 PM >> To: ECRIT >> Subject: Re: [Ecrit] PhoneBCP >> >> I hum for the text, which doesn't constrain the use of the protocols, >> but merely describes the assumptions under which it works. As such, >> it is useful and helpful. Even for those who think the assumptions >> are obvious, it does no harm to state them. >> >> We had a lot of debate on this in SFO, and the text in this version >> was discussed on the mailing list in the days during and following >> the meeting. >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself > only >> -------------- Randomly selected tag: --------------- >> One's need for loneliness is not satisfied if one sits at a table >> alone. >> There must be empty chairs as well. --Karl > Kraus >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance > upon this information by persons or entities other than the intended > recipient is prohibited. If you received this in error, please > contact the sender and delete the material from all computers. GA623 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From randy@qualcomm.com Tue Apr 28 09:53:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5EA73A6954 for ; Tue, 28 Apr 2009 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.385 X-Spam-Level: X-Spam-Status: No, score=-105.385 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EddhO8sVu2ep for ; Tue, 28 Apr 2009 09:53:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E3A163A6A12 for ; Tue, 28 Apr 2009 09:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1240937662; x=1272473662; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<49F6891E.7080706@bbn.com>|References:=20 =09<49F27637.7050201@bbn.com> =0D=0A=20=0D=0A=20<058701c9c5d0$53c5ef40$fb51cdc0$@net >=0D=0A=20=0D=0A=20<28B7C3AA2A7ABA4A841F11217ABE78D675 90BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-=0D=0A=20lucent.com> =09=0D=0A=20<49F68 91E.7080706@bbn.com>|X-Mailer:=20Eudora=20for=20Mac=20OS =20X|X-message-Note:=20Warning:=20Outlook=20in=20use.=20 =20Upgrade=20to=20Eudora:=20|Date: =20Tue,=2028=20Apr=202009=2009:52:27=20-0700|To:=20Richar d=20Barnes=20|From:=20Randall=20Gellens =20|Subject:=20Re:=20[Ecrit]=20PhoneB CP|CC:=20ECRIT=20|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5599"=3B=20 a=3D"17551280"; bh=Z6LzhIB0eDS54099RTuxIJZ5QNR4FuBYRJN8iQGhZzs=; b=f0nrx1mi2BALgCtz5X9fA+rRKdZQxgSROkFZhS2jTRW8yXHePt4XBZnA ZUZfKRRm4L8I1JX0B/vdO8WdaQz0yGG1vev0O6/gyhoZPhGjDQ8r2e3u+ aYelRZ02bvrNY3n4tH/TyOxr01yrrU1ne/Qcu7ssGCjv3JDcaNOPDSblM E=; X-IronPort-AV: E=McAfee;i="5300,2777,5599"; a="17551280" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2009 09:54:22 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3SGsM5i032459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 09:54:22 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3SGsLfd019135 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Apr 2009 09:54:21 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 09:54:21 -0700 Received: from [172.28.171.53] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Apr 2009 09:54:20 -0700 Message-ID: In-Reply-To: <49F6891E.7080706@bbn.com> References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 28 Apr 2009 09:52:27 -0700 To: Richard Barnes From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:53:02 -0000 At 12:42 AM -0400 4/28/09, Richard Barnes wrote: > Ok, we clearly need to revise the text, since that's a pretty > serious misunderstanding. The text doesn't constrain the use of > the protocols at all I think the text as written is pretty clear that there is no constraint. > -- in fact it says "they underlying protocols can also be used to > support other models in which parts of the process are delegated to > the Communications Service Provider". Yes, exactly correct. > The point of the current text is just that those scenarios aren't > discussed in this draft, not that the overall model doesn't apply > to those scenarios. Yes, exactly. The text merely clarifies what the draft discusses. > Randall Gellens wrote: >> I hum for the text, which doesn't constrain the use of the >> protocols, but merely describes the assumptions under which it >> works. As such, it is useful and helpful. Even for those who >> think the assumptions are obvious, it does no harm to state them. >> >> We had a lot of debate on this in SFO, and the text in this >> version was discussed on the mailing list in the days during and >> following the meeting. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I love the smell of excessive quoting in the morning. --Steve Dorner From randy@qualcomm.com Tue Apr 28 09:59:35 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844273A6CD8 for ; Tue, 28 Apr 2009 09:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.506 X-Spam-Level: X-Spam-Status: No, score=-105.506 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wE2w1BP9nkV for ; Tue, 28 Apr 2009 09:59:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8FC5E3A6E84 for ; Tue, 28 Apr 2009 09:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1240938056; x=1272474056; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20|References:=20=0D =0A=20<49F27637.7050201@bbn.com><058701c9c5d0 $53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F 11217A=0D=0A=20BE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel -lucent.com>=0D=0A=20=0D=0A=20<7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@cre xc41p>=0D=0A=20|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-Note:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20Tu e,=2028=20Apr=202009=2009:56:43=20-0700|To:=20Henning=20S chulzrinne=20,=0D=0A=20=20=20=20=20 =20=20=20"Stark,=20Barbara"=0D=0A=09 |From:=20Randall=20Gellens=20 |Subject:=20Re:=20[Ecrit]=20PhoneBCP|CC:=20ECRIT=20|MIME-Version:=201.0|Content-Type:=20text/plain =3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5599"=3B=20a=3D"17551600"; bh=NOJk+J/fzjjxW/xsqr3YJEIpMW7wFP3jMZxvDkq87bo=; b=U8UQ2sfJcct7HCqhQH3XiXrbgR6Ag5EvW6e1Yp6wanHAAV8Bl7iMtHvD gwYTPs2oWlKpQz+KjF3JJb5YdjSXw6V11NdaDHyCCDvCdgX6Z4g60T17g fOLmZjBnwZMaDxsp6PxjumyRN72Kt9ZP+oo5+XD33jUcdL5rMkhAg1ckR o=; X-IronPort-AV: E=McAfee;i="5300,2777,5599"; a="17551600" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2009 10:00:41 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3SH0ffG016459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 10:00:41 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3SH0XUs016330 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Apr 2009 10:00:41 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 10:00:40 -0700 Received: from [172.28.171.53] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Apr 2009 10:00:38 -0700 Message-ID: In-Reply-To: References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217A BE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 28 Apr 2009 09:56:43 -0700 To: Henning Schulzrinne , "Stark, Barbara" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:59:35 -0000 At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote: > It is clear that the text has ulterior motives to restrict the > applicability of the document. From my view, the text does not restrict the applicability, nor is there a desire to do so. The text does clarify the assumptions of the rest of the text in the document, which I think is helpful. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The solution to a problem changes the nature of the problem. From sedge@qualcomm.com Tue Apr 28 10:28:41 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839DE28C0F6 for ; Tue, 28 Apr 2009 10:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-sINuU83WNX for ; Tue, 28 Apr 2009 10:28:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3DE723A70FC for ; Tue, 28 Apr 2009 10:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1240939802; x=1272475802; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Gellens,=20Randall"=20,=0D=0A=20=20 =20=20=20=20=20=20Henning=20Schulzrinne=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"Stark,=20Barb ara"=20,=20ECRIT=0D=0A=09 |Date:=20Tue,=2028=20Apr=202009=2010:29:59=20-0700 |Subject:=20RE:=20[Ecrit]=20PhoneBCP|Thread-Topic:=20[Ecr it]=20PhoneBCP|Thread-Index:=20AcnIIvqh4HtW4THrQ3WLstV8Jn SWmQAAVJtA|Message-ID:=20<1288E74A73964940B132A0B9EA8D8AB C5926A365@NASANEXMB04.na.qualcomm.com>|References:=20=0D=0A=09<49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><2 8B7C3AA2A7ABA4A841F11217A=0D=0A=09BE78D67590BD8E@FRMRSSXC HMBSB3.dc-m.alcatel-lucent.com>=0D=0A=09=0D=0A=09<7582BC68E4994F4ABF0BD4723 975C3FA0E0471BA@crexc41p>=0D=0A=09=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5599"=3B=20a=3D"17544371"; bh=5fGN3d7B6Ilitr/3qAcDvhvMaLGW5/h6sMqjO4XgJi8=; b=vzsrl9BkgKodxaVRKXIL1yILf95xSu6ef1RXP69mXy/zYp19qU1QqVUX O4LVFX/mlyB9NmzZFZsG6whPZ0BZt+WYapTnOxRuhvs6ZdSWqFkZgmqsi kSPol6ew4q9Nd6MB++K5/yYoxN7N+LnyXfgpr675qZtS8S0a4qCtuuM/A o=; X-IronPort-AV: E=McAfee;i="5300,2777,5599"; a="17544371" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2009 10:30:01 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3SHU1KZ020807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 10:30:01 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3SHU0m0003974 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Apr 2009 10:30:00 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Tue, 28 Apr 2009 10:30:00 -0700 From: "Edge, Stephen" To: "Gellens, Randall" , Henning Schulzrinne , "Stark, Barbara" , ECRIT Date: Tue, 28 Apr 2009 10:29:59 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIIvqh4HtW4THrQ3WLstV8JnSWmQAAVJtA Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com> References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217A BE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:28:41 -0000 All I would have thought that motivation should be irrelevant. There are a lot = of motives at work here. Should we assume that the document was originally = written with only the purest and most altruistic motives (e.g. no thought o= f business or academic interest at stake)? The issue is whether the current statement serves a useful purpose in conve= ying the possibility (well known to be true) of alternative solutions not f= ully aligned with the current drafts. Nothing in the statement implies that= the current drafts are necessarily deficient or that alternative solutions= must necessarily be used for some scenarios (even though they optionally c= an be). Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= andall Gellens Sent: Tuesday, April 28, 2009 9:57 AM To: Henning Schulzrinne; Stark, Barbara Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote: > It is clear that the text has ulterior motives to restrict the=20 > applicability of the document. From my view, the text does not restrict the applicability, nor is=20 there a desire to do so. The text does clarify the assumptions of=20 the rest of the text in the document, which I think is helpful. --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The solution to a problem changes the nature of the problem. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Tue Apr 28 10:43:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017283A679F for ; Tue, 28 Apr 2009 10:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iE1Wu9-wtC2 for ; Tue, 28 Apr 2009 10:43:15 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 119C63A63C9 for ; Tue, 28 Apr 2009 10:43:15 -0700 (PDT) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LyrMB-00056N-An; Tue, 28 Apr 2009 13:44:35 -0400 Message-ID: <49F74082.2080804@bbn.com> Date: Tue, 28 Apr 2009 13:44:34 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Randall Gellens References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:43:16 -0000 I still think we're disagreeing; let me try to clarify why. I was wrong to focus on the word "constrain" in your message; the real issue is "assumptions". This document doesn't have any "assumptions under which it works" other than those that need to be true for any emergency calling system, namely that (1) the endpoint can be located, (2) there's a location-to-service mapping system. (3) relevant entities communicate over IP These assumptions need to be true in whatever IP network you want to do emergency calling -- in the Internet, in a 3G network, in a WiMAX network, etc. The IMS emergency calling architecture also makes these assumptions. As a corollary, the solution described in this document works in any IP network where the above assumptions hold (including cellular networks as a case in point). So one should not draw from the additional text in the latest draft that there are assumptions underlying the solution in this document that would prevent its applicability in some IP networks. If that's how it is being interpreted, then we need to revise it again. --Richard Randall Gellens wrote: > At 12:42 AM -0400 4/28/09, Richard Barnes wrote: > >> Ok, we clearly need to revise the text, since that's a pretty serious >> misunderstanding. The text doesn't constrain the use of the protocols >> at all > > I think the text as written is pretty clear that there is no constraint. > >> -- in fact it says "they underlying protocols can also be used to >> support other models in which parts of the process are delegated to >> the Communications Service Provider". > > Yes, exactly correct. > >> The point of the current text is just that those scenarios aren't >> discussed in this draft, not that the overall model doesn't apply to >> those scenarios. > > Yes, exactly. The text merely clarifies what the draft discusses. > >> Randall Gellens wrote: >>> I hum for the text, which doesn't constrain the use of the >>> protocols, but merely describes the assumptions under which it >>> works. As such, it is useful and helpful. Even for those who think >>> the assumptions are obvious, it does no harm to state them. >>> >>> We had a lot of debate on this in SFO, and the text in this version >>> was discussed on the mailing list in the days during and following >>> the meeting. > From bernard_aboba@hotmail.com Tue Apr 28 11:54:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B3D3A70D5 for ; Tue, 28 Apr 2009 11:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKQynZNUQLTn for ; Tue, 28 Apr 2009 11:54:27 -0700 (PDT) Received: from blu0-omc4-s10.blu0.hotmail.com (blu0-omc4-s10.blu0.hotmail.com [65.55.111.149]) by core3.amsl.com (Postfix) with ESMTP id C34BA3A6970 for ; Tue, 28 Apr 2009 11:54:26 -0700 (PDT) Received: from BLU137-W27 ([65.55.111.135]) by blu0-omc4-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 11:55:48 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_57f722d7-6440-4801-94a9-58ac45b10423_" X-Originating-IP: [131.107.0.112] From: Bernard Aboba To: Date: Tue, 28 Apr 2009 11:55:48 -0700 Importance: Normal In-Reply-To: <49F74082.2080804@bbn.com> References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Apr 2009 18:55:48.0413 (UTC) FILETIME=[F19A96D0:01C9C832] Cc: ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:54:28 -0000 --_57f722d7-6440-4801-94a9-58ac45b10423_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > So one should not draw from the additional text in the latest draft that= =20 > there are assumptions underlying the solution in this document that=20 > would prevent its applicability in some IP networks. If that's how it=20 > is being interpreted=2C then we need to revise it again. In the consensus call=2C the paragraph in question was described as an "app= licability statement". If you are saying that the intent of the paragraph= was not to provide an indication of the applicability of the solution desc= ribed in the document=2C then we have an issue that cannot be solved merely= by revising the text. Rather=2C we need to figure out what the purpose o= f the statement is=2C and what problem it is trying to solve. RFC 2026 Sec= tion 3.2 describes the purpose of applicability statements as follows: 3.2 Applicability Statement (AS) An Applicability Statement specifies how=2C and under what circumstances=2C one or more TSs may be applied to support a particular Internet capability. An AS may specify uses for TSs that are not Internet Standards=2C as discussed in Section 7. An AS identifies the relevant TSs and the specific way in which they are to be combined=2C and may also specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented. An AS also specifies the circumstances in which the use of a particular TS is required=2C recommended=2C or elective (see sectio= n 3.3). An AS may describe particular methods of using a TS in a restricted "domain of applicability"=2C such as Internet routers=2C terminal servers=2C Internet systems that interface to Ethernets=2C or datagram- based database servers. The broadest type of AS is a comprehensive conformance specification=2C commonly called a "requirements document"=2C for a particular class of Internet systems=2C such as Internet routers or Internet hosts. --_57f722d7-6440-4801-94a9-58ac45b10423_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B So one should not draw from the additional text in the latest draft = that
>=3B there are assumptions underlying the solution in this docum= ent that
>=3B would prevent its applicability in some IP networks. I= f that's how it
>=3B is being interpreted=2C then we need to revise i= t again.

In the consensus call=2C the paragraph in question was desc= ribed as an "applicability statement". =3B =3B If you are saying th= at the intent of the paragraph was not to provide an indication of the appl= icability of the solution described in the document=2C then we have an issu= e that cannot be solved merely by revising the text. =3B =3B Rather= =2C we need to figure out what the purpose of the statement is=2C and what = problem it is trying to solve. =3B RFC 2026 Section 3.2 describes the p= urpose of applicability statements as follows:
3.2  Applicability S=
tatement (AS)

   An Applicability Statement specifies how=2C and und=
er what
   circumstances=2C one or more TSs may be applied to support a =
particular
   Internet capability.  An AS may specify uses for TSs that =
are not
   Internet Standards=2C as discussed in Section 7.

   An=
 AS identifies the relevant TSs and the specific way in which they
   ar=
e to be combined=2C and may also specify particular values or ranges
   =
of TS parameters or subfunctions of a TS protocol that must be
   implem=
ented.  An AS also specifies the circumstances in which the use
   of a =
particular TS is required=2C recommended=2C or elective (see section
   =
3.3).

   An AS may describe particular methods of using a TS in a re=
stricted
   "domain of applicability"=2C such as Internet routers=2C ter=
minal
   servers=2C Internet systems that interface to Ethernets=2C or d=
atagram-
   based database servers.

   The broadest type of AS is=
 a comprehensive conformance specification=2C
   commonly called a "requ=
irements document"=2C for a particular class of
   Internet systems=2C s=
uch as Internet routers or Internet hosts.

= --_57f722d7-6440-4801-94a9-58ac45b10423_-- From rbarnes@bbn.com Tue Apr 28 12:24:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576963A6C20 for ; Tue, 28 Apr 2009 12:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRwOChCM3ybf for ; Tue, 28 Apr 2009 12:24:37 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 651A73A6BFB for ; Tue, 28 Apr 2009 12:24:37 -0700 (PDT) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LyswI-0006vS-AL; Tue, 28 Apr 2009 15:25:58 -0400 Message-ID: <49F75845.7070904@bbn.com> Date: Tue, 28 Apr 2009 15:25:57 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Bernard Aboba References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 19:24:38 -0000 If the proposal is for an Applicability Statement in the sense of RFC 2026, then I certainly vote against the proposition, for the reasons listed in the prior email. Not to speak for the chairs, but my impression is that the intent was not to take such a limited definition, but rather to discuss adding some text to address concerns that had been raised. Could the chairs clarify? --Richard Bernard Aboba wrote: >> So one should not draw from the additional text in the latest draft that >> there are assumptions underlying the solution in this document that >> would prevent its applicability in some IP networks. If that's how it >> is being interpreted, then we need to revise it again. > > In the consensus call, the paragraph in question was described as an "applicability statement". If you are saying that the intent of the paragraph was not to provide an indication of the applicability of the solution described in the document, then we have an issue that cannot be solved merely by revising the text. Rather, we need to figure out what the purpose of the statement is, and what problem it is trying to solve. RFC 2026 Section 3.2 describes the purpose of applicability statements as follows: > 3.2 Applicability Statement (AS) > > An Applicability Statement specifies how, and under what > circumstances, one or more TSs may be applied to support a particular > Internet capability. An AS may specify uses for TSs that are not > Internet Standards, as discussed in Section 7. > > An AS identifies the relevant TSs and the specific way in which they > are to be combined, and may also specify particular values or ranges > of TS parameters or subfunctions of a TS protocol that must be > implemented. An AS also specifies the circumstances in which the use > of a particular TS is required, recommended, or elective (see section > 3.3). > > An AS may describe particular methods of using a TS in a restricted > "domain of applicability", such as Internet routers, terminal > servers, Internet systems that interface to Ethernets, or datagram- > based database servers. > > The broadest type of AS is a comprehensive conformance specification, > commonly called a "requirements document", for a particular class of > Internet systems, such as Internet routers or Internet hosts. > > From hgs@cs.columbia.edu Tue Apr 28 12:32:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFBD3A6B9F for ; Tue, 28 Apr 2009 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU81r5EloUfY for ; Tue, 28 Apr 2009 12:32:00 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id BC51D3A6C33 for ; Tue, 28 Apr 2009 12:32:00 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n3SJXJgL028659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2009 15:33:20 -0400 (EDT) Message-Id: <9B44328B-07EE-4C48-95BD-01913848B6C6@cs.columbia.edu> From: Henning Schulzrinne To: Richard Barnes In-Reply-To: <49F75845.7070904@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 15:33:19 -0400 References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> <49F75845.7070904@bbn.com> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 19:32:01 -0000 But the concerns were concerns about applicability, so this is an applicability statement, regardless of what labels get attached to the text to cover up this fact. It is clear that the text is not necessary to implement the goals of the draft and it does not fix any technical problems or clarify any of the issues addressed in the document. So this is clearly meant to be lawyer-text of some form. Maybe we should leave writing of such text to lawyers... Henning On Apr 28, 2009, at 3:25 PM, Richard Barnes wrote: > If the proposal is for an Applicability Statement in the sense of > RFC 2026, then I certainly vote against the proposition, for the > reasons listed in the prior email. > > Not to speak for the chairs, but my impression is that the intent > was not to take such a limited definition, but rather to discuss > adding some text to address concerns that had been raised. > > Could the chairs clarify? > > --Richard > From rbarnes@bbn.com Tue Apr 28 13:05:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A013A7128 for ; Tue, 28 Apr 2009 13:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHrFxgpzb6Oe for ; Tue, 28 Apr 2009 13:05:22 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B30773A6B5D for ; Tue, 28 Apr 2009 13:05:22 -0700 (PDT) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LytZd-0007Ze-AK; Tue, 28 Apr 2009 16:06:37 -0400 Message-ID: <49F761CC.3090902@bbn.com> Date: Tue, 28 Apr 2009 16:06:36 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Edge, Stephen" References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217A BE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Gellens, Randall" , ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 20:05:23 -0000 Stephen, As was noted in the meeting, it is *always* possible that there are alternative solutions out there when you're talking about the Internet. TCP vs. UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs. XMPP, SASL vs. TLS, S/MIME vs. OpenPGP. None of the many RFCs out there have explicit statements that somebody else might do it differently because it's obvious that they can. So I don't really think conveying the possibility of other implementations is actually useful at all, technically speaking. That means that the only real purpose of such a statement is rhetorical, and as we've seen in a few messages here, some people misconstrue the rhetoric to mean that this system has constrained applicability. Given that, I'd rather leave it off unless we can avoid that impression. --Richard Edge, Stephen wrote: > All > > I would have thought that motivation should be irrelevant. There are a lot of motives at work here. Should we assume that the document was originally written with only the purest and most altruistic motives (e.g. no thought of business or academic interest at stake)? > > The issue is whether the current statement serves a useful purpose in conveying the possibility (well known to be true) of alternative solutions not fully aligned with the current drafts. Nothing in the statement implies that the current drafts are necessarily deficient or that alternative solutions must necessarily be used for some scenarios (even though they optionally can be). > > Kind Regards > > Stephen > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens > Sent: Tuesday, April 28, 2009 9:57 AM > To: Henning Schulzrinne; Stark, Barbara > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP > > At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote: > >> It is clear that the text has ulterior motives to restrict the >> applicability of the document. > > From my view, the text does not restrict the applicability, nor is > there a desire to do so. The text does clarify the assumptions of > the rest of the text in the document, which I think is helpful. > From randy@qualcomm.com Tue Apr 28 14:10:35 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5D33A6D00 for ; Tue, 28 Apr 2009 14:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.876 X-Spam-Level: X-Spam-Status: No, score=-104.876 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lOcP4mQEOBp for ; Tue, 28 Apr 2009 14:10:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A1E823A6C21 for ; Tue, 28 Apr 2009 14:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1240953116; x=1272489116; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20|References:=20=09<49F27637 .7050201@bbn.com>=0D=0A=20=0D=0A=20<058701c9c5d0$53c5e f40$fb51cdc0$@net>=0D=0A=20=0D=0A=20<28B7C3AA2A7ABA4A8 41F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-=0D =0A=20lucent.com>=09=0D=0A=20<49F6891E.7080706@bbn.com>=20=20=0D=0A=20<49F74082.2080804@bbn.c om>=0D=0A=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-Note: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Tue,=2028=20Apr=20 2009=2014:08:44=20-0700|To:=20Bernard=20Aboba=20,=20|From:=20Randall =20Gellens=20|Subject:=20Re:=20[Ecrit ]=20PhoneBCP|CC:=20|MIME-Version:=201.0 |Content-Type:=20text/html=3B=20charset=3D"us-ascii" |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5599"=3B=20a=3D"17562993"; bh=vEYl/a7yRgqtwl3EL6RNp8hV11VqTdjrH9q+dfawrWM=; b=YXDc/FX00LNxbOyDGpqQ2Abo3MALLJpJCK3RA0a34Ii0rzKzT+6JDsLP e0Y5Ez/QWihT8L4Glk/LGf6Iw55eV6AlWVmDxV0G2Plm69Ik4bvkViDem RsIMuE1dJFAJDir+wLE2PTxpPJ6K0W9ocoYLyMIK7H8QxK7KDA2Domj6J 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5599"; a="17562993" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2009 14:11:54 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3SLBrMT019242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 14:11:54 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3SLBnHS002080 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Apr 2009 14:11:49 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 14:11:49 -0700 Received: from [172.28.171.53] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Apr 2009 14:11:48 -0700 Message-ID: In-Reply-To: References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 28 Apr 2009 14:08:44 -0700 To: Bernard Aboba , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 Cc: ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 21:10:35 -0000 Re: [Ecrit] PhoneBCP
At 11:55 AM -0700 4/28/09, Bernard Aboba wrote:

Rather, we need to figure out what the purpose of the statement is, and what problem it is trying to solve.

The phonebcp and framework documents are unusual in that they make very broad claims to cover all emergency calls over IP.  Since there are other mechanisms that are likely to be used in some environments,  it's important to clarify that while these documents describe a solution they do not describe these other environments nor interoperbility with solutions used in those environments.

Per the definition of an applicability statement, all of phonebcp can be considered to be one.

 RFC 2026 Section 3.2 describes the purpose of applicability statements as follows:
3.2  Applicability Statement (AS)

   An Applicability Statement specifies how, and under what
   circumstances, one or more TSs may be applied to support a particular
   Internet capability.  An AS may specify uses for TSs that are not
   Internet Standards, as discussed in Section 7.

   An AS identifies the relevant TSs and the specific way in which they
   are to be combined, and may also specify particular values or ranges
   of TS parameters or subfunctions of a TS protocol that must be
   implemented.  An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective (see section
   3.3).


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Television is simply automated day-dreaming.
      --Lee Lovinger, _Quote_, July 30, 1967
From rbarnes@bbn.com Tue Apr 28 14:50:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADC428C10B for ; Tue, 28 Apr 2009 14:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIEM5ql8tiXI for ; Tue, 28 Apr 2009 14:50:00 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7E4F028C0CE for ; Tue, 28 Apr 2009 14:50:00 -0700 (PDT) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LyvCy-0000mL-AW; Tue, 28 Apr 2009 17:51:20 -0400 Message-ID: <49F77A57.2040205@bbn.com> Date: Tue, 28 Apr 2009 17:51:19 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Randall Gellens References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 21:50:01 -0000 > The phonebcp and framework documents are unusual in that they make very broad > claims to cover all emergency calls over IP. I don't think that's true. From the Abstract and Introduction: " The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. ... This document focuses on how devices using the Internet can place emergency calls and how PSAPs can handle Internet multimedia emergency calls natively. " Note the use of the word "can" (and we can switch the "are" in the abstract to "can" if that makes things better). Could you provide a pointer to the text that leads you to a different interpretation? > Per the definition of an applicability statement, all of phonebcp can be > considered to be one. Technically speaking, that seems to be accurate, but irrelevant to the current discussion. --Richard > >> RFC 2026 Section 3.2 describes the purpose of applicability statements as >> follows: >> 3.2 Applicability Statement (AS) >> >> An Applicability Statement specifies how, and under what >> circumstances, one or more TSs may be applied to support a particular >> Internet capability. An AS may specify uses for TSs that are not >> Internet Standards, as discussed in Section 7. >> >> An AS identifies the relevant TSs and the specific way in which they >> are to be combined, and may also specify particular values or ranges >> of TS parameters or subfunctions of a TS protocol that must be >> implemented. An AS also specifies the circumstances in which the use >> of a particular TS is required, recommended, or elective (see section >> 3.3). > > > -- > > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Television is simply automated day-dreaming. > --Lee Lovinger, _Quote_, July 30, 1967 From randy@qualcomm.com Tue Apr 28 17:11:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E813A6876 for ; Tue, 28 Apr 2009 17:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.627 X-Spam-Level: X-Spam-Status: No, score=-103.627 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ8IvLyxH1P8 for ; Tue, 28 Apr 2009 17:11:37 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 49C4E3A6781 for ; Tue, 28 Apr 2009 17:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1240963979; x=1272499979; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<49F74082.2080804@bbn.com>|References:=20 =09<49F27637.7050201@bbn.com> =0D=0A=20=0D=0A=20<058701c9c5d0$53c5ef40$fb51cdc0$@net >=0D=0A=20=0D=0A=20<28B7C3AA2A7ABA4A841F11217ABE78D675 90BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-=0D=0A=20lucent.com> =09=0D=0A=20<49F68 91E.7080706@bbn.com>=20=0D=0A=20<49F74082.2080804@bbn.com>|X-Mailer:=20Eudo ra=20for=20Mac=20OS=20X|X-message-Note:=20Warning:=20Outl ook=20in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Tue,=2028=20Apr=202009=2017:12:53=20 -0700|To:=20Richard=20Barnes=20|From:=20 Randall=20Gellens=20|Subject:=20Re: =20[Ecrit]=20PhoneBCP|CC:=20ECRIT=20 |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,55 99"=3B=20a=3D"17562329"; bh=tmXjeP2j0AZlHnG68J59Tt8/yVhS4d4AmcO0WIT+ZYY=; b=tWalBzmT0Frk1uMIRMYfU7nX1VXUHs3jBUlu5a3wP7rcCio5TKIgKnw0 UE+OrkrD+HYnjLNjt/aaVF2EktT5OlV0+EeOqvUj1tp23pG05uzlCQIuT RStIVYyrCiNrCjuLBzxJ6JeHGLd9UqyhDoaM42st8Bn9AD1HE6ZUmsHDP U=; X-IronPort-AV: E=McAfee;i="5300,2777,5599"; a="17562329" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2009 17:12:59 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3T0CwOW009431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 17:12:59 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3T0CujF031461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Apr 2009 17:12:58 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Apr 2009 17:12:56 -0700 Received: from [172.28.171.53] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Apr 2009 17:12:55 -0700 Message-ID: In-Reply-To: <49F74082.2080804@bbn.com> References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 28 Apr 2009 17:12:53 -0700 To: Richard Barnes From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 00:11:38 -0000 At 1:44 PM -0400 4/28/09, Richard Barnes wrote: > So one should not draw from the additional text in the latest draft > that there are assumptions underlying the solution in this document > that would prevent its applicability in some IP networks. If > that's how it is being interpreted, then we need to revise it again. I don't think anyone who wants this text included is interpreting it to say anything about whether the solution could be used in any particular environment. There is a separate discussion regarding whether the solution as written makes sense for cell phone environments, for example the mobile-centric aspects such as determining location and routes and the requirement for handsets to support protocols that are not used in their environments, but that's an unrelated discussion and the text clearly says nothing about this. The text is a compromise that clarifies the documents without in any way limiting them. I think the text helps the understanding of readers of the documents who have not been immersed in the protocols for the past few years. I can't see how the text will help or hurt anyone's marketing efforts, so I think that is a red herring. Are there really people who think that this clarifying text will impede their ability to market some product? Or that some standards body would adopt this solution wholeheartedly if only this clarifying text is deleted? Neither idea seems plausible to me. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Time is nature's way of making sure that everything doesn't happen on schedule. From Martin.Thomson@andrew.com Tue Apr 28 17:39:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F5B3A6B5D for ; Tue, 28 Apr 2009 17:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTChssd7eaws for ; Tue, 28 Apr 2009 17:39:15 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3BB853A67B4 for ; Tue, 28 Apr 2009 17:39:15 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_28_20_01_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 28 Apr 2009 20:01:23 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 19:40:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 28 Apr 2009 19:40:33 -0500 Message-ID: In-Reply-To: <49F71677.2070007@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 Thread-Index: AcnID/JwyyPvpi9+SQ27T7D4LEHtXAAUxphg References: <49F71677.2070007@bbn.com> From: "Thomson, Martin" To: "Richard Barnes" , "Marc Linsner" X-OriginalArrivalTime: 29 Apr 2009 00:40:36.0405 (UTC) FILETIME=[1C9BA650:01C9C863] Cc: ECRIT Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 00:39:16 -0000 V2hhdCBSaWNoYXJkIHNhaWQuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZiBSaWNoYXJkIEJhcm5lcw0KPiBTZW50OiBXZWRuZXNkYXksIDI5IEFw cmlsIDIwMDkgMTI6NDUgQU0NCj4gVG86IE1hcmMgTGluc25lcg0KPiBDYzogRUNSSVQNCj4gU3Vi amVjdDogUmU6IFtFY3JpdF0gZHJhZnQtd29sZi1lY3JpdC1sb3N0LXNlcnZpY2VsaXN0Ym91bmRh cnktMDENCj4gDQo+IEkgdGhpbmsgdGhpcyBkb2N1bWVudCBpcyB1c2VmdWwuICBJdCBmaWxscyBh IGdhcCBpbiB0aGUgbG9naWNhbA0KPiBzdHJ1Y3R1cmUgb2YgTG9TVCwgYW5kIGVuYWJsZXMgYSBt b3JlIGNvbXBsZXRlLCBhdXRvbWF0aWMgY2xpZW50DQo+IHByb2Nlc3NpbmcgbW9kZWwuDQo+IA0K PiAtLVJpY2hhcmQNCj4gDQo+IA0KPiANCj4gTWFyYyBMaW5zbmVyIHdyb3RlOg0KPiA+IEFsbCwN Cj4gPg0KPiA+IFBsZWFzZSByZXZpZXcgdGhpcyBkcmFmdCB0byBhbmQgcmVzcG9uZCBieSBGcmlk YXkgTWF5IDEgaWYgeW91IGZpbmQNCj4gdGhpcw0KPiA+IHZhbHVhYmxlIGZvciBFQ1JJVCB0byB3 b3JrIG9uLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+DQo+ID4gLU1hcmMtDQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0NCj4gPg0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRWNyaXQgbWFpbGluZyBs aXN0DQo+ID4gRWNyaXRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWdu YXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0 YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBl bWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpbbWYyXQ0K From Gabor.Bajko@nokia.com Tue Apr 28 18:41:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628303A6D00 for ; Tue, 28 Apr 2009 18:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du2TvAA7+MS3 for ; Tue, 28 Apr 2009 18:41:11 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D4BD43A6C7E for ; Tue, 28 Apr 2009 18:40:49 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3T1fiqX025629; Wed, 29 Apr 2009 04:41:56 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 04:41:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 04:41:44 +0300 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 29 Apr 2009 03:41:43 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Wed, 29 Apr 2009 03:41:43 +0200 From: To: , Date: Wed, 29 Apr 2009 03:41:42 +0200 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIS4DvKz/xAAGzQrGHPZ+5jX3pvgAGVM3w Message-ID: References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> <49F77A57.2040205@bbn.com> In-Reply-To: <49F77A57.2040205@bbn.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-OriginalArrivalTime: 29 Apr 2009 01:41:44.0949 (UTC) FILETIME=[A73B0A50:01C9C86B] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 01:41:12 -0000 Hi Richard, >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Richard Barnes >Sent: Tuesday, April 28, 2009 2:51 PM >To: Randall Gellens >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] PhoneBCP > >> The phonebcp and framework documents are unusual in that they make=20 >> very broad claims to cover all emergency calls over IP. > >I don't think that's true. From the Abstract and Introduction: >" >The IETF has standardized various aspects of placing=20 >emergency calls.=20 >This document describes how all of those component parts are=20 >used to support emergency calls from citizens and visitors=20 >to authorities. >... >This document focuses on how devices using the Internet can=20 >place emergency calls and how PSAPs can handle Internet=20 >multimedia emergency calls natively. >" Which version did you quote from? The Abstract of version -09 says:=20 "The IETF and other standards organization have efforts targeted at standar= dizing various aspects of placing emergency calls on IP networks. This mem= o describes best current ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^ practice on how devices, networks and services should use such st= andards to make emergency=20 ^^^^^^^^^^^^^^^^^^^^^^^ calls." And I think here's the problem, as the text is too generic. IMS is also an = "IP network" and has different "best current practices". I think all these differences could be resolved if the Intended Status of t= he document would be changed to Proposed Standard (instead of BCP), its tit= le to "Requirements for Internet based Emergency Calls" and the Abstract to= "The IETF efforts are targeted at standardizing various aspects of placing emergency calls over the Intern= et. This memo describes requirements for devices, networks and services th= at should be supported in order to make emergency calls over the Internet". The above minimal changes should be enough to differentiate the scope of th= is document from the 3GPP solution, as 3GPP calls their solution "IMS Emerg= ency Sessions", thus there would not be a need for the controversial applic= ability statement. - Gabor >Note the use of the word "can" (and we can switch the "are"=20 >in the abstract to "can" if that makes things better). =20 >Could you provide a pointer to the text that leads you to a=20 >different interpretation? > >> Per the definition of an applicability statement, all of=20 >phonebcp can=20 >> be considered to be one. > >Technically speaking, that seems to be accurate, but=20 >irrelevant to the current discussion. > >--Richard > > > > > >>=20 >>> RFC 2026 Section 3.2 describes the purpose of applicability=20 >>> statements as >>> follows: >>> 3.2 Applicability Statement (AS) >>> >>> An Applicability Statement specifies how, and under what >>> circumstances, one or more TSs may be applied to=20 >support a particular >>> Internet capability. An AS may specify uses for TSs=20 >that are not >>> Internet Standards, as discussed in Section 7. >>> >>> An AS identifies the relevant TSs and the specific way=20 >in which they >>> are to be combined, and may also specify particular=20 >values or ranges >>> of TS parameters or subfunctions of a TS protocol that must be >>> implemented. An AS also specifies the circumstances=20 >in which the use >>> of a particular TS is required, recommended, or=20 >elective (see section >>> 3.3). >>=20 >>=20 >> -- >>=20 >> Randall Gellens >> Opinions are personal; facts are suspect; I speak=20 >for myself only >> -------------- Randomly selected tag: ---------------=20 >Television is=20 >> simply automated day-dreaming. >> --Lee Lovinger, _Quote_, July 30, 1967 >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit >= From bernard_aboba@hotmail.com Tue Apr 28 19:30:37 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D1B3A6774 for ; Tue, 28 Apr 2009 19:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsJzCxu2iv9G for ; Tue, 28 Apr 2009 19:30:36 -0700 (PDT) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by core3.amsl.com (Postfix) with ESMTP id DE4D33A6C12 for ; Tue, 28 Apr 2009 19:30:35 -0700 (PDT) Received: from BLU137-W9 ([65.55.111.72]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 19:31:57 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_766509c7-c942-41a7-88f8-77d168f65240_" X-Originating-IP: [131.107.0.103] From: Bernard Aboba To: Date: Tue, 28 Apr 2009 19:31:57 -0700 Importance: Normal In-Reply-To: References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2009 02:31:57.0988 (UTC) FILETIME=[AB244E40:01C9C872] Cc: ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 02:30:37 -0000 --_766509c7-c942-41a7-88f8-77d168f65240_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Per the definition of an applicability statement=2C all of phonebcp can be= considered to be one. =20 I think that is correct with respect to the "how" -- the document is all ab= out how TSs may be applied.=20 =20 I'm not so sure about the "under what circumstances" part of it=2C though. = That seems to be the point under discussion. =20 =20 BTW=2C it is not only the cellular community that may have a point of view = on that issue. IEEE 802 has recently debated an Emergency Services PAR (se= e http://www.ieee802.org/21/email21/msg02957.html) that has been somewhat c= ontroversial. =20 =20 3.2 Applicability Statement (AS) An Applicability Statement specifies how=2C and under what circumstances=2C one or more TSs may be applied to support a particular Internet capability. An AS may specify uses for TSs that are not Internet Standards=2C as discussed in Section 7. An AS identifies the relevant TSs and the specific way in which they are to be combined=2C and may also specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented. An AS also specifies the circumstances in which the use of a particular TS is required=2C recommended=2C or elective (see sectio= n 3.3). = --_766509c7-c942-41a7-88f8-77d168f65240_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3BPer the definition of an applicability statement=2C all of phonebcp c= an be considered to be one.
 =3B
I think that is correct with respect to the "how" -- the document is all ab= out how TSs =3Bmay be =3Bapplied.
 =3B
I'm not so sure about the "under what circumstances" part of it=2C though.&= nbsp=3B That seems to be the point under discussion. =3B
 =3B
BTW=2C =3Bit is not only the cellular community that may have a point o= f view on that issue. =3B IEEE 802 has recently =3Bdebated an Emerg= ency Services PAR (see http://www.ieee802.org/21/email21/msg02957.html) that has been = somewhat controversial. =3B
 =3B
3.2 =3B Applicability Statement (AS)

 =3B&nb= sp=3B An Applicability Statement specifies how=2C and under what
 = =3B =3B circumstances=2C one or more TSs may be applied to support a pa= rticular
 =3B =3B Internet capability. =3B An AS may specify= uses for TSs that are not
 =3B =3B Internet Standards=2C as dis= cussed in Section 7.

 =3B =3B An AS identifies the relevant = TSs and the specific way in which they
 =3B =3B are to be combin= ed=2C and may also specify particular values or ranges
 =3B =3B = of TS parameters or subfunctions of a TS protocol that must be
 =3B&= nbsp=3B implemented. =3B An AS also specifies the circumstances in whic= h the use
 =3B =3B of a particular TS is required=2C recommended= =2C or elective (see section
 =3B =3B 3.3).

 =3B
= --_766509c7-c942-41a7-88f8-77d168f65240_-- From Hannes.Tschofenig@gmx.net Wed Apr 29 01:22:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4973A681E for ; Wed, 29 Apr 2009 01:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssTM1v9s-XAC for ; Wed, 29 Apr 2009 01:22:01 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5F8213A6A63 for ; Wed, 29 Apr 2009 01:22:00 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2009 08:23:21 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp003) with SMTP; 29 Apr 2009 10:23:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18cg9dZbD8cr28XbSSYy6OTramNJ27FOQ9gRLe+vL JPCZ5fdjR5x6WT From: "Hannes Tschofenig" To: "'ECRIT'" Date: Wed, 29 Apr 2009 11:24:28 +0300 Message-ID: <001b01c9c8a3$fabb8eb0$3d49a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnIGwO25rFBha6sQAGFr5ebF5c83w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Subject: [Ecrit] Location Validation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 08:22:02 -0000 Hi all, There was an interesting today in the NENA ECRF LVF Working Group phone conference all about location validation and the definition of it. Looking at http://www.ietf.org/rfc/rfc5012.txt the definition of the term location is: Location validation: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference system (e.g., United States Postal Address or the WGS-84 datum) and can be mapped to one or more PSAPs. While it is desirable to determine that a location exists, validation may not ensure that such a location exists, but rather may only ensure that the location falls within some range of known values. Location validation ensures that a location is able to be referenced for mapping, but makes no assumption about the association between the caller and the caller's location. This definition is useful for geo- and civic location information. The LoST specification, see Section 8.4.2 of http://www.ietf.org/rfc/rfc5222.txt, does more than just fulfilling the check whether an address maps to a PSAP URI. We provided this functionality in response to the interaction we had with NENA. LoST determines whether there is an civic address in an address database that corresponds to the civic address provided in the request (using the , and elements). In the conf. call then the differentiation between 'location validation for routing' and location validation for dispatch' was made. The former would match the definition in RFC 5012 while the latter is more related to the question whether a particular civic address exists so that dispatched first responders can actually go there. Do we need to need to clarify or enhance our definition of location validation? Ciao Hannes From Ray.Bellis@nominet.org.uk Wed Apr 29 03:11:53 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B298B28C122; Wed, 29 Apr 2009 03:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frxCIo+79aZD; Wed, 29 Apr 2009 03:11:52 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 55C1C3A6D2B; Wed, 29 Apr 2009 03:11:12 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=s4GOT8VRBb9id3ZvljG+q8VNuXwi1O/AWqTn10LKy9wI0/bXlOugZ5L+ gSIxa1c4far0kyI8T9oee7wBHw1sJ79NdCUjavZAjIMbzzMLi28g7onT2 0DnavwX7oN50TIY; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1240999956; x=1272535956; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20PhoneBCP|Date:=20Wed,=2029=20Apr=202009=2011:12:31 =20+0100|Message-ID:=20|To:=20Richard=20 Barnes=20|Cc:=20ecrit@ietf.org,=0D=0A=09 ecrit-bounces@ietf.org|MIME-Version:=201.0|In-Reply-To: =20<49F77A57.2040205@bbn.com>|References:=20=0D=0A=09<49F27637.7050201@bbn.com>=09=0D=0A=09 <058701c9c5d0$53c5ef40$fb51cdc0$@net>=09=0D=0A=09<28B7 C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m. alcatel-=0D=0A=09lucent.com>=09=09<49F6891E.7080706@bbn.com>=20=0D=0A=09<49F74082.2080804@bbn .com>=09=09< p06240615c61d1f6977b2@[172.28.171.53]>=20<49F77A57.204020 5@bbn.com>; bh=20uESPoisJYizVgEj4aWc44+4eLq3yEV/xNmhMn2oow=; b=Wc+NESczbmjx8wAGf8XVvZzDjz2MTc/3C+ctPvAFNjnMpdGkEnJGn2Vz WyOFWJj/ALqVBLYThMtcnyUBiN7HQIIced/yQsieiCUWGI3gobL5OQWQ5 Zq3s0ce91uO5Kyy; X-IronPort-AV: E=Sophos;i="4.40,265,1238972400"; d="scan'208";a="13407324" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 29 Apr 2009 11:12:33 +0100 In-Reply-To: <49F77A57.2040205@bbn.com> References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <49F6891E.7080706@bbn.com> <49F74082.2080804@bbn.com> <49F77A57.2040205@bbn.com> To: Richard Barnes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 29 Apr 2009 11:12:31 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 29/04/2009 11:12:33 AM, Serialize complete at 29/04/2009 11:12:33 AM Content-Type: text/plain; charset="US-ASCII" Cc: ecrit@ietf.org, ecrit-bounces@ietf.org Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 10:11:53 -0000 > Richard Barnes > I don't think that's true. From the Abstract and Introduction: > " > The IETF has standardized various aspects of placing emergency calls. > This document describes how all of those component parts are used to > support emergency calls from citizens and visitors to authorities. > ... I would be much happier if this said "may be used" rather then "are used". Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From br@brianrosen.net Wed Apr 29 05:06:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF403A6B1D for ; Wed, 29 Apr 2009 05:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsrwkwmRuCny for ; Wed, 29 Apr 2009 05:06:13 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 668BB3A685E for ; Wed, 29 Apr 2009 05:06:13 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lz8ZV-000171-BA; Wed, 29 Apr 2009 07:07:29 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <001b01c9c8a3$fabb8eb0$3d49a20a@nsnintra.net> In-Reply-To: <001b01c9c8a3$fabb8eb0$3d49a20a@nsnintra.net> Date: Wed, 29 Apr 2009 08:07:31 -0400 Message-ID: <03f701c9c8c3$149ef730$3ddce590$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnIGwO25rFBha6sQAGFr5ebF5c83wApZvGQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Location Validation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 12:06:14 -0000 I'm sorry I wasn't on that call but the LoST definition is sufficient because it doesn't differentiate. Within the NENA i3 effort, we have defined valid as there is exactly one point in the LoST database that matches the fields supplied by the PIDF with sufficient accuracy to dispatch a responder. That means if you give us, for example, a street name and number, a state and a country, if it happens that there is only one street with that name in the state, and there is an address point with that street number, then the location is valid. Of course, we would prefer all of the fields to be present, but as long as we locate a single dispatchable location, it's valid. Correspondingly, if you gave every field but the street name suffix, and there were two streets within that community, neighborhood and zipcode that differed only in the suffix, then it isn't valid. The database has every valid address point, represented by a point or polygon, with attributes or polygons on other layers that define all of the required PIDF elements above the address point (postal code, municipality, .... As you can see, valid is dispatch valid. If you supplied a location that turned out to be accurate enough to determine which PSAP should get the call, then you would have a route valid location, but it would not validate in a North American LoST server. Technically, the definition says "within an acceptable location reference system", which for North America will be the LoST database map, or a geo with WGS84 datum, which has a regulatory accuracy requirement. It also says "and can be mapped to one or more PSAPs", which gets the route validity test. So, I don't think a change is needed. I do think we should consider allowing the server to return possible interesting information if a location is not valid. In North America, we will return a PIDF with all the fields if the location is valid: if you don't send in a value for a field, but the LoST server determines what you did send is valid, we return all the other fields. We would like to return some possible valid locations if the PIDF submitted is invalid ("There is no Main Ave, but we have a Main St or a North Main Ave"). Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, April 29, 2009 4:24 AM To: 'ECRIT' Subject: [Ecrit] Location Validation Hi all, There was an interesting today in the NENA ECRF LVF Working Group phone conference all about location validation and the definition of it. Looking at http://www.ietf.org/rfc/rfc5012.txt the definition of the term location is: Location validation: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference system (e.g., United States Postal Address or the WGS-84 datum) and can be mapped to one or more PSAPs. While it is desirable to determine that a location exists, validation may not ensure that such a location exists, but rather may only ensure that the location falls within some range of known values. Location validation ensures that a location is able to be referenced for mapping, but makes no assumption about the association between the caller and the caller's location. This definition is useful for geo- and civic location information. The LoST specification, see Section 8.4.2 of http://www.ietf.org/rfc/rfc5222.txt, does more than just fulfilling the check whether an address maps to a PSAP URI. We provided this functionality in response to the interaction we had with NENA. LoST determines whether there is an civic address in an address database that corresponds to the civic address provided in the request (using the , and elements). In the conf. call then the differentiation between 'location validation for routing' and location validation for dispatch' was made. The former would match the definition in RFC 5012 while the latter is more related to the question whether a particular civic address exists so that dispatched first responders can actually go there. Do we need to need to clarify or enhance our definition of location validation? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Wed Apr 29 06:04:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7CD33A6D07 for ; Wed, 29 Apr 2009 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKf5JRrEA5iR for ; Wed, 29 Apr 2009 06:04:17 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8B2433A6CFA for ; Wed, 29 Apr 2009 06:04:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,266,1238976000"; d="scan'208";a="42911331" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Apr 2009 13:05:39 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3TD5dDg029258; Wed, 29 Apr 2009 09:05:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3TD5dS2025789; Wed, 29 Apr 2009 13:05:39 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 09:05:39 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 09:05:38 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 29 Apr 2009 09:05:36 -0400 From: Marc Linsner To: Hannes Tschofenig , "'ECRIT'" Message-ID: Thread-Topic: [Ecrit] Location Validation Thread-Index: AcnIGwO25rFBha6sQAGFr5ebF5c83wAsCvsi In-Reply-To: <001b01c9c8a3$fabb8eb0$3d49a20a@nsnintra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Apr 2009 13:05:38.0793 (UTC) FILETIME=[314EBD90:01C9C8CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2837; t=1241010339; x=1241874339; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20Validation |Sender:=20 |To:=20Hannes=20Tschofenig=20,=2 0=22'ECRIT'=22=20; bh=daUwiOOHcN6gQR5guOS33wwLSvK4bEt6trbxIM0p1Po=; b=LwBKvQ5V76a/wfaOmpK8aT3dlIYlfSeakO5XfwsRKFYkYF/zCHoxZSwgMF 6b/qFija8rXY/T4/L2+B+xVzPETa02zWc05c2Br3ZnDeWmGBpFOy8cIIl4Hv 2p3neNDNwb; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] Location Validation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:04:18 -0000 Hannes, We had discussions around this topic 'way back when'. I agree with Brian, we don't need to change anything. We designed the support of validation within LoST to return any/all tags that were found to be 'in the database'. If in fact a tag is found valid but not suitable for dispatch, it's a database problem. Concerned parties should pay close attention to this LoST feature and how the database is constructed. If a tag is found to be not valid, then it's up to the provider/source of the location determination to fix it. Obviously the protocol can't nor shouldn't try to force such a 'fix'. -Marc- On 4/29/09 4:24 AM, "Hannes Tschofenig" wrote: > Hi all, > > There was an interesting today in the NENA ECRF LVF Working Group phone > conference all about location validation and the definition of it. > > Looking at http://www.ietf.org/rfc/rfc5012.txt the definition of the term > location is: > > Location validation: A caller location is considered valid if the > civic or geographic location is recognizable within an acceptable > location reference system (e.g., United States Postal Address or > the WGS-84 datum) and can be mapped to one or more PSAPs. While > it is desirable to determine that a location exists, validation > may not ensure that such a location exists, but rather may only > ensure that the location falls within some range of known values. > Location validation ensures that a location is able to be > referenced for mapping, but makes no assumption about the > association between the caller and the caller's location. > > This definition is useful for geo- and civic location information. > > The LoST specification, see Section 8.4.2 of > http://www.ietf.org/rfc/rfc5222.txt, does more than just fulfilling the > check whether an address maps to a PSAP URI. We provided this functionality > in response to the interaction we had with NENA. > > LoST determines whether there is an civic address in an address database > that corresponds to the civic address provided in the request (using the > , and elements). > > In the conf. call then the differentiation between 'location validation for > routing' and location validation for dispatch' was made. The former would > match the definition in RFC 5012 while the latter is more related to the > question whether a particular civic address exists so that dispatched first > responders can actually go there. > > Do we need to need to clarify or enhance our definition of location > validation? > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Wed Apr 29 06:09:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D9A3A6DF7 for ; Wed, 29 Apr 2009 06:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.619 X-Spam-Level: X-Spam-Status: No, score=-3.619 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BzgLDUzH442 for ; Wed, 29 Apr 2009 06:09:11 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4C4B73A6D91 for ; Wed, 29 Apr 2009 06:09:10 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3TDA1h6014923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 15:10:01 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3TDA1Ja030820; Wed, 29 Apr 2009 15:10:01 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 15:10:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 16:11:34 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45015007AF@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Validation Thread-Index: AcnIGwO25rFBha6sQAGFr5ebF5c83wAsCvsiAAAZT4A= References: <001b01c9c8a3$fabb8eb0$3d49a20a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Marc Linsner" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 29 Apr 2009 13:10:01.0194 (UTC) FILETIME=[CDB5F4A0:01C9C8CB] Subject: Re: [Ecrit] Location Validation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:09:12 -0000 Hi Brian, Hi Marc,=20 The problem is that the definition in RFC 5012 does not correspond to the usage of the term in LoST. The same term 'validation' means different things in these two documents. =20 The definition used in the NENA i3 document does not seem to correspond to RFC 5012 either.=20 The source of the confusion is the lack of differentiation between validation for routing and validation for dispatch.=20 I am not saying that any of the protocol mechanisms should be changed.=20 Ciao Hannes =20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Marc Linsner >Sent: 29 April, 2009 16:06 >To: Hannes Tschofenig; 'ECRIT' >Subject: Re: [Ecrit] Location Validation > >Hannes, > >We had discussions around this topic 'way back when'. I agree=20 >with Brian, we don't need to change anything. We designed the=20 >support of validation within LoST to return any/all tags that=20 >were found to be 'in the database'. >If in fact a tag is found valid but not suitable for dispatch,=20 >it's a database problem. Concerned parties should pay close=20 >attention to this LoST feature and how the database is=20 >constructed. If a tag is found to be not valid, then it's up=20 >to the provider/source of the location determination to fix=20 >it. Obviously the protocol can't nor shouldn't try to force=20 >such a 'fix'. > >-Marc- > > >On 4/29/09 4:24 AM, "Hannes Tschofenig"=20 > wrote: > >> Hi all, >>=20 >> There was an interesting today in the NENA ECRF LVF Working Group=20 >> phone conference all about location validation and the=20 >definition of it. >>=20 >> Looking at http://www.ietf.org/rfc/rfc5012.txt the definition of the=20 >> term location is: >>=20 >> Location validation: A caller location is considered valid if the >> civic or geographic location is recognizable within an=20 >acceptable >> location reference system (e.g., United States Postal=20 >Address or >> the WGS-84 datum) and can be mapped to one or more=20 >PSAPs. While >> it is desirable to determine that a location exists, validation >> may not ensure that such a location exists, but rather may only >> ensure that the location falls within some range of=20 >known values. >> Location validation ensures that a location is able to be >> referenced for mapping, but makes no assumption about the >> association between the caller and the caller's location. >>=20 >> This definition is useful for geo- and civic location information. >>=20 >> The LoST specification, see Section 8.4.2 of=20 >> http://www.ietf.org/rfc/rfc5222.txt, does more than just fulfilling=20 >> the check whether an address maps to a PSAP URI. We provided this=20 >> functionality in response to the interaction we had with NENA. >>=20 >> LoST determines whether there is an civic address in an address=20 >> database that corresponds to the civic address provided in=20 >the request=20 >> (using the , and elements). >>=20 >> In the conf. call then the differentiation between 'location=20 >> validation for routing' and location validation for dispatch' was=20 >> made. The former would match the definition in RFC 5012 while the=20 >> latter is more related to the question whether a particular civic=20 >> address exists so that dispatched first responders can=20 >actually go there. >>=20 >> Do we need to need to clarify or enhance our definition of location=20 >> validation? >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From MBerryman@911.org Wed Apr 29 06:11:31 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CE43A6EF8 for ; Wed, 29 Apr 2009 06:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q2YgGsMobVX for ; Wed, 29 Apr 2009 06:11:30 -0700 (PDT) Received: from mail1.911.org (mail1.911.org [65.67.130.186]) by core3.amsl.com (Postfix) with ESMTP id 69A6728C161 for ; Wed, 29 Apr 2009 06:11:28 -0700 (PDT) Received: from ghcmail [65.67.130.172] by mail1.911.org - SurfControl E-mail Filter (5.5.0); Wed, 29 Apr 2009 08:07:00 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Apr 2009 08:12:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Validation Thread-Index: AcnIGwO25rFBha6sQAGFr5ebF5c83wAsCvsiAAA//kE= From: "Marc Berryman" To: , , X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-Processed: 5_5_0_191__2009_04_29_08_07_01 Subject: Re: [Ecrit] Location Validation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:11:31 -0000 SSBhZ3JlZSB3aXRoIE1hcmMgTCBvbiB0aGlzIGFuZCBoYXZlIGlzc3VlcyB3aXRoIHRoZSBtYW5u ZXIgdGhhdCB0aGUgTFZGIHdvcmsgZ3JvdXAgaXMgZGVmaW5pbmcgYSB2YWxpZCBsb2NhdGlvbi4N Ck1hcmMgQg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBlY3JpdC1ib3Vu Y2VzQGlldGYub3JnIDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPg0KVG86IEhhbm5lcyBUc2Nob2Zl bmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0PjsgJ0VDUklUJyA8ZWNyaXRAaWV0Zi5vcmc+ DQpTZW50OiBXZWQgQXByIDI5IDA4OjA1OjM2IDIwMDkNClN1YmplY3Q6IFJlOiBbRWNyaXRdIExv Y2F0aW9uIFZhbGlkYXRpb24NCg0KSGFubmVzLA0KDQpXZSBoYWQgZGlzY3Vzc2lvbnMgYXJvdW5k IHRoaXMgdG9waWMgJ3dheSBiYWNrIHdoZW4nLiAgSSBhZ3JlZSB3aXRoIEJyaWFuLA0Kd2UgZG9u J3QgbmVlZCB0byBjaGFuZ2UgYW55dGhpbmcuICBXZSBkZXNpZ25lZCB0aGUgc3VwcG9ydCBvZiB2 YWxpZGF0aW9uDQp3aXRoaW4gTG9TVCB0byByZXR1cm4gYW55L2FsbCB0YWdzIHRoYXQgd2VyZSBm b3VuZCB0byBiZSAnaW4gdGhlIGRhdGFiYXNlJy4NCklmIGluIGZhY3QgYSB0YWcgaXMgZm91bmQg dmFsaWQgYnV0IG5vdCBzdWl0YWJsZSBmb3IgZGlzcGF0Y2gsIGl0J3MgYQ0KZGF0YWJhc2UgcHJv YmxlbS4gIENvbmNlcm5lZCBwYXJ0aWVzIHNob3VsZCBwYXkgY2xvc2UgYXR0ZW50aW9uIHRvIHRo aXMgTG9TVA0KZmVhdHVyZSBhbmQgaG93IHRoZSBkYXRhYmFzZSBpcyBjb25zdHJ1Y3RlZC4gIElm IGEgdGFnIGlzIGZvdW5kIHRvIGJlIG5vdA0KdmFsaWQsIHRoZW4gaXQncyB1cCB0byB0aGUgcHJv dmlkZXIvc291cmNlIG9mIHRoZSBsb2NhdGlvbiBkZXRlcm1pbmF0aW9uIHRvDQpmaXggaXQuICBP YnZpb3VzbHkgdGhlIHByb3RvY29sIGNhbid0IG5vciBzaG91bGRuJ3QgdHJ5IHRvIGZvcmNlIHN1 Y2ggYQ0KJ2ZpeCcuDQoNCi1NYXJjLQ0KDQoNCk9uIDQvMjkvMDkgNDoyNCBBTSwgIkhhbm5lcyBU c2Nob2ZlbmlnIiA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQoNCj4gSGkgYWxs LCANCj4gDQo+IFRoZXJlIHdhcyBhbiBpbnRlcmVzdGluZyB0b2RheSBpbiB0aGUgTkVOQSBFQ1JG IExWRiBXb3JraW5nIEdyb3VwIHBob25lDQo+IGNvbmZlcmVuY2UgYWxsIGFib3V0IGxvY2F0aW9u IHZhbGlkYXRpb24gYW5kIHRoZSBkZWZpbml0aW9uIG9mIGl0Lg0KPiANCj4gTG9va2luZyBhdCBo dHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmM1MDEyLnR4dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUg dGVybQ0KPiBsb2NhdGlvbiBpczogDQo+IA0KPiAgICBMb2NhdGlvbiB2YWxpZGF0aW9uOiAgQSBj YWxsZXIgbG9jYXRpb24gaXMgY29uc2lkZXJlZCB2YWxpZCBpZiB0aGUNCj4gICAgICAgY2l2aWMg b3IgZ2VvZ3JhcGhpYyBsb2NhdGlvbiBpcyByZWNvZ25pemFibGUgd2l0aGluIGFuIGFjY2VwdGFi bGUNCj4gICAgICAgbG9jYXRpb24gcmVmZXJlbmNlIHN5c3RlbSAoZS5nLiwgVW5pdGVkIFN0YXRl cyBQb3N0YWwgQWRkcmVzcyBvcg0KPiAgICAgICB0aGUgV0dTLTg0IGRhdHVtKSBhbmQgY2FuIGJl IG1hcHBlZCB0byBvbmUgb3IgbW9yZSBQU0FQcy4gIFdoaWxlDQo+ICAgICAgIGl0IGlzIGRlc2ly YWJsZSB0byBkZXRlcm1pbmUgdGhhdCBhIGxvY2F0aW9uIGV4aXN0cywgdmFsaWRhdGlvbg0KPiAg ICAgICBtYXkgbm90IGVuc3VyZSB0aGF0IHN1Y2ggYSBsb2NhdGlvbiBleGlzdHMsIGJ1dCByYXRo ZXIgbWF5IG9ubHkNCj4gICAgICAgZW5zdXJlIHRoYXQgdGhlIGxvY2F0aW9uIGZhbGxzIHdpdGhp biBzb21lIHJhbmdlIG9mIGtub3duIHZhbHVlcy4NCj4gICAgICAgTG9jYXRpb24gdmFsaWRhdGlv biBlbnN1cmVzIHRoYXQgYSBsb2NhdGlvbiBpcyBhYmxlIHRvIGJlDQo+ICAgICAgIHJlZmVyZW5j ZWQgZm9yIG1hcHBpbmcsIGJ1dCBtYWtlcyBubyBhc3N1bXB0aW9uIGFib3V0IHRoZQ0KPiAgICAg ICBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBjYWxsZXIgYW5kIHRoZSBjYWxsZXIncyBsb2NhdGlv bi4NCj4gDQo+IFRoaXMgZGVmaW5pdGlvbiBpcyB1c2VmdWwgZm9yIGdlby0gYW5kIGNpdmljIGxv Y2F0aW9uIGluZm9ybWF0aW9uLg0KPiANCj4gVGhlIExvU1Qgc3BlY2lmaWNhdGlvbiwgc2VlIFNl Y3Rpb24gOC40LjIgb2YNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjNTIyMi50eHQsIGRv ZXMgbW9yZSB0aGFuIGp1c3QgZnVsZmlsbGluZyB0aGUNCj4gY2hlY2sgd2hldGhlciBhbiBhZGRy ZXNzIG1hcHMgdG8gYSBQU0FQIFVSSS4gV2UgcHJvdmlkZWQgdGhpcyBmdW5jdGlvbmFsaXR5DQo+ IGluIHJlc3BvbnNlIHRvIHRoZSBpbnRlcmFjdGlvbiB3ZSBoYWQgd2l0aCBORU5BLg0KPiANCj4g TG9TVCBkZXRlcm1pbmVzIHdoZXRoZXIgdGhlcmUgaXMgYW4gY2l2aWMgYWRkcmVzcyBpbiBhbiBh ZGRyZXNzIGRhdGFiYXNlDQo+IHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlIGNpdmljIGFkZHJlc3Mg cHJvdmlkZWQgaW4gdGhlIHJlcXVlc3QgKHVzaW5nIHRoZQ0KPiA8dmFsaWQ+LCA8dW5jaGVja2Vk PiBhbmQgPGludmFsaWQ+IGVsZW1lbnRzKS4NCj4gDQo+IEluIHRoZSBjb25mLiBjYWxsIHRoZW4g dGhlIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuICdsb2NhdGlvbiB2YWxpZGF0aW9uIGZvcg0KPiBy b3V0aW5nJyBhbmQgbG9jYXRpb24gdmFsaWRhdGlvbiBmb3IgZGlzcGF0Y2gnIHdhcyBtYWRlLiBU aGUgZm9ybWVyIHdvdWxkDQo+IG1hdGNoIHRoZSBkZWZpbml0aW9uIGluIFJGQyA1MDEyIHdoaWxl IHRoZSBsYXR0ZXIgaXMgbW9yZSByZWxhdGVkIHRvIHRoZQ0KPiBxdWVzdGlvbiB3aGV0aGVyIGEg cGFydGljdWxhciBjaXZpYyBhZGRyZXNzIGV4aXN0cyBzbyB0aGF0IGRpc3BhdGNoZWQgZmlyc3QN Cj4gcmVzcG9uZGVycyBjYW4gYWN0dWFsbHkgZ28gdGhlcmUuDQo+IA0KPiBEbyB3ZSBuZWVkIHRv IG5lZWQgdG8gY2xhcmlmeSBvciBlbmhhbmNlIG91ciBkZWZpbml0aW9uIG9mIGxvY2F0aW9uDQo+ IHZhbGlkYXRpb24/IA0KPiANCj4gQ2lhbw0KPiBIYW5uZXMNCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0K PiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Vjcml0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0K From mlinsner@cisco.com Wed Apr 29 06:18:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0CF3A6EBE for ; Wed, 29 Apr 2009 06:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49rYLV55dDpP for ; Wed, 29 Apr 2009 06:18:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B351D3A6EFC for ; Wed, 29 Apr 2009 06:18:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,266,1238976000"; d="scan'208";a="295096003" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 Apr 2009 13:20:12 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3TDKCMi006009; Wed, 29 Apr 2009 06:20:12 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3TDKBo1011318; Wed, 29 Apr 2009 13:20:11 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 09:20:11 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 09:20:10 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 29 Apr 2009 09:20:09 -0400 From: Marc Linsner To: "Tschofenig, Hannes (NSN - FI/Espoo)" , Hannes Tschofenig , ECRIT Message-ID: Thread-Topic: [Ecrit] Location Validation Thread-Index: AcnIGwO25rFBha6sQAGFr5ebF5c83wAsCvsiAAAZT4AAAGjHkw== In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45015007AF@FIESEXC015.nsn-intra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Apr 2009 13:20:10.0829 (UTC) FILETIME=[3914DFD0:01C9C8CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4618; t=1241011212; x=1241875212; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20Validation |Sender:=20; bh=Fs6Ov1PpXjURHqjcY4Ixe4hOn4la0Az7PafC31O3YpA=; b=kWxOf2UrqWHgAbP+GMPc3V5WUxHVrNW7CkNkP5DkGV17BjPw8d0LWx8I/T Q1nqS09K70PhhxCgyXAlBRxC0cHtHGBBME1SjiMe1iLW/PConQAWzoKy8ewy qJlYAavjhv3QMWirUC4pgcIXh11R9vDeMRe71cFM1xhYdb6z+OMic=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Location Validation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:18:50 -0000 Hannes, I don't see any differentiation required in our documents. From a protocol perspective, there are no differences between a 'valid for routing' location and a 'valid for dispatch' location. Each tag is evaluated on whether there is a matching value in the database. The results of a non-match are of no consequences to LoST. The actions taken based on the non-match are outside of IETF purview. I suggest that NENA provide procedures on the consequences of the various types of validation matches/non-matches. -Marc- On 4/29/09 9:11 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: > Hi Brian, Hi Marc, > > The problem is that the definition in RFC 5012 does not correspond to > the usage of the term in LoST. The same term 'validation' means > different things in these two documents. > > The definition used in the NENA i3 document does not seem to correspond > to RFC 5012 either. > > The source of the confusion is the lack of differentiation between > validation for routing and validation for dispatch. > > I am not saying that any of the protocol mechanisms should be changed. > > Ciao > Hannes > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of ext Marc Linsner >> Sent: 29 April, 2009 16:06 >> To: Hannes Tschofenig; 'ECRIT' >> Subject: Re: [Ecrit] Location Validation >> >> Hannes, >> >> We had discussions around this topic 'way back when'. I agree >> with Brian, we don't need to change anything. We designed the >> support of validation within LoST to return any/all tags that >> were found to be 'in the database'. >> If in fact a tag is found valid but not suitable for dispatch, >> it's a database problem. Concerned parties should pay close >> attention to this LoST feature and how the database is >> constructed. If a tag is found to be not valid, then it's up >> to the provider/source of the location determination to fix >> it. Obviously the protocol can't nor shouldn't try to force >> such a 'fix'. >> >> -Marc- >> >> >> On 4/29/09 4:24 AM, "Hannes Tschofenig" >> wrote: >> >>> Hi all, >>> >>> There was an interesting today in the NENA ECRF LVF Working Group >>> phone conference all about location validation and the >> definition of it. >>> >>> Looking at http://www.ietf.org/rfc/rfc5012.txt the definition of the >>> term location is: >>> >>> Location validation: A caller location is considered valid if the >>> civic or geographic location is recognizable within an >> acceptable >>> location reference system (e.g., United States Postal >> Address or >>> the WGS-84 datum) and can be mapped to one or more >> PSAPs. While >>> it is desirable to determine that a location exists, validation >>> may not ensure that such a location exists, but rather may only >>> ensure that the location falls within some range of >> known values. >>> Location validation ensures that a location is able to be >>> referenced for mapping, but makes no assumption about the >>> association between the caller and the caller's location. >>> >>> This definition is useful for geo- and civic location information. >>> >>> The LoST specification, see Section 8.4.2 of >>> http://www.ietf.org/rfc/rfc5222.txt, does more than just fulfilling >>> the check whether an address maps to a PSAP URI. We provided this >>> functionality in response to the interaction we had with NENA. >>> >>> LoST determines whether there is an civic address in an address >>> database that corresponds to the civic address provided in >> the request >>> (using the , and elements). >>> >>> In the conf. call then the differentiation between 'location >>> validation for routing' and location validation for dispatch' was >>> made. The former would match the definition in RFC 5012 while the >>> latter is more related to the question whether a particular civic >>> address exists so that dispatched first responders can >> actually go there. >>> >>> Do we need to need to clarify or enhance our definition of location >>> validation? >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> From br@brianrosen.net Wed Apr 29 06:47:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C643A7169 for ; Wed, 29 Apr 2009 06:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf8Eo0P38eHS for ; Wed, 29 Apr 2009 06:47:00 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E1CAB28C257 for ; Wed, 29 Apr 2009 06:46:30 -0700 (PDT) Received: from [24.154.127.233] (helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LzA8W-0005YF-Rv; Wed, 29 Apr 2009 08:47:45 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'Hannes Tschofenig'" , "'ECRIT'" References: <3D3C75174CB95F42AD6BCC56E5555B45015007AF@FIESEXC015.nsn-intra.net> In-Reply-To: Date: Wed, 29 Apr 2009 09:47:47 -0400 Message-ID: <042801c9c8d1$1674e750$435eb5f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnIGwO25rFBha6sQAGFr5ebF5c83wAsCvsiAAAZT4AAAGjHkwAA8AIQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Location Validation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:47:01 -0000 Agree. The definition in 5012 is accurate, and no IETF action on definitions is warranted in my opinion. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, April 29, 2009 9:20 AM To: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; ECRIT Subject: Re: [Ecrit] Location Validation Hannes, I don't see any differentiation required in our documents. From a protocol perspective, there are no differences between a 'valid for routing' location and a 'valid for dispatch' location. Each tag is evaluated on whether there is a matching value in the database. The results of a non-match are of no consequences to LoST. The actions taken based on the non-match are outside of IETF purview. I suggest that NENA provide procedures on the consequences of the various types of validation matches/non-matches. -Marc- On 4/29/09 9:11 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: > Hi Brian, Hi Marc, > > The problem is that the definition in RFC 5012 does not correspond to > the usage of the term in LoST. The same term 'validation' means > different things in these two documents. > > The definition used in the NENA i3 document does not seem to correspond > to RFC 5012 either. > > The source of the confusion is the lack of differentiation between > validation for routing and validation for dispatch. > > I am not saying that any of the protocol mechanisms should be changed. > > Ciao > Hannes > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of ext Marc Linsner >> Sent: 29 April, 2009 16:06 >> To: Hannes Tschofenig; 'ECRIT' >> Subject: Re: [Ecrit] Location Validation >> >> Hannes, >> >> We had discussions around this topic 'way back when'. I agree >> with Brian, we don't need to change anything. We designed the >> support of validation within LoST to return any/all tags that >> were found to be 'in the database'. >> If in fact a tag is found valid but not suitable for dispatch, >> it's a database problem. Concerned parties should pay close >> attention to this LoST feature and how the database is >> constructed. If a tag is found to be not valid, then it's up >> to the provider/source of the location determination to fix >> it. Obviously the protocol can't nor shouldn't try to force >> such a 'fix'. >> >> -Marc- >> >> >> On 4/29/09 4:24 AM, "Hannes Tschofenig" >> wrote: >> >>> Hi all, >>> >>> There was an interesting today in the NENA ECRF LVF Working Group >>> phone conference all about location validation and the >> definition of it. >>> >>> Looking at http://www.ietf.org/rfc/rfc5012.txt the definition of the >>> term location is: >>> >>> Location validation: A caller location is considered valid if the >>> civic or geographic location is recognizable within an >> acceptable >>> location reference system (e.g., United States Postal >> Address or >>> the WGS-84 datum) and can be mapped to one or more >> PSAPs. While >>> it is desirable to determine that a location exists, validation >>> may not ensure that such a location exists, but rather may only >>> ensure that the location falls within some range of >> known values. >>> Location validation ensures that a location is able to be >>> referenced for mapping, but makes no assumption about the >>> association between the caller and the caller's location. >>> >>> This definition is useful for geo- and civic location information. >>> >>> The LoST specification, see Section 8.4.2 of >>> http://www.ietf.org/rfc/rfc5222.txt, does more than just fulfilling >>> the check whether an address maps to a PSAP URI. We provided this >>> functionality in response to the interaction we had with NENA. >>> >>> LoST determines whether there is an civic address in an address >>> database that corresponds to the civic address provided in >> the request >>> (using the , and elements). >>> >>> In the conf. call then the differentiation between 'location >>> validation for routing' and location validation for dispatch' was >>> made. The former would match the definition in RFC 5012 while the >>> latter is more related to the question whether a particular civic >>> address exists so that dispatched first responders can >> actually go there. >>> >>> Do we need to need to clarify or enhance our definition of location >>> validation? >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From randy@qualcomm.com Wed Apr 29 11:39:55 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E863A707B for ; Wed, 29 Apr 2009 11:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BbHmbTdrBVZ for ; Wed, 29 Apr 2009 11:39:54 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D2E463A6C41 for ; Wed, 29 Apr 2009 11:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1241030477; x=1272566477; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20|References:=20=09<49F27637.7050201@bbn.com>=0D=0A=20=0D=0A=20<058 701c9c5d0$53c5ef40$fb51cdc0$@net>=0D=0A=20|X-Mailer: =20Eudora=20for=20Mac=20OS=20X|X-message-Note:=20Warning: =20Outlook=20in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Wed,=2029=20Apr=202009=2011:3 8:27=20-0700|To:=20ECRIT=20|From:=20Randa ll=20Gellens=20|Subject:=20Re:=20[Ecr it]=20PhoneBCP|MIME-Version:=201.0|Content-Type:=20text/p lain=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5600"=3B=20a=3D"17595602"; bh=glHkFYaKKGo0BibAnhNnhrz+NeGxndOsJwCebTNhy2c=; b=e996l/tBnS7vMqGoeK8mxEoUgU4SIWOjRUM8ZHNlYbbElr1PCFBxZsgJ 37Yl84GfqsRUOyFFWnLyJhYcQsM8ORU0/73/RRUZjB7qZQ+MFZLfrGrd5 Jfx63cKeh2Pjq2LA4kfLC+yOrXerj7o2g+fMr7GkKiSkwSi921DJ5DpFV M=; X-IronPort-AV: E=McAfee;i="5300,2777,5600"; a="17595602" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 11:41:17 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3TIfG43029841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Apr 2009 11:41:17 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3TIfGHs030525 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 29 Apr 2009 11:41:16 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 29 Apr 2009 11:41:16 -0700 Received: from [192.168.1.13] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 29 Apr 2009 11:41:15 -0700 Message-ID: In-Reply-To: References: <49F27637.7050201@bbn.com> <058701c9c5d0$53c5ef40$fb51cdc0$@net> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 29 Apr 2009 11:38:27 -0700 To: ECRIT From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:39:55 -0000 There have been a couple of people asserting that the text in the document was added without consensus. While it is certainly the chairs' prerogative to call for consensus on this point, there was a lot of discussion on the list five weeks ago. It certainly had enough discussion then to warrant inclusion in a document version for discussion. In fact, I think the current text is basically Richard's take on a compromise that would get us past the deadlock we seem to be revisiting. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Premature optimization is the root of all evil --C. A. R. Hoare From mlinsner@cisco.com Wed Apr 29 11:51:43 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA763A69ED for ; Wed, 29 Apr 2009 11:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vqmUwTH3s55 for ; Wed, 29 Apr 2009 11:51:42 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 819033A687A for ; Wed, 29 Apr 2009 11:51:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,267,1238976000"; d="scan'208";a="178645805" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 29 Apr 2009 18:52:53 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3TIqqJo018282; Wed, 29 Apr 2009 11:52:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3TIqmgK023609; Wed, 29 Apr 2009 18:52:52 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:52:52 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:52:52 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 29 Apr 2009 14:52:51 -0400 From: Marc Linsner To: Randall Gellens , ECRIT Message-ID: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnI+7JFmLGvwVzc7Em01pfFUj7wEQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Apr 2009 18:52:52.0252 (UTC) FILETIME=[B3044DC0:01C9C8FB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1563; t=1241031173; x=1241895173; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20PhoneBCP |Sender:=20; bh=b2Sv+fjZDwSoiE/ZXKdEXK+yGNBngwVWNNfo+N1VwAY=; b=O75ECLFGSXBUH8TT1uLualYwjI5K8cNTa/rKyGeiLzmiXON5mj7tiyTNQA ZoFHFvTFToo7C9yVvgtOBBE+83SnoEVSfHYnaiTt2kmExTdNnpyt76kBkEf1 8JwPD9vLbd; Authentication-Results: sj-dkim-4; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:51:43 -0000 All, *Remember, this hum closes tomorrow (Friday, May 1). As I stated in an email on Monday. " This is a consolidated hum. If you don't agree that we need an applicability statement, hum against it. If you agree that we need an applicability statement, but don't like the current text, hum against it. If you agree with the statement as written, hum for it. If consensus is against the statement, it will be taken out of the draft. " I use the term 'applicability statement' as that was the term that originally started this discussion. It in no way implies the chairs desires. Changing the term now would cause an even bigger discussion, IMO. My hope is that everyone followed the discussion and makes their choice heard via this call for a hum. Thank you to those that have already expressed their choice. We still have the old version of the draft. If consensus fails as outlined above, we'll bring back the old version. -Marc- On 4/29/09 2:38 PM, "Randall Gellens" wrote: > There have been a couple of people asserting that the text in the > document was added without consensus. While it is certainly the > chairs' prerogative to call for consensus on this point, there was a > lot of discussion on the list five weeks ago. It certainly had > enough discussion then to warrant inclusion in a document version for > discussion. In fact, I think the current text is basically Richard's > take on a compromise that would get us past the deadlock we seem to > be revisiting. From mlinsner@cisco.com Wed Apr 29 11:58:19 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBB93A6E5C for ; Wed, 29 Apr 2009 11:58:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Yw4nt-XbPYv for ; Wed, 29 Apr 2009 11:58:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 562F23A67EC for ; Wed, 29 Apr 2009 11:58:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,267,1238976000"; d="scan'208";a="178649532" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Apr 2009 18:59:40 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3TIxeF2003499 for ; Wed, 29 Apr 2009 11:59:40 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3TIxeAd011481 for ; Wed, 29 Apr 2009 18:59:40 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:59:40 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:59:40 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 29 Apr 2009 14:59:39 -0400 From: Marc Linsner To: ECRIT Message-ID: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnI/KV1Vq5BmQ5zKEWG4JmZqlEkpQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Apr 2009 18:59:40.0216 (UTC) FILETIME=[A62EAB80:01C9C8FC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=320; t=1241031580; x=1241895580; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20PhoneBCP |Sender:=20; bh=sA2mtdkUU1o/wAgIYnIE56ETnZRHAOqbP51haLCclQ4=; b=hLi5mjxS0m3xOwaMWeP8/0kFpO3LaKaHdMFt/QUMHte+nOCwUUqnlgwbmj CwR667kIidjB6nxQxtWJy/gLTaLXA8RT+feM0UE+NLvnWrddVC1fKR062wTz BLOP50dMQcFzvt3jCImZiVzN3BzyR7Uvu+s5vdUPyXs+AXu8P/A8c=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:58:19 -0000 [chair hat off] +1 -Marc- On 4/27/09 9:42 AM, "Henning Schulzrinne" wrote: > +1 > > On Apr 27, 2009, at 8:34 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> I hum against the applicability statement. I cannot see why we need >> one. >> >> >> Ciao >> Hannes >> > From randy@qualcomm.com Wed Apr 29 12:14:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A403A6E5C for ; Wed, 29 Apr 2009 12:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.481 X-Spam-Level: X-Spam-Status: No, score=-105.481 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2slwfxBWp-6 for ; Wed, 29 Apr 2009 12:14:55 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 1AE803A6C90 for ; Wed, 29 Apr 2009 12:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1241032577; x=1272568577; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20 |References:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-Note: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Wed,=2029=20Apr=20 2009=2012:15:30=20-0700|To:=20Marc=20Linsner=20,=20ECRIT=20|From:=20Randall=20 Gellens=20|Subject:=20Re:=20[Ecrit] =20PhoneBCP|MIME-Version:=201.0|Content-Type:=20text/plai n=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5600"=3B=20a=3D"17605099"; bh=FU+yV5VXh9qrjnZHrlgF4KQlQl4hct9CO+NCBphQMvE=; b=GdXcVVtd8JjiAmgBaMExcqNHgzUQKJajUy4Kfuc2hvd6E0enPv+qIKim erYTPFJVU7K91i2hkX7xe6WXt25ipszZnwhHcTwqGHrNXLteU1Y/Z6XUa KyEqOxjXpBVAUM3sjArlQSDnpkqah/l7N5BTR7trOXEKt9wm6M09z610E s=; X-IronPort-AV: E=McAfee;i="5300,2777,5600"; a="17605099" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 12:16:17 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3TJGHUQ018388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 12:16:17 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3TJGGfg017489 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Apr 2009 12:16:16 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 29 Apr 2009 12:16:16 -0700 Received: from [192.168.1.13] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 29 Apr 2009 12:16:15 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 29 Apr 2009 12:15:30 -0700 To: Marc Linsner , ECRIT From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:14:56 -0000 Using the term applicability statement only confuses things, since this text is not an applicability statement and does not limit the applicability of the solution. We did have discussion in SFO on the need for an applicability statement, without clear consensus in the meeting. We had some people who supported one, and some who objected to one. We then had a compromise proposal on the list for text. After much discussion, the text was added, but the text is not an applicability statement, and calling it such now only muddies things. At 2:52 PM -0400 4/29/09, Marc Linsner wrote: > All, > > *Remember, this hum closes tomorrow (Friday, May 1). > > As I stated in an email on Monday. > > " > This is a consolidated hum. > > If you don't agree that we need an applicability statement, hum against it. > > If you agree that we need an applicability statement, but don't like the > current text, hum against it. > > If you agree with the statement as written, hum for it. > > If consensus is against the statement, it will be taken out of the draft. > > " > > I use the term 'applicability statement' as that was the term that > originally started this discussion. It in no way implies the chairs > desires. Changing the term now would cause an even bigger discussion, IMO. > My hope is that everyone followed the discussion and makes their choice > heard via this call for a hum. Thank you to those that have already > expressed their choice. > > We still have the old version of the draft. If consensus fails as outlined > above, we'll bring back the old version. > > -Marc- > > > On 4/29/09 2:38 PM, "Randall Gellens" wrote: > >> There have been a couple of people asserting that the text in the >> document was added without consensus. While it is certainly the >> chairs' prerogative to call for consensus on this point, there was a >> lot of discussion on the list five weeks ago. It certainly had >> enough discussion then to warrant inclusion in a document version for >> discussion. In fact, I think the current text is basically Richard's >> take on a compromise that would get us past the deadlock we seem to > > be revisiting. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is by the fortune of God that, in this country, we have three benefits: freedom of speech, freedom of thought, and the wisdom never to use either. --Mark Twain From bsmith@indigital.net Wed Apr 29 12:52:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC4D28C1B9 for ; Wed, 29 Apr 2009 12:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfq0JIKqliA7 for ; Wed, 29 Apr 2009 12:52:13 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 074E528C1AA for ; Wed, 29 Apr 2009 12:52:10 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1427991qwe.31 for ; Wed, 29 Apr 2009 12:53:33 -0700 (PDT) Received: by 10.224.61.14 with SMTP id r14mr933516qah.253.1241034812910; Wed, 29 Apr 2009 12:53:32 -0700 (PDT) Received: from ?149.161.16.58? (viper-058-client.iusb.edu [149.161.16.58]) by mx.google.com with ESMTPS id 26sm2550009qwa.6.2009.04.29.12.53.31 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Apr 2009 12:53:32 -0700 (PDT) Message-ID: <49F8B00D.4000406@indigital.net> Date: Wed, 29 Apr 2009 15:52:45 -0400 From: Byron Smith Organization: INdigital Telecom User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ECRIT References: <3D3C75174CB95F42AD6BCC56E5555B45014D4A6D@FIESEXC015.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsmith@indigital.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:52:14 -0000 Add my hum against the statement. Byron Byron L. Smith INdigital Telecom Henning Schulzrinne wrote: > +1 > > On Apr 27, 2009, at 8:34 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> I hum against the applicability statement. I cannot see why we need one. >> >> >> Ciao >> Hannes >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Wed Apr 29 12:58:48 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1F03A71A7 for ; Wed, 29 Apr 2009 12:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOS6aJwbcmGl for ; Wed, 29 Apr 2009 12:58:48 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 92F363A7168 for ; Wed, 29 Apr 2009 12:58:47 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2009 20:00:08 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp056) with SMTP; 29 Apr 2009 22:00:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18QfelbR7oQZUpTQtpxqr6N9Rcb8fxT4d0+gk5igP 6GAwqaXSTUdCzi From: "Hannes Tschofenig" To: "'ECRIT'" Date: Wed, 29 Apr 2009 23:01:42 +0300 Message-ID: <00da01c9c905$51309e50$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnJAOeUnrP2801XQqePR+cWG+13nw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Ecrit] ECRIT Virtual Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:58:48 -0000 Hi all, as promised in the status update writeup we are planning to schedule a virtual interim meeting for ECRIT. Please indicate your availability here: http://www.doodle.com/e5r7p8p8xypdzcfd Ciao Hannes & Marc From James.Winterbottom@andrew.com Wed Apr 29 13:46:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2CE73A71C0 for ; Wed, 29 Apr 2009 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHU-hvB97ylX for ; Wed, 29 Apr 2009 13:46:39 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 755CC3A71B4 for ; Wed, 29 Apr 2009 13:46:06 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_29_16_08_15 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Apr 2009 16:08:15 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 15:47:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 15:47:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnI/KV1Vq5BmQ5zKEWG4JmZqlEkpQADwk+x References: From: "Winterbottom, James" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 29 Apr 2009 20:47:27.0810 (UTC) FILETIME=[B52B3220:01C9C90B] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 20:46:40 -0000 =0D=0A+1=0D=0A=0D=0AJames=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: = ecrit-bounces@ietf.org on behalf of Marc Linsner=0D=0ASent: Wed 4/29/2009 1= :59 PM=0D=0ATo: ECRIT=0D=0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=20=0D=0A[cha= ir hat off]=0D=0A=0D=0A+1=0D=0A=0D=0A-Marc-=0D=0A=0D=0A=0D=0AOn 4/27/09 9:4= 2 AM, "Henning Schulzrinne" wrote:=0D=0A=0D=0A> +1=0D= =0A>=20=0D=0A> On Apr 27, 2009, at 8:34 AM, Tschofenig, Hannes (NSN - FI/Es= poo) wrote:=0D=0A>=20=0D=0A>> I hum against the applicability statement. I = cannot see why we need=0D=0A>> one.=0D=0A>>=20=0D=0A>>=20=0D=0A>> Ciao=0D=0A= >> Hannes=0D=0A>>=20=0D=0A>=20=0D=0A=0D=0A=0D=0A___________________________= ____________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps= ://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A From jmpolk@cisco.com Wed Apr 29 14:21:31 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6314928C0E5 for ; Wed, 29 Apr 2009 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkq1XV-OQNSo for ; Wed, 29 Apr 2009 14:21:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7E4FB28C2ED for ; Wed, 29 Apr 2009 14:20:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,268,1238976000"; d="scan'208";a="295371317" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 Apr 2009 21:22:16 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3TLMGEt010032 for ; Wed, 29 Apr 2009 14:22:16 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3TLMGhn015206 for ; Wed, 29 Apr 2009 21:22:16 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:22:15 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.22.47]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:22:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Apr 2009 16:22:11 -0500 To: Marc Linsner , ECRIT From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Apr 2009 21:22:15.0768 (UTC) FILETIME=[91B04D80:01C9C910] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1655; t=1241040136; x=1241904136; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20PhoneBCP |Sender:=20; bh=vae6175TmvSoh7OeSN+4Id6ERMGa8zsjwECzZR7VeTU=; b=t/Hp3UY8D5QnfJfpOrRjm1FPdGZQUjaCdbIK4fPHm/+pe9UIjgU5jvW/vF KL+o1g6q9oy39iCn3JkgwYD0l5IXymonOEGJ2QtP4BH6n+AqWRfBpjNpc+P1 k/PxEJilgEuMNk0hUJfCXfI2NrVjb6vMtxiFFTcWQAL9eC+NEc7fg=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:21:31 -0000 Marc I do not believe the applicability statement is necessary, regardless of how well or poor it is written. The scope of this effort is clear - in the IETF community - and this is not an industry view of applicability, which is how I believe some are reacting as if it were. Were this applicability to remain, then every IETF ID and RFC would require one, as I know of no situation in which any communication is ever entirely comprised of IETF technologies (i.e., every communication has a layer 2 - which the IETF has no charge of - or is contained entirely within the same physical entity, in which it is rare that maintaining standards based protocols are necessary). There may be corner cases that I'm not thinking about - but I believe this is generally true. Therefore, I hum *no* to add this applicability statement. James At 01:23 PM 4/24/2009, Marc Linsner wrote: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt > > >At the San Francisco meeting and ensuing list threads, the last >issue around PhoneBCP was whether or not to include an >'applicability statement'. The hum during the meeting was >inconclusive. The draft editor has included text in this latest >version in an attempt to compromise on this issue. > >Please review this version and respond by Friday May 1 to the list >as to your acceptance of this change. > >Thanks, > >Marc, Hannes, & Roger >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Wed Apr 29 15:49:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6614828C2F1 for ; Wed, 29 Apr 2009 15:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rIMFAl4qi7C for ; Wed, 29 Apr 2009 15:49:09 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 4B0F828C2EE for ; Wed, 29 Apr 2009 15:49:09 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 29 Apr 2009 15:50:30 -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: Wed, 29 Apr 2009 15:50:29 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750CB2D217@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 Thread-Index: AcnID/JwyyPvpi9+SQ27T7D4LEHtXAAUxphgAC5q7QA= References: <49F71677.2070007@bbn.com> From: "Roger Marshall" To: "Thomson, Martin" , "Richard Barnes" , "Marc Linsner" Cc: ECRIT Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:49:10 -0000 This is good work and is needful for LoST implementation. Let's make it a wg item. -roger marshall. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Thomson, Martin > Sent: Tuesday, April 28, 2009 5:41 PM > To: Richard Barnes; Marc Linsner > Cc: ECRIT > Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 >=20 > What Richard said. >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of Richard Barnes > > Sent: Wednesday, 29 April 2009 12:45 AM > > To: Marc Linsner > > Cc: ECRIT > > Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-01 > > > > I think this document is useful. It fills a gap in the logical > > structure of LoST, and enables a more complete, automatic client > > processing model. > > > > --Richard > > > > > > > > Marc Linsner wrote: > > > All, > > > > > > Please review this draft to and respond by Friday May 1 if you find > > this > > > valuable for ECRIT to work on. > > > > > > Thanks, > > > > > > -Marc- > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > -- > > --- > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > ----------------------------------------------------------------------- > ------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ----------------------------------------------------------------------- > ------------------------- > [mf2] > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From Martin.Thomson@andrew.com Wed Apr 29 16:22:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E463A692E for ; Wed, 29 Apr 2009 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt06ZJBImIeI for ; Wed, 29 Apr 2009 16:22:01 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 879013A7145 for ; Wed, 29 Apr 2009 16:22:01 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_29_18_44_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Apr 2009 18:44:11 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 18:23:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Apr 2009 18:23:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnJEK06iXdyBNyIRWWDngdOkUCDmQAEI8MA References: From: "Thomson, Martin" To: "James M. Polk" , "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 29 Apr 2009 23:23:23.0482 (UTC) FILETIME=[7D9573A0:01C9C921] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:22:02 -0000 SGF2aW5nIGJlZW4gdGhlIHZpY3RpbSBvZiAiYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQiIGF0dGFj a3MgaW4gdGhlIHBhc3QsIGxldCdzIGp1c3Qgc2F5IEknbSBzb21ld2hhdCBwcmVqdWRpY2VkIGFn YWluc3QgdGhlbS4NCg0KSSBhbHNvIHRoaW5rIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byBzYXkgd2hh dCBldmVuIHRoZSBkdWxsZXN0IG9mIG91ciBhdWRpZW5jZSBzaG91bGQgYmUgYWJsZSB0byB3b3Jr IG91dCBmb3IgdGhlbXNlbHZlcy4NCg0KTm8gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQsIG9yIHdo YXRldmVyIFJhbmR5IHRoaW5rcyB0aGlzIGlzLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgSmFtZXMgTS4gUG9saw0KPiBTZW50OiBUaHVyc2Rh eSwgMzAgQXByaWwgMjAwOSA3OjIyIEFNDQo+IFRvOiBNYXJjIExpbnNuZXI7IEVDUklUDQo+IFN1 YmplY3Q6IFJlOiBbRWNyaXRdIFBob25lQkNQDQo+IA0KPiBNYXJjDQo+IA0KPiBJIGRvIG5vdCBi ZWxpZXZlIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBpcyBuZWNlc3NhcnksIHJlZ2FyZGxl c3MNCj4gb2YgaG93IHdlbGwgb3IgcG9vciBpdCBpcyB3cml0dGVuLiAgVGhlIHNjb3BlIG9mIHRo aXMgZWZmb3J0IGlzIGNsZWFyDQo+IC0gaW4gdGhlIElFVEYgY29tbXVuaXR5IC0gYW5kIHRoaXMg aXMgbm90IGFuIGluZHVzdHJ5IHZpZXcgb2YNCj4gYXBwbGljYWJpbGl0eSwgd2hpY2ggaXMgaG93 IEkgYmVsaWV2ZSBzb21lIGFyZSByZWFjdGluZyBhcyBpZiBpdCB3ZXJlLg0KPiANCj4gV2VyZSB0 aGlzIGFwcGxpY2FiaWxpdHkgdG8gcmVtYWluLCB0aGVuIGV2ZXJ5IElFVEYgSUQgYW5kIFJGQyB3 b3VsZA0KPiByZXF1aXJlIG9uZSwgYXMgSSBrbm93IG9mIG5vIHNpdHVhdGlvbiBpbiB3aGljaCBh bnkgY29tbXVuaWNhdGlvbiBpcw0KPiBldmVyIGVudGlyZWx5IGNvbXByaXNlZCBvZiBJRVRGIHRl Y2hub2xvZ2llcyAoaS5lLiwgZXZlcnkNCj4gY29tbXVuaWNhdGlvbiBoYXMgYSBsYXllciAyIC0g d2hpY2ggdGhlIElFVEYgaGFzIG5vIGNoYXJnZSBvZiAtIG9yIGlzDQo+IGNvbnRhaW5lZCBlbnRp cmVseSB3aXRoaW4gdGhlIHNhbWUgcGh5c2ljYWwgZW50aXR5LCBpbiB3aGljaCBpdCBpcw0KPiBy YXJlIHRoYXQgbWFpbnRhaW5pbmcgc3RhbmRhcmRzIGJhc2VkIHByb3RvY29scyBhcmUgbmVjZXNz YXJ5KS4gVGhlcmUNCj4gbWF5IGJlIGNvcm5lciBjYXNlcyB0aGF0IEknbSBub3QgdGhpbmtpbmcg YWJvdXQgLSBidXQgSSBiZWxpZXZlIHRoaXMNCj4gaXMgZ2VuZXJhbGx5IHRydWUuDQo+IA0KPiBU aGVyZWZvcmUsIEkgaHVtICpubyogdG8gYWRkIHRoaXMgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQu DQo+IA0KPiBKYW1lcw0KPiANCj4gQXQgMDE6MjMgUE0gNC8yNC8yMDA5LCBNYXJjIExpbnNuZXIg d3JvdGU6DQo+ID48aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1lY3JpdC1waG9uZWJjcC0NCj4gMDkudHh0Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtZWNyaXQtcGhvbmViY3AtDQo+IDA5LnR4dA0KPiA+DQo+ID4NCj4g PkF0IHRoZSBTYW4gRnJhbmNpc2NvIG1lZXRpbmcgYW5kIGVuc3VpbmcgbGlzdCB0aHJlYWRzLCB0 aGUgbGFzdA0KPiA+aXNzdWUgYXJvdW5kIFBob25lQkNQIHdhcyB3aGV0aGVyIG9yIG5vdCB0byBp bmNsdWRlIGFuDQo+ID4nYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQnLiAgVGhlIGh1bSBkdXJpbmcg dGhlIG1lZXRpbmcgd2FzDQo+ID5pbmNvbmNsdXNpdmUuICBUaGUgZHJhZnQgZWRpdG9yIGhhcyBp bmNsdWRlZCB0ZXh0IGluIHRoaXMgbGF0ZXN0DQo+ID52ZXJzaW9uIGluIGFuIGF0dGVtcHQgdG8g Y29tcHJvbWlzZSBvbiB0aGlzIGlzc3VlLg0KPiA+DQo+ID5QbGVhc2UgcmV2aWV3IHRoaXMgdmVy c2lvbiBhbmQgcmVzcG9uZCBieSBGcmlkYXkgTWF5IDEgdG8gdGhlIGxpc3QNCj4gPmFzIHRvIHlv dXIgYWNjZXB0YW5jZSBvZiB0aGlzIGNoYW5nZS4NCj4gPg0KPiA+VGhhbmtzLA0KPiA+DQo+ID5N YXJjLCBIYW5uZXMsICYgUm9nZXINCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID5FY3JpdCBtYWlsaW5nIGxpc3QNCj4gPkVjcml0QGlldGYub3Jn DQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBt YWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkg YW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHBy aXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdp bmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== From sedge@qualcomm.com Wed Apr 29 16:22:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEAB33A69E7 for ; Wed, 29 Apr 2009 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.474 X-Spam-Level: X-Spam-Status: No, score=-105.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGjbRowWlqlK for ; Wed, 29 Apr 2009 16:22:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 789D53A67B6 for ; Wed, 29 Apr 2009 16:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241047404; x=1272583404; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20R ichard=20Barnes=20,=20"Gellens,=20Randal l"=20,=0D=0A=20=20=20=20=20=20=20=20H enning=20Schulzrinne=20,=0D=0A=20=20 =20=20=20=20=20=20"Stark,=20Barbara"=20, =20ECRIT=20|Date:=20Wed,=2029=20Apr=20200 9=2016:23:22=20-0700|Subject:=20RE:=20[Ecrit]=20PhoneBCP |Thread-Topic:=20[Ecrit]=20PhoneBCP|Thread-Index:=20AcnIP OEzsgk5dznfTdGkY0hVKlKLbAA1krMA|Message-ID:=20<1288E74A73 964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.co m>|References:=20=0D=0A=09<49F27637.7 050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc 0$@net><28B7C3AA2A7ABA4A841F11217A=0D=0A=09BE 78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>=0D =0A=09=0D=0A=09<75 82BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p>=0D=0A=09 =0D =0A=09=0D=0A=20<12 88E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qua lcomm.com>=0D=0A=20<49F761CC.3090902@bbn.com> |In-Reply-To:=20<49F761CC.3090902@bbn.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5600"=3B=20a=3D"17614520"; bh=S3c0NJjr7yLmDPPjO0YMdr9dCU4aSJLKiS54RgEwqwk=; b=OvDG0RUzBnL//V89WEMVRc+2nuxDfpV2UN26d9eLRORe0AIVlVSyD6OC FsT2JwW2ISW9bUXddPSqTtmGTL6uNxwcYR+Ig4v1ZQvthFNC1ZKA9QKPy UhrA5KuLUYyzOGxNqCNAUzp+VXJim8bgi/rqUVt9dS8ycjIOEU3mckxkh E=; X-IronPort-AV: E=McAfee;i="5300,2777,5600"; a="17614520" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 16:23:24 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3TNNNaW019659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 16:23:23 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3TNNNdL013911 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Apr 2009 16:23:23 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Wed, 29 Apr 2009 16:23:23 -0700 From: "Edge, Stephen" To: Richard Barnes , "Gellens, Randall" , Henning Schulzrinne , "Stark, Barbara" , ECRIT Date: Wed, 29 Apr 2009 16:23:22 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMA Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217A BE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com> <49F761CC.3090902@bbn.com> In-Reply-To: <49F761CC.3090902@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:22:02 -0000 Richard and all others I wonder if those now humming against this statement (and who were all stra= ngely silent 5 weeks ago) would support any kind of statement concerning ap= plicability and scope. Or is it the case that the solution supported by bot= h drafts is considered to apply to all devices, ANs and VSPs that provide s= ome form of internet access. If so, is it irrelevant whether the solution i= s actually suitable for a particular type of AN or VSP (e.g. cellular AN, I= MS based VSP)? For example, is it irrelevant whether significant additional= support from an AN or VSP to which the solution might be applied would be = needed in order to access legacy PSAPs, handoff to the circuit domain, auth= enticate the caller and provide access to non-subscribed users? Is it furth= er irrelevant whether the solution would even work for a particular device,= AN or VSP without substantial changes to the latter? In other words, is th= e solution now considered so sacrosanct that any adaptation must come from = the rest of the infrastructure and not from the solution itself in the case= of any mismatch? If the consensus answers to these questions are all yes, = then I would have to agree that including the currently disputed statement = or anything of a similar nature would be inconsistent and unnecessary. Of c= ourse, the representatives of the potentially affected portions of infrastr= ucture should be forgiven for disagreeing with the basic premise - and may = be expected to offer some type of protest! Kind Regards Stephen -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Tuesday, April 28, 2009 1:07 PM To: Edge, Stephen Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT Subject: Re: [Ecrit] PhoneBCP Stephen, As was noted in the meeting, it is *always* possible that there are=20 alternative solutions out there when you're talking about the Internet.=20 TCP vs. UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs.=20 XMPP, SASL vs. TLS, S/MIME vs. OpenPGP. None of the many RFCs out there=20 have explicit statements that somebody else might do it differently=20 because it's obvious that they can. So I don't really think conveying the possibility of other=20 implementations is actually useful at all, technically speaking. That means that the only real purpose of such a statement is rhetorical,=20 and as we've seen in a few messages here, some people misconstrue the=20 rhetoric to mean that this system has constrained applicability. Given=20 that, I'd rather leave it off unless we can avoid that impression. --Richard Edge, Stephen wrote: > All >=20 > I would have thought that motivation should be irrelevant. There are a lo= t of motives at work here. Should we assume that the document was originall= y written with only the purest and most altruistic motives (e.g. no thought= of business or academic interest at stake)? >=20 > The issue is whether the current statement serves a useful purpose in con= veying the possibility (well known to be true) of alternative solutions not= fully aligned with the current drafts. Nothing in the statement implies th= at the current drafts are necessarily deficient or that alternative solutio= ns must necessarily be used for some scenarios (even though they optionally= can be). >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Randall Gellens > Sent: Tuesday, April 28, 2009 9:57 AM > To: Henning Schulzrinne; Stark, Barbara > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote: >=20 >> It is clear that the text has ulterior motives to restrict the=20 >> applicability of the document. >=20 > From my view, the text does not restrict the applicability, nor is=20 > there a desire to do so. The text does clarify the assumptions of=20 > the rest of the text in the document, which I think is helpful. >=20 From Martin.Thomson@andrew.com Wed Apr 29 17:11:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5853A6EFE for ; Wed, 29 Apr 2009 17:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXhdbdtyT2Pi for ; Wed, 29 Apr 2009 17:11:39 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6531828C0E3 for ; Wed, 29 Apr 2009 17:11:06 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_29_19_33_16 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Apr 2009 19:33:15 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 19:12:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Apr 2009 19:12:25 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAQZkTA= References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> From: "Thomson, Martin" To: "Edge, Stephen" , "Richard Barnes" , "Gellens, Randall" , "Henning Schulzrinne" , "Stark, Barbara" , "ECRIT" X-OriginalArrivalTime: 30 Apr 2009 00:12:27.0809 (UTC) FILETIME=[588A1910:01C9C928] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 00:11:40 -0000 SGkgU3RlcGhlbiwNCg0KSSdtIGNvbnZpbmNlZCB0aGF0IHRoZSBFQ1JJVCBhcmNoaXRlY3R1cmUg aXMgdGhlIG9ubHkgc29sdXRpb24gdGhhdCB3aWxsIHdvcmsgZm9yIEFMTCBmb3JtcyBvZiBJbnRl cm5ldCBhY2Nlc3MuDQoNCkkgdGhlbiBvZmZlciB5b3UgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlICJh cHBsaWNhYmlsaXR5IHN0YXRlbWVudCIgeW91IHJlcXVlc3Q6DQoNCiAgV2hlcmUgeW91IGJlbGll dmUgdGhhdCB0aGUgRUNSSVQgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IGFwcGx5LCBzdGF0ZSB3aHku ICBJbmNsdWRlIGFsc28gYSBkZXNjcmlwdGlvbiBvZiB3aHkgaW50ZXJ3b3JraW5nIHdpdGggc3Vj aCBhbiBhcmNoaXRlY3R1cmUgaXMgbm90IG5lY2Vzc2FyeS4NCg0KVGhlIGdyZWF0IHRoaW5nIGFi b3V0IHRoaXMgaXMgdGhhdCB5b3UgY2FuIGRvIHRoaXMgaW4gdGhlIGZvcnVtIG9mIHlvdXIgY2hv aWNlLiAgWW91IGRvbid0IGhhdmUgdG8gZGVhbCB3aXRoIHRoZSByZWNhbGNpdHJhbnQgYnVuY2gg YXQgdGhlIElFVEYuICBJbiBmYWN0LCBJJ2QgZW5jb3VyYWdlIHlvdSB0byBjb25zaWRlciB0aGF0 IGFwcHJvYWNoLg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYNCj4gT2YgRWRnZSwgU3RlcGhlbg0KPiBTZW50OiBUaHVyc2RheSwgMzAg QXByaWwgMjAwOSA5OjIzIEFNDQo+IFRvOiBSaWNoYXJkIEJhcm5lczsgR2VsbGVucywgUmFuZGFs bDsgSGVubmluZyBTY2h1bHpyaW5uZTsgU3RhcmssDQo+IEJhcmJhcmE7IEVDUklUDQo+IFN1Ympl Y3Q6IFJlOiBbRWNyaXRdIFBob25lQkNQDQo+IA0KPiBSaWNoYXJkIGFuZCBhbGwgb3RoZXJzDQo+ IA0KPiBJIHdvbmRlciBpZiB0aG9zZSBub3cgaHVtbWluZyBhZ2FpbnN0IHRoaXMgc3RhdGVtZW50 IChhbmQgd2hvIHdlcmUgYWxsDQo+IHN0cmFuZ2VseSBzaWxlbnQgNSB3ZWVrcyBhZ28pIHdvdWxk IHN1cHBvcnQgYW55IGtpbmQgb2Ygc3RhdGVtZW50DQo+IGNvbmNlcm5pbmcgYXBwbGljYWJpbGl0 eSBhbmQgc2NvcGUuIE9yIGlzIGl0IHRoZSBjYXNlIHRoYXQgdGhlIHNvbHV0aW9uDQo+IHN1cHBv cnRlZCBieSBib3RoIGRyYWZ0cyBpcyBjb25zaWRlcmVkIHRvIGFwcGx5IHRvIGFsbCBkZXZpY2Vz LCBBTnMgYW5kDQo+IFZTUHMgdGhhdCBwcm92aWRlIHNvbWUgZm9ybSBvZiBpbnRlcm5ldCBhY2Nl c3MuIElmIHNvLCBpcyBpdCBpcnJlbGV2YW50DQo+IHdoZXRoZXIgdGhlIHNvbHV0aW9uIGlzIGFj dHVhbGx5IHN1aXRhYmxlIGZvciBhIHBhcnRpY3VsYXIgdHlwZSBvZiBBTg0KPiBvciBWU1AgKGUu Zy4gY2VsbHVsYXIgQU4sIElNUyBiYXNlZCBWU1ApPyBGb3IgZXhhbXBsZSwgaXMgaXQgaXJyZWxl dmFudA0KPiB3aGV0aGVyIHNpZ25pZmljYW50IGFkZGl0aW9uYWwgc3VwcG9ydCBmcm9tIGFuIEFO IG9yIFZTUCB0byB3aGljaCB0aGUNCj4gc29sdXRpb24gbWlnaHQgYmUgYXBwbGllZCB3b3VsZCBi ZSBuZWVkZWQgaW4gb3JkZXIgdG8gYWNjZXNzIGxlZ2FjeQ0KPiBQU0FQcywgaGFuZG9mZiB0byB0 aGUgY2lyY3VpdCBkb21haW4sIGF1dGhlbnRpY2F0ZSB0aGUgY2FsbGVyIGFuZA0KPiBwcm92aWRl IGFjY2VzcyB0byBub24tc3Vic2NyaWJlZCB1c2Vycz8gSXMgaXQgZnVydGhlciBpcnJlbGV2YW50 DQo+IHdoZXRoZXIgdGhlIHNvbHV0aW9uIHdvdWxkIGV2ZW4gd29yayBmb3IgYSBwYXJ0aWN1bGFy IGRldmljZSwgQU4gb3IgVlNQDQo+IHdpdGhvdXQgc3Vic3RhbnRpYWwgY2hhbmdlcyB0byB0aGUg bGF0dGVyPyBJbiBvdGhlciB3b3JkcywgaXMgdGhlDQo+IHNvbHV0aW9uIG5vdyBjb25zaWRlcmVk IHNvIHNhY3Jvc2FuY3QgdGhhdCBhbnkgYWRhcHRhdGlvbiBtdXN0IGNvbWUNCj4gZnJvbSB0aGUg cmVzdCBvZiB0aGUNCj4gICBpbmZyYXN0cnVjdHVyZSBhbmQgbm90IGZyb20gdGhlIHNvbHV0aW9u IGl0c2VsZiBpbiB0aGUgY2FzZSBvZiBhbnkNCj4gbWlzbWF0Y2g/IElmIHRoZSBjb25zZW5zdXMg YW5zd2VycyB0byB0aGVzZSBxdWVzdGlvbnMgYXJlIGFsbCB5ZXMsIHRoZW4NCj4gSSB3b3VsZCBo YXZlIHRvIGFncmVlIHRoYXQgaW5jbHVkaW5nIHRoZSBjdXJyZW50bHkgZGlzcHV0ZWQgc3RhdGVt ZW50DQo+IG9yIGFueXRoaW5nIG9mIGEgc2ltaWxhciBuYXR1cmUgd291bGQgYmUgaW5jb25zaXN0 ZW50IGFuZCB1bm5lY2Vzc2FyeS4NCj4gT2YgY291cnNlLCB0aGUgcmVwcmVzZW50YXRpdmVzIG9m IHRoZSBwb3RlbnRpYWxseSBhZmZlY3RlZCBwb3J0aW9ucyBvZg0KPiBpbmZyYXN0cnVjdHVyZSBz aG91bGQgYmUgZm9yZ2l2ZW4gZm9yIGRpc2FncmVlaW5nIHdpdGggdGhlIGJhc2ljDQo+IHByZW1p c2UgLSBhbmQgbWF5IGJlIGV4cGVjdGVkIHRvIG9mZmVyIHNvbWUgdHlwZSBvZiBwcm90ZXN0IQ0K PiANCj4gS2luZCBSZWdhcmRzDQo+IA0KPiBTdGVwaGVuDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmJhcm5lc0BiYm4uY29tXQ0K PiBTZW50OiBUdWVzZGF5LCBBcHJpbCAyOCwgMjAwOSAxOjA3IFBNDQo+IFRvOiBFZGdlLCBTdGVw aGVuDQo+IENjOiBHZWxsZW5zLCBSYW5kYWxsOyBIZW5uaW5nIFNjaHVsenJpbm5lOyBTdGFyaywg QmFyYmFyYTsgRUNSSVQNCj4gU3ViamVjdDogUmU6IFtFY3JpdF0gUGhvbmVCQ1ANCj4gDQo+IFN0 ZXBoZW4sDQo+IA0KPiBBcyB3YXMgbm90ZWQgaW4gdGhlIG1lZXRpbmcsIGl0IGlzICphbHdheXMq IHBvc3NpYmxlIHRoYXQgdGhlcmUgYXJlDQo+IGFsdGVybmF0aXZlIHNvbHV0aW9ucyBvdXQgdGhl cmUgd2hlbiB5b3UncmUgdGFsa2luZyBhYm91dCB0aGUgSW50ZXJuZXQuDQo+ICAgVENQIHZzLiBV RFAsIFBPUCB2cy4gSU1BUCwgRlRQIHZzLiBIVFRQIHZzLiBCaXRUb3JyZW50LCBTSU1QTEUgdnMu DQo+IFhNUFAsIFNBU0wgdnMuIFRMUywgUy9NSU1FIHZzLiBPcGVuUEdQLiAgTm9uZSBvZiB0aGUg bWFueSBSRkNzIG91dA0KPiB0aGVyZQ0KPiBoYXZlIGV4cGxpY2l0IHN0YXRlbWVudHMgdGhhdCBz b21lYm9keSBlbHNlIG1pZ2h0IGRvIGl0IGRpZmZlcmVudGx5DQo+IGJlY2F1c2UgaXQncyBvYnZp b3VzIHRoYXQgdGhleSBjYW4uDQo+IA0KPiBTbyBJIGRvbid0IHJlYWxseSB0aGluayBjb252ZXlp bmcgdGhlIHBvc3NpYmlsaXR5IG9mIG90aGVyDQo+IGltcGxlbWVudGF0aW9ucyBpcyBhY3R1YWxs eSB1c2VmdWwgYXQgYWxsLCB0ZWNobmljYWxseSBzcGVha2luZy4NCj4gDQo+IFRoYXQgbWVhbnMg dGhhdCB0aGUgb25seSByZWFsIHB1cnBvc2Ugb2Ygc3VjaCBhIHN0YXRlbWVudCBpcw0KPiByaGV0 b3JpY2FsLA0KPiBhbmQgYXMgd2UndmUgc2VlbiBpbiBhIGZldyBtZXNzYWdlcyBoZXJlLCBzb21l IHBlb3BsZSBtaXNjb25zdHJ1ZSB0aGUNCj4gcmhldG9yaWMgdG8gbWVhbiB0aGF0IHRoaXMgc3lz dGVtIGhhcyBjb25zdHJhaW5lZCBhcHBsaWNhYmlsaXR5LiAgR2l2ZW4NCj4gdGhhdCwgSSdkIHJh dGhlciBsZWF2ZSBpdCBvZmYgdW5sZXNzIHdlIGNhbiBhdm9pZCB0aGF0IGltcHJlc3Npb24uDQo+ IA0KPiAtLVJpY2hhcmQNCj4gDQo+IA0KPiANCj4gDQo+IEVkZ2UsIFN0ZXBoZW4gd3JvdGU6DQo+ ID4gQWxsDQo+ID4NCj4gPiBJIHdvdWxkIGhhdmUgdGhvdWdodCB0aGF0IG1vdGl2YXRpb24gc2hv dWxkIGJlIGlycmVsZXZhbnQuIFRoZXJlIGFyZQ0KPiBhIGxvdCBvZiBtb3RpdmVzIGF0IHdvcmsg aGVyZS4gU2hvdWxkIHdlIGFzc3VtZSB0aGF0IHRoZSBkb2N1bWVudCB3YXMNCj4gb3JpZ2luYWxs eSB3cml0dGVuIHdpdGggb25seSB0aGUgcHVyZXN0IGFuZCBtb3N0IGFsdHJ1aXN0aWMgbW90aXZl cw0KPiAoZS5nLiBubyB0aG91Z2h0IG9mIGJ1c2luZXNzIG9yIGFjYWRlbWljIGludGVyZXN0IGF0 IHN0YWtlKT8NCj4gPg0KPiA+IFRoZSBpc3N1ZSBpcyB3aGV0aGVyIHRoZSBjdXJyZW50IHN0YXRl bWVudCBzZXJ2ZXMgYSB1c2VmdWwgcHVycG9zZSBpbg0KPiBjb252ZXlpbmcgdGhlIHBvc3NpYmls aXR5ICh3ZWxsIGtub3duIHRvIGJlIHRydWUpIG9mIGFsdGVybmF0aXZlDQo+IHNvbHV0aW9ucyBu b3QgZnVsbHkgYWxpZ25lZCB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0cy4gTm90aGluZyBpbiB0aGUN Cj4gc3RhdGVtZW50IGltcGxpZXMgdGhhdCB0aGUgY3VycmVudCBkcmFmdHMgYXJlIG5lY2Vzc2Fy aWx5IGRlZmljaWVudCBvcg0KPiB0aGF0IGFsdGVybmF0aXZlIHNvbHV0aW9ucyBtdXN0IG5lY2Vz c2FyaWx5IGJlIHVzZWQgZm9yIHNvbWUgc2NlbmFyaW9zDQo+IChldmVuIHRob3VnaCB0aGV5IG9w dGlvbmFsbHkgY2FuIGJlKS4NCj4gPg0KPiA+IEtpbmQgUmVnYXJkcw0KPiA+DQo+ID4gU3RlcGhl bg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogZWNyaXQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBP ZiBSYW5kYWxsIEdlbGxlbnMNCj4gPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAyOCwgMjAwOSA5OjU3 IEFNDQo+ID4gVG86IEhlbm5pbmcgU2NodWx6cmlubmU7IFN0YXJrLCBCYXJiYXJhDQo+ID4gQ2M6 IEVDUklUDQo+ID4gU3ViamVjdDogUmU6IFtFY3JpdF0gUGhvbmVCQ1ANCj4gPg0KPiA+IEF0IDEx OjE0IEFNIC0wNDAwIDQvMjgvMDksIEhlbm5pbmcgU2NodWx6cmlubmUgd3JvdGU6DQo+ID4NCj4g Pj4gIEl0IGlzIGNsZWFyIHRoYXQgdGhlIHRleHQgaGFzIHVsdGVyaW9yIG1vdGl2ZXMgdG8gcmVz dHJpY3QgdGhlDQo+ID4+IGFwcGxpY2FiaWxpdHkgb2YgdGhlIGRvY3VtZW50Lg0KPiA+DQo+ID4g IEZyb20gbXkgdmlldywgdGhlIHRleHQgZG9lcyBub3QgcmVzdHJpY3QgdGhlIGFwcGxpY2FiaWxp dHksIG5vciBpcw0KPiA+IHRoZXJlIGEgZGVzaXJlIHRvIGRvIHNvLiAgVGhlIHRleHQgZG9lcyBj bGFyaWZ5IHRoZSBhc3N1bXB0aW9ucyBvZg0KPiA+IHRoZSByZXN0IG9mIHRoZSB0ZXh0IGluIHRo ZSBkb2N1bWVudCwgd2hpY2ggSSB0aGluayBpcyBoZWxwZnVsLg0KPiA+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlz dA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Vjcml0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhp cyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpj b250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZv cm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkg dW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From sedge@qualcomm.com Wed Apr 29 18:19:55 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6933A6BA5 for ; Wed, 29 Apr 2009 18:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.519 X-Spam-Level: X-Spam-Status: No, score=-105.519 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRIrvsnEEh6V for ; Wed, 29 Apr 2009 18:19:52 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id F05D33A6DDF for ; Wed, 29 Apr 2009 18:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241054475; x=1272590475; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Thomson,=20Martin"=20,=0D=0A =20=20=20=20=20=20=20=20Richard=20Barnes=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"Gellens,=20Randa ll"=20,=0D=0A=20=20=20=20=20=20=20=20 Henning=0D=0A=20Schulzrinne=20,=0D =0A=20=20=20=20=20=20=20=20"Stark,=20Barbara"=20,=20ECRIT=0D=0A=09|Date:=20Wed,=20 29=20Apr=202009=2018:20:53=20-0700|Subject:=20RE:=20[Ecri t]=20PhoneBCP|Thread-Topic:=20[Ecrit]=20PhoneBCP |Thread-Index:=20AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAQZ kTAAA48OcA=3D=3D|Message-ID:=20<1288E74A73964940B132A0B9E A8D8ABC5926A498@NASANEXMB04.na.qualcomm.com>|References: =20<49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4 A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-luc ent.com><7582BC68E 4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926 A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.co m>=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC5926A470@NASA NEXMB04.na.qualcomm.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5600"=3B=20a=3D"17618195"; bh=t8VncAtWHOEHhL20OEx1liq9fcipEjLDBlAty5s7gwU=; b=Ure8AHh5AEufa2JxituZnZQCdajpAXtvgbjmchHc8CsI2dTXlbjcPLoD ROzH+niX/BFzuxLcjVpHrPLfLUbWvQp15vzeY9felTFG1Ql8Qt2f9gWNi NZkqP2wNB4ghcjX1QHDNcMd7BHGUxwCAHsOmz4DMql0qlkfyoG0an/aax o=; X-IronPort-AV: E=McAfee;i="5300,2777,5600"; a="17618195" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 18:21:03 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3U1L3Zf031918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 18:21:03 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3U1Ksf2016293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Apr 2009 18:20:58 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Wed, 29 Apr 2009 18:20:54 -0700 From: "Edge, Stephen" To: "Thomson, Martin" , Richard Barnes , "Gellens, Randall" , Henning Schulzrinne , "Stark, Barbara" , ECRIT Date: Wed, 29 Apr 2009 18:20:53 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAQZkTAAA48OcA== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.com> References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 01:19:55 -0000 Martin You are one of those humming against the current statement. You seemingly d= on't believe that any statement of applicability or scope is needed (or am = I wrong?). Yet you have ducked my simple questions which are clearly releva= nt in that context. I would appreciate some answers to those questions - perhaps from others. Kind Regards Stephen -----Original Message----- From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 Sent: Wednesday, April 29, 2009 5:12 PM To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning Schulzrinne; S= tark, Barbara; ECRIT Subject: RE: [Ecrit] PhoneBCP Hi Stephen, I'm convinced that the ECRIT architecture is the only solution that will wo= rk for ALL forms of Internet access. I then offer you an alternative to the "applicability statement" you reques= t: Where you believe that the ECRIT architecture does not apply, state why. = Include also a description of why interworking with such an architecture i= s not necessary. The great thing about this is that you can do this in the forum of your cho= ice. You don't have to deal with the recalcitrant bunch at the IETF. In f= act, I'd encourage you to consider that approach. --Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Edge, Stephen > Sent: Thursday, 30 April 2009 9:23 AM > To: Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark, > Barbara; ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > Richard and all others >=20 > I wonder if those now humming against this statement (and who were all > strangely silent 5 weeks ago) would support any kind of statement > concerning applicability and scope. Or is it the case that the solution > supported by both drafts is considered to apply to all devices, ANs and > VSPs that provide some form of internet access. If so, is it irrelevant > whether the solution is actually suitable for a particular type of AN > or VSP (e.g. cellular AN, IMS based VSP)? For example, is it irrelevant > whether significant additional support from an AN or VSP to which the > solution might be applied would be needed in order to access legacy > PSAPs, handoff to the circuit domain, authenticate the caller and > provide access to non-subscribed users? Is it further irrelevant > whether the solution would even work for a particular device, AN or VSP > without substantial changes to the latter? In other words, is the > solution now considered so sacrosanct that any adaptation must come > from the rest of the > infrastructure and not from the solution itself in the case of any > mismatch? If the consensus answers to these questions are all yes, then > I would have to agree that including the currently disputed statement > or anything of a similar nature would be inconsistent and unnecessary. > Of course, the representatives of the potentially affected portions of > infrastructure should be forgiven for disagreeing with the basic > premise - and may be expected to offer some type of protest! >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, April 28, 2009 1:07 PM > To: Edge, Stephen > Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > Stephen, >=20 > As was noted in the meeting, it is *always* possible that there are > alternative solutions out there when you're talking about the Internet. > TCP vs. UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs. > XMPP, SASL vs. TLS, S/MIME vs. OpenPGP. None of the many RFCs out > there > have explicit statements that somebody else might do it differently > because it's obvious that they can. >=20 > So I don't really think conveying the possibility of other > implementations is actually useful at all, technically speaking. >=20 > That means that the only real purpose of such a statement is > rhetorical, > and as we've seen in a few messages here, some people misconstrue the > rhetoric to mean that this system has constrained applicability. Given > that, I'd rather leave it off unless we can avoid that impression. >=20 > --Richard >=20 >=20 >=20 >=20 > Edge, Stephen wrote: > > All > > > > I would have thought that motivation should be irrelevant. There are > a lot of motives at work here. Should we assume that the document was > originally written with only the purest and most altruistic motives > (e.g. no thought of business or academic interest at stake)? > > > > The issue is whether the current statement serves a useful purpose in > conveying the possibility (well known to be true) of alternative > solutions not fully aligned with the current drafts. Nothing in the > statement implies that the current drafts are necessarily deficient or > that alternative solutions must necessarily be used for some scenarios > (even though they optionally can be). > > > > Kind Regards > > > > Stephen > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of Randall Gellens > > Sent: Tuesday, April 28, 2009 9:57 AM > > To: Henning Schulzrinne; Stark, Barbara > > Cc: ECRIT > > Subject: Re: [Ecrit] PhoneBCP > > > > At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote: > > > >> It is clear that the text has ulterior motives to restrict the > >> applicability of the document. > > > > From my view, the text does not restrict the applicability, nor is > > there a desire to do so. The text does clarify the assumptions of > > the rest of the text in the document, which I think is helpful. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] From Martin.Thomson@andrew.com Wed Apr 29 20:47:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153563A68C5 for ; Wed, 29 Apr 2009 20:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3k04J1sO8Tb for ; Wed, 29 Apr 2009 20:47:43 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 613A53A6B15 for ; Wed, 29 Apr 2009 20:47:42 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_29_23_09_52 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Apr 2009 23:09:52 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 22:49:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Apr 2009 22:49:01 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAQZkTAAA48OcAAAJEUA References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.com> From: "Thomson, Martin" To: "Edge, Stephen" X-OriginalArrivalTime: 30 Apr 2009 03:49:04.0542 (UTC) FILETIME=[9B322BE0:01C9C946] Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 03:47:45 -0000 U3RlcGhlbiwNCg0KVGhlIGNvbnNlbnN1cyBjYWxsIHdhcyByZXF1ZXN0ZWQgc28gdGhhdCB3ZSBj b3VsZCBjbG9zZSB0aGlzIGlzc3VlLiAgV2hhdCB5b3UgcHJvcG9zZSBvbmx5IGFkZHMgZGVsYXlz LiAgWW91ciBxdWVzdGlvbnMgYXJlIGhhcmRseSAic2ltcGxlIi4gIE9uIHRoZSB3aG9sZSwgeW91 ciBxdWVzdGlvbnMgYXJlIGVpdGhlciBub3Qgb2YgaW50ZXJlc3QgdG8gdGhpcyBvcmdhbmlzYXRp b24gKGJ5IGRlZmluaXRpb24pLCBvciBjb25jbHVzaW9ucyBoYXZlIGFscmVhZHkgYmVlbiBhcnJp dmVkIGF0IHRvIHRoZSBzYXRpc2ZhY3Rpb24gb2YgbW9zdC4NCg0KQXNraW5nIGZvciBhbiBhcHBs aWNhYmlsaXR5IHN0YXRlbWVudCBpcyBhIG5pY2UsIGlubm9jdW91cyBzb3VuZGluZyByZXF1ZXN0 LiAgSXQncyBleHBlZGllbnQgYmVjYXVzZSB5b3UgY2FuIGxhYmVsIG9wcG9zaXRpb24gYXMgInVu cmVhc29uYWJsZSIuICBMYWJlbCBtZSB0aHVzIGFzIHlvdSB3aXNoLiAgSSd2ZSBzZWVuIGFwcGxp Y2FiaWxpdHkgc3RhdGVtZW50cyBhYnVzZWQgdG9vIG1hbnkgdGltZXMgYmVmb3JlLiAgSSBwcmVm ZXIgbm93IHRvIGxldCB0aGUgYXVkaWVuY2UgZGVjaWRlIHdoYXQgYSBzcGVjaWZpY2F0aW9uIGlz IGdvb2QgZm9yLCBiZWNhdXNlIHRoYXQncyB1c3VhbGx5IHByZXR0eSBjbGVhci4gIEFwcGxpY2Fi aWxpdHkgc3RhdGVtZW50cyBvbmx5IGFydGlmaWNpYWxseSBjb25zdHJhaW4gc2NvcGUuDQoNCg0K Rm9yIGludGVyZXN0LCBob3dldmVyLCBzaW5jZSB5b3UgYXNrZWQgZm9yIGFuc3dlcnMsIEknbGwg aHVtb3VyIHlvdS4uLg0KDQpROiAiSWYgc28sIGlzIGl0IGlycmVsZXZhbnQgd2hldGhlciB0aGUg c29sdXRpb24gaXMgYWN0dWFsbHkgc3VpdGFibGUgZm9yIGEgcGFydGljdWxhciB0eXBlIG9mIEFO IG9yIFZTUCAoZS5nLiBjZWxsdWxhciBBTiwgSU1TIGJhc2VkIFZTUCk/ICINCg0KQTogTXUgKFll cykuDQoNClRoaXMgaXMgYmV5b25kIHF1ZXN0aW9ucyBvZiAic3VpdGFiaWxpdHkiLiAgRUNSSVQg d2lsbCB3b3JrIGZvciBhbnkgQU4sIERldmljZSwgb3IgVlNQIHRoYXQgZm9sbG93cyB0aGUgKHF1 aXRlIGZyYW5rbHksIHNpbXBsZSkgcnVsZXMuICBUaGlzIG1pZ2h0IG5vdCBiZSBhbiAiZWFzeSIg c29sdXRpb24sIG9yIGEgSlNURC0wMzYtQiBsb29rYWxpa2UsIG9yIHdoYXRldmVyIHlvdSdkIGxp a2UgaXQgdG8gYmUuICBObyBzdXBlcmlvciBzb2x1dGlvbiBoYXMgYmVlbiBvZmZlcmVkIHRoYXQg bWVldHMgYWxsIHRoZSByZXF1aXJlbWVudHMuDQoNCk9mIGNvdXJzZSwgdGhlIHNvbHV0aW9uIGhh cyB0byBiZSBkZXBsb3lhYmxlLiAgQnV0IHRoYXQncyBuZXZlciBiZWVuIHRoZSBjb25jZXJuLCBo YXMgaXQ/DQoNCkkgaGF2ZSBldmVyeSBjb25maWRlbmNlIHRoYXQgRUNSSVQgY291bGQgYmUgZGVw bG95ZWQgaW4gYSAzR1BQIGFjY2VzcyBuZXR3b3JrLiAgSXQgbWlnaHQgZXZlbiB3b3JrIGFscmVh ZHkgaW4gc29tZSBuZXR3b3JrcywgYXMgbG9uZyBhcyBubyBzdGVwcyBoYXZlIGFscmVhZHkgYmVl biB0YWtlbiB0byBwcmV2ZW50IGl0LiAgR2l2ZSBtZSBNTy1MUiBhbmQgYW4gSVAgY29ubmVjdGlv biBhbmQgSSdtIGdvb2QgdG8gZ28uDQoNCkhvd2V2ZXIsIHRoYXQgZG9lc24ndCBwbGF5IHdlbGwg d2l0aCB2aXNpdG9ycyB0byB0aGUgbmV0d29yay4gIFVubGVzcyB5b3UgbWFpbnRhaW4gdGhlIGls bHVzaW9uIHRoYXQgeW91IGFyZSBhYmxlIHRvIGNvbnRyb2wgYWxsIGRldmljZXMgdGhhdCBlbnRl ciB5b3VyIG5ldHdvcmssIHlvdSB3aWxsIG5lZWQgdG8gc3VwcG9ydCB0aGUgbWVjaGFuaXNtcyB0 aGF0IHRoZXkgZXhwZWN0LiAgVGhhdCBpcywgYXMgbG9uZyBhcyBhIG5ldHdvcmsgcHJvdmlkZXMg SW50ZXJuZXQgYWNjZXNzLCBFQ1JJVCBzdXBwb3J0IGlzIG5lZWRlZCB0byBwcm92aWRlIGVtZXJn ZW5jeSBjYWxsaW5nLg0KDQpCVFcsIGEgTElTIGlzbid0IHJlYWxseSB2ZXJ5IGhhcmQgdG8gZGVw bG95IHdoZW4geW91IGFscmVhZHkgaGF2ZSBsb2NhdGlvbiBpbmZyYXN0cnVjdHVyZSwgaXQgbG9v a3MgYSBsaXR0bGUgbGlrZSBhIHByb3RvY29sIHRyYW5zbGF0b3IuICANCg0KVGhlcmUncyBhIHNp bWlsYXIgc3RvcnkgZm9yIHRoZSB2b2ljZSBzZXJ2aWNlLiAgTG9jYXRpb24tYmFzZWQgY2FsbCBy b3V0aW5nIGlzIG5vdCBlc3BlY2lhbGx5IGNvbXBsZXggdG8gaW1wbGVtZW50LiAgWW91IGNhbiBt YWtlIGl0IG1vcmUgY29tcGxpY2F0ZWQsIGJ1dCBvbmx5IGlmIHlvdSdkIHByZWZlciBpdCB0aGF0 IHdheS4NCg0KUTogIkZvciBleGFtcGxlLCBpcyBpdCBpcnJlbGV2YW50IHdoZXRoZXIgc2lnbmlm aWNhbnQgYWRkaXRpb25hbCBzdXBwb3J0IGZyb20gYW4gQU4gb3IgVlNQIHRvIHdoaWNoIHRoZSBz b2x1dGlvbiBtaWdodCBiZSBhcHBsaWVkIHdvdWxkIGJlIG5lZWRlZCBpbiBvcmRlciB0byBhY2Nl c3MgbGVnYWN5IFBTQVBzLCBoYW5kb2ZmIHRvIHRoZSBjaXJjdWl0IGRvbWFpbiwgYXV0aGVudGlj YXRlIHRoZSBjYWxsZXIgYW5kIHByb3ZpZGUgYWNjZXNzIHRvIG5vbi1zdWJzY3JpYmVkIHVzZXJz PyINCg0KQSAobGVnYWN5IFBTQVBzKTogWWVzLg0KDQpPZiBjb3Vyc2UsIHRoZSBxdWVzdGlvbiBv ZiBob3cgdG8gZGVhbCB3aXRoIGxlZ2FjeSBQU0FQcyBpcyBvbmUgb2YgaW50ZXJlc3QsIGJ1dCBp dCdzIGEgbm90IGEgcHJvYmxlbSB0aGF0IGhhcyBiZWVuIGlnbm9yZWQuICBSZWFkIE5FTkEgaTIg Zm9yIGEgZGVzY3JpcHRpb24gb24gaG93IHRoaXMgaXMgZG9uZS4gIChPaCB5ZWFoLCBhbmQgdGhl cmUgaXMgYSBnb29kIGNhc2Ugb2YgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgYmVpbmcgYWJ1 c2VkIC0gaTIgaXMgc3VwcG9zZWRseSBvbmx5IGFwcGxpY2FibGUgZm9yIG5vbi1tb2JpbGUgZGV2 aWNlcyAtIHdoaWNoIGlzIHdob2xseSBmYWxzZS4pDQoNCkEgKGNpcmN1aXQgaGFuZG9mZik6IFll cy4NCg0KQWdhaW4sIG5vdGhpbmcgc3RvcHMgeW91IGZyb20gd29ya2luZyB0aGlzIG9uZSBvdXQg aWYgeW91IGZlZWwgdGhhdCB3YXkgaW5jbGluZWQuICBUaGUgSUVURiBkb2VzIHRlbmQgdG8gbGlt aXQgaXRzIGNvbmNlcm5zIHRvIHRoZSBJbnRlcm5ldCB0aG91Z2gsIHNvIEkgd291bGRuJ3QgZXhw ZWN0IHRvIHNlZSBhbnkgc29sdXRpb24gdG8gdGhhdCBwcm9ibGVtIGhlcmUuICBJdCdzIGEgcHJv YmxlbSB0aGF0IGNvdWxkIHN0aWxsIGJlIHNvbHZlZCBpbiBhIGNvbXBhdGlibGUgd2F5Lg0KDQpU aGUgYmFzaWMgcGFyYWRpZ20gaXMgc3RpbGwgYXBwbGljYWJsZTogZGV2aWNlIGFjcXVpcmVzIGxv Y2F0aW9uLCBkZXZpY2UgZGV0ZXJtaW5lcyBkZXN0aW5hdGlvbiBQU0FQLCBkZXZpY2UgbWFrZXMg Y2FsbCwgd2l0aCB0aGUgY2F2ZWF0IHRoYXQgYW5vdGhlciBlbnRpdHkgY2FuIGFjdCBvbiBiZWhh bGYgb2YgdGhlIGRldmljZSBnaXZlbiBzdWZmaWNpZW50IGNvbnN0cmFpbnRzLg0KDQpBIChjYWxs ZXIgYXV0aGVudGljYXRpb24gYW5kIHVuYXV0aGVudGljYXRlZCBhY2Nlc3MpOiBNdSAoWWVzKS4N Cg0KT2J2aW91c2x5LCB0aGVyZSBhcmUgY29uY2VybnMgdG8gcmVzb2x2ZS4gIFdoaWNoIGRpZCBz b3J0IG9mIGF1dGhlbnRpY2F0aW9uIHdlcmUgeW91IHJlZmVycmluZyB0bz8gIEFOIG9yIFZTUD8g IE9yIGFyZSB3ZSBhdXRoZW50aWNhdGluZyB1c2VycyB0byBQU0FQcz8gIEFzIGZhciBhcyB0aGUg ZnJhbWV3b3JrIGlzIGNvbmNlcm5lZCwgdGhlc2UgYXJlIG5vdCBpbXBvcnRhbnQgcXVlc3Rpb25z IC0gcG9saWN5IChsZWdpc2xhdGlvbiwgdGVybXMgb2Ygc2VydmljZSBmb3IgQU4gYW5kIFZTUCkg ZGV0ZXJtaW5lIHdoYXQgbmVlZCwgaWYgYW55IGF1dGhlbnRpY2F0aW9uIGlzIHJlcXVpcmVkIGJl Zm9yZSBhY2Nlc3MgaXMgZ3JhbnRlZC4NCg0KUTogIklzIGl0IGZ1cnRoZXIgaXJyZWxldmFudCB3 aGV0aGVyIHRoZSBzb2x1dGlvbiB3b3VsZCBldmVuIHdvcmsgZm9yIGEgcGFydGljdWxhciBkZXZp Y2UsIEFOIG9yIFZTUCB3aXRob3V0IHN1YnN0YW50aWFsIGNoYW5nZXMgdG8gdGhlIGxhdHRlcj8g SW4gb3RoZXIgd29yZHMsIGlzIHRoZSBzb2x1dGlvbiBub3cgY29uc2lkZXJlZCBzbyBzYWNyb3Nh bmN0IHRoYXQgYW55IGFkYXB0YXRpb24gbXVzdCBjb21lIGZyb20gdGhlIHJlc3Qgb2YgdGhlIGlu ZnJhc3RydWN0dXJlIGFuZCBub3QgZnJvbSB0aGUgc29sdXRpb24gaXRzZWxmIGluIHRoZSBjYXNl IG9mIGFueSBtaXNtYXRjaD8iDQoNCkE6IFllcy4NCg0KVGhhdCBpcyB0aGUgd2F5IHlvdSBoYXZl IHRvIGRvIHRoZXNlIHRoaW5ncy4gIFdlIHBpY2sgYSBzb2x1dGlvbiwgYW5kIHRoZW4gZXZlcnlv bmUgbGl2ZXMgd2l0aCBpdC4gIFdlIGRvIG91ciBiZXN0IHRvIHBpY2sgYSBnb29kIHNvbHV0aW9u LCBidXQgdGhlcmUgaXMgbm8gcHJldGVuY2Ugb2YgaW5mYWxsaWJpbGl0eSwgb3IgYW55IGFzc3Vt cHRpb24gdGhhdCBhIHNvbHV0aW9uIGlzICJzYWNyb3NhbmN0Ii4gIEl0J3Mgbm90IGxpa2Ugd2Ug YXJlIGV4cGVjdGVkIHRvIHByb2R1Y2UgYSBwZXJmZWN0IHNvbHV0aW9uIG9uIHRoZSBmaXJzdCBh dHRlbXB0LiAgVGhlIGNvbW11bml0eSBpc24ndCBnb2luZyB0byBob2xkIHVzIHRvIHRoYXQgaW1w b3NzaWJsZSBzdGFuZGFyZC4gIElmIHRoZXJlIGlzIGEgcHJvYmxlbSBpbiB0aGUgZG9jdW1lbnQs IHdlJ2xsIGp1c3QgaGF2ZSB0byBmaXggaXQuDQoNCkkgZG9uJ3Qgc2VlIHRoYXQgdGhlcmUgaXMg YSBtaXNtYXRjaCwgYnV0IHRoZW4geW91IGNvbnRpbnVlIHRvIGltcGx5IHRoYXQgdGhlcmUgaXMu ICBFQ1JJVCBkb2VzIHNvbWV0aGluZyB0aGF0IGhhcyBub3QgYmVlbiBhdHRlbXB0ZWQgYmVmb3Jl OiBlbWVyZ2VuY3kgc2VydmljZXMgZm9yIHRoZSBlbnRpcmUgSW50ZXJuZXQuICBZb3UgY2FuJ3Qg cmVhc29uYWJseSBleHBlY3QgdGhlcmUgdG8gYmUgYW4gZXhpc3Rpbmcgc29sdXRpb24gdG8gdGhl IHByb2JsZW0uICBUaGF0IG1lYW5zIGNoYW5nZXMgdG8gZXhpc3RpbmcgbmV0d29ya3MgaWYgdGhl eSB3YW50IHRvIGJlIHBhcnQgb2YgdGhlIHNvbHV0aW9uLg0KDQoNClNpbmNlIEkndmUgYW5zd2Vy ZWQgeWVzIHRvIGFsbCB0aGUgcmVsZXZhbnQgcXVlc3Rpb25zLCBJIGNvbmNsdWRlIHRoYXQgdGhl IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGlzICJpbmNvbnNpc3RlbnQgYW5kIHVubmVjZXNzYXJ5 Ii4gIFRoZSByZWFzb25zIEkgcHJldmlvdXNseSBzdGF0ZWQgc3RpbGwgZXF1YWxseSBhcHBseS4N Cg0KLS1NYXJ0aW4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEVk Z2UsIFN0ZXBoZW4gW21haWx0bzpzZWRnZUBxdWFsY29tbS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5 LCAzMCBBcHJpbCAyMDA5IDExOjIxIEFNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47IFJpY2hhcmQg QmFybmVzOyBHZWxsZW5zLCBSYW5kYWxsOyBIZW5uaW5nDQo+IFNjaHVsenJpbm5lOyBTdGFyaywg QmFyYmFyYTsgRUNSSVQNCj4gU3ViamVjdDogUkU6IFtFY3JpdF0gUGhvbmVCQ1ANCj4gDQo+IE1h cnRpbg0KPiANCj4gWW91IGFyZSBvbmUgb2YgdGhvc2UgaHVtbWluZyBhZ2FpbnN0IHRoZSBjdXJy ZW50IHN0YXRlbWVudC4gWW91DQo+IHNlZW1pbmdseSBkb24ndCBiZWxpZXZlIHRoYXQgYW55IHN0 YXRlbWVudCBvZiBhcHBsaWNhYmlsaXR5IG9yIHNjb3BlIGlzDQo+IG5lZWRlZCAob3IgYW0gSSB3 cm9uZz8pLiBZZXQgeW91IGhhdmUgZHVja2VkIG15IHNpbXBsZSBxdWVzdGlvbnMgd2hpY2gNCj4g YXJlIGNsZWFybHkgcmVsZXZhbnQgaW4gdGhhdCBjb250ZXh0Lg0KPiANCj4gSSB3b3VsZCBhcHBy ZWNpYXRlIHNvbWUgYW5zd2VycyB0byB0aG9zZSBxdWVzdGlvbnMgLSBwZXJoYXBzIGZyb20NCj4g b3RoZXJzLg0KPiANCj4gS2luZCBSZWdhcmRzDQo+IA0KPiBTdGVwaGVuDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRob21zb24sIE1hcnRpbiBbbWFpbHRvOk1hcnRpbi5U aG9tc29uQGFuZHJldy5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMDkgNTox MiBQTQ0KPiBUbzogRWRnZSwgU3RlcGhlbjsgUmljaGFyZCBCYXJuZXM7IEdlbGxlbnMsIFJhbmRh bGw7IEhlbm5pbmcNCj4gU2NodWx6cmlubmU7IFN0YXJrLCBCYXJiYXJhOyBFQ1JJVA0KPiBTdWJq ZWN0OiBSRTogW0Vjcml0XSBQaG9uZUJDUA0KPiANCj4gSGkgU3RlcGhlbiwNCj4gDQo+IEknbSBj b252aW5jZWQgdGhhdCB0aGUgRUNSSVQgYXJjaGl0ZWN0dXJlIGlzIHRoZSBvbmx5IHNvbHV0aW9u IHRoYXQNCj4gd2lsbCB3b3JrIGZvciBBTEwgZm9ybXMgb2YgSW50ZXJuZXQgYWNjZXNzLg0KPiAN Cj4gSSB0aGVuIG9mZmVyIHlvdSBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgImFwcGxpY2FiaWxpdHkg c3RhdGVtZW50IiB5b3UNCj4gcmVxdWVzdDoNCj4gDQo+ICAgV2hlcmUgeW91IGJlbGlldmUgdGhh dCB0aGUgRUNSSVQgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IGFwcGx5LCBzdGF0ZQ0KPiB3aHkuICBJ bmNsdWRlIGFsc28gYSBkZXNjcmlwdGlvbiBvZiB3aHkgaW50ZXJ3b3JraW5nIHdpdGggc3VjaCBh bg0KPiBhcmNoaXRlY3R1cmUgaXMgbm90IG5lY2Vzc2FyeS4NCj4gDQo+IFRoZSBncmVhdCB0aGlu ZyBhYm91dCB0aGlzIGlzIHRoYXQgeW91IGNhbiBkbyB0aGlzIGluIHRoZSBmb3J1bSBvZiB5b3Vy DQo+IGNob2ljZS4gIFlvdSBkb24ndCBoYXZlIHRvIGRlYWwgd2l0aCB0aGUgcmVjYWxjaXRyYW50 IGJ1bmNoIGF0IHRoZQ0KPiBJRVRGLiAgSW4gZmFjdCwgSSdkIGVuY291cmFnZSB5b3UgdG8gY29u c2lkZXIgdGhhdCBhcHByb2FjaC4NCj4gDQo+IC0tTWFydGluDQo+IA0KPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+IE9mIEVkZ2UsIFN0ZXBo ZW4NCj4gPiBTZW50OiBUaHVyc2RheSwgMzAgQXByaWwgMjAwOSA5OjIzIEFNDQo+ID4gVG86IFJp Y2hhcmQgQmFybmVzOyBHZWxsZW5zLCBSYW5kYWxsOyBIZW5uaW5nIFNjaHVsenJpbm5lOyBTdGFy aywNCj4gPiBCYXJiYXJhOyBFQ1JJVA0KPiA+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIFBob25lQkNQ DQo+ID4NCj4gPiBSaWNoYXJkIGFuZCBhbGwgb3RoZXJzDQo+ID4NCj4gPiBJIHdvbmRlciBpZiB0 aG9zZSBub3cgaHVtbWluZyBhZ2FpbnN0IHRoaXMgc3RhdGVtZW50IChhbmQgd2hvIHdlcmUNCj4g YWxsDQo+ID4gc3RyYW5nZWx5IHNpbGVudCA1IHdlZWtzIGFnbykgd291bGQgc3VwcG9ydCBhbnkg a2luZCBvZiBzdGF0ZW1lbnQNCj4gPiBjb25jZXJuaW5nIGFwcGxpY2FiaWxpdHkgYW5kIHNjb3Bl LiBPciBpcyBpdCB0aGUgY2FzZSB0aGF0IHRoZQ0KPiBzb2x1dGlvbg0KPiA+IHN1cHBvcnRlZCBi eSBib3RoIGRyYWZ0cyBpcyBjb25zaWRlcmVkIHRvIGFwcGx5IHRvIGFsbCBkZXZpY2VzLCBBTnMN Cj4gYW5kDQo+ID4gVlNQcyB0aGF0IHByb3ZpZGUgc29tZSBmb3JtIG9mIGludGVybmV0IGFjY2Vz cy4gSWYgc28sIGlzIGl0DQo+IGlycmVsZXZhbnQNCj4gPiB3aGV0aGVyIHRoZSBzb2x1dGlvbiBp cyBhY3R1YWxseSBzdWl0YWJsZSBmb3IgYSBwYXJ0aWN1bGFyIHR5cGUgb2YgQU4NCj4gPiBvciBW U1AgKGUuZy4gY2VsbHVsYXIgQU4sIElNUyBiYXNlZCBWU1ApPyBGb3IgZXhhbXBsZSwgaXMgaXQN Cj4gaXJyZWxldmFudA0KPiA+IHdoZXRoZXIgc2lnbmlmaWNhbnQgYWRkaXRpb25hbCBzdXBwb3J0 IGZyb20gYW4gQU4gb3IgVlNQIHRvIHdoaWNoIHRoZQ0KPiA+IHNvbHV0aW9uIG1pZ2h0IGJlIGFw cGxpZWQgd291bGQgYmUgbmVlZGVkIGluIG9yZGVyIHRvIGFjY2VzcyBsZWdhY3kNCj4gPiBQU0FQ cywgaGFuZG9mZiB0byB0aGUgY2lyY3VpdCBkb21haW4sIGF1dGhlbnRpY2F0ZSB0aGUgY2FsbGVy IGFuZA0KPiA+IHByb3ZpZGUgYWNjZXNzIHRvIG5vbi1zdWJzY3JpYmVkIHVzZXJzPyBJcyBpdCBm dXJ0aGVyIGlycmVsZXZhbnQNCj4gPiB3aGV0aGVyIHRoZSBzb2x1dGlvbiB3b3VsZCBldmVuIHdv cmsgZm9yIGEgcGFydGljdWxhciBkZXZpY2UsIEFOIG9yDQo+IFZTUA0KPiA+IHdpdGhvdXQgc3Vi c3RhbnRpYWwgY2hhbmdlcyB0byB0aGUgbGF0dGVyPyBJbiBvdGhlciB3b3JkcywgaXMgdGhlDQo+ ID4gc29sdXRpb24gbm93IGNvbnNpZGVyZWQgc28gc2Fjcm9zYW5jdCB0aGF0IGFueSBhZGFwdGF0 aW9uIG11c3QgY29tZQ0KPiA+IGZyb20gdGhlIHJlc3Qgb2YgdGhlDQo+ID4gICBpbmZyYXN0cnVj dHVyZSBhbmQgbm90IGZyb20gdGhlIHNvbHV0aW9uIGl0c2VsZiBpbiB0aGUgY2FzZSBvZiBhbnkN Cj4gPiBtaXNtYXRjaD8gSWYgdGhlIGNvbnNlbnN1cyBhbnN3ZXJzIHRvIHRoZXNlIHF1ZXN0aW9u cyBhcmUgYWxsIHllcywNCj4gdGhlbg0KPiA+IEkgd291bGQgaGF2ZSB0byBhZ3JlZSB0aGF0IGlu Y2x1ZGluZyB0aGUgY3VycmVudGx5IGRpc3B1dGVkIHN0YXRlbWVudA0KPiA+IG9yIGFueXRoaW5n IG9mIGEgc2ltaWxhciBuYXR1cmUgd291bGQgYmUgaW5jb25zaXN0ZW50IGFuZA0KPiB1bm5lY2Vz c2FyeS4NCj4gPiBPZiBjb3Vyc2UsIHRoZSByZXByZXNlbnRhdGl2ZXMgb2YgdGhlIHBvdGVudGlh bGx5IGFmZmVjdGVkIHBvcnRpb25zDQo+IG9mDQo+ID4gaW5mcmFzdHJ1Y3R1cmUgc2hvdWxkIGJl IGZvcmdpdmVuIGZvciBkaXNhZ3JlZWluZyB3aXRoIHRoZSBiYXNpYw0KPiA+IHByZW1pc2UgLSBh bmQgbWF5IGJlIGV4cGVjdGVkIHRvIG9mZmVyIHNvbWUgdHlwZSBvZiBwcm90ZXN0IQ0KPiA+DQo+ ID4gS2luZCBSZWdhcmRzDQo+ID4NCj4gPiBTdGVwaGVuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVk IHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnks IG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQg ZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWls IGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClttZjJdDQo= From James.Winterbottom@andrew.com Wed Apr 29 20:58:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E133A6825 for ; Wed, 29 Apr 2009 20:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGxcj-qZL50H for ; Wed, 29 Apr 2009 20:58:15 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 523E23A67F4 for ; Wed, 29 Apr 2009 20:58:15 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_29_23_20_26 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Apr 2009 23:20:25 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 22:59:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 22:59:35 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAOvt4A= References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Edge, Stephen" , "Richard Barnes" , "Gellens, Randall" , "Henning Schulzrinne" , "Stark, Barbara" , "ECRIT" X-OriginalArrivalTime: 30 Apr 2009 03:59:37.0811 (UTC) FILETIME=[14A75A30:01C9C948] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 03:58:16 -0000 Stephen,=0D=0A=0D=0AAs someone that has been vocal on this topic all along = I will respond.=0D=0A=0D=0AWould you agree that this solution does allow th= e ultimate destination=0D=0Aof the PSAP being reached using legacy TDM trun= ks=3F=20=0D=0AIf you want to take the debate offline I can clearly show to = you the=0D=0Asolution does, and as preparation please take a look at some o= f the NENA=0D=0Ai3 and i2 work.=0D=0A=0D=0ASo this makes quite a lot of you= r argument below irrelevant.=0D=0A=0D=0AYou have continually argued that th= ere is something special about IMS=0D=0Aand cellular despite continual evid= ence being presented that there is=0D=0Anot. Voice is not special when it c= omes to IP traffic, it is just=0D=0Aanother data stream. What you are doing= is coming here and saying that=0D=0A3GPP are introducing a whole bunch of = complex machinations to maintain a=0D=0Abundling of access and service, so = please would we put an applicability=0D=0Astatement into our documents to s= ay that they don't apply to 3GPP=0D=0Anetworks. This is unreasonable.=0D=0A=0D= =0AIf I read 23.167 correctly, then the calling device can obtain its=0D=0A= location directly from the IP CAN, at least one of the IETF LCP is even=0D=0A= mentioned, and I have seen a CR that suggested that HELD could also be=0D=0A= used.=0D=0A=0D=0A23.167 also makes use of SIP location conveyance. So far, = this is 2 of=0D=0Athe 3 elements we require for ECRIT to just work.=0D=0A=0D= =0AI think it is perfectly reasonable to assume that if I get my location=0D= =0Afrom the IP CAN, I can probably get the serving domain also, in which=0D= =0Acase I can do a LoST lookup. Alternatively I can go back to my home LoST=0D= =0Aserver and rely on forest guides. In either case, these are quite=0D=0Ar= easonable assumptions, and the onus on an infrastructure provider is a=0D=0A= provisioning record, rather than E-SLP.... hmmmm which is cheaper and=0D=0A= easier I wonder=3F=0D=0A=0D=0ANow what does TS23.167 say to do if my SIP cl= ient directs a call to a=0D=0AURI that it obtained from a LoST Server=3F=0D= =0AI would place odds that it would just deliver the call.=0D=0A=0D=0AFurth= er more, if that SIP INVITE included both a CID header and a=0D=0Alocation = URI what happens=3F For i2 and i3 we know what happens. Again,=0D=0Athe LRF= in 23.167 at a minimum will provide a route to the PSAP based on=0D=0Athe = provided location.=0D=0A=0D=0ANow, lets take Martin's argument a bit more.=0D= =0AI have a device that can operate on 3G, 4G or WiFi. If it connect to a=0D= =0Anon-IMS WiFi hotspot (basically all of them) what happens=3F Where is th= e=0D=0AE-CSCF, where is the E-SLP, how can it help me=3F=0D=0A=0D=0AThe poi= nt I am making is that ECRIT will actually work even in IMS=0D=0Aarchitectu= res, but the IMS architecture doesn't work in the vast=0D=0Amajority of IP = cases. Any applicability statement you want please go and=0D=0Aadd it to 3G= PP and not here, it is 3GPP that has the applicability=0D=0Aissues and not = the IETF.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=20=0D=0A=0D=0A-----Original Me= ssage-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf=0D=0AOf Edge, Stephen=0D=0ASent: Thursday, 30 April 2009 9:23 A= M=0D=0ATo: Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark,=0D= =0ABarbara; ECRIT=0D=0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0ARichard and= all others=0D=0A=0D=0AI wonder if those now humming against this statement= (and who were all=0D=0Astrangely silent 5 weeks ago) would support any kin= d of statement=0D=0Aconcerning applicability and scope. Or is it the case t= hat the solution=0D=0Asupported by both drafts is considered to apply to al= l devices, ANs and=0D=0AVSPs that provide some form of internet access. If = so, is it irrelevant=0D=0Awhether the solution is actually suitable for a p= articular type of AN or=0D=0AVSP (e.g. cellular AN, IMS based VSP)=3F For e= xample, is it irrelevant=0D=0Awhether significant additional support from a= n AN or VSP to which the=0D=0Asolution might be applied would be needed in = order to access legacy=0D=0APSAPs, handoff to the circuit domain, authentic= ate the caller and=0D=0Aprovide access to non-subscribed users=3F Is it fur= ther irrelevant whether=0D=0Athe solution would even work for a particular = device, AN or VSP without=0D=0Asubstantial changes to the latter=3F In othe= r words, is the solution now=0D=0Aconsidered so sacrosanct that any adaptat= ion must come from the rest of=0D=0Athe=0D=0A infrastructure and not from = the solution itself in the case of any=0D=0Amismatch=3F If the consensus an= swers to these questions are all yes, then=0D=0AI would have to agree that = including the currently disputed statement or=0D=0Aanything of a similar na= ture would be inconsistent and unnecessary. Of=0D=0Acourse, the representat= ives of the potentially affected portions of=0D=0Ainfrastructure should be = forgiven for disagreeing with the basic premise=0D=0A- and may be expected = to offer some type of protest!=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D= =0A-----Original Message-----=0D=0AFrom: Richard Barnes [mailto:rbarnes@bbn= =2Ecom]=20=0D=0ASent: Tuesday, April 28, 2009 1:07 PM=0D=0ATo: Edge, Stephe= n=0D=0ACc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT=0D=0A= Subject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0AStephen,=0D=0A=0D=0AAs was noted i= n the meeting, it is *always* possible that there are=20=0D=0Aalternative s= olutions out there when you're talking about the Internet.=20=0D=0A TCP vs= =2E UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs.=20=0D=0AXMPP= , SASL vs. TLS, S/MIME vs. OpenPGP. None of the many RFCs out there=0D=0A=0D= =0Ahave explicit statements that somebody else might do it differently=20=0D= =0Abecause it's obvious that they can.=0D=0A=0D=0ASo I don't really think c= onveying the possibility of other=20=0D=0Aimplementations is actually usefu= l at all, technically speaking.=0D=0A=0D=0AThat means that the only real pu= rpose of such a statement is rhetorical,=0D=0A=0D=0Aand as we've seen in a = few messages here, some people misconstrue the=20=0D=0Arhetoric to mean tha= t this system has constrained applicability. Given=20=0D=0Athat, I'd rathe= r leave it off unless we can avoid that impression.=0D=0A=0D=0A--Richard=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0AEdge, Stephen wrote:=0D=0A> All=0D=0A>=20=0D=0A>= I would have thought that motivation should be irrelevant. There are a=0D=0A= lot of motives at work here. Should we assume that the document was=0D=0Aor= iginally written with only the purest and most altruistic motives=0D=0A(e.g= =2E no thought of business or academic interest at stake)=3F=0D=0A>=20=0D=0A= > The issue is whether the current statement serves a useful purpose in=0D=0A= conveying the possibility (well known to be true) of alternative=0D=0Asolut= ions not fully aligned with the current drafts. Nothing in the=0D=0Astateme= nt implies that the current drafts are necessarily deficient or=0D=0Athat a= lternative solutions must necessarily be used for some scenarios=0D=0A(even= though they optionally can be).=0D=0A>=20=0D=0A> Kind Regards=0D=0A>=20=0D= =0A> Stephen=0D=0A> -----Original Message-----=0D=0A> From: ecrit-bounces@i= etf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Randall Gellens=0D= =0A> Sent: Tuesday, April 28, 2009 9:57 AM=0D=0A> To: Henning Schulzrinne; = Stark, Barbara=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] PhoneBCP=0D=0A>= =20=0D=0A> At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote:=0D=0A>=20=0D= =0A>> It is clear that the text has ulterior motives to restrict the=20=0D= =0A>> applicability of the document.=0D=0A>=20=0D=0A> From my view, the te= xt does not restrict the applicability, nor is=20=0D=0A> there a desire to = do so. The text does clarify the assumptions of=20=0D=0A> the rest of the = text in the document, which I think is helpful.=0D=0A>=20=0D=0A____________= ___________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf= =2Eorg=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0AThis message is for the designated recipient only and ma= y=0D=0Acontain privileged, proprietary, or otherwise private information. =0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A From sedge@qualcomm.com Thu Apr 30 00:12:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCB43A657C for ; Thu, 30 Apr 2009 00:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leEagDqBzppA for ; Thu, 30 Apr 2009 00:12:26 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 12FF33A6784 for ; Thu, 30 Apr 2009 00:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241075629; x=1272611629; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Thomson,=20Martin"=20,=20ECRIT =20|Date:=20Thu,=2030=20Apr=202009=2000:1 3:45=20-0700|Subject:=20RE:=20[Ecrit]=20PhoneBCP |Thread-Topic:=20[Ecrit]=20PhoneBCP|Thread-Index:=20AcnIP OEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAQZkTAAA48OcAAAJEUAAApK7Q A=3D|Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC5926A 4B2@NASANEXMB04.na.qualcomm.com>|References:=20<49F27637.7050201@bbn.com><058701c9c5d0$53c5ef4 0$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590B D8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3F A0E0471BA@crexc41p><1 288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qu alcomm.com><49F761CC.3090902@bbn.com>=0D=0A=20<1288E74A73 964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.co m>=0D=0A=20=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC5 926A498@NASANEXMB04.na.qualcomm.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5600"=3B=20a=3D"17620853"; bh=M3qCbZVjk4Lngrsh35RON0d0FF4j/hKEccn44POeIvs=; b=p3KYH81VA8fLOq2Ik5E+G1H3DsCu8Sv8zu/q01T3LBBgjxlaceapnPt/ lCWec4qSN4OZnlbRh3uqfOszi4ZDwTRG/ap8qDw1a3nj5GbrG9dfXsDhn SmTJeZnkkI+/acplrMBwiZnywyEaEWDDXYSwyG3yASuXqk2pkAZ2KkHSJ 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5600"; a="17620853" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 00:13:48 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3U7DmUo007550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 00:13:48 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3U7DlI6015348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Apr 2009 00:13:48 -0700 (PDT) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Thu, 30 Apr 2009 00:13:48 -0700 From: "Edge, Stephen" To: "Thomson, Martin" , ECRIT Date: Thu, 30 Apr 2009 00:13:45 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAQZkTAAA48OcAAAJEUAAApK7QA= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.com> References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:12:27 -0000 Martin Thanks for the detailed reply. Actually the current delay (if any) is due t= o those now humming No to a statement added 5 weeks ago following support f= rom a number of others who in general continue to support the statement now= . I am in fact not proposing anything new at this moment. Your interpretation of applicability is certainly extreme (yes or qualified= yes to all questions) - removing any dependence on suitability or feasibil= ity (which are the more normal benchmarks) and simply making a legalistic b= lanket assertion. (I can now more understand incidentally why the fictitiou= s protocol police are so often invoked on matters of conformance.) But do others have any views on this? Kind Regards Stephen -----Original Message----- From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 Sent: Wednesday, April 29, 2009 8:49 PM To: Edge, Stephen Cc: ECRIT Subject: RE: [Ecrit] PhoneBCP Stephen, The consensus call was requested so that we could close this issue. What y= ou propose only adds delays. Your questions are hardly "simple". On the w= hole, your questions are either not of interest to this organisation (by de= finition), or conclusions have already been arrived at to the satisfaction = of most. Asking for an applicability statement is a nice, innocuous sounding request= . It's expedient because you can label opposition as "unreasonable". Labe= l me thus as you wish. I've seen applicability statements abused too many = times before. I prefer now to let the audience decide what a specification= is good for, because that's usually pretty clear. Applicability statement= s only artificially constrain scope. For interest, however, since you asked for answers, I'll humour you... Q: "If so, is it irrelevant whether the solution is actually suitable for a= particular type of AN or VSP (e.g. cellular AN, IMS based VSP)? " A: Mu (Yes). This is beyond questions of "suitability". ECRIT will work for any AN, Dev= ice, or VSP that follows the (quite frankly, simple) rules. This might not= be an "easy" solution, or a JSTD-036-B lookalike, or whatever you'd like i= t to be. No superior solution has been offered that meets all the requirem= ents. Of course, the solution has to be deployable. But that's never been the co= ncern, has it? I have every confidence that ECRIT could be deployed in a 3GPP access netwo= rk. It might even work already in some networks, as long as no steps have = already been taken to prevent it. Give me MO-LR and an IP connection and I= 'm good to go. However, that doesn't play well with visitors to the network. Unless you m= aintain the illusion that you are able to control all devices that enter yo= ur network, you will need to support the mechanisms that they expect. That= is, as long as a network provides Internet access, ECRIT support is needed= to provide emergency calling. BTW, a LIS isn't really very hard to deploy when you already have location = infrastructure, it looks a little like a protocol translator. =20 There's a similar story for the voice service. Location-based call routing= is not especially complex to implement. You can make it more complicated,= but only if you'd prefer it that way. Q: "For example, is it irrelevant whether significant additional support fr= om an AN or VSP to which the solution might be applied would be needed in o= rder to access legacy PSAPs, handoff to the circuit domain, authenticate th= e caller and provide access to non-subscribed users?" A (legacy PSAPs): Yes. Of course, the question of how to deal with legacy PSAPs is one of interest= , but it's a not a problem that has been ignored. Read NENA i2 for a descr= iption on how this is done. (Oh yeah, and there is a good case of an appli= cability statement being abused - i2 is supposedly only applicable for non-= mobile devices - which is wholly false.) A (circuit handoff): Yes. Again, nothing stops you from working this one out if you feel that way inc= lined. The IETF does tend to limit its concerns to the Internet though, so= I wouldn't expect to see any solution to that problem here. It's a proble= m that could still be solved in a compatible way. The basic paradigm is still applicable: device acquires location, device de= termines destination PSAP, device makes call, with the caveat that another = entity can act on behalf of the device given sufficient constraints. A (caller authentication and unauthenticated access): Mu (Yes). Obviously, there are concerns to resolve. Which did sort of authentication= were you referring to? AN or VSP? Or are we authenticating users to PSAP= s? As far as the framework is concerned, these are not important questions= - policy (legislation, terms of service for AN and VSP) determine what nee= d, if any authentication is required before access is granted. Q: "Is it further irrelevant whether the solution would even work for a par= ticular device, AN or VSP without substantial changes to the latter? In oth= er words, is the solution now considered so sacrosanct that any adaptation = must come from the rest of the infrastructure and not from the solution its= elf in the case of any mismatch?" A: Yes. That is the way you have to do these things. We pick a solution, and then = everyone lives with it. We do our best to pick a good solution, but there = is no pretence of infallibility, or any assumption that a solution is "sacr= osanct". It's not like we are expected to produce a perfect solution on th= e first attempt. The community isn't going to hold us to that impossible s= tandard. If there is a problem in the document, we'll just have to fix it. I don't see that there is a mismatch, but then you continue to imply that t= here is. ECRIT does something that has not been attempted before: emergenc= y services for the entire Internet. You can't reasonably expect there to b= e an existing solution to the problem. That means changes to existing netw= orks if they want to be part of the solution. Since I've answered yes to all the relevant questions, I conclude that the = applicability statement is "inconsistent and unnecessary". The reasons I p= reviously stated still equally apply. --Martin > -----Original Message----- > From: Edge, Stephen [mailto:sedge@qualcomm.com] > Sent: Thursday, 30 April 2009 11:21 AM > To: Thomson, Martin; Richard Barnes; Gellens, Randall; Henning > Schulzrinne; Stark, Barbara; ECRIT > Subject: RE: [Ecrit] PhoneBCP >=20 > Martin >=20 > You are one of those humming against the current statement. You > seemingly don't believe that any statement of applicability or scope is > needed (or am I wrong?). Yet you have ducked my simple questions which > are clearly relevant in that context. >=20 > I would appreciate some answers to those questions - perhaps from > others. >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Wednesday, April 29, 2009 5:12 PM > To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning > Schulzrinne; Stark, Barbara; ECRIT > Subject: RE: [Ecrit] PhoneBCP >=20 > Hi Stephen, >=20 > I'm convinced that the ECRIT architecture is the only solution that > will work for ALL forms of Internet access. >=20 > I then offer you an alternative to the "applicability statement" you > request: >=20 > Where you believe that the ECRIT architecture does not apply, state > why. Include also a description of why interworking with such an > architecture is not necessary. >=20 > The great thing about this is that you can do this in the forum of your > choice. You don't have to deal with the recalcitrant bunch at the > IETF. In fact, I'd encourage you to consider that approach. >=20 > --Martin >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of Edge, Stephen > > Sent: Thursday, 30 April 2009 9:23 AM > > To: Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark, > > Barbara; ECRIT > > Subject: Re: [Ecrit] PhoneBCP > > > > Richard and all others > > > > I wonder if those now humming against this statement (and who were > all > > strangely silent 5 weeks ago) would support any kind of statement > > concerning applicability and scope. Or is it the case that the > solution > > supported by both drafts is considered to apply to all devices, ANs > and > > VSPs that provide some form of internet access. If so, is it > irrelevant > > whether the solution is actually suitable for a particular type of AN > > or VSP (e.g. cellular AN, IMS based VSP)? For example, is it > irrelevant > > whether significant additional support from an AN or VSP to which the > > solution might be applied would be needed in order to access legacy > > PSAPs, handoff to the circuit domain, authenticate the caller and > > provide access to non-subscribed users? Is it further irrelevant > > whether the solution would even work for a particular device, AN or > VSP > > without substantial changes to the latter? In other words, is the > > solution now considered so sacrosanct that any adaptation must come > > from the rest of the > > infrastructure and not from the solution itself in the case of any > > mismatch? If the consensus answers to these questions are all yes, > then > > I would have to agree that including the currently disputed statement > > or anything of a similar nature would be inconsistent and > unnecessary. > > Of course, the representatives of the potentially affected portions > of > > infrastructure should be forgiven for disagreeing with the basic > > premise - and may be expected to offer some type of protest! > > > > Kind Regards > > > > Stephen ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] From khwolf1@gmail.com Thu Apr 30 00:13:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9A83A69F6 for ; Thu, 30 Apr 2009 00:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E3NQ2+UlLip for ; Thu, 30 Apr 2009 00:13:09 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 893DB3A6784 for ; Thu, 30 Apr 2009 00:13:09 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1718527qwe.31 for ; Thu, 30 Apr 2009 00:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5eyxj3E7b4iW5sg2I9g3q7mgjLhgVVvWzq5Hea+ghQs=; b=qo2tJIhGqEOk3Y79OGlspMYAJj3wfERp6ZMr6nkYB0No7V2euuu2sJOhLEOG6wleqA qAPjlKabmSeNL5MTKRfRfNX1ihOASQqOcu0CYThFwPqMN877J/6FZIPFPL1BljvS8l05 F0BVJCRF+ZxXirLxFtCzqueC0Tleg1iN6Vu+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ax81kEmskRlycJzSocgNCwqG0HeIf4s/kdPRO+UTaokvZCfveL+xOQAKGJgc0kzj8f 6zpkcQP5e+cPfoi4OYks00J8DiANbOF/1FxBuZfe/5wtcALAOmE89iwgOyaOtDKodoal mqunG90BUKweefQGeoxufRAtdV2dIGjNybeys= MIME-Version: 1.0 Received: by 10.220.74.4 with SMTP id s4mr2686238vcj.18.1241075671958; Thu, 30 Apr 2009 00:14:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Apr 2009 09:14:31 +0200 Message-ID: From: Karl Heinz Wolf To: Marc Linsner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:13:10 -0000 +1 Besides, ED-6 isn't back. editorial: ED-9 isn't exactly the same text on it's two occurrences. karl heinz On Wed, Apr 29, 2009 at 8:59 PM, Marc Linsner wrote: > [chair hat off] > > +1 > > -Marc- > > > On 4/27/09 9:42 AM, "Henning Schulzrinne" wrote: > >> +1 >> >> On Apr 27, 2009, at 8:34 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >>> I hum against the applicability statement. I cannot see why we need >>> one. >>> >>> >>> Ciao >>> Hannes >>> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From sedge@qualcomm.com Thu Apr 30 00:33:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE6C3A6A6C for ; Thu, 30 Apr 2009 00:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.525 X-Spam-Level: X-Spam-Status: No, score=-103.525 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSVngD3F1Y17 for ; Thu, 30 Apr 2009 00:33:53 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3E0EE3A6860 for ; Thu, 30 Apr 2009 00:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241076916; x=1272612916; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Winterbottom,=20James"=20, =0D=0A=20=20=20=20=20=20=20=20Richard=20Barnes=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"Gellens, =20Randall"=20,=0D=0A=20=20=20=20=20 =20=20=20Henning=0D=0A=20Schulzrinne=20,=0D=0A=20=20=20=20=20=20=20=20"Stark,=20Barbara"=20,=20ECRIT=0D=0A=09|Date:=20 Thu,=2030=20Apr=202009=2000:35:10=20-0700|Subject:=20RE: =20[Ecrit]=20PhoneBCP|Thread-Topic:=20[Ecrit]=20PhoneBCP |Thread-Index:=20AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAOv t4AAEIpT0A=3D=3D|Message-ID:=20<1288E74A73964940B132A0B9E A8D8ABC5926A4B4@NASANEXMB04.na.qualcomm.com>|References: =20<49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4 A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-luc ent.com><7582BC68E 4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926 A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.co m>=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC5926A470@NASA NEXMB04.na.qualcomm.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5600"=3B=20a=3D"17621317"; bh=X/Xv1jg2N76A1ngBRyaWUnGaRsc+QFVMQhs5gGBqBPY=; b=SsCRAlHVa+Q+fxtjgxJlbQ28Gk88DfXsNuqhaH+Obi0Ae0hzpIwjvU7o HmGv5J9UN+mvBZav5N9jvrso+W57kxCsRuwGIhs5vnEZ7bwjNIYSJpJbY tgAKvaJY65KW/5hTrpVRuhLz8QMOk4xnd62qi/9bo6hDvu4ALHVi591ow I=; X-IronPort-AV: E=McAfee;i="5300,2777,5600"; a="17621317" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 00:35:15 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3U7ZFHn027133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 00:35:15 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3U7ZCQd017243 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Apr 2009 00:35:15 -0700 (PDT) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Thu, 30 Apr 2009 00:35:12 -0700 From: "Edge, Stephen" To: "Winterbottom, James" , Richard Barnes , "Gellens, Randall" , Henning Schulzrinne , "Stark, Barbara" , ECRIT Date: Thu, 30 Apr 2009 00:35:10 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAOvt4AAEIpT0A== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A4B4@NASANEXMB04.na.qualcomm.com> References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:33:54 -0000 Hi James The current statement being debated does not say that Ecrit is not applicab= le to 3GPP and 3GPP2. We got past that point 5 weeks ago and I and others m= ore on the 3GPP/3GPP2 side are now perfectly willing to let that drop given= the current statement which essentially characterizes the main principles = of the Ecrit solution, admits the potential existence of other solutions an= d the fact that they are not defined within the Ecrit solution.=20 The detailed points you raise below may not be worth answering if you also = take the same view as Martin namely that suitability and feasibility are ir= relevant when it comes to Ecrit (though not of course when it comes to 3GPP= and 3GPP2 I should note). But I am still awaiting answers to my original questions from others in the= Ecrit community. Kind Regards Stephen -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Wednesday, April 29, 2009 9:00 PM To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning Schulzrinne; S= tark, Barbara; ECRIT Subject: RE: [Ecrit] PhoneBCP Stephen, As someone that has been vocal on this topic all along I will respond. Would you agree that this solution does allow the ultimate destination of the PSAP being reached using legacy TDM trunks?=20 If you want to take the debate offline I can clearly show to you the solution does, and as preparation please take a look at some of the NENA i3 and i2 work. So this makes quite a lot of your argument below irrelevant. You have continually argued that there is something special about IMS and cellular despite continual evidence being presented that there is not. Voice is not special when it comes to IP traffic, it is just another data stream. What you are doing is coming here and saying that 3GPP are introducing a whole bunch of complex machinations to maintain a bundling of access and service, so please would we put an applicability statement into our documents to say that they don't apply to 3GPP networks. This is unreasonable. If I read 23.167 correctly, then the calling device can obtain its location directly from the IP CAN, at least one of the IETF LCP is even mentioned, and I have seen a CR that suggested that HELD could also be used. 23.167 also makes use of SIP location conveyance. So far, this is 2 of the 3 elements we require for ECRIT to just work. I think it is perfectly reasonable to assume that if I get my location from the IP CAN, I can probably get the serving domain also, in which case I can do a LoST lookup. Alternatively I can go back to my home LoST server and rely on forest guides. In either case, these are quite reasonable assumptions, and the onus on an infrastructure provider is a provisioning record, rather than E-SLP.... hmmmm which is cheaper and easier I wonder? Now what does TS23.167 say to do if my SIP client directs a call to a URI that it obtained from a LoST Server? I would place odds that it would just deliver the call. Further more, if that SIP INVITE included both a CID header and a location URI what happens? For i2 and i3 we know what happens. Again, the LRF in 23.167 at a minimum will provide a route to the PSAP based on the provided location. Now, lets take Martin's argument a bit more. I have a device that can operate on 3G, 4G or WiFi. If it connect to a non-IMS WiFi hotspot (basically all of them) what happens? Where is the E-CSCF, where is the E-SLP, how can it help me? The point I am making is that ECRIT will actually work even in IMS architectures, but the IMS architecture doesn't work in the vast majority of IP cases. Any applicability statement you want please go and add it to 3GPP and not here, it is 3GPP that has the applicability issues and not the IETF. Cheers James =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Thursday, 30 April 2009 9:23 AM To: Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT Subject: Re: [Ecrit] PhoneBCP Richard and all others I wonder if those now humming against this statement (and who were all strangely silent 5 weeks ago) would support any kind of statement concerning applicability and scope. Or is it the case that the solution supported by both drafts is considered to apply to all devices, ANs and VSPs that provide some form of internet access. If so, is it irrelevant whether the solution is actually suitable for a particular type of AN or VSP (e.g. cellular AN, IMS based VSP)? For example, is it irrelevant whether significant additional support from an AN or VSP to which the solution might be applied would be needed in order to access legacy PSAPs, handoff to the circuit domain, authenticate the caller and provide access to non-subscribed users? Is it further irrelevant whether the solution would even work for a particular device, AN or VSP without substantial changes to the latter? In other words, is the solution now considered so sacrosanct that any adaptation must come from the rest of the infrastructure and not from the solution itself in the case of any mismatch? If the consensus answers to these questions are all yes, then I would have to agree that including the currently disputed statement or anything of a similar nature would be inconsistent and unnecessary. Of course, the representatives of the potentially affected portions of infrastructure should be forgiven for disagreeing with the basic premise - and may be expected to offer some type of protest! Kind Regards Stephen -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Tuesday, April 28, 2009 1:07 PM To: Edge, Stephen Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT Subject: Re: [Ecrit] PhoneBCP Stephen, As was noted in the meeting, it is *always* possible that there are=20 alternative solutions out there when you're talking about the Internet.=20 TCP vs. UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs.=20 XMPP, SASL vs. TLS, S/MIME vs. OpenPGP. None of the many RFCs out there have explicit statements that somebody else might do it differently=20 because it's obvious that they can. So I don't really think conveying the possibility of other=20 implementations is actually useful at all, technically speaking. That means that the only real purpose of such a statement is rhetorical, and as we've seen in a few messages here, some people misconstrue the=20 rhetoric to mean that this system has constrained applicability. Given=20 that, I'd rather leave it off unless we can avoid that impression. --Richard Edge, Stephen wrote: > All >=20 > I would have thought that motivation should be irrelevant. There are a lot of motives at work here. Should we assume that the document was originally written with only the purest and most altruistic motives (e.g. no thought of business or academic interest at stake)? >=20 > The issue is whether the current statement serves a useful purpose in conveying the possibility (well known to be true) of alternative solutions not fully aligned with the current drafts. Nothing in the statement implies that the current drafts are necessarily deficient or that alternative solutions must necessarily be used for some scenarios (even though they optionally can be). >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens > Sent: Tuesday, April 28, 2009 9:57 AM > To: Henning Schulzrinne; Stark, Barbara > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote: >=20 >> It is clear that the text has ulterior motives to restrict the=20 >> applicability of the document. >=20 > From my view, the text does not restrict the applicability, nor is=20 > there a desire to do so. The text does clarify the assumptions of=20 > the rest of the text in the document, which I think is helpful. >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] From bernard_aboba@hotmail.com Thu Apr 30 01:11:43 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579DF3A6ECE for ; Thu, 30 Apr 2009 01:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D8pGbpkcK-O for ; Thu, 30 Apr 2009 01:11:42 -0700 (PDT) Received: from blu0-omc4-s18.blu0.hotmail.com (blu0-omc4-s18.blu0.hotmail.com [65.55.111.157]) by core3.amsl.com (Postfix) with ESMTP id 524703A6F32 for ; Thu, 30 Apr 2009 01:11:14 -0700 (PDT) Received: from BLU137-W27 ([65.55.111.136]) by blu0-omc4-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 01:12:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_cf7653d7-5f31-4726-abc9-c5eb634324dc_" X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: , , Date: Thu, 30 Apr 2009 01:12:37 -0700 Importance: Normal In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.com> References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.com> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Apr 2009 08:12:37.0465 (UTC) FILETIME=[6C6EBC90:01C9C96B] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 08:11:43 -0000 --_cf7653d7-5f31-4726-abc9-c5eb634324dc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Your interpretation of applicability is certainly extreme (yes or qualifi= ed yes to all questions) - removing any dependence on suitability or feasib= ility (which are the more normal benchmarks) and simply making a legalistic= blanket assertion. (I can now more understand incidentally why the fictiti= ous protocol police are so often invoked on matters of conformance.) >=20 > But do others have any views on this? Here is my 2 pence. As noted in the Introduction=2C the Phone BCP documen= t and framework documents are closely related documents that need to be rea= d (and understood) together. In looking at Phone BCP=2C there have been ma= ny situations in which I wondered what the justification was for a require= ment=2C only to find the (usually persuasive) explanation in the correspond= ing section of the framework document. IMHO=2C the separation of the two documents is somewhat unnatural. It's a b= it like taking a meal=2C freeze drying it=2C and then presenting the diner = with a cup of powder and a cup of water and wondering why they are left wit= h a quizical look on their faces. Including cooking instructions along wit= h the two cups is not a fully satisfactory answer. Given this reality=2C if there is a need for text explaining the fundamenta= l assumptions of the architecture=2C the place for that text is not in the = BCP document=2C but in the framework document. As has been noted by others= =2C the entire BCP document is an applicability statement=2C and when viewe= d in that way=2C the proposed text is not only unnecessary=2C but somewhat = confusing since required context for the BCP document belongs in the framew= ork document. If anything more is necesary=2C it would probably be some ad= ditional instructions for the reader delving into the document set for the= first time.=20 Like any IETF effort=2C the framework and BCP documents will be evaluated o= n their own merits. Athough this is an area with a considerable regulatory = component=2C I see little evidence that the world at large is so in awe of = the IETF that every word will be taken as immutable truth. No doubt other = SDOs will take issue with these documents in whole or in part and will expl= ain the basis of their assessments and where necessary=2C their alternative= s. As a result=2C some portions of the architecture may be adopted=2C some = portions may be ignored=2C and others will be revised in an effort to addre= ss the issues encountered and improve their chances for deployment.=20 With respect to this process=2C the addition of cautionary text is a bit li= ke the warning labels that we find on consumer products. While it may be n= ecessary in some legalistic sense=2C given the expertise of the individuals= assessing these documents=2C one wonders what the practical effect will be= . Typically these are individuals who already understand that it is a good= idea to double-cup hot coffee.=20 --_cf7653d7-5f31-4726-abc9-c5eb634324dc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B Your interpretation of applicability is certainly extreme (yes or qu= alified yes to all questions) - removing any dependence on suitability or f= easibility (which are the more normal benchmarks) and simply making a legal= istic blanket assertion. (I can now more understand incidentally why the fi= ctitious protocol police are so often invoked on matters of conformance.)>=3B
>=3B But do others have any views on this?

Here is my= 2 pence. =3B =3B As noted in the Introduction=2C the Phone BCP doc= ument and framework documents are closely related documents that need to be= read (and understood) together. =3B In looking at Phone BCP=2C there h= ave been many situations in which =3B I wondered what the justification= was for a requirement=2C only to find the (usually persuasive) explanation= in the corresponding section of the framework document.

IMHO=2C the= separation of the two documents is somewhat unnatural. It's a bit like tak= ing a meal=2C freeze drying it=2C and then presenting the diner with a cup = of powder and a cup of water and wondering why they are left with a quizica= l look on their faces. =3B Including cooking instructions along with th= e two cups is not a fully satisfactory answer.

Given this reality=2C= if there is a need for text explaining the fundamental assumptions of the = architecture=2C the place for that text is not in the BCP document=2C but i= n the framework document. =3B As has been noted by others=2C the entire= BCP document is an applicability statement=2C and when viewed in that way= =2C the proposed text is not only unnecessary=2C but somewhat confusing sin= ce required context for the BCP document belongs in the framework document.=  =3B If anything more is necesary=2C it would probably be some addition= al instructions for the reader =3B delving into the document set for th= e first time.

Like any IETF effort=2C the framework and BCP documen= ts will be evaluated on their own merits. Athough this is an area with a co= nsiderable regulatory component=2C I see little evidence that the world at = large is so in awe of the IETF that every word will be taken as immutable t= ruth. =3B No doubt other SDOs will take issue with these documents in w= hole or in part and will explain the basis of their assessments and where n= ecessary=2C their alternatives. As a result=2C some portions of the archite= cture may be adopted=2C some portions may be ignored=2C and others will be = revised in an effort to address the issues encountered and improve their ch= ances for deployment.

With respect to this process=2C the addition = of cautionary text is a bit like the warning labels that we find on consume= r products. =3B While it may be necessary in some legalistic sense=2C g= iven the expertise of the individuals assessing these documents=2C one wond= ers what the practical effect will be. =3B Typically these are individu= als who already understand that it is a good idea to double-cup hot coffee.=

= --_cf7653d7-5f31-4726-abc9-c5eb634324dc_-- From Peter.Dawes@vodafone.com Thu Apr 30 03:51:43 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DAF3A6D88 for ; Thu, 30 Apr 2009 03:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG-SSkOJ0z6a for ; Thu, 30 Apr 2009 03:51:41 -0700 (PDT) Received: from mo1.vodafone.com (mo1.vodafone.com [195.232.246.84]) by core3.amsl.com (Postfix) with ESMTP id 70C9128C2A7 for ; Thu, 30 Apr 2009 03:51:28 -0700 (PDT) Received: from mi3.vodafone.com (mi3.vodafone.com [195.232.246.140]) by mo1.vodafone.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n3UAqmWZ018465; Thu, 30 Apr 2009 12:52:48 +0200 Received: from avoexs02.internal.vodafone.com ([145.230.4.135]) by mi3.vodafone.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id n3UAqkWF003267 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 30 Apr 2009 12:52:48 +0200 Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 12:52:36 +0200 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: Thu, 30 Apr 2009 12:52:35 +0200 Message-ID: In-Reply-To: <0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Thread-Index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAF7crgA= From: "Dawes, Peter, VF-Group" To: "Milan Patel" , "Gonzalo Camarillo" X-OriginalArrivalTime: 30 Apr 2009 10:52:36.0722 (UTC) FILETIME=[C6091D20:01C9C981] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 10:51:43 -0000 Hello Milan, Gonzalo, I have read through draft-patel-ecrit-sos-parameter-04 and I have a few comments: Section 4.2 says: The "sos" URI parameter is appended to the URI included in the Contact header, thus indicating to the UA that this contact address will be included in the Contact header of an INVITE for emergency call initiation. I think it would be clearer to say: The "sos" URI parameter is appended to the URI included in the Contact header, thus indicating to the UA that it MUST include this contact address in the Contact header of an INVITE for emergency call initiation. Also, 4.2 says nothing about whether the PSAP uses the URI in the Contact: header for=20 callback. At the end of section 1., it says: A call back from a PSAP would be routed to the registered contact address. So it seems that for any subsequent callback session initiated by the PSAP, the address in the From: or P-Asserted-Identity header fields will be used. I am not sure that draft-ietf-ecrit-framework-09 is clear on what to include in the Request URI for callback, but it suggests that for dropped calls the URI from the Contact: header field may be used.=20 =20 Section 4.3 says: If registration is successful, the 200 (OK) response from a legacy registrar is unlikely to include the "sos" URI parameter in the Contact header. The UAC is aware of its registered contact address and address-of-record, however, is unable to distinguish between this registration and a non-emergency registration. Does it matter if the UAC gets the "sos" URI parameter back from the registrar? I would have thought that the disadvantage of a non-supporting registrar is limited to not=20 routing callbacks to the contact address marked for emergency use. The UAC can still use the emergency registered contact address in the Contact: header field of an INVITE request for an emergency call. Editorials ---------- The draft has a mixture of e.g. REGISTER message and REGISTER request.=20 In 7. Security Considerations, . . =20 . It is RECOMMENDED to log events of misuse of the "sos" URI parameter, for example by including it in a request or response not related to an emergency call. (last 's' deleted) In 8. Acknowledgements The author would like to thank ...... for the discussions and contributions that le(a)d to this work. delete the a in brackets Also 4.2. 2xx Re(s)ponse to REGISTER Request has the 's' missing. Regards, Peter -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Milan Patel Sent: 28 April 2009 14:36 To: Gonzalo Camarillo Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi Gonzalo, Version 4 of draft-patel-ecrit-sos-parameter addresses all the comments you provided in the expert review. Please can you confirm that you are OK with its contents and that all the issues you had previously highlighted are now resolved. http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 Best regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: 09 March 2009 10:32 To: Patel, Milan (MOP:EP10) Cc: ecrit@ietf.org; Hannes Tschofenig Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi, the problem with this text is that it specifies behavior for entities that will not implement this specification. The new section should describe how a legacy registrar will handle, following regular SIP rules, a REGISTER request with the sos parameter. However, it cannot specify extra behavior for such a legacy registrar. That is the whole point of backwards compatibility: to support unchanged legacy applications that will not implement the new functionality. In any case, I believe you can use most of the text you proposed below.=20 It just needs to be rephrased so that it is more descriptive and non normative. Thanks, Gonzalo Milan Patel wrote: > Folks, >=20 > In response to Gonzalo's comment on backwards compatibility, I propose > a subclause "4.3 Backwards compatibility issues" as follows: >=20 > ---------------------------------------------------------------------- > -- > ---------------------------------- > 4.3 Backwards compatibility issues > The backwards compatibility scenario considered in this document is=20 > where the registrar does not support the "sos" URI parameter. In this=20 > case, if the registrar receives a REGISTER request that includes the=20 > "sos" URI parameter in the Contact header, the registrar MUST proceed=20 > with registration procedures and silently ignore the URI-parameter in=20 > accordance with RFC 3261. This ensures the user is registered and thus > can successfully initiate an emergency call. >=20 > The drawback of proceeding with registration is if the=20 > address-of-record is barred or has roaming restrictions applied, then=20 > these restrictions will not be lifted and thus registration will be=20 > unsuccessful. This may limit the UAC's ability to successfully place an emergency call. >=20 > If registration is successful, the registrar shall return a 200 (OK)=20 > response to the UAC and does not include the "sos" URI parameter in=20 > the Contact header. The UAC is aware of its registered contact address > and address-of-record, however, cannot distinguish between this=20 > registration and a non-emergency registration. > ---------------------------------------------------------------------- > -- > -------------------------------------- >=20 > Comments/feedback/suggestions for improvement are appreciated. I will=20 > address Gonzalo's other comments in version -04 of the draft as well. >=20 > Best regards, > Milan >=20 > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 /=20 > ESN 748 9261 >=20 > For the Companies listed below, The Institute of Chartered Accountants > in England and Wales authorises A R Bloom, S Harris and C Hill to act=20 > as Insolvency Practitioners under section 390(2)(a) of the Insolvency=20 > Act > 1986 and the Association of Chartered Certified Accountants authorises > A M Hudson to act as an Insolvency Practitioner under section > 390(2)(a) of the Insolvency Act 1986. >=20 > The affairs, business and property of the Companies are being managed=20 > by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill > who act as agents of the Companies only and without personal liability. >=20 > The Companies are Nortel Networks UK Limited; Nortel Networks SA;=20 > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel=20 > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo;=20 > Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel=20 > Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel > Networks Romania SRL; Nortel Networks AB; Nortel Networks=20 > International Finance & Holding BV >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Gonzalo Camarillo > Sent: 19 February 2009 13:57 > To: ecrit@ietf.org > Subject: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt >=20 > Folks, >=20 > I have been asked to perform an expert review of the following draft: >=20 > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt >=20 > The approach taken by the draft seems OK in general. I have a few=20 > comments though: >=20 > The requirement in Section 3 is too specific because it already=20 > assumes that the solution will be an indication in the SIP header=20 > fields. The requirement does not need to make that assumption. I would > remove "by providing an appropriate indication in the SIP header fields". >=20 > In Section 5, the reference to RFC 2234 should be replaced with one to > RFC 5234. >=20 > Also in Section 5, the formal syntax should be rewritten so that it is > compatible with the ABNF in RFC 3261. RFC 3261 already defines=20 > uri-parameter as follows: >=20 > uri-parameter =3D transport-param / user-param / method-param > / ttl-param / maddr-param / lr-param /=20 > other-param >=20 > other-param =3D pname [ "=3D" pvalue ] > pname =3D 1*paramchar > pvalue =3D 1*paramchar >=20 > This document should simply define a new value for pname. >=20 > The document does not talk about backwards compatibility. What happens > if the registrar does not understand the 'sos' parameter? Will it do=20 > the right thing? Will the UAC detect the failure? Is there a need to=20 > define an option tag?... the document should address these points. >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Thu Apr 30 05:47:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBBE83A6BB8 for ; Thu, 30 Apr 2009 05:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryg9G65fqlSA for ; Thu, 30 Apr 2009 05:47:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3A66228C30A for ; Thu, 30 Apr 2009 05:46:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208";a="295809624" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Apr 2009 12:48:00 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3UCm0OG009657; Thu, 30 Apr 2009 05:48:00 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3UClpZJ026885; Thu, 30 Apr 2009 12:48:00 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 08:47:59 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 08:47:57 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 30 Apr 2009 08:47:52 -0400 From: Marc Linsner To: "Edge, Stephen" , ECRIT Message-ID: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAOvt4AAEIpT0AALcu3y In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A4B4@NASANEXMB04.na.qualcomm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Apr 2009 12:47:57.0830 (UTC) FILETIME=[E3566260:01C9C991] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9684; t=1241095680; x=1241959680; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20PhoneBCP |Sender:=20; bh=NAUWEzyyv1T1wI7MalPlPzPi7Qx2lAWPP0b5uW5d2B4=; b=OXNnw+XkKx0hKQsWEIA/pYJFcDYSZE6+D3rJB5w2lCGtv0HS04UccAdOjz bfYvLstQRu4Fj+KOVCjpDZP9CK4+gMCDdfW9jPpv01Srct7PjSdmnni1P8p+ HXR1nzefUTJ8tkeEMwJl7HFMQljayVAHOvrKtdZioekySD426QLBE=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:47:14 -0000 Stephen, As I pondered on the new text, I saw no great harm with it, but the reason I hummed against it, I don't see that it adds any value. If we declare in either/both drafts that this solution is based on the requirements in RFC5012/RFC5069, would that satisfy your concern...?? (I'm somewhat surprised this isn't in either draft.) -Marc- On 4/30/09 3:35 AM, "Edge, Stephen" wrote: > Hi James > > The current statement being debated does not say that Ecrit is not applicable > to 3GPP and 3GPP2. We got past that point 5 weeks ago and I and others more on > the 3GPP/3GPP2 side are now perfectly willing to let that drop given the > current statement which essentially characterizes the main principles of the > Ecrit solution, admits the potential existence of other solutions and the fact > that they are not defined within the Ecrit solution. > > The detailed points you raise below may not be worth answering if you also > take the same view as Martin namely that suitability and feasibility are > irrelevant when it comes to Ecrit (though not of course when it comes to 3GPP > and 3GPP2 I should note). > > But I am still awaiting answers to my original questions from others in the > Ecrit community. > > Kind Regards > > Stephen > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, April 29, 2009 9:00 PM > To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning Schulzrinne; > Stark, Barbara; ECRIT > Subject: RE: [Ecrit] PhoneBCP > > Stephen, > > As someone that has been vocal on this topic all along I will respond. > > Would you agree that this solution does allow the ultimate destination > of the PSAP being reached using legacy TDM trunks? > If you want to take the debate offline I can clearly show to you the > solution does, and as preparation please take a look at some of the NENA > i3 and i2 work. > > So this makes quite a lot of your argument below irrelevant. > > You have continually argued that there is something special about IMS > and cellular despite continual evidence being presented that there is > not. Voice is not special when it comes to IP traffic, it is just > another data stream. What you are doing is coming here and saying that > 3GPP are introducing a whole bunch of complex machinations to maintain a > bundling of access and service, so please would we put an applicability > statement into our documents to say that they don't apply to 3GPP > networks. This is unreasonable. > > If I read 23.167 correctly, then the calling device can obtain its > location directly from the IP CAN, at least one of the IETF LCP is even > mentioned, and I have seen a CR that suggested that HELD could also be > used. > > 23.167 also makes use of SIP location conveyance. So far, this is 2 of > the 3 elements we require for ECRIT to just work. > > I think it is perfectly reasonable to assume that if I get my location > from the IP CAN, I can probably get the serving domain also, in which > case I can do a LoST lookup. Alternatively I can go back to my home LoST > server and rely on forest guides. In either case, these are quite > reasonable assumptions, and the onus on an infrastructure provider is a > provisioning record, rather than E-SLP.... hmmmm which is cheaper and > easier I wonder? > > Now what does TS23.167 say to do if my SIP client directs a call to a > URI that it obtained from a LoST Server? > I would place odds that it would just deliver the call. > > Further more, if that SIP INVITE included both a CID header and a > location URI what happens? For i2 and i3 we know what happens. Again, > the LRF in 23.167 at a minimum will provide a route to the PSAP based on > the provided location. > > Now, lets take Martin's argument a bit more. > I have a device that can operate on 3G, 4G or WiFi. If it connect to a > non-IMS WiFi hotspot (basically all of them) what happens? Where is the > E-CSCF, where is the E-SLP, how can it help me? > > The point I am making is that ECRIT will actually work even in IMS > architectures, but the IMS architecture doesn't work in the vast > majority of IP cases. Any applicability statement you want please go and > add it to 3GPP and not here, it is 3GPP that has the applicability > issues and not the IETF. > > Cheers > James > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Edge, Stephen > Sent: Thursday, 30 April 2009 9:23 AM > To: Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark, > Barbara; ECRIT > Subject: Re: [Ecrit] PhoneBCP > > Richard and all others > > I wonder if those now humming against this statement (and who were all > strangely silent 5 weeks ago) would support any kind of statement > concerning applicability and scope. Or is it the case that the solution > supported by both drafts is considered to apply to all devices, ANs and > VSPs that provide some form of internet access. If so, is it irrelevant > whether the solution is actually suitable for a particular type of AN or > VSP (e.g. cellular AN, IMS based VSP)? For example, is it irrelevant > whether significant additional support from an AN or VSP to which the > solution might be applied would be needed in order to access legacy > PSAPs, handoff to the circuit domain, authenticate the caller and > provide access to non-subscribed users? Is it further irrelevant whether > the solution would even work for a particular device, AN or VSP without > substantial changes to the latter? In other words, is the solution now > considered so sacrosanct that any adaptation must come from the rest of > the > infrastructure and not from the solution itself in the case of any > mismatch? If the consensus answers to these questions are all yes, then > I would have to agree that including the currently disputed statement or > anything of a similar nature would be inconsistent and unnecessary. Of > course, the representatives of the potentially affected portions of > infrastructure should be forgiven for disagreeing with the basic premise > - and may be expected to offer some type of protest! > > Kind Regards > > Stephen > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, April 28, 2009 1:07 PM > To: Edge, Stephen > Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT > Subject: Re: [Ecrit] PhoneBCP > > Stephen, > > As was noted in the meeting, it is *always* possible that there are > alternative solutions out there when you're talking about the Internet. > TCP vs. UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs. > XMPP, SASL vs. TLS, S/MIME vs. OpenPGP. None of the many RFCs out there > > have explicit statements that somebody else might do it differently > because it's obvious that they can. > > So I don't really think conveying the possibility of other > implementations is actually useful at all, technically speaking. > > That means that the only real purpose of such a statement is rhetorical, > > and as we've seen in a few messages here, some people misconstrue the > rhetoric to mean that this system has constrained applicability. Given > that, I'd rather leave it off unless we can avoid that impression. > > --Richard > > > > > Edge, Stephen wrote: >> All >> >> I would have thought that motivation should be irrelevant. There are a > lot of motives at work here. Should we assume that the document was > originally written with only the purest and most altruistic motives > (e.g. no thought of business or academic interest at stake)? >> >> The issue is whether the current statement serves a useful purpose in > conveying the possibility (well known to be true) of alternative > solutions not fully aligned with the current drafts. Nothing in the > statement implies that the current drafts are necessarily deficient or > that alternative solutions must necessarily be used for some scenarios > (even though they optionally can be). >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Randall Gellens >> Sent: Tuesday, April 28, 2009 9:57 AM >> To: Henning Schulzrinne; Stark, Barbara >> Cc: ECRIT >> Subject: Re: [Ecrit] PhoneBCP >> >> At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote: >> >>> It is clear that the text has ulterior motives to restrict the >>> applicability of the document. >> >> From my view, the text does not restrict the applicability, nor is >> there a desire to do so. The text does clarify the assumptions of >> the rest of the text in the document, which I think is helpful. >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------ > ------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------ > ------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From sedge@qualcomm.com Thu Apr 30 09:28:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1163A3A677D for ; Thu, 30 Apr 2009 09:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.491 X-Spam-Level: X-Spam-Status: No, score=-105.491 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7UVD3wg7txx for ; Thu, 30 Apr 2009 09:28:05 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E9CA23A6885 for ; Thu, 30 Apr 2009 09:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241108968; x=1272644968; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20B ernard=20Aboba=20,=0D=0A=20=20 =20=20=20=20=20=20"martin.thomson@andrew.com"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"e crit@ietf.org"=20|Date:=20Thu,=2030=20Apr =202009=2009:28:32=20-0700|Subject:=20RE:=20[Ecrit]=20Pho neBCP|Thread-Topic:=20[Ecrit]=20PhoneBCP|Thread-Index:=20 AcnJa27EY580z/r8T4SuVdCY50VYCgAQMkdg|Message-ID:=20<1288E 74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualco mm.com>|References:=20 <49F27637.7050201@ bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C 3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.a lcatel-lucent.com> <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA 8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090 902@bbn.com>=0D=0A=09<1288E74A73964940B132A0B9EA8D8ABC592 6A470@NASANEXMB04.na.qualcomm.com>=0D=0A=20=09=0D=0A =20=09<1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB 04.na.qualcomm.com>=0D=0A=20=09=0D=0A=20=20<1288E74A73 964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.co m>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_1288E74A73964940B132A0B9EA8D8ABC5926A 4D4NASANEXMB04naqu_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5601"=3B=20a=3D"17642136"; bh=3/eMV2OthoJ2H+CrHuo70stwj7INsvijfPmaVm2ronc=; b=fLEu4VqAPkt5ytiXcOs5khx4F2imo+WNsA4r1pBDhLnlyNpc2IH09kK7 zkDFIuXog3F9+uar2Ru3Fxa2BVzPMZKbkYXXZIKmA+pkmJWGGPbmoZCLz hTRXFW8hqcWYSjViZ0vVdP9dHITc6qKDDpZWMmqDcHh4HETIhiY+PQq0B k=; X-IronPort-AV: E=McAfee;i="5300,2777,5601"; a="17642136" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 09:29:27 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UGTRhG021357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 09:29:27 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UGTQ4k009553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Apr 2009 09:29:26 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Thu, 30 Apr 2009 09:29:26 -0700 From: "Edge, Stephen" To: Bernard Aboba , "martin.thomson@andrew.com" , "ecrit@ietf.org" Date: Thu, 30 Apr 2009 09:28:32 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnJa27EY580z/r8T4SuVdCY50VYCgAQMkdg Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1288E74A73964940B132A0B9EA8D8ABC5926A4D4NASANEXMB04naqu_" MIME-Version: 1.0 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:28:13 -0000 --_000_1288E74A73964940B132A0B9EA8D8ABC5926A4D4NASANEXMB04naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard and others This is an interesting view - an admission that the Ecrit solution will pro= bably not be universally applied and when it is may be subject to modificat= ion. On the 3GPP/3GPP2 sides, solutions are defined with a specific and exp= licit scope and are expected to be - and nearly always actually are - suppo= rted exactly as defined in the appropriate spec.s for all scenarios covered= by the scope. A solution whose deployment is unpredictable will be less us= eful because of the implied interworking problems between incompatible impl= ementations. That is a main reason why I and others initially tried to incl= ude a more precise applicability/scope statement than the one we are now di= scussing. Specifically, the Ecrit solution will probably not be deployed by= 3GPP/3GPP2 operators for cellular terminals because they have defined a so= mewhat different solution more suitable for cellular operation. That means = that a terminal supporting only the Ecrit solution (based on an assertion o= f universal applicability) will encounter problems when its user attempts a= n emergency call on a 3GPP/3GPP2 network. If I can extend your analogies, t= his would be like not including a precise menu description for a meal conta= ining meat and/or fish in a restaurant catering to both vegetarians and non= -vegetarians. Kind Regards Stephen ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Thursday, April 30, 2009 1:13 AM To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org Subject: RE: [Ecrit] PhoneBCP > Your interpretation of applicability is certainly extreme (yes or qualifi= ed yes to all questions) - removing any dependence on suitability or feasib= ility (which are the more normal benchmarks) and simply making a legalistic= blanket assertion. (I can now more understand incidentally why the fictiti= ous protocol police are so often invoked on matters of conformance.) > > But do others have any views on this? Here is my 2 pence. As noted in the Introduction, the Phone BCP document = and framework documents are closely related documents that need to be read = (and understood) together. In looking at Phone BCP, there have been many s= ituations in which I wondered what the justification was for a requirement= , only to find the (usually persuasive) explanation in the corresponding se= ction of the framework document. IMHO, the separation of the two documents is somewhat unnatural. It's a bit= like taking a meal, freeze drying it, and then presenting the diner with a= cup of powder and a cup of water and wondering why they are left with a qu= izical look on their faces. Including cooking instructions along with the = two cups is not a fully satisfactory answer. Given this reality, if there is a need for text explaining the fundamental = assumptions of the architecture, the place for that text is not in the BCP = document, but in the framework document. As has been noted by others, the = entire BCP document is an applicability statement, and when viewed in that = way, the proposed text is not only unnecessary, but somewhat confusing sinc= e required context for the BCP document belongs in the framework document. = If anything more is necesary, it would probably be some additional instruc= tions for the reader delving into the document set for the first time. Like any IETF effort, the framework and BCP documents will be evaluated on = their own merits. Athough this is an area with a considerable regulatory co= mponent, I see little evidence that the world at large is so in awe of the = IETF that every word will be taken as immutable truth. No doubt other SDOs= will take issue with these documents in whole or in part and will explain = the basis of their assessments and where necessary, their alternatives. As = a result, some portions of the architecture may be adopted, some portions m= ay be ignored, and others will be revised in an effort to address the issue= s encountered and improve their chances for deployment. With respect to this process, the addition of cautionary text is a bit like= the warning labels that we find on consumer products. While it may be nec= essary in some legalistic sense, given the expertise of the individuals ass= essing these documents, one wonders what the practical effect will be. Typ= ically these are individuals who already understand that it is a good idea = to double-cup hot coffee. --_000_1288E74A73964940B132A0B9EA8D8ABC5926A4D4NASANEXMB04naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard and others

 

This is an interesting view – a= n admission that the Ecrit solution will probably not be universally applied = and when it is may be subject to modification. On the 3GPP/3GPP2 sides, solutio= ns are defined with a specific and explicit scope and are expected to be ̵= 1; and nearly always actually are - supported exactly as defined in the appropriate spec.s for all scenarios covered by the scope. A solution whose deployment is unpredictable will be less useful because of the implied interworking problems between incompatible implementations. That is a main reason why I and others initially tried to include a more precise applicability/scope statement than the one we are now discussing. Specifica= lly, the Ecrit solution will probably not be deployed by 3GPP/3GPP2 operators fo= r cellular terminals because they have defined a somewhat different solution = more suitable for cellular operation. That means that a terminal supporting only= the Ecrit solution (based on an assertion of universal applicability) will encounter problems when its user attempts an emergency call on a 3GPP/3GPP2 network. If I can extend your analogies, this would be like not including a precise menu description for a meal containing meat and/or fish in a restau= rant catering to both vegetarians and non-vegetarians.

 

Kind Regards

 

Stephen

From: Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Thursday, April 30, 20= 09 1:13 AM
To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org
Subject: RE: [Ecrit] PhoneBC= P

 

> Your interpretation of = applicability is certainly extreme (yes or qualified yes to all questions) - removing any dependence on suitability or feasibility (which are the more normal benchma= rks) and simply making a legalistic blanket assertion. (I can now more understan= d incidentally why the fictitious protocol police are so often invoked on mat= ters of conformance.)
>
> But do others have any views on this?

Here is my 2 pence.   As noted in the Introduction, the Phone BCP document and framework documents are closely related documents that need to= be read (and understood) together.  In looking at Phone BCP, there have b= een many situations in which  I wondered what the justification was for a requirement, only to find the (usually persuasive) explanation in the corre= sponding section of the framework document.

IMHO, the separation of the two documents is somewhat unnatural. It's a bit like taking a meal, freeze drying it, and then presenting the diner with a = cup of powder and a cup of water and wondering why they are left with a quizica= l look on their faces.  Including cooking instructions along with the tw= o cups is not a fully satisfactory answer.

Given this reality, if there is a need for text explaining the fundamental assumptions of the architecture, the place for that text is not in the BCP document, but in the framework document.  As has been noted by others,= the entire BCP document is an applicability statement, and when viewed in that = way, the proposed text is not only unnecessary, but somewhat confusing since required context for the BCP document belongs in the framework document.&nb= sp; If anything more is necesary, it would probably be some additional instruct= ions for the reader  delving into the document set for the first time.

Like any IETF effort, the framework and BCP documents will be evaluated on their own merits. Athough this is an area with a considerable regulatory component, I see little evidence that the world at large is so in awe of th= e IETF that every word will be taken as immutable truth.  No doubt other= SDOs will take issue with these documents in whole or in part and will explain t= he basis of their assessments and where necessary, their alternatives. As a result, some portions of the architecture may be adopted, some portions may= be ignored, and others will be revised in an effort to address the issues encountered and improve their chances for deployment.

With respect to this process, the addition of cautionary text is a bit like= the warning labels that we find on consumer products.  While it may be necessary in some legalistic sense, given the expertise of the individuals assessing these documents, one wonders what the practical effect will be.&n= bsp; Typically these are individuals who already understand that it is a good id= ea to double-cup hot coffee.

--_000_1288E74A73964940B132A0B9EA8D8ABC5926A4D4NASANEXMB04naqu_-- From Martin.Dawson@andrew.com Thu Apr 30 09:47:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85693A6842 for ; Thu, 30 Apr 2009 09:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.152 X-Spam-Level: X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJBQDSuebaWe for ; Thu, 30 Apr 2009 09:47:20 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 327963A67F7 for ; Thu, 30 Apr 2009 09:47:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_30_12_09_31 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 30 Apr 2009 12:09:30 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 11:48:42 -0500 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_01C9C9B3.844E46C8" Date: Thu, 30 Apr 2009 11:48:40 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnJa27EY580z/r8T4SuVdCY50VYCgAQMkdgAAFpsPA= References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com><1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , "Bernard Aboba" , "Thomson, Martin" , X-OriginalArrivalTime: 30 Apr 2009 16:48:42.0059 (UTC) FILETIME=[84C4D1B0:01C9C9B3] Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:47:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C9B3.844E46C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Or would it be like a statement on the menu saying "You might find a=0D=0Ad= ish of the same name in other restaurants, this menu does not attempt=0D=0A= to describe the contents of their dish"=3F I'm surprised diners aren't=0D=0A= crying out for this sort of helpful note... not.=0D=0A=0D=0A=20=0D=0A=0D=0A= I think this is an object lesson in convergence. "On the 3GPP/3GPP2=0D=0Asi= des, solutions are defined with a specific and explicit scope and are=0D=0A= expected to be - and nearly always actually are - supported exactly as=0D=0A= defined". This is exactly where walled-garden presumption collides with=0D=0A= convergence reality. Understanding ECRIT means understanding that=0D=0Abroa= dband Internet access is broadband Internet access is broadband=0D=0AIntern= et access. Having to change the way the device initiates an=0D=0Aemergency = call when something as prosaic as the access technology=0D=0Achanges is aki= n to having to change your web browser just because the=0D=0Aaccess technol= ogy has changed. It's neither helpful nor harmless to have=0D=0Asuch a rest= riction.=0D=0A=0D=0A=20=0D=0A=0D=0AA helpful statement to put in the BCP mi= ght be "Other architectures,=0D=0Asuch as IMS Emergency calling defined by = 3GPP and 3GPP2, which are not=0D=0Abased on the ECRIT framework are likely = to not be compatible with=0D=0Adevices and emergency networks which assume = this framework - e.g. such=0D=0Aas is defined by NENA as i3."=0D=0A=0D=0A =0D= =0A=0D=0AI don't endorse the inclusion of such a statement; it's commentary= - as=0D=0Ais the proposed "applicability statement" and commentary is unne= cessary.=0D=0ANevertheless, I think it's a more accurate characterization. = That is,=0D=0Ait's more the case that the 3GPP IMS emergency architecture d= oesn't fit=0D=0AECRIT than it is that ECRIT doesn't fit a 3GPP access netwo= rk.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: ecrit-bounces@ietf.org= [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Edge, Stephen=0D=0ASent:= Friday, 1 May 2009 2:29 AM=0D=0ATo: Bernard Aboba; Thomson, Martin; ecrit@= ietf.org=0D=0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0A=20=0D=0A=0D=0ABerna= rd and others=0D=0A=0D=0A=20=0D=0A=0D=0AThis is an interesting view - an ad= mission that the Ecrit solution will=0D=0Aprobably not be universally appli= ed and when it is may be subject to=0D=0Amodification. On the 3GPP/3GPP2 si= des, solutions are defined with a=0D=0Aspecific and explicit scope and are = expected to be - and nearly always=0D=0Aactually are - supported exactly as= defined in the appropriate spec.s=0D=0Afor all scenarios covered by the sc= ope. A solution whose deployment is=0D=0Aunpredictable will be less useful = because of the implied interworking=0D=0Aproblems between incompatible impl= ementations. That is a main reason why=0D=0AI and others initially tried to= include a more precise=0D=0Aapplicability/scope statement than the one we = are now discussing.=0D=0ASpecifically, the Ecrit solution will probably not= be deployed by=0D=0A3GPP/3GPP2 operators for cellular terminals because th= ey have defined a=0D=0Asomewhat different solution more suitable for cellul= ar operation. That=0D=0Ameans that a terminal supporting only the Ecrit sol= ution (based on an=0D=0Aassertion of universal applicability) will encounte= r problems when its=0D=0Auser attempts an emergency call on a 3GPP/3GPP2 ne= twork. If I can extend=0D=0Ayour analogies, this would be like not includin= g a precise menu=0D=0Adescription for a meal containing meat and/or fish in= a restaurant=0D=0Acatering to both vegetarians and non-vegetarians.=0D=0A=0D= =0A=20=0D=0A=0D=0AKind Regards=0D=0A=0D=0A=20=0D=0A=0D=0AStephen=0D=0A=0D=0A= ________________________________=0D=0A=0D=0AFrom: Bernard Aboba [mailto:ber= nard_aboba@hotmail.com]=20=0D=0ASent: Thursday, April 30, 2009 1:13 AM=0D=0A= To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org=0D=0ASubject: = RE: [Ecrit] PhoneBCP=0D=0A=0D=0A=20=0D=0A=0D=0A> Your interpretation of app= licability is certainly extreme (yes or=0D=0Aqualified yes to all questions= ) - removing any dependence on suitability=0D=0Aor feasibility (which are t= he more normal benchmarks) and simply making=0D=0Aa legalistic blanket asse= rtion. (I can now more understand incidentally=0D=0Awhy the fictitious prot= ocol police are so often invoked on matters of=0D=0Aconformance.)=0D=0A> =0D= =0A> But do others have any views on this=3F=0D=0A=0D=0AHere is my 2 pence.= As noted in the Introduction, the Phone BCP=0D=0Adocument and framework = documents are closely related documents that need=0D=0Ato be read (and unde= rstood) together. In looking at Phone BCP, there=0D=0Ahave been many situa= tions in which I wondered what the justification=0D=0Awas for a requiremen= t, only to find the (usually persuasive) explanation=0D=0Ain the correspond= ing section of the framework document.=0D=0A=0D=0AIMHO, the separation of t= he two documents is somewhat unnatural. It's a=0D=0Abit like taking a meal,= freeze drying it, and then presenting the diner=0D=0Awith a cup of powder = and a cup of water and wondering why they are left=0D=0Awith a quizical loo= k on their faces. Including cooking instructions=0D=0Aalong with the two c= ups is not a fully satisfactory answer.=0D=0A=0D=0AGiven this reality, if t= here is a need for text explaining the=0D=0Afundamental assumptions of the = architecture, the place for that text is=0D=0Anot in the BCP document, but = in the framework document. As has been=0D=0Anoted by others, the entire BC= P document is an applicability statement,=0D=0Aand when viewed in that way,= the proposed text is not only unnecessary,=0D=0Abut somewhat confusing sin= ce required context for the BCP document=0D=0Abelongs in the framework docu= ment. If anything more is necesary, it=0D=0Awould probably be some additio= nal instructions for the reader delving=0D=0Ainto the document set for the= first time.=20=0D=0A=0D=0ALike any IETF effort, the framework and BCP docu= ments will be evaluated=0D=0Aon their own merits. Athough this is an area w= ith a considerable=0D=0Aregulatory component, I see little evidence that th= e world at large is=0D=0Aso in awe of the IETF that every word will be take= n as immutable truth.=0D=0ANo doubt other SDOs will take issue with these d= ocuments in whole or in=0D=0Apart and will explain the basis of their asses= sments and where=0D=0Anecessary, their alternatives. As a result, some port= ions of the=0D=0Aarchitecture may be adopted, some portions may be ignored,= and others=0D=0Awill be revised in an effort to address the issues encount= ered and=0D=0Aimprove their chances for deployment.=20=0D=0A=0D=0AWith resp= ect to this process, the addition of cautionary text is a bit=0D=0Alike the= warning labels that we find on consumer products. While it may=0D=0Abe ne= cessary in some legalistic sense, given the expertise of the=0D=0Aindividua= ls assessing these documents, one wonders what the practical=0D=0Aeffect wi= ll be. Typically these are individuals who already understand=0D=0Athat it= is a good idea to double-cup hot coffee.=20=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C9C9B3.844E46C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A
=0D=0A=0D=0A

Or = would it be like a statement on the=0D=0Amenu saying “You might find = a dish of the same name in other restaurants,=0D=0Athis menu does not attem= pt to describe the contents of their dish”=3F I’m=0D=0Asurprise= d diners aren’t crying out for this sort of helpful note…=0D=0A= not.

=0D=0A=0D=0A

 

=0D=0A=0D=0A

I think this is an obje= ct lesson in=0D=0Aconvergence. “On the=0D=0A3GPP/3GPP2 sides, solutions are define= d with a specific and explicit scope and=0D=0Aare expected to be – an= d nearly always actually are - supported exactly=0D=0Aas defined”. This is exactly=0D=0Awhere wal= led-garden presumption collides with convergence reality. Understanding=0D=0A= ECRIT means understanding that broadband Internet access is broadband Inter= net=0D=0Aaccess is broadband Internet access. Having to change the way the = device=0D=0Ainitiates an emergency call when something as prosaic as the ac= cess technology=0D=0Achanges is akin to having to change your web browser j= ust because the access=0D=0Atechnology has changed. It’s neither help= ful nor harmless to have such a=0D=0Arestriction.<= /p>=0D=0A=0D=0A

=  

=0D=0A=0D=0A

A helpful statement to put in the BCP=0D=0Amight be &#= 8220;Other architectures, such as IMS Emergency calling defined by=0D=0A3GP= P and 3GPP2, which are not based on the ECRIT framework are likely to not b= e=0D=0Acompatible with devices and emergency networks which assume this fra= mework –=0D=0Ae.g. such as is defined by NENA as i3.”

=0D=0A=0D=0A

 

=0D=0A=0D=0A

I don’t endorse the inclusion of=0D= =0Asuch a statement; it’s commentary – as is the proposed ̶= 0;applicability=0D=0Astatement” and commentary is unnecessary. Nevert= heless, I think it’s=0D=0Aa more accurate characterization. That is, = it’s more the case that the=0D=0A3GPP IMS emergency architecture does= n’t fit ECRIT than it is that ECRIT=0D=0Adoesn’t fit a 3GPP acc= ess network.

=0D=0A=0D=0A

<= font size=3D2 color=3Dnavy face=3DArial> 

=0D=0A=0D= =0A

Cheers,

=0D=0A=0D=0A

Martin

=0D=0A=0D=0A

 

=0D= =0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0Aecrit-bounces@ietf.org [mailto:ecrit= -bounces@ietf.org] On Behalf Of Edge, Stephen
=0D=0ASent: Friday, 1 May 2009 2:29 AM
=0D=0ATo: Bernard Aboba; Thoms= on, Martin; ecrit@ietf.org
=0D=0ASubject: Re: [Ecrit] PhoneBCP

=0D=0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A

Bernard and others=

=0D=0A=0D=0A

 

=0D=0A=0D=0A

This is an inte= resting=0D=0Aview – an admission that the Ecrit solution will probabl= y not be=0D=0Auniversally applied and when it is may be subject to modifica= tion. On the=0D=0A3GPP/3GPP2 sides, solutions are defined with a specific a= nd explicit scope and=0D=0Aare expected to be – and nearly always act= ually are - supported exactly=0D=0Aas defined in the appropriate spec.s for= all scenarios covered by the scope. A=0D=0Asolution whose deployment is un= predictable will be less useful because of the=0D=0Aimplied interworking pr= oblems between incompatible implementations. That is a=0D=0Amain reason why= I and others initially tried to include a more precise=0D=0Aapplicability/= scope statement than the one we are now discussing. Specifically,=0D=0Athe = Ecrit solution will probably not be deployed by 3GPP/3GPP2 operators for=0D= =0Acellular terminals because they have defined a somewhat different soluti= on more=0D=0Asuitable for cellular operation. That means that a terminal su= pporting only the=0D=0AEcrit solution (based on an assertion of universal a= pplicability) will=0D=0Aencounter problems when its user attempts an emerge= ncy call on a 3GPP/3GPP2=0D=0Anetwork. If I can extend your analogies, this= would be like not including a precise=0D=0Amenu description for a meal con= taining meat and/or fish in a restaurant=0D=0Acatering to both vegetarians = and non-vegetarians.

=0D=0A=0D=0A

 =0D=0A=0D=0A

Kind Regards

=0D=0A=0D=0A

 =0D=0A=0D=0A

Stephen

=0D= =0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0ABernard Aboba [mailto:bernard_aboba@hotmail.com]=0D=0A
=0D=0ASent: Thursday, April 30, 2009=0D= =0A1:13 AM
=0D=0ATo: Edge= , Stephen;=0D=0Amartin.thomson@andrew.com; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] PhoneBCP=

=0D=0A=0D=0A
=0D=0A=0D= =0A

 

=0D= =0A=0D=0A

> Your=0D=0Ainterpretation of applicability is certainly ext= reme (yes or qualified yes to=0D=0Aall questions) - removing any dependence= on suitability or feasibility (which=0D=0Aare the more normal benchmarks) = and simply making a legalistic blanket=0D=0Aassertion. (I can now more unde= rstand incidentally why the fictitious protocol=0D=0Apolice are so often in= voked on matters of conformance.)
=0D=0A>
=0D=0A> But do other= s have any views on this=3F
=0D=0A
=0D=0AHere is my 2 pence. &nb= sp; As noted in the Introduction, the Phone BCP=0D=0Adocument and framework= documents are closely related documents that need to be=0D=0Aread (and und= erstood) together.  In looking at Phone BCP, there have been=0D=0Amany= situations in which  I wondered what the justification was for a=0D=0A= requirement, only to find the (usually persuasive) explanation in the=0D=0A= corresponding section of the framework document.
=0D=0A
=0D=0AIMHO, t= he separation of the two documents is somewhat unnatural. It's a bit=0D=0Al= ike taking a meal, freeze drying it, and then presenting the diner with a c= up=0D=0Aof powder and a cup of water and wondering why they are left with a= quizical=0D=0Alook on their faces.  Including cooking instructions al= ong with the two=0D=0Acups is not a fully satisfactory answer.
=0D=0A=0D=0AGiven this reality, if there is a need for text explaining the funda= mental=0D=0Aassumptions of the architecture, the place for that text is not= in the BCP=0D=0Adocument, but in the framework document.  As has been= noted by others, the=0D=0Aentire BCP document is an applicability statemen= t, and when viewed in that way,=0D=0Athe proposed text is not only unnecess= ary, but somewhat confusing since=0D=0Arequired context for the BCP documen= t belongs in the framework document. =0D=0AIf anything more is necesar= y, it would probably be some additional instructions=0D=0Afor the reader&nb= sp; delving into the document set for the first time.
=0D=0A
=0D=0AL= ike any IETF effort, the framework and BCP documents will be evaluated on=0D= =0Atheir own merits. Athough this is an area with a considerable regulatory=0D= =0Acomponent, I see little evidence that the world at large is so in awe of= the=0D=0AIETF that every word will be taken as immutable truth.  No d= oubt other=0D=0ASDOs will take issue with these documents in whole or in pa= rt and will explain=0D=0Athe basis of their assessments and where necessary= , their alternatives. As a=0D=0Aresult, some portions of the architecture m= ay be adopted, some portions may be=0D=0Aignored, and others will be revise= d in an effort to address the issues=0D=0Aencountered and improve their cha= nces for deployment.
=0D=0A
=0D=0AWith respect to this process, the = addition of cautionary text is a bit like the=0D=0Awarning labels that we f= ind on consumer products.  While it may be=0D=0Anecessary in some lega= listic sense, given the expertise of the individuals=0D=0Aassessing these d= ocuments, one wonders what the practical effect will be. =0D=0ATypical= ly these are individuals who already understand that it is a good idea=0D=0A= to double-cup hot coffee.

=0D=0A=0D=0A
=0D=0A=0D=0A


-------------------------------------------------= -----------------------------------------------
=0D=0AThis message&= nbsp;is for the designated recipient only and=  may
=0D=0Acontain privileged, proprietary, or = otherwise private information.  
=0D=0AIf you&n= bsp;have received it in error, please notify&= nbsp;the sender
=0D=0Aimmediately and delete the&nbs= p;original.  Any unauthorized use of
=0D=0Athis=  email is prohibited.
=0D=0A-----------------------------= -------------------------------------------------------------------
=0D=0A= [mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C9C9B3.844E46C8-- From hardie@qualcomm.com Thu Apr 30 10:39:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208C928C195 for ; Thu, 30 Apr 2009 10:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.346 X-Spam-Level: X-Spam-Status: No, score=-105.346 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tM1O1zmmSYc for ; Thu, 30 Apr 2009 10:39:13 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 0AECA3A6F69 for ; Thu, 30 Apr 2009 10:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1241113236; x=1272649236; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:content-transfer-encoding: x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20<49F27637.7050201@bbn.com><0 58701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2 A7ABA4A841F11217ABE78D67590B=0D=0A=20D8E@FRMRSSXCHMBSB3.d c-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@c rexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXM B04.na.qualcomm.com>=0D=0A=20<49F761CC.3090902@bbn.com><1 288E74A73964940B132A0B9EA8D8ABC5926A470@NASANE=0D=0A=20XM B04.na.qualcomm.com><1288E74A73964940B132A0B9 EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.=0D=0A=20com> <1288E74A7=0D=0A=203964940B132A0B9EA8D8ABC5926A4B2@NASANE XMB04.na.qualcomm.com>=0D=0A=20<1288E74A73964940B132A0 B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com>=0D=0A=20< EB921991A86A974C80EAFA46AD428E1E05999C7D@aopex4.andrew.co m>|Date:=20Thu,=2030=20Apr=202009=2010:40:24=20-0700|To: =20"Dawson,=20Martin"=20,=0D=0A =20=20=20=20=20=20=20=20"Edge,=20Stephen"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Bernard=20Abo ba=20,=0D=0A=20=20=20=20=20=20 =20=20"Thomson,=0D=0A=20Martin"=20,=0D=0A=20=20=20=20=20=20=20=20"ecrit@ietf.org"=20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20PhoneBCP|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5601"=3B=20 a=3D"17645788"; bh=BV0ZhPBkxvfb5QfvCN/v++unUUJIRW+XzgAC2ENZRko=; b=xscKz8TD5uVvEUuOBs3HxbkelNUkUpZJTW7qwMxaYdW8A3IvhSIMr1DI ohvVmm2zFoQZPI8D7OQgVNWuATHiQ4p4woxUHWYIVTxL5mLzZXNwR8t5A fhSydP7yZdA5ThJKEV91WNWOPUbOGyuoQnjw2C2z1ks/Jwps3UcVUrgUu A=; X-IronPort-AV: E=McAfee;i="5300,2777,5601"; a="17645788" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 10:40:27 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UHeQXL000612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 10:40:27 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UHeQXB016237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Apr 2009 10:40:26 -0700 (PDT) Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 30 Apr 2009 10:40:26 -0700 Received: from [10.0.1.197] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 30 Apr 2009 10:40:25 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67590B D8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com> <49F761CC.3090902@bbn.com><1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANE XMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm. com><1288E74A7 3964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> Date: Thu, 30 Apr 2009 10:40:24 -0700 To: "Dawson, Martin" , "Edge, Stephen" , Bernard Aboba , "Thomson, Martin" , "ecrit@ietf.org" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 17:39:15 -0000 At 9:48 AM -0700 4/30/09, Dawson, Martin wrote: >Understanding ECRIT means understanding that broadband Internet access is = broadband Internet access is broadband Internet access. To put it mildy, this is far from true. There is a whole class of offering= s that is voice-as-a-service (the IMS/NGN group) which absolutely do not act like voice-as-an-application. The solution we've defined is for voice-as-an-a= pplication, which has the natural result that the end user device has the primary role. The root of the problem we're facing is that there is a difference between using IP and using the Internet model. IMS uses IP, but uses a different model entirely (Whatever you think of that model, I don't think anyone who looked at how it works could argue that it is the same as the Internet model.) The documents we're dealing with contrast the offering with PSTN, but don't really see any differentiation among "packet-switched networks". Take this early text from the Framework document: >It is beyond the scope of this document to enumerate and discuss all > the differences between traditional (Public Switched Telephone > Network) and IP-based telephony, but calling on the Internet is > characterized by: > o the interleaving over the same infrastructure of a wider variety > of services; > o the separation of the access provider from the application > provider; > o media other than voice (e.g. video and text in several forms); > o the potential mobility of all end systems, including endpoints > nominally thought of as fixed systems and not just those using > radio access technology. For example, consider a wired phone > connected to a router using a mobile data network such as EV-DO as > an uplink. > > This document focuses on how devices using the Internet can place > emergency calls and how PSAPs can handle Internet multimedia > emergency calls natively, rather than describing how circuit-switched > PSAPs can handle VoIP calls. In many cases, PSAPs making the > transition from circuit-switched interfaces to packet-switched > interfaces may be able to use some of the mechanisms described here, > in combination with gateways that translate packet-switched calls > into legacy interfaces, e.g., to continue to be able to use existing > call taker equipment. There are many legacy telephone networks that > will persist long after most systems have been upgraded to IP > origination and termination of emergency calls. Many of these legacy > systems route calls based on telephone numbers. Gateways and > conversions between existing systems and newer systems defined by > this document will be required. Since existing systems are governed > primarily by local government regulations and national standards, the > gateway and conversion details will be governed by national standards > and thus are out of scope for this document. The real contrast being made is between circuit-switched and Internet model, but the terms used mix "packet-switched", "IP-based", and "Internet"= ; there is even an explicit mention of EV-DO, but in a mode that treats it as a pure IP bearer (which is not what is being sold in most markets today). The reality on the ground today is that there are at least circuit= -switched, Internet model IP, and IP with operator services out there in the real world. This document set doesn't acknowledge that, and it treats all packet-switched services/IP-based services as if they were Internet model. That's simply not true. The argument that Steven and others have made is that the document set needs to have an explicit acknowledgement of the other model, so that there is a realization by those reading them that just because they have IP, doesn't mean they are dealing with the Internet model. You could argue that everyone knows that, but the document itself muddies it far enough that it is far from evident. Do I, personally believe the Internet model version is better? Yep. Do I, personally believe that it will eventually subsume other versions? Mayb= e, and I think it would be nice. But I also recognize that it is not the case= now, and we're trying to define a system that will actually work to deliver eme= rgency calls in the real world. Explicit acknowledgement seems to me valuable in that case. The other option is to re-write the documents to clarify tha= t not any packet-switched network nor any network using IP fits this set of assumptions; that seems to me likely to take longer and not add much. You've already had Keith note that he would object to the documents if they did not contain language like that which was in -09. If it is taken o= ut, I believe the documents will need a major editing pass to accomplish the clarification without the explicit text. This text is a compromise already= , and the issue it deals with is important. Unless we are going to pretend that the IMS model simply doesn't exist and won't be used to deliver a substantial fraction of emergency calls for a good long time to come, we need it. If we are going to pretend that, I think we are being very foo= lish indeed. Ted >Having to change the way the device initiates an emergency call when somet= hing as prosaic as the access technology changes is akin to having to chang= e your web browser just because the access technology has changed. It's nei= ther helpful nor harmless to have such a restriction. >=20 >A helpful statement to put in the BCP might be "Other architectures, such = as IMS Emergency calling defined by 3GPP and 3GPP2, which are not based on = the ECRIT framework are likely to not be compatible with devices and emerge= ncy networks which assume this framework - e.g. such as is defined by NENA = as i3." >=20 >I don't endorse the inclusion of such a statement; it's commentary - as is= the proposed "applicability statement" and commentary is unnecessary. Neve= rtheless, I think it's a more accurate characterization. That is, it's more= the case that the 3GPP IMS emergency architecture doesn't fit ECRIT than i= t is that ECRIT doesn't fit a 3GPP access network. >=20 >Cheers, >Martin >=20 > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Edge, Stephen >Sent: Friday, 1 May 2009 2:29 AM >To: Bernard Aboba; Thomson, Martin; ecrit@ietf.org >Subject: Re: [Ecrit] PhoneBCP >=20 >Bernard and others >=20 >This is an interesting view - an admission that the Ecrit solution will pr= obably not be universally applied and when it is may be subject to modifica= tion. On the 3GPP/3GPP2 sides, solutions are defined with a specific and ex= plicit scope and are expected to be - and nearly always actually are - supp= orted exactly as defined in the appropriate spec.s for all scenarios covere= d by the scope. A solution whose deployment is unpredictable will be less u= seful because of the implied interworking problems between incompatible imp= lementations. That is a main reason why I and others initially tried to inc= lude a more precise applicability/scope statement than the one we are now d= iscussing. Specifically, the Ecrit solution will probably not be deployed b= y 3GPP/3GPP2 operators for cellular terminals because they have defined a s= omewhat different solution more suitable for cellular operation. That means= that a terminal supporting only the Ecrit solution (based on an assertion = of universal applicability) will encounter problems when its user attempts = an emergency call on a 3GPP/3GPP2 network. If I can extend your analogies, = this would be like not including a precise menu description for a meal cont= aining meat and/or fish in a restaurant catering to both vegetarians and no= n-vegetarians. >=20 >Kind Regards >=20 >Stephen > >From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >Sent: Thursday, April 30, 2009 1:13 AM >To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org >Subject: RE: [Ecrit] PhoneBCP >=20 > > Your interpretation of applicability is certainly extreme (yes or quali= fied yes to all questions) - removing any dependence on suitability or feas= ibility (which are the more normal benchmarks) and simply making a legalist= ic blanket assertion. (I can now more understand incidentally why the ficti= tious protocol police are so often invoked on matters of conformance.) > > >> But do others have any views on this? > >Here is my 2 pence. As noted in the Introduction, the Phone BCP document= and framework documents are closely related documents that need to be read= (and understood) together. In looking at Phone BCP, there have been many = situations in which I wondered what the justification was for a requiremen= t, only to find the (usually persuasive) explanation in the corresponding s= ection of the framework document. > >IMHO, the separation of the two documents is somewhat unnatural. It's a bi= t like taking a meal, freeze drying it, and then presenting the diner with = a cup of powder and a cup of water and wondering why they are left with a q= uizical look on their faces. Including cooking instructions along with the= two cups is not a fully satisfactory answer. > >Given this reality, if there is a need for text explaining the fundamental= assumptions of the architecture, the place for that text is not in the BCP= document, but in the framework document. As has been noted by others, the= entire BCP document is an applicability statement, and when viewed in that= way, the proposed text is not only unnecessary, but somewhat confusing sin= ce required context for the BCP document belongs in the framework document.= If anything more is necesary, it would probably be some additional instru= ctions for the reader delving into the document set for the first time. > >Like any IETF effort, the framework and BCP documents will be evaluated on= their own merits. Athough this is an area with a considerable regulatory c= omponent, I see little evidence that the world at large is so in awe of the= IETF that every word will be taken as immutable truth. No doubt other SDO= s will take issue with these documents in whole or in part and will explain= the basis of their assessments and where necessary, their alternatives. As= a result, some portions of the architecture may be adopted, some portions = may be ignored, and others will be revised in an effort to address the issu= es encountered and improve their chances for deployment. > >With respect to this process, the addition of cautionary text is a bit lik= e the warning labels that we find on consumer products. While it may be ne= cessary in some legalistic sense, given the expertise of the individuals as= sessing these documents, one wonders what the practical effect will be. Ty= pically these are individuals who already understand that it is a good idea= to double-cup hot coffee. > > > >--------------------------------------------------------------------------= ---------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. =20 >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------------------= ---------------------- >[mf2] > >Content-Type: text/plain; name=3D"ATT00001.txt" >Content-Description: ATT00001.txt >Content-Disposition: attachment; filename=3D"ATT00001.txt"; size=3D194; > creation-date=3D"Thu, 30 Apr 2009 09:49:15 GMT"; > modification-date=3D"Thu, 30 Apr 2009 09:49:15 GMT" > >Attachment converted: Macintosh HD:ATT00001 5257.txt (TEXT/ttxt) (0040366B= ) From mlinsner@cisco.com Thu Apr 30 12:51:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BEB3A68B9 for ; Thu, 30 Apr 2009 12:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPwf5JfakjTQ for ; Thu, 30 Apr 2009 12:51:38 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 71CA53A6F38 for ; Thu, 30 Apr 2009 12:51:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,274,1238976000"; d="scan'208";a="43126483" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2009 19:52:33 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3UJqXCS029675; Thu, 30 Apr 2009 15:52:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3UJqXAb012260; Thu, 30 Apr 2009 19:52:33 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 15:52:33 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 15:52:32 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 30 Apr 2009 15:52:29 -0400 From: Marc Linsner To: Ted Hardie , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnJzTFWv2G1/rdFK0mW8nvlVMBQZg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Apr 2009 19:52:32.0183 (UTC) FILETIME=[333C2C70:01C9C9CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12875; t=1241121153; x=1241985153; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20PhoneBCP |Sender:=20 |To:=20Ted=20Hardie=20,=20=22ecrit@iet f.org=22=20; bh=iPLukgykbxD9xHozDuB6l/TOXrLM5rHiRHt+M1P+kzg=; b=OMKa93KQ3h6iC7cMjdJ0/sdz5S2KQHoTrQGUluOln1wCGahLq55CsSWx5N rvodPTFGseY6ax1mH9Hf01qsWlklIsnHHV50xLUdIhIKDSerABPncsq6YesR /bAYC9zuDw; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:51:40 -0000 Ted, I searched a small amount for comparison type language in other IETF drafts. I'm struggling with the notion that anyone who would read IETF drafts would get confused as to their solution/applicability space. Since my search was small and cycles are short, are you aware if there is any such language in any of the ream of SIP drafts that point out the solution space and explicitly exclude IMS? -Marc- On 4/30/09 1:40 PM, "Ted Hardie" wrote: > At 9:48 AM -0700 4/30/09, Dawson, Martin wrote: >> Understanding ECRIT means understanding that broadband Internet access is >> broadband Internet access is broadband Internet access. > > To put it mildy, this is far from true. There is a whole class of offerings > that > is voice-as-a-service (the IMS/NGN group) which absolutely do not act like > voice-as-an-application. The solution we've defined is for > voice-as-an-application, > which has the natural result that the end user device has the primary role. > > The root of the problem we're facing is that there is a difference between > using IP and using the Internet model. IMS uses IP, but uses a different > model entirely (Whatever you think of that model, I don't think anyone > who looked at how it works could argue that it is the same as the Internet > model.) > > The documents we're dealing with contrast the offering with PSTN, but > don't really see any differentiation among "packet-switched networks". > Take this early text from the Framework document: > >> It is beyond the scope of this document to enumerate and discuss all >> the differences between traditional (Public Switched Telephone >> Network) and IP-based telephony, but calling on the Internet is >> characterized by: >> o the interleaving over the same infrastructure of a wider variety >> of services; >> o the separation of the access provider from the application >> provider; >> o media other than voice (e.g. video and text in several forms); >> o the potential mobility of all end systems, including endpoints >> nominally thought of as fixed systems and not just those using >> radio access technology. For example, consider a wired phone >> connected to a router using a mobile data network such as EV-DO as >> an uplink. >> >> This document focuses on how devices using the Internet can place >> emergency calls and how PSAPs can handle Internet multimedia >> emergency calls natively, rather than describing how circuit-switched >> PSAPs can handle VoIP calls. In many cases, PSAPs making the >> transition from circuit-switched interfaces to packet-switched >> interfaces may be able to use some of the mechanisms described here, >> in combination with gateways that translate packet-switched calls >> into legacy interfaces, e.g., to continue to be able to use existing >> call taker equipment. There are many legacy telephone networks that >> will persist long after most systems have been upgraded to IP >> origination and termination of emergency calls. Many of these legacy >> systems route calls based on telephone numbers. Gateways and >> conversions between existing systems and newer systems defined by >> this document will be required. Since existing systems are governed >> primarily by local government regulations and national standards, the >> gateway and conversion details will be governed by national standards >> and thus are out of scope for this document. > > The real contrast being made is between circuit-switched and Internet > model, but the terms used mix "packet-switched", "IP-based", and "Internet"; > there is even an explicit mention of EV-DO, but in a mode that treats > it as a pure IP bearer (which is not what is being sold in most markets > today). The reality on the ground today is that there are at least > circuit-switched, > Internet model IP, and IP with operator services out there in the real > world. This document set doesn't acknowledge that, and it treats all > packet-switched services/IP-based services as if they were Internet model. > That's simply not true. > > The argument that Steven and others have made is that the document set > needs to have an explicit acknowledgement of the other model, so that > there is a realization by those reading them that just because they have > IP, doesn't mean they are dealing with the Internet model. You could > argue that everyone knows that, but the document itself muddies it > far enough that it is far from evident. > > Do I, personally believe the Internet model version is better? Yep. Do > I, personally believe that it will eventually subsume other versions? Maybe, > and I think it would be nice. But I also recognize that it is not the case > now, > and we're trying to define a system that will actually work to deliver > emergency > calls in the real world. Explicit acknowledgement seems to me valuable > in that case. The other option is to re-write the documents to clarify that > not any packet-switched network nor any network using IP fits this set > of assumptions; that seems to me likely to take longer and not add much. > > You've already had Keith note that he would object to the documents if > they did not contain language like that which was in -09. If it is taken out, > I believe the documents will need a major editing pass to accomplish the > clarification without the explicit text. This text is a compromise already, > and the issue it deals with is important. Unless we are going to pretend > that the IMS model simply doesn't exist and won't be used to deliver a > substantial fraction of emergency calls for a good long time to come, > we need it. If we are going to pretend that, I think we are being very > foolish > indeed. > > Ted > > > >> Having to change the way the device initiates an emergency call when >> something as prosaic as the access technology changes is akin to having to >> change your web browser just because the access technology has changed. It's >> neither helpful nor harmless to have such a restriction. >> >> A helpful statement to put in the BCP might be "Other architectures, such as >> IMS Emergency calling defined by 3GPP and 3GPP2, which are not based on the >> ECRIT framework are likely to not be compatible with devices and emergency >> networks which assume this framework - e.g. such as is defined by NENA as >> i3." >> >> I don't endorse the inclusion of such a statement; it's commentary - as is >> the proposed "applicability statement" and commentary is unnecessary. >> Nevertheless, I think it's a more accurate characterization. That is, it's >> more the case that the 3GPP IMS emergency architecture doesn't fit ECRIT than >> it is that ECRIT doesn't fit a 3GPP access network. >> >> Cheers, >> Martin >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Edge, Stephen >> Sent: Friday, 1 May 2009 2:29 AM >> To: Bernard Aboba; Thomson, Martin; ecrit@ietf.org >> Subject: Re: [Ecrit] PhoneBCP >> >> Bernard and others >> >> This is an interesting view - an admission that the Ecrit solution will >> probably not be universally applied and when it is may be subject to >> modification. On the 3GPP/3GPP2 sides, solutions are defined with a specific >> and explicit scope and are expected to be - and nearly always actually are - >> supported exactly as defined in the appropriate spec.s for all scenarios >> covered by the scope. A solution whose deployment is unpredictable will be >> less useful because of the implied interworking problems between incompatible >> implementations. That is a main reason why I and others initially tried to >> include a more precise applicability/scope statement than the one we are now >> discussing. Specifically, the Ecrit solution will probably not be deployed by >> 3GPP/3GPP2 operators for cellular terminals because they have defined a >> somewhat different solution more suitable for cellular operation. That means >> that a terminal supporting only the Ecrit solution (based on an assertion of >> universal ap > plicability) will encounter problems when its user attempts an emergency call > on a 3GPP/3GPP2 network. If I can extend your analogies, this would be like > not including a precise menu description for a meal containing meat and/or > fish in a restaurant catering to both vegetarians and non-vegetarians. >> >> Kind Regards >> >> Stephen >> >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >> Sent: Thursday, April 30, 2009 1:13 AM >> To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org >> Subject: RE: [Ecrit] PhoneBCP >> >>> Your interpretation of applicability is certainly extreme (yes or qualified >>> yes to all questions) - removing any dependence on suitability or >>> feasibility (which are the more normal benchmarks) and simply making a >>> legalistic blanket assertion. (I can now more understand incidentally why >>> the fictitious protocol police are so often invoked on matters of >>> conformance.) >>> >>> But do others have any views on this? >> >> Here is my 2 pence. As noted in the Introduction, the Phone BCP document >> and framework documents are closely related documents that need to be read >> (and understood) together. In looking at Phone BCP, there have been many >> situations in which I wondered what the justification was for a requirement, >> only to find the (usually persuasive) explanation in the corresponding >> section of the framework document. >> >> IMHO, the separation of the two documents is somewhat unnatural. It's a bit >> like taking a meal, freeze drying it, and then presenting the diner with a >> cup of powder and a cup of water and wondering why they are left with a >> quizical look on their faces. Including cooking instructions along with the >> two cups is not a fully satisfactory answer. >> >> Given this reality, if there is a need for text explaining the fundamental >> assumptions of the architecture, the place for that text is not in the BCP >> document, but in the framework document. As has been noted by others, the >> entire BCP document is an applicability statement, and when viewed in that >> way, the proposed text is not only unnecessary, but somewhat confusing since >> required context for the BCP document belongs in the framework document. If >> anything more is necesary, it would probably be some additional instructions >> for the reader delving into the document set for the first time. >> >> Like any IETF effort, the framework and BCP documents will be evaluated on >> their own merits. Athough this is an area with a considerable regulatory >> component, I see little evidence that the world at large is so in awe of the >> IETF that every word will be taken as immutable truth. No doubt other SDOs >> will take issue with these documents in whole or in part and will explain the >> basis of their assessments and where necessary, their alternatives. As a >> result, some portions of the architecture may be adopted, some portions may >> be ignored, and others will be revised in an effort to address the issues >> encountered and improve their chances for deployment. >> >> With respect to this process, the addition of cautionary text is a bit like >> the warning labels that we find on consumer products. While it may be >> necessary in some legalistic sense, given the expertise of the individuals >> assessing these documents, one wonders what the practical effect will be. >> Typically these are individuals who already understand that it is a good idea >> to double-cup hot coffee. >> >> >> >> ----------------------------------------------------------------------------- >> ------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ----------------------------------------------------------------------------- >> ------------------- >> [mf2] >> >> Content-Type: text/plain; name="ATT00001.txt" >> Content-Description: ATT00001.txt >> Content-Disposition: attachment; filename="ATT00001.txt"; size=194; >> creation-date="Thu, 30 Apr 2009 09:49:15 GMT"; >> modification-date="Thu, 30 Apr 2009 09:49:15 GMT" >> >> Attachment converted: Macintosh HD:ATT00001 5257.txt (TEXT/ttxt) (0040366B) > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hardie@qualcomm.com Thu Apr 30 12:53:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48923A6E12 for ; Thu, 30 Apr 2009 12:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.387 X-Spam-Level: X-Spam-Status: No, score=-103.387 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXiBwbJo75Mw for ; Thu, 30 Apr 2009 12:53:51 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4A32E3A6AB5 for ; Thu, 30 Apr 2009 12:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1241121314; x=1272657314; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20|Date:=20Thu,=2030=20Apr=202009=2012:54:55=20-0700|To: =20Marc=20Linsner=20,=20"ecrit@ietf.o rg"=20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20PhoneBCP |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5601"=3B=20 a=3D"17645106"; bh=Nq4QqOZrWnSgpmgz+CvawvqqFFH3ksXltEaDPMDI7O0=; b=iyLWmL0GcMw8mM+EM+n4Hbgoe0oBCPdC0TTj+oa9Z81ss8PGC37tP0WA Mb8CMuYi7Og1dpeeK54VxpGaJykcxEjuuLWWNDBzpQme5sCftPajeYFJO oDblmhoCUOGVtUTsk3QWmYdk/gvta3DNz/9KXLzwe0GfNwn/rWaUAEePJ w=; X-IronPort-AV: E=McAfee;i="5300,2777,5601"; a="17645106" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 12:54:59 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UJsxsJ020178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 12:54:59 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UJsgtQ015890 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Apr 2009 12:54:58 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 30 Apr 2009 12:54:57 -0700 Received: from [10.0.1.197] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 30 Apr 2009 12:54:57 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Thu, 30 Apr 2009 12:54:55 -0700 To: Marc Linsner , "ecrit@ietf.org" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:53:54 -0000 At 12:52 PM -0700 4/30/09, Marc Linsner wrote: >Ted, > >I searched a small amount for comparison type language in other IETF drafts. >I'm struggling with the notion that anyone who would read IETF drafts would >get confused as to their solution/applicability space. > >Since my search was small and cycles are short, are you aware if there is >any such language in any of the ream of SIP drafts that point out the >solution space and explicitly exclude IMS? > >-Marc- Besides the long-running argument over SBCs? I am not sure; possibly Keith would be able to point to comparison text. Ted > >On 4/30/09 1:40 PM, "Ted Hardie" wrote: > >> At 9:48 AM -0700 4/30/09, Dawson, Martin wrote: >>> Understanding ECRIT means understanding that broadband Internet access is >>> broadband Internet access is broadband Internet access. >> >> To put it mildy, this is far from true. There is a whole class of offerings >> that >> is voice-as-a-service (the IMS/NGN group) which absolutely do not act like >> voice-as-an-application. The solution we've defined is for >> voice-as-an-application, >> which has the natural result that the end user device has the primary role. >> >> The root of the problem we're facing is that there is a difference between >> using IP and using the Internet model. IMS uses IP, but uses a different >> model entirely (Whatever you think of that model, I don't think anyone >> who looked at how it works could argue that it is the same as the Internet >> model.) >> >> The documents we're dealing with contrast the offering with PSTN, but >> don't really see any differentiation among "packet-switched networks". >> Take this early text from the Framework document: >> >>> It is beyond the scope of this document to enumerate and discuss all >>> the differences between traditional (Public Switched Telephone >>> Network) and IP-based telephony, but calling on the Internet is >>> characterized by: >>> o the interleaving over the same infrastructure of a wider variety >>> of services; >>> o the separation of the access provider from the application >>> provider; >>> o media other than voice (e.g. video and text in several forms); >>> o the potential mobility of all end systems, including endpoints >>> nominally thought of as fixed systems and not just those using >>> radio access technology. For example, consider a wired phone >>> connected to a router using a mobile data network such as EV-DO as >>> an uplink. >>> >>> This document focuses on how devices using the Internet can place >>> emergency calls and how PSAPs can handle Internet multimedia >>> emergency calls natively, rather than describing how circuit-switched >>> PSAPs can handle VoIP calls. In many cases, PSAPs making the >>> transition from circuit-switched interfaces to packet-switched >>> interfaces may be able to use some of the mechanisms described here, >>> in combination with gateways that translate packet-switched calls >>> into legacy interfaces, e.g., to continue to be able to use existing >>> call taker equipment. There are many legacy telephone networks that >>> will persist long after most systems have been upgraded to IP >>> origination and termination of emergency calls. Many of these legacy >>> systems route calls based on telephone numbers. Gateways and >>> conversions between existing systems and newer systems defined by >>> this document will be required. Since existing systems are governed >>> primarily by local government regulations and national standards, the >>> gateway and conversion details will be governed by national standards >>> and thus are out of scope for this document. >> >> The real contrast being made is between circuit-switched and Internet >> model, but the terms used mix "packet-switched", "IP-based", and "Internet"; >> there is even an explicit mention of EV-DO, but in a mode that treats >> it as a pure IP bearer (which is not what is being sold in most markets > > today). The reality on the ground today is that there are at least >> circuit-switched, >> Internet model IP, and IP with operator services out there in the real >> world. This document set doesn't acknowledge that, and it treats all >> packet-switched services/IP-based services as if they were Internet model. >> That's simply not true. >> >> The argument that Steven and others have made is that the document set >> needs to have an explicit acknowledgement of the other model, so that >> there is a realization by those reading them that just because they have >> IP, doesn't mean they are dealing with the Internet model. You could >> argue that everyone knows that, but the document itself muddies it >> far enough that it is far from evident. >> >> Do I, personally believe the Internet model version is better? Yep. Do >> I, personally believe that it will eventually subsume other versions? Maybe, >> and I think it would be nice. But I also recognize that it is not the case >> now, >> and we're trying to define a system that will actually work to deliver >> emergency >> calls in the real world. Explicit acknowledgement seems to me valuable >> in that case. The other option is to re-write the documents to clarify that >> not any packet-switched network nor any network using IP fits this set >> of assumptions; that seems to me likely to take longer and not add much. >> >> You've already had Keith note that he would object to the documents if >> they did not contain language like that which was in -09. If it is taken out, >> I believe the documents will need a major editing pass to accomplish the >> clarification without the explicit text. This text is a compromise already, >> and the issue it deals with is important. Unless we are going to pretend >> that the IMS model simply doesn't exist and won't be used to deliver a >> substantial fraction of emergency calls for a good long time to come, >> we need it. If we are going to pretend that, I think we are being very >> foolish >> indeed. >> >> Ted >> >> >> >>> Having to change the way the device initiates an emergency call when >>> something as prosaic as the access technology changes is akin to having to >>> change your web browser just because the access technology has changed. It's >>> neither helpful nor harmless to have such a restriction. >>> >>> A helpful statement to put in the BCP might be "Other architectures, such as >>> IMS Emergency calling defined by 3GPP and 3GPP2, which are not based on the >>> ECRIT framework are likely to not be compatible with devices and emergency >>> networks which assume this framework - e.g. such as is defined by NENA as >>> i3." >>> >>> I don't endorse the inclusion of such a statement; it's commentary - as is >>> the proposed "applicability statement" and commentary is unnecessary. >>> Nevertheless, I think it's a more accurate characterization. That is, it's >>> more the case that the 3GPP IMS emergency architecture doesn't fit ECRIT than >>> it is that ECRIT doesn't fit a 3GPP access network. >>> >>> Cheers, >>> Martin >>> >>> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>> Edge, Stephen >>> Sent: Friday, 1 May 2009 2:29 AM >>> To: Bernard Aboba; Thomson, Martin; ecrit@ietf.org >>> Subject: Re: [Ecrit] PhoneBCP >>> >>> Bernard and others >>> >>> This is an interesting view - an admission that the Ecrit solution will >>> probably not be universally applied and when it is may be subject to >>> modification. On the 3GPP/3GPP2 sides, solutions are defined with a specific >>> and explicit scope and are expected to be - and nearly always actually are - >>> supported exactly as defined in the appropriate spec.s for all scenarios >>> covered by the scope. A solution whose deployment is unpredictable will be >>> less useful because of the implied interworking problems between incompatible >>> implementations. That is a main reason why I and others initially tried to >>> include a more precise applicability/scope statement than the one we are now >>> discussing. Specifically, the Ecrit solution will probably not be deployed by >>> 3GPP/3GPP2 operators for cellular terminals because they have defined a > >> somewhat different solution more suitable for cellular operation. That means >>> that a terminal supporting only the Ecrit solution (based on an assertion of >>> universal ap >> plicability) will encounter problems when its user attempts an emergency call >> on a 3GPP/3GPP2 network. If I can extend your analogies, this would be like >> not including a precise menu description for a meal containing meat and/or >> fish in a restaurant catering to both vegetarians and non-vegetarians. >>> >>> Kind Regards >>> >>> Stephen >>> >>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >>> Sent: Thursday, April 30, 2009 1:13 AM >>> To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org >>> Subject: RE: [Ecrit] PhoneBCP >>> >>>> Your interpretation of applicability is certainly extreme (yes or qualified >>>> yes to all questions) - removing any dependence on suitability or >>>> feasibility (which are the more normal benchmarks) and simply making a >>>> legalistic blanket assertion. (I can now more understand incidentally why >>>> the fictitious protocol police are so often invoked on matters of >>>> conformance.) >>>> >>>> But do others have any views on this? >>> >>> Here is my 2 pence. As noted in the Introduction, the Phone BCP document >>> and framework documents are closely related documents that need to be read >>> (and understood) together. In looking at Phone BCP, there have been many >>> situations in which I wondered what the justification was for a requirement, >>> only to find the (usually persuasive) explanation in the corresponding >>> section of the framework document. >>> >>> IMHO, the separation of the two documents is somewhat unnatural. It's a bit >>> like taking a meal, freeze drying it, and then presenting the diner with a >>> cup of powder and a cup of water and wondering why they are left with a >>> quizical look on their faces. Including cooking instructions along with the >>> two cups is not a fully satisfactory answer. >>> >>> Given this reality, if there is a need for text explaining the fundamental >>> assumptions of the architecture, the place for that text is not in the BCP >>> document, but in the framework document. As has been noted by others, the >>> entire BCP document is an applicability statement, and when viewed in that >>> way, the proposed text is not only unnecessary, but somewhat confusing since >>> required context for the BCP document belongs in the framework document. If >>> anything more is necesary, it would probably be some additional instructions >>> for the reader delving into the document set for the first time. >>> >>> Like any IETF effort, the framework and BCP documents will be evaluated on >>> their own merits. Athough this is an area with a considerable regulatory >>> component, I see little evidence that the world at large is so in awe of the >>> IETF that every word will be taken as immutable truth. No doubt other SDOs >>> will take issue with these documents in whole or in part and will explain the >>> basis of their assessments and where necessary, their alternatives. As a >>> result, some portions of the architecture may be adopted, some portions may >>> be ignored, and others will be revised in an effort to address the issues >>> encountered and improve their chances for deployment. >>> >>> With respect to this process, the addition of cautionary text is a bit like >>> the warning labels that we find on consumer products. While it may be >>> necessary in some legalistic sense, given the expertise of the individuals >>> assessing these documents, one wonders what the practical effect will be. >>> Typically these are individuals who already understand that it is a good idea >>> to double-cup hot coffee. >>> >>> >>> >>> ----------------------------------------------------------------------------- >>> ------------------- >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> ----------------------------------------------------------------------------- > >> ------------------- >>> [mf2] >>> >>> Content-Type: text/plain; name="ATT00001.txt" >>> Content-Description: ATT00001.txt >>> Content-Disposition: attachment; filename="ATT00001.txt"; size=194; >>> creation-date="Thu, 30 Apr 2009 09:49:15 GMT"; >>> modification-date="Thu, 30 Apr 2009 09:49:15 GMT" >>> >>> Attachment converted: Macintosh HD:ATT00001 5257.txt (TEXT/ttxt) (0040366B) >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From sedge@qualcomm.com Thu Apr 30 13:31:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EF03A6ACA for ; Thu, 30 Apr 2009 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.53 X-Spam-Level: X-Spam-Status: No, score=-105.53 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcwbo55pZPiU for ; Thu, 30 Apr 2009 13:31:11 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 099723A67F7 for ; Thu, 30 Apr 2009 13:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241123524; x=1272659524; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20M arc=20Linsner=20,=20ECRIT=20|Date:=20Thu,=2030=20Apr=202009=2013:31:55=20-0700 |Subject:=20RE:=20[Ecrit]=20PhoneBCP|Thread-Topic:=20[Ecr it]=20PhoneBCP|Thread-Index:=20AcnIPOEzsgk5dznfTdGkY0hVKl KLbAA1krMAAAOvt4AAEIpT0AALcu3yAA/5C6A=3D|Message-ID:=20<1 288E74A73964940B132A0B9EA8D8ABC5926A504@NASANEXMB04.na.qu alcomm.com>|References:=20<1288E74A73964940B132A0B9EA8D8A BC5926A4B4@NASANEXMB04.na.qualcomm.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5601"=3B=20a=3D"17652938"; bh=xC6fXM0t/zyr9DxVeB1ix+ZoCcKL0szf15Y+XUDAouw=; b=Elk4EJDhCD54d39v/KD7glQn7le71V7wY/UkWEtOIskp9fa7g6IJj9ni XhL/h/fphi2PdxSPr7IcwMW/kMF7sz1m5gf+2x8eFlSDD3+T3rA8jZw3P cdDJgj2MtZGiszbj22b1gJLHgkbHTJebmZjMRNGD/vu42spU9pyg5IKFV E=; X-IronPort-AV: E=McAfee;i="5300,2777,5601"; a="17652938" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 13:32:04 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UKW3uW025370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 13:32:03 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UKVvtu013075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Apr 2009 13:31:57 -0700 (PDT) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Thu, 30 Apr 2009 13:31:57 -0700 From: "Edge, Stephen" To: Marc Linsner , ECRIT Date: Thu, 30 Apr 2009 13:31:55 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnIPOEzsgk5dznfTdGkY0hVKlKLbAA1krMAAAOvt4AAEIpT0AALcu3yAA/5C6A= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A504@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC5926A4B4@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:31:12 -0000 Hi Marc It seems that RFC 5012 would be a useful acknowledgement (assuming that its= requirements are all or mostly supported). But I do not have the impressio= n that RFC 5069 is supported - but if it is, then it's also another good re= ference. Neither of these, however, is an effective substitute for a clear simple st= atement like the one we are discussing (and I saw no equivalent statement i= n either of the RFCs). Kind Regards Stephen -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Thursday, April 30, 2009 5:48 AM To: Edge, Stephen; ECRIT Subject: Re: [Ecrit] PhoneBCP Stephen, As I pondered on the new text, I saw no great harm with it, but the reason = I hummed against it, I don't see that it adds any value. If we declare in either/both drafts that this solution is based on the requirements in RFC5012/RFC5069, would that satisfy your concern...?? (I'm somewhat surprised this isn't in either draft.) -Marc- On 4/30/09 3:35 AM, "Edge, Stephen" wrote: > Hi James >=20 > The current statement being debated does not say that Ecrit is not applic= able > to 3GPP and 3GPP2. We got past that point 5 weeks ago and I and others mo= re on > the 3GPP/3GPP2 side are now perfectly willing to let that drop given the > current statement which essentially characterizes the main principles of = the > Ecrit solution, admits the potential existence of other solutions and the= fact > that they are not defined within the Ecrit solution. >=20 > The detailed points you raise below may not be worth answering if you als= o > take the same view as Martin namely that suitability and feasibility are > irrelevant when it comes to Ecrit (though not of course when it comes to = 3GPP > and 3GPP2 I should note). >=20 > But I am still awaiting answers to my original questions from others in t= he > Ecrit community. >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, April 29, 2009 9:00 PM > To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning Schulzrinne; > Stark, Barbara; ECRIT > Subject: RE: [Ecrit] PhoneBCP >=20 > Stephen, >=20 > As someone that has been vocal on this topic all along I will respond. >=20 > Would you agree that this solution does allow the ultimate destination > of the PSAP being reached using legacy TDM trunks? > If you want to take the debate offline I can clearly show to you the > solution does, and as preparation please take a look at some of the NENA > i3 and i2 work. >=20 > So this makes quite a lot of your argument below irrelevant. >=20 > You have continually argued that there is something special about IMS > and cellular despite continual evidence being presented that there is > not. Voice is not special when it comes to IP traffic, it is just > another data stream. What you are doing is coming here and saying that > 3GPP are introducing a whole bunch of complex machinations to maintain a > bundling of access and service, so please would we put an applicability > statement into our documents to say that they don't apply to 3GPP > networks. This is unreasonable. >=20 > If I read 23.167 correctly, then the calling device can obtain its > location directly from the IP CAN, at least one of the IETF LCP is even > mentioned, and I have seen a CR that suggested that HELD could also be > used. >=20 > 23.167 also makes use of SIP location conveyance. So far, this is 2 of > the 3 elements we require for ECRIT to just work. >=20 > I think it is perfectly reasonable to assume that if I get my location > from the IP CAN, I can probably get the serving domain also, in which > case I can do a LoST lookup. Alternatively I can go back to my home LoST > server and rely on forest guides. In either case, these are quite > reasonable assumptions, and the onus on an infrastructure provider is a > provisioning record, rather than E-SLP.... hmmmm which is cheaper and > easier I wonder? >=20 > Now what does TS23.167 say to do if my SIP client directs a call to a > URI that it obtained from a LoST Server? > I would place odds that it would just deliver the call. >=20 > Further more, if that SIP INVITE included both a CID header and a > location URI what happens? For i2 and i3 we know what happens. Again, > the LRF in 23.167 at a minimum will provide a route to the PSAP based on > the provided location. >=20 > Now, lets take Martin's argument a bit more. > I have a device that can operate on 3G, 4G or WiFi. If it connect to a > non-IMS WiFi hotspot (basically all of them) what happens? Where is the > E-CSCF, where is the E-SLP, how can it help me? >=20 > The point I am making is that ECRIT will actually work even in IMS > architectures, but the IMS architecture doesn't work in the vast > majority of IP cases. Any applicability statement you want please go and > add it to 3GPP and not here, it is 3GPP that has the applicability > issues and not the IETF. >=20 > Cheers > James > =20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Edge, Stephen > Sent: Thursday, 30 April 2009 9:23 AM > To: Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark, > Barbara; ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > Richard and all others >=20 > I wonder if those now humming against this statement (and who were all > strangely silent 5 weeks ago) would support any kind of statement > concerning applicability and scope. Or is it the case that the solution > supported by both drafts is considered to apply to all devices, ANs and > VSPs that provide some form of internet access. If so, is it irrelevant > whether the solution is actually suitable for a particular type of AN or > VSP (e.g. cellular AN, IMS based VSP)? For example, is it irrelevant > whether significant additional support from an AN or VSP to which the > solution might be applied would be needed in order to access legacy > PSAPs, handoff to the circuit domain, authenticate the caller and > provide access to non-subscribed users? Is it further irrelevant whether > the solution would even work for a particular device, AN or VSP without > substantial changes to the latter? In other words, is the solution now > considered so sacrosanct that any adaptation must come from the rest of > the > infrastructure and not from the solution itself in the case of any > mismatch? If the consensus answers to these questions are all yes, then > I would have to agree that including the currently disputed statement or > anything of a similar nature would be inconsistent and unnecessary. Of > course, the representatives of the potentially affected portions of > infrastructure should be forgiven for disagreeing with the basic premise > - and may be expected to offer some type of protest! >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, April 28, 2009 1:07 PM > To: Edge, Stephen > Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 > Stephen, >=20 > As was noted in the meeting, it is *always* possible that there are > alternative solutions out there when you're talking about the Internet. > TCP vs. UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs. > XMPP, SASL vs. TLS, S/MIME vs. OpenPGP. None of the many RFCs out there >=20 > have explicit statements that somebody else might do it differently > because it's obvious that they can. >=20 > So I don't really think conveying the possibility of other > implementations is actually useful at all, technically speaking. >=20 > That means that the only real purpose of such a statement is rhetorical, >=20 > and as we've seen in a few messages here, some people misconstrue the > rhetoric to mean that this system has constrained applicability. Given > that, I'd rather leave it off unless we can avoid that impression. >=20 > --Richard >=20 >=20 >=20 >=20 > Edge, Stephen wrote: >> All >>=20 >> I would have thought that motivation should be irrelevant. There are a > lot of motives at work here. Should we assume that the document was > originally written with only the purest and most altruistic motives > (e.g. no thought of business or academic interest at stake)? >>=20 >> The issue is whether the current statement serves a useful purpose in > conveying the possibility (well known to be true) of alternative > solutions not fully aligned with the current drafts. Nothing in the > statement implies that the current drafts are necessarily deficient or > that alternative solutions must necessarily be used for some scenarios > (even though they optionally can be). >>=20 >> Kind Regards >>=20 >> Stephen >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Randall Gellens >> Sent: Tuesday, April 28, 2009 9:57 AM >> To: Henning Schulzrinne; Stark, Barbara >> Cc: ECRIT >> Subject: Re: [Ecrit] PhoneBCP >>=20 >> At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote: >>=20 >>> It is clear that the text has ulterior motives to restrict the >>> applicability of the document. >>=20 >> From my view, the text does not restrict the applicability, nor is >> there a desire to do so. The text does clarify the assumptions of >> the rest of the text in the document, which I think is helpful. >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > -------------------------------------------------------------------------= ----- > ------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------= ----- > ------------------ > [mf2] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Thu Apr 30 16:36:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546C928C1BE for ; Thu, 30 Apr 2009 16:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0UClpu6qHJX for ; Thu, 30 Apr 2009 16:36:41 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B8DA528C1B8 for ; Thu, 30 Apr 2009 16:36:29 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_04_30_18_58_40 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 30 Apr 2009 18:58:39 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 18:37:50 -0500 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_01C9C9EC.ACA5CBA0" Date: Thu, 30 Apr 2009 18:37:49 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Phone BCP Hum Thread-Index: AcnJ7KwaxYYHzuuuSKepInED4dj4ew== From: "Winterbottom, James" To: "ECRIT" X-OriginalArrivalTime: 30 Apr 2009 23:37:50.0986 (UTC) FILETIME=[AD11CEA0:01C9C9EC] Subject: [Ecrit] Phone BCP Hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 23:36:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C9EC.ACA5CBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=0D=0A=0D=0A=20=0D=0A=0D=0AMarc's original thread has turned into an= issue discussion thread.=0D=0A=0D=0ACan people please keep this thread jus= t for humming, and rant in the=0D=0Aother thread=3F=0D=0A=0D=0A=20=0D=0A=0D= =0AI hum against the inclusion of the statement!=0D=0A=0D=0A=20=0D=0A=0D=0A= Cheers=0D=0A=0D=0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A-------------------------= -----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C9C9EC.ACA5CBA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=