From ecrit-bounces@ietf.org Mon Dec 1 07:58:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E0B3A6A4F; Mon, 1 Dec 2008 07:58:52 -0800 (PST) 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 87C213A6A4F for ; Mon, 1 Dec 2008 07:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 6oLiMOTfDQd4 for ; Mon, 1 Dec 2008 07:58:49 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 486EA3A696B for ; Mon, 1 Dec 2008 07:58:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-146.messagelabs.com!1228147124!2979721!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 8423 invoked from network); 1 Dec 2008 15:58:44 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 1 Dec 2008 15:58:44 -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 mB1FwfSR014735; Mon, 1 Dec 2008 10:58:42 -0500 Received: from 01GAF5142010622.AD.BLS.COM ([139.76.131.83]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id mB1FwWoP014386; Mon, 1 Dec 2008 10:58:35 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 1 Dec 2008 10:58:34 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 1 Dec 2008 10:58:34 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 10:58:33 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Additional text - location mech - wireless & mobilitysupport thread-index: AclMGvVEfWp8KLJwSQWgXrQcHJA+0wAAaLeAAWLualAAiPUaoA== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80! c d670$ @ne t> <8C83 7214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com> From: "Stark, Barbara" To: "Roger Marshall" , "Rosen, Brian" X-OriginalArrivalTime: 01 Dec 2008 15:58:34.0946 (UTC) FILETIME=[AA6D4A20:01C953CD] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional text - location mech - wireless & mobilitysupport 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't understand this proposed sentence: " Requirements for endpoint location determination vary, depending on whether an endpoint's resulting location is based on internal (device-based) or external (network-based) measurements, or by manual provisioning - for mobile capable, or fixed environment endpoints, respectively. " That is, I understand the first part, up to the dash "-". I don't understand the part after the dash "-", specifically the use of the word "respectively". Is a Femtocell access point (which connects via Ethernet into the LAN of a home network that is connected by a broadband connection to the Internet) mobile capable or fixed? The FAP itself is certainly *not* mobile. It will be able to use GPS or AGPS (with SUPL) to get its location determined. It will also need to be able to use other methods to get its location when it finds itself in a basement, unable to make use of GPS. Is a GSM/Wi-Fi PDA that is in someone's basement (where GPS doesn't work, and they can't get a cellular signal), and is connected via Wi-Fi into a home network, supposed to use internal or external measurements? It's definitely mobile capable. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Friday, November 28, 2008 5:35 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: [Ecrit] Additional text - location mech - wireless & mobilitysupport Brian: Below is a proposed change in text to the current phonebcp-06 that adds some background for various requirements later in the draft that specify "wireless" and "mobile", per remarks made in the 11/20 ECRIT wg meeting. 1. Section 6. Location and its role in emergency calls change from: In Internet emergency calling, where the endpoint is located is "determined" using a variety of measurement or wiretracing methods. Endpoints may be "configured" with their own location by the access network. change to: In Internet emergency calling, the endpoint location is "determined" using a variety of measurement or wiretracing methods. Requirements for endpoint location determination vary, depending on whether an endpoint's resulting location is based on internal (device-based) or external (network-based) measurements, or by manual provisioning - for mobile capable, or fixed environment endpoints, respectively. Once location has been determined, endpoints may then be "configured" with their own location by the access network via some Location Configuration Protocol (LCP). -roger marshall. CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ 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. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 1 08:58:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D393A6816; Mon, 1 Dec 2008 08:58:16 -0800 (PST) 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 4A8A23A6816 for ; Mon, 1 Dec 2008 08:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDqNftZuW9+P for ; Mon, 1 Dec 2008 08:58:14 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 255B23A67D9 for ; Mon, 1 Dec 2008 08:58:14 -0800 (PST) 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 ; Mon, 1 Dec 2008 08:58:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 08:56:46 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B5B6DE8@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Additional text - location mech - wireless & mobilitysupport Thread-Index: AclMGvVEfWp8KLJwSQWgXrQcHJA+0wAAaLeAAWLualAAiPUaoAACPi0A References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80! c d670$ @ne t> <8C83 7214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p> From: "Roger Marshall" To: "Stark, Barbara" , "Rosen, Brian" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional text - location mech - wireless & mobilitysupport 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Barbara: I acknowledge the wording problem (and the bigger deployment problem). How about just shortening the sentence a little by removing the offending word, "respectively"... as follows: " Requirements for endpoint location determination vary, depending on whether an endpoint's resulting location is based on internal (device-based) or external (network-based) measurements, or by manual provisioning, for mobile capable or fixed environment endpoints. " -roger. > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, December 01, 2008 7:59 AM > To: Roger Marshall; Rosen, Brian > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Additional text - location mech - > wireless & mobilitysupport > > I don't understand this proposed sentence: " Requirements for > endpoint location determination vary, depending on whether an > endpoint's resulting location is based on internal > (device-based) or external (network-based) measurements, or > by manual provisioning - for mobile capable, or fixed > environment endpoints, respectively. " > > That is, I understand the first part, up to the dash "-". I > don't understand the part after the dash "-", specifically > the use of the word "respectively". > > Is a Femtocell access point (which connects via Ethernet into > the LAN of a home network that is connected by a broadband > connection to the > Internet) mobile capable or fixed? The FAP itself is > certainly *not* mobile. It will be able to use GPS or AGPS > (with SUPL) to get its location determined. It will also need > to be able to use other methods to get its location when it > finds itself in a basement, unable to make use of GPS. > > Is a GSM/Wi-Fi PDA that is in someone's basement (where GPS > doesn't work, and they can't get a cellular signal), and is > connected via Wi-Fi into a home network, supposed to use > internal or external measurements? > It's definitely mobile capable. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Friday, November 28, 2008 5:35 PM > To: Rosen, Brian > Cc: ecrit@ietf.org > Subject: [Ecrit] Additional text - location mech - wireless & > mobilitysupport > > > > Brian: > Below is a proposed change in text to the current phonebcp-06 > that adds some background for various requirements later in > the draft that specify "wireless" and "mobile", per remarks > made in the 11/20 ECRIT wg meeting. > > 1. Section 6. Location and its role in emergency calls > > change from: > > In Internet emergency calling, where the endpoint is located > is "determined" using a variety of measurement or wiretracing > methods. Endpoints may be "configured" with their own > location by the access network. > > change to: > > In Internet emergency calling, the endpoint location is > "determined" using a variety of measurement or wiretracing > methods. Requirements for endpoint location determination > vary, depending on whether an endpoint's resulting location > is based on internal (device-based) or external > (network-based) measurements, or by manual provisioning - for > mobile capable, or fixed environment endpoints, respectively. > Once location has been determined, endpoints may then be > "configured" with their own location by the access network > via some Location Configuration Protocol (LCP). > > > -roger marshall. > > CONFIDENTIALITY NOTICE: The information contained in this > message may be privileged and/or confidential. If you are not > the intended recipient, or responsible for delivering this > message to the intended recipient, any review, forwarding, > dissemination, distribution or copying of this communication > or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender > immediately, and delete it and all attachments from your > computer and network. > _______________________________________________ > 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. GA622 > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 1 11:45:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C962428C0F9; Mon, 1 Dec 2008 11:45:32 -0800 (PST) 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 38FFA28C0F9 for ; Mon, 1 Dec 2008 11:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 jFylPxdtROpo for ; Mon, 1 Dec 2008 11:45:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7E23828C0D8 for ; Mon, 1 Dec 2008 11:45:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,697,1220227200"; d="scan'208";a="29628787" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Dec 2008 19:45:26 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB1JjQQF029521; Mon, 1 Dec 2008 14:45:26 -0500 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 mB1JjQmo025347; Mon, 1 Dec 2008 19:45:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 14:45:26 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.255.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 14:45:25 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Dec 2008 13:45:24 -0600 To: "Stark, Barbara" , "Roger Marshall" , "Rosen, Brian" From: "James M. Polk" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p> References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> <020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> <5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80! c d670$ @ne t> <8C83 7214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 01 Dec 2008 19:45:25.0931 (UTC) FILETIME=[5B34C7B0:01C953ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4432; t=1228160726; x=1229024726; 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]=20Additional=20text=20-=20locat ion=20mech=20-=20wireless=20&=0A=20=20mobilitysupport |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=0A=20=20= 20=20=20=20=20=20=22Roger=20Marshall=22=20,=0A=20=20=20=20=20=20=20=20=22Rosen,=20Brian=22=20< Brian.Rosen@neustar.biz>; bh=OSNZJJKe+63BZqYtbvqtYNiJKbJh/6XCM4JDCobGUFg=; b=nWdLHSUAxoLTb1+ndEErPjPLPu5A+faHuQUPzhe+wuj6X3Cq4O0L2+31jP QXhEOw6srtLF8rXI1a4FINTUdLR9S0AZd8nnkzqUEPy24kbxXU9v0dNjSfKZ b0NqkfXY4t; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional text - location mech - wireless & mobilitysupport 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Barb I generally agree with your concerns, as I've been on a kick for the last year or so to have anyone that says "wireless" to distinguish whether they are referring to cellular or dot11 based radio-link tethering. The two are most often have (very) different properties. I think this any text changes either need to be more general in nature, or painfully explicit (wrt which or each radio-type). James At 09:58 AM 12/1/2008, Stark, Barbara wrote: >I don't understand this proposed sentence: " Requirements for endpoint >location determination vary, >depending on whether an endpoint's resulting location is based >on internal (device-based) or external (network-based) >measurements, or by manual provisioning - for mobile capable, or >fixed environment endpoints, respectively. " > >That is, I understand the first part, up to the dash "-". I don't >understand the part after the dash "-", specifically the use of the word >"respectively". > >Is a Femtocell access point (which connects via Ethernet into the LAN of >a home network that is connected by a broadband connection to the >Internet) mobile capable or fixed? The FAP itself is certainly *not* >mobile. It will be able to use GPS or AGPS (with SUPL) to get its >location determined. It will also need to be able to use other methods >to get its location when it finds itself in a basement, unable to make >use of GPS. > >Is a GSM/Wi-Fi PDA that is in someone's basement (where GPS doesn't >work, and they can't get a cellular signal), and is connected via Wi-Fi >into a home network, supposed to use internal or external measurements? >It's definitely mobile capable. >Barbara > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of Roger Marshall >Sent: Friday, November 28, 2008 5:35 PM >To: Rosen, Brian >Cc: ecrit@ietf.org >Subject: [Ecrit] Additional text - location mech - wireless & >mobilitysupport > > > >Brian: >Below is a proposed change in text to the current phonebcp-06 that adds >some background for various requirements later in the draft that specify >"wireless" and "mobile", per remarks made in the 11/20 ECRIT wg meeting. > >1. Section 6. Location and its role in emergency calls > >change from: > >In Internet emergency calling, where the endpoint is located >is "determined" using a variety of measurement or wiretracing >methods. Endpoints may be "configured" with their own location >by the access network. > >change to: > >In Internet emergency calling, the endpoint location >is "determined" using a variety of measurement or wiretracing >methods. Requirements for endpoint location determination vary, >depending on whether an endpoint's resulting location is based >on internal (device-based) or external (network-based) >measurements, or by manual provisioning - for mobile capable, or >fixed environment endpoints, respectively. Once location has >been determined, endpoints may then be "configured" with their >own location by the access network via some Location Configuration >Protocol (LCP). > > >-roger marshall. > >CONFIDENTIALITY NOTICE: The information contained in this message may be >privileged and/or confidential. If you are not the intended recipient, >or responsible for delivering this message to the intended recipient, >any review, forwarding, dissemination, distribution or copying of this >communication or any attachment(s) is strictly prohibited. If you have >received this message in error, please notify the sender immediately, >and delete it and all attachments from your computer and network. >_______________________________________________ >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. GA622 > > >_______________________________________________ >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 ecrit-bounces@ietf.org Mon Dec 1 11:48:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127253A6808; Mon, 1 Dec 2008 11:48:16 -0800 (PST) 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 C31203A67DD for ; Mon, 1 Dec 2008 11:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 hdNnnaqV-eHH for ; Mon, 1 Dec 2008 11:48:13 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 85ADE3A67A7 for ; Mon, 1 Dec 2008 11:48:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-6.tower-146.messagelabs.com!1228160887!9111010!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 27825 invoked from network); 1 Dec 2008 19:48:08 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-6.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 1 Dec 2008 19:48:08 -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 mB1Jm64B009672; Mon, 1 Dec 2008 14:48:07 -0500 Received: from 01GAF5142010625.AD.BLS.COM ([139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id mB1Jm06T009544; Mon, 1 Dec 2008 14:48:00 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 1 Dec 2008 14:48:00 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 1 Dec 2008 14:47:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 14:47:58 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0BF060B9@crexc41p> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B5B6DE8@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Additional text - location mech - wireless & mobilitysupport Thread-Index: AclMGvVEfWp8KLJwSQWgXrQcHJA+0wAAaLeAAWLualAAiPUaoAACPi0AAAYZJEA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80! c d670$ @ne t> <8C83 7214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p> <8C837214C95C864C9F34F3635C2A65750B5B6DE8@SEA-EXCHVS-2.telecomsys.com> From: "Stark, Barbara" To: "Roger Marshall" , "Rosen, Brian" X-OriginalArrivalTime: 01 Dec 2008 19:47:59.0811 (UTC) FILETIME=[B6ED0130:01C953ED] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional text - location mech - wireless & mobilitysupport 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yep. That's fine. Barbara -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Monday, December 01, 2008 11:57 AM To: Stark, Barbara; Rosen, Brian Cc: ecrit@ietf.org Subject: RE: [Ecrit] Additional text - location mech - wireless & mobilitysupport Barbara: I acknowledge the wording problem (and the bigger deployment problem). How about just shortening the sentence a little by removing the offending word, "respectively"... as follows: " Requirements for endpoint location determination vary, depending on whether an endpoint's resulting location is based on internal (device-based) or external (network-based) measurements, or by manual provisioning, for mobile capable or fixed environment endpoints. " -roger. > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, December 01, 2008 7:59 AM > To: Roger Marshall; Rosen, Brian > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Additional text - location mech - > wireless & mobilitysupport > > I don't understand this proposed sentence: " Requirements for > endpoint location determination vary, depending on whether an > endpoint's resulting location is based on internal > (device-based) or external (network-based) measurements, or > by manual provisioning - for mobile capable, or fixed > environment endpoints, respectively. " > > That is, I understand the first part, up to the dash "-". I > don't understand the part after the dash "-", specifically > the use of the word "respectively". > > Is a Femtocell access point (which connects via Ethernet into > the LAN of a home network that is connected by a broadband > connection to the > Internet) mobile capable or fixed? The FAP itself is > certainly *not* mobile. It will be able to use GPS or AGPS > (with SUPL) to get its location determined. It will also need > to be able to use other methods to get its location when it > finds itself in a basement, unable to make use of GPS. > > Is a GSM/Wi-Fi PDA that is in someone's basement (where GPS > doesn't work, and they can't get a cellular signal), and is > connected via Wi-Fi into a home network, supposed to use > internal or external measurements? > It's definitely mobile capable. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Friday, November 28, 2008 5:35 PM > To: Rosen, Brian > Cc: ecrit@ietf.org > Subject: [Ecrit] Additional text - location mech - wireless & > mobilitysupport > > > > Brian: > Below is a proposed change in text to the current phonebcp-06 > that adds some background for various requirements later in > the draft that specify "wireless" and "mobile", per remarks > made in the 11/20 ECRIT wg meeting. > > 1. Section 6. Location and its role in emergency calls > > change from: > > In Internet emergency calling, where the endpoint is located > is "determined" using a variety of measurement or wiretracing > methods. Endpoints may be "configured" with their own > location by the access network. > > change to: > > In Internet emergency calling, the endpoint location is > "determined" using a variety of measurement or wiretracing > methods. Requirements for endpoint location determination > vary, depending on whether an endpoint's resulting location > is based on internal (device-based) or external > (network-based) measurements, or by manual provisioning - for > mobile capable, or fixed environment endpoints, respectively. > Once location has been determined, endpoints may then be > "configured" with their own location by the access network > via some Location Configuration Protocol (LCP). > > > -roger marshall. > > CONFIDENTIALITY NOTICE: The information contained in this > message may be privileged and/or confidential. If you are not > the intended recipient, or responsible for delivering this > message to the intended recipient, any review, forwarding, > dissemination, distribution or copying of this communication > or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender > immediately, and delete it and all attachments from your > computer and network. > _______________________________________________ > 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. GA622 > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 1 14:00:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233CE28C103; Mon, 1 Dec 2008 14:00:02 -0800 (PST) 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 5481928C103 for ; Mon, 1 Dec 2008 14:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.485, 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 FbWWKDiCun3q for ; Mon, 1 Dec 2008 14:00:00 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 058E23A680E for ; Mon, 1 Dec 2008 13:59:59 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_12_01_16_17_48 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, 01 Dec 2008 16:17:48 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 15:59:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 15:59:51 -0600 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0BF060B9@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Additional text - location mech - wireless &mobilitysupport Thread-Index: AclMGvVEfWp8KLJwSQWgXrQcHJA+0wAAaLeAAWLualAAiPUaoAACPi0AAAYZJEAABHDxAA== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com><03cd01c94bf9$8d599cd0$a80! c d670$ @ ne t> <8C837 214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com><8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p><8C837214C95C864C9F34F3635C2A65750B5B6DE8@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BF060B9@crexc41p> From: "Thomson, Martin" To: "Stark, Barbara" , "Roger Marshall" , "Rosen, Brian" X-OriginalArrivalTime: 01 Dec 2008 21:59:54.0996 (UTC) FILETIME=[24BE6340:01C95400] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional text - location mech - wireless &mobilitysupport 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm not as easy to please as Barbara... I don't see why there is a continual insistence on distinguishing between "mobile" and "fixed" in relation to how location is generated. The number of cases where this distinction is confusing or misleading only seems to increase over time. Location generation methods and mobility should be considered orthogonal. At least leave that up to the device/LIS. Be clear on what the discussion requires and focus on that perspective. Never try to imply some correlation between the two. Since this is talking about the mechanism involved in location generation, I'd prefer to see this bit removed: ", for mobile capable or fixed environment endpoints". Cheers, Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Stark, Barbara > Sent: Tuesday, 2 December 2008 6:48 AM > To: Roger Marshall; Rosen, Brian > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Additional text - location mech - wireless > &mobilitysupport > > Yep. That's fine. > Barbara > > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Monday, December 01, 2008 11:57 AM > To: Stark, Barbara; Rosen, Brian > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Additional text - location mech - wireless & > mobilitysupport > > Barbara: > > I acknowledge the wording problem (and the bigger deployment problem). > > How about just shortening the sentence a little by removing the > offending word, "respectively"... as follows: > > " Requirements for > endpoint location determination vary, depending on whether an > endpoint's resulting location is based on internal > (device-based) or external (network-based) measurements, or > by manual provisioning, for mobile capable or fixed > environment endpoints. " > > -roger. > > > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Monday, December 01, 2008 7:59 AM > > To: Roger Marshall; Rosen, Brian > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Additional text - location mech - > > wireless & mobilitysupport > > > > I don't understand this proposed sentence: " Requirements for > > endpoint location determination vary, depending on whether an > > endpoint's resulting location is based on internal > > (device-based) or external (network-based) measurements, or > > by manual provisioning - for mobile capable, or fixed > > environment endpoints, respectively. " > > > > That is, I understand the first part, up to the dash "-". I > > don't understand the part after the dash "-", specifically > > the use of the word "respectively". > > > > Is a Femtocell access point (which connects via Ethernet into > > the LAN of a home network that is connected by a broadband > > connection to the > > Internet) mobile capable or fixed? The FAP itself is > > certainly *not* mobile. It will be able to use GPS or AGPS > > (with SUPL) to get its location determined. It will also need > > to be able to use other methods to get its location when it > > finds itself in a basement, unable to make use of GPS. > > > > Is a GSM/Wi-Fi PDA that is in someone's basement (where GPS > > doesn't work, and they can't get a cellular signal), and is > > connected via Wi-Fi into a home network, supposed to use > > internal or external measurements? > > It's definitely mobile capable. > > Barbara > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Roger Marshall > > Sent: Friday, November 28, 2008 5:35 PM > > To: Rosen, Brian > > Cc: ecrit@ietf.org > > Subject: [Ecrit] Additional text - location mech - wireless & > > mobilitysupport > > > > > > > > Brian: > > Below is a proposed change in text to the current phonebcp-06 > > that adds some background for various requirements later in > > the draft that specify "wireless" and "mobile", per remarks > > made in the 11/20 ECRIT wg meeting. > > > > 1. Section 6. Location and its role in emergency calls > > > > change from: > > > > In Internet emergency calling, where the endpoint is located > > is "determined" using a variety of measurement or wiretracing > > methods. Endpoints may be "configured" with their own > > location by the access network. > > > > change to: > > > > In Internet emergency calling, the endpoint location is > > "determined" using a variety of measurement or wiretracing > > methods. Requirements for endpoint location determination > > vary, depending on whether an endpoint's resulting location > > is based on internal (device-based) or external > > (network-based) measurements, or by manual provisioning - for > > mobile capable, or fixed environment endpoints, respectively. > > Once location has been determined, endpoints may then be > > "configured" with their own location by the access network > > via some Location Configuration Protocol (LCP). > > > > > > -roger marshall. > > > > CONFIDENTIALITY NOTICE: The information contained in this > > message may be privileged and/or confidential. If you are not > > the intended recipient, or responsible for delivering this > > message to the intended recipient, any review, forwarding, > > dissemination, distribution or copying of this communication > > or any attachment(s) is strictly prohibited. If you have > > received this message in error, please notify the sender > > immediately, and delete it and all attachments from your > > computer and network. > > _______________________________________________ > > 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. GA622 > > > > > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Mon Dec 1 14:05:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F269F3A6B25; Mon, 1 Dec 2008 14:05:35 -0800 (PST) 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 4E46428C127 for ; Mon, 1 Dec 2008 14:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFA5fDjcOHcV for ; Mon, 1 Dec 2008 14:05:32 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id B021828C11D for ; Mon, 1 Dec 2008 14:05:32 -0800 (PST) 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 ; Mon, 1 Dec 2008 14:05:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 14:03:46 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B6516FE@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Additional text - location mech - wireless &mobilitysupport Thread-Index: AclMGvVEfWp8KLJwSQWgXrQcHJA+0wAAaLeAAWLualAAiPUaoAACPi0AAAYZJEAABHDxAAAAR9GA References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com><03cd01c94bf9$8d599cd0$a80! c d670$ @ ne t> <8C837 214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com><8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p><8C837214C95C864C9F34F3635C2A65750B5B6DE8@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BF060B9@crexc41p> From: "Roger Marshall" To: "Thomson, Martin" , "Stark, Barbara" , "Rosen, Brian" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional text - location mech - wireless &mobilitysupport 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am ok with the further trimming. ..." Requirements for endpoint location determination vary, depending on whether an endpoint's resulting location is based on internal (device-based) or external (network-based) measurements, or by manual provisioning. "... -roger. > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Monday, December 01, 2008 2:00 PM > To: Stark, Barbara; Roger Marshall; Rosen, Brian > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Additional text - location mech - > wireless &mobilitysupport > > I'm not as easy to please as Barbara... > > I don't see why there is a continual insistence on > distinguishing between "mobile" and "fixed" in relation to > how location is generated. The number of cases where this > distinction is confusing or misleading only seems to increase > over time. Location generation methods and mobility should > be considered orthogonal. At least leave that up to the > device/LIS. Be clear on what the discussion requires and > focus on that perspective. Never try to imply some > correlation between the two. > > Since this is talking about the mechanism involved in > location generation, I'd prefer to see this bit removed: ", > for mobile capable or fixed environment endpoints". > > Cheers, > Martin > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Stark, Barbara > > Sent: Tuesday, 2 December 2008 6:48 AM > > To: Roger Marshall; Rosen, Brian > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Additional text - location mech - wireless > > &mobilitysupport > > > > Yep. That's fine. > > Barbara > > > > -----Original Message----- > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > Sent: Monday, December 01, 2008 11:57 AM > > To: Stark, Barbara; Rosen, Brian > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Additional text - location mech - wireless & > > mobilitysupport > > > > Barbara: > > > > I acknowledge the wording problem (and the bigger > deployment problem). > > > > How about just shortening the sentence a little by removing the > > offending word, "respectively"... as follows: > > > > " Requirements for > > endpoint location determination vary, depending on whether an > > endpoint's resulting location is based on internal > > (device-based) or external (network-based) measurements, or > by manual > > provisioning, for mobile capable or fixed environment endpoints. " > > > > -roger. > > > > > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Monday, December 01, 2008 7:59 AM > > > To: Roger Marshall; Rosen, Brian > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Additional text - location mech - wireless & > > > mobilitysupport > > > > > > I don't understand this proposed sentence: " Requirements for > > > endpoint location determination vary, depending on whether an > > > endpoint's resulting location is based on internal > > > (device-based) or external (network-based) measurements, or by > > > manual provisioning - for mobile capable, or fixed environment > > > endpoints, respectively. " > > > > > > That is, I understand the first part, up to the dash "-". I don't > > > understand the part after the dash "-", specifically the > use of the > > > word "respectively". > > > > > > Is a Femtocell access point (which connects via Ethernet into the > > > LAN of a home network that is connected by a broadband > connection to > > > the > > > Internet) mobile capable or fixed? The FAP itself is > certainly *not* > > > mobile. It will be able to use GPS or AGPS (with SUPL) to get its > > > location determined. It will also need to be able to use other > > > methods to get its location when it finds itself in a basement, > > > unable to make use of GPS. > > > > > > Is a GSM/Wi-Fi PDA that is in someone's basement (where > GPS doesn't > > > work, and they can't get a cellular signal), and is connected via > > > Wi-Fi into a home network, supposed to use internal or external > > > measurements? > > > It's definitely mobile capable. > > > Barbara > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > Behalf Of Roger Marshall > > > Sent: Friday, November 28, 2008 5:35 PM > > > To: Rosen, Brian > > > Cc: ecrit@ietf.org > > > Subject: [Ecrit] Additional text - location mech - wireless & > > > mobilitysupport > > > > > > > > > > > > Brian: > > > Below is a proposed change in text to the current > phonebcp-06 that > > > adds some background for various requirements later in the draft > > > that specify "wireless" and "mobile", per remarks made in > the 11/20 > > > ECRIT wg meeting. > > > > > > 1. Section 6. Location and its role in emergency calls > > > > > > change from: > > > > > > In Internet emergency calling, where the endpoint is located is > > > "determined" using a variety of measurement or > wiretracing methods. > > > Endpoints may be "configured" with their own location by > the access > > > network. > > > > > > change to: > > > > > > In Internet emergency calling, the endpoint location is > "determined" > > > using a variety of measurement or wiretracing methods. > Requirements > > > for endpoint location determination vary, depending on whether an > > > endpoint's resulting location is based on internal > (device-based) or > > > external > > > (network-based) measurements, or by manual provisioning - > for mobile > > > capable, or fixed environment endpoints, respectively. > > > Once location has been determined, endpoints may then be > > > "configured" with their own location by the access > network via some > > > Location Configuration Protocol (LCP). > > > > > > > > > -roger marshall. > > > > > > CONFIDENTIALITY NOTICE: The information contained in this message > > > may be privileged and/or confidential. If you are not the > intended > > > recipient, or responsible for delivering this message to the > > > intended recipient, any review, forwarding, dissemination, > > > distribution or copying of this communication or any > attachment(s) > > > is strictly prohibited. If you have received this message > in error, > > > please notify the sender immediately, and delete it and all > > > attachments from your computer and network. > > > _______________________________________________ > > > 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. GA622 > > > > > > > > > > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Mon Dec 1 14:30:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631AA28C0E4; Mon, 1 Dec 2008 14:30:18 -0800 (PST) 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 050233A682E for ; Mon, 1 Dec 2008 14:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.850, 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 X6MZfzgR1F2f for ; Mon, 1 Dec 2008 14:30:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E0FE83A67AD for ; Mon, 1 Dec 2008 14:30:15 -0800 (PST) Received: (qmail invoked by alias); 01 Dec 2008 22:30:10 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp004) with SMTP; 01 Dec 2008 23:30:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX185EEYmeZk5bBk56S4RHc9/05mGMOlyLR+wN8+rrI iHiFoWtPqtzZZ6 From: "Hannes Tschofenig" To: "'ECRIT'" Date: Tue, 2 Dec 2008 00:30:16 +0200 Message-ID: <018f01c95404$62f278f0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclUAh3nfGtaT1FdSzSEKx+T1Kmvrw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 Subject: [Ecrit] IETF#73 Meeting Minutes 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here are the meeting minutes from IETF#73: http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt The slides can be found here: https://datatracker.ietf.org/meeting/73/materials.html Thank you Roger for putting the minutes together. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 1 15:40:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7672428C0E4; Mon, 1 Dec 2008 15:40:15 -0800 (PST) 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 12F8228C0E4 for ; Mon, 1 Dec 2008 15:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 JNP6AC-YujO3 for ; Mon, 1 Dec 2008 15:40:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 639423A6998 for ; Mon, 1 Dec 2008 15:40:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,698,1220227200"; d="scan'208";a="29624543" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 01 Dec 2008 23:40:08 +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 mB1Ne8aI030287; Mon, 1 Dec 2008 18:40:08 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB1Ne8mx006357; Mon, 1 Dec 2008 23:40:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 18:40:07 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.255.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 18:40:07 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Dec 2008 17:40:06 -0600 To: "Thomson, Martin" , "Stark, Barbara" , "Roger Marshall" , "Rosen, Brian" From: "James M. Polk" In-Reply-To: References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> <020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> <5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80! c d670$ @ ne t> <8C837 214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BF05FDC@crexc41p> <8C837214C95C864C9F34F3635C2A65750B5B6DE8@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BF060B9@crexc41p> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 01 Dec 2008 23:40:07.0445 (UTC) FILETIME=[24714C50:01C9540E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7582; t=1228174808; x=1229038808; 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]=20Additional=20text=20-=20locat ion=20mech=20-=20wireless=0A=20=20&mobilitysupport |Sender:=20 |To:=20=22Thomson,=20Martin=22=20,=0A=20=20=20=20=20=20=20=20=22Stark,=20Barbara=22=20,=0A=20=20=20=20=20=20=20=20=22Roger=20Marshall=22 =20,=0A=20=20=20=20=20=20=20=20=22 Rosen,=20Brian=22=20; bh=Hwk3jKg8i0lJgjwOgjaCQghKQf0e5dnE2h+KijevTPU=; b=eydddu98I2JvC9h1erXjfgkeqSVnrkB2OoXp+MorILIqcRIyHLbotONRkm Rzjya2o6cPe2/ohobADW2FYsMWA/t66zdBCnKqRHnLdGSuiIk4taGBPU3i+a CLJPnBJI0Q; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional text - location mech - wireless &mobilitysupport 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:59 PM 12/1/2008, Thomson, Martin wrote: >I'm not as easy to please as Barbara... ;-) >I don't see why there is a continual insistence on distinguishing >between "mobile" and "fixed" in relation to how location is >generated. The number of cases where this distinction is confusing >or misleading only seems to increase over time. Location generation >methods and mobility should be considered orthogonal. At least >leave that up to the device/LIS. Be clear on what the discussion >requires and focus on that perspective. Never try to imply some >correlation between the two. hence the comment earlier that connectivity remain a general issue in the whole scheme of things btw - I generally agree with Martin's little rant here >Since this is talking about the mechanism involved in location >generation, I'd prefer to see this bit removed: ", for mobile >capable or fixed environment endpoints". > >Cheers, >Martin > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Stark, Barbara > > Sent: Tuesday, 2 December 2008 6:48 AM > > To: Roger Marshall; Rosen, Brian > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Additional text - location mech - wireless > > &mobilitysupport > > > > Yep. That's fine. > > Barbara > > > > -----Original Message----- > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > Sent: Monday, December 01, 2008 11:57 AM > > To: Stark, Barbara; Rosen, Brian > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Additional text - location mech - wireless & > > mobilitysupport > > > > Barbara: > > > > I acknowledge the wording problem (and the bigger deployment problem). > > > > How about just shortening the sentence a little by removing the > > offending word, "respectively"... as follows: > > > > " Requirements for > > endpoint location determination vary, depending on whether an > > endpoint's resulting location is based on internal > > (device-based) or external (network-based) measurements, or > > by manual provisioning, for mobile capable or fixed > > environment endpoints. " > > > > -roger. > > > > > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Monday, December 01, 2008 7:59 AM > > > To: Roger Marshall; Rosen, Brian > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Additional text - location mech - > > > wireless & mobilitysupport > > > > > > I don't understand this proposed sentence: " Requirements for > > > endpoint location determination vary, depending on whether an > > > endpoint's resulting location is based on internal > > > (device-based) or external (network-based) measurements, or > > > by manual provisioning - for mobile capable, or fixed > > > environment endpoints, respectively. " > > > > > > That is, I understand the first part, up to the dash "-". I > > > don't understand the part after the dash "-", specifically > > > the use of the word "respectively". > > > > > > Is a Femtocell access point (which connects via Ethernet into > > > the LAN of a home network that is connected by a broadband > > > connection to the > > > Internet) mobile capable or fixed? The FAP itself is > > > certainly *not* mobile. It will be able to use GPS or AGPS > > > (with SUPL) to get its location determined. It will also need > > > to be able to use other methods to get its location when it > > > finds itself in a basement, unable to make use of GPS. > > > > > > Is a GSM/Wi-Fi PDA that is in someone's basement (where GPS > > > doesn't work, and they can't get a cellular signal), and is > > > connected via Wi-Fi into a home network, supposed to use > > > internal or external measurements? > > > It's definitely mobile capable. > > > Barbara > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > On Behalf Of Roger Marshall > > > Sent: Friday, November 28, 2008 5:35 PM > > > To: Rosen, Brian > > > Cc: ecrit@ietf.org > > > Subject: [Ecrit] Additional text - location mech - wireless & > > > mobilitysupport > > > > > > > > > > > > Brian: > > > Below is a proposed change in text to the current phonebcp-06 > > > that adds some background for various requirements later in > > > the draft that specify "wireless" and "mobile", per remarks > > > made in the 11/20 ECRIT wg meeting. > > > > > > 1. Section 6. Location and its role in emergency calls > > > > > > change from: > > > > > > In Internet emergency calling, where the endpoint is located > > > is "determined" using a variety of measurement or wiretracing > > > methods. Endpoints may be "configured" with their own > > > location by the access network. > > > > > > change to: > > > > > > In Internet emergency calling, the endpoint location is > > > "determined" using a variety of measurement or wiretracing > > > methods. Requirements for endpoint location determination > > > vary, depending on whether an endpoint's resulting location > > > is based on internal (device-based) or external > > > (network-based) measurements, or by manual provisioning - for > > > mobile capable, or fixed environment endpoints, respectively. > > > Once location has been determined, endpoints may then be > > > "configured" with their own location by the access network > > > via some Location Configuration Protocol (LCP). > > > > > > > > > -roger marshall. > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may be privileged and/or confidential. If you are not > > > the intended recipient, or responsible for delivering this > > > message to the intended recipient, any review, forwarding, > > > dissemination, distribution or copying of this communication > > > or any attachment(s) is strictly prohibited. If you have > > > received this message in error, please notify the sender > > > immediately, and delete it and all attachments from your > > > computer and network. > > > _______________________________________________ > > > 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. GA622 > > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 2 23:44:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855C23A67F0; Tue, 2 Dec 2008 23:44:59 -0800 (PST) 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 115AF3A67F0 for ; Tue, 2 Dec 2008 23:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.846 X-Spam-Level: X-Spam-Status: No, score=-3.846 tagged_above=-999 required=5 tests=[AWL=-1.247, 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 RuBsK54RHUeC for ; Tue, 2 Dec 2008 23:44:58 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C192B3A67A5 for ; Tue, 2 Dec 2008 23:44:57 -0800 (PST) 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 mB37iqOb007157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Dec 2008 08:44:52 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mB37iqsr023342 for ; Wed, 3 Dec 2008 08:44:52 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 08:44:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 09:44:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5031bis - Service URNs Thread-Index: AclVGwrdQkNb6NKzQVy/rEvvCy1NTg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 03 Dec 2008 07:44:51.0906 (UTC) FILETIME=[068B9A20:01C9551B] Subject: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At the IETF#73 ECRIT meeting we spoke about producing a RFC 5031bis. The problem is that the current document demands a Standards Track document for allocating a new top-level top-level service labels. This turned out to make our own work more difficult. During the meeting I suggested the following: - Work on RFC5031bis to change allocation policy - Submit draft-forte-ecrit-service-classification and draft-sun-ecrit-shelter-service as informational/experimental documents to the RFC Editor after Expert Review from the ECRIT working group. I recall that some folks had some comments about the allocation policy they would like to see. Unfortunately, the meeting minutes do not capture the issue. I did listen to the audio recording (see ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) and noticed that Ted argued for "Specification Required" (instead of "Expert Review"). When you look at RFC 5226 then you will find a description of what the difference between "Specification Required" and "Expert Review" is. Here is the description for "Specification Required": Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review. Examples: Diffserv-aware TE Bandwidth Constraints Model Identifiers [RFC4124], TLS ClientCertificateType Identifiers [RFC4346], ROHC Profile Identifiers [RFC4995]. Are you happy about this approach? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 3 05:42:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A82C3A6A00; Wed, 3 Dec 2008 05:42:25 -0800 (PST) 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 DB3DA3A6A00 for ; Wed, 3 Dec 2008 05:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 wDvMQzj3JyuX for ; Wed, 3 Dec 2008 05:42:23 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B620A3A683B for ; Wed, 3 Dec 2008 05:42:23 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id mB3DgHBk024989; Wed, 3 Dec 2008 07:42:18 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 07:42:16 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 14:42:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 14:42:12 +0100 Message-ID: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RFC 5031bis - Service URNs Thread-Index: AclVGwrdQkNb6NKzQVy/rEvvCy1NTgAMLQZw References: From: "DRAGE, Keith \(Keith\)" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ECRIT" X-OriginalArrivalTime: 03 Dec 2008 13:42:15.0139 (UTC) FILETIME=[F3B54B30:01C9554C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Does this apply only for top level? What I believe we should retain is that any sub-service under the "sos" top-level should be standards track. I believe that we need IETF review of those to ensure that they really should be classed as an emergency situation and not something else. If we relax the rules for new top-level identifiers, I believe we do need to provide more guidance on what is a valid service urn value, and what is not (and therefore should use some other construct in SIP or other protocol). regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Wednesday, December 03, 2008 7:45 AM > To: ECRIT > Subject: [Ecrit] RFC 5031bis - Service URNs > > At the IETF#73 ECRIT meeting we spoke about producing a RFC 5031bis. > > The problem is that the current document demands a Standards > Track document for allocating a new top-level top-level > service labels. > > This turned out to make our own work more difficult. > > During the meeting I suggested the following: > - Work on RFC5031bis to change allocation policy > - Submit draft-forte-ecrit-service-classification and > draft-sun-ecrit-shelter-service as informational/experimental > documents to the RFC Editor after Expert Review from the > ECRIT working group. > > I recall that some folks had some comments about the > allocation policy they would like to see. Unfortunately, the > meeting minutes do not capture the issue. I did listen to the > audio recording (see > ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) and > noticed that Ted argued for "Specification Required" (instead > of "Expert Review"). > > When you look at RFC 5226 then you will find a description of > what the difference between "Specification Required" and > "Expert Review" is. Here is the description for > "Specification Required": > > Specification Required - Values and their meanings must be > documented in a permanent and readily available public > specification, in sufficient detail so that > interoperability > between independent implementations is possible. > When used, > Specification Required also implies use of a Designated > Expert, who will review the public specification and > evaluate whether it is sufficiently clear to allow > interoperable implementations. The intention behind > "permanent and readily available" is that a document can > reasonably be expected to be findable and retrievable long > after IANA assignment of the requested value. Publication > of an RFC is an ideal means of achieving this requirement, > but Specification Required is intended to also cover the > case of a document published outside of the RFC path. For > RFC publication, the normal RFC review process is expected > to provide the necessary review for > interoperability, though > the Designated Expert may be a particularly well-qualified > person to perform such a review. > > Examples: Diffserv-aware TE Bandwidth Constraints Model > Identifiers [RFC4124], TLS ClientCertificateType > Identifiers > [RFC4346], ROHC Profile Identifiers [RFC4995]. > > Are you happy about this approach? > > 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 ecrit-bounces@ietf.org Wed Dec 3 05:48:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40033A6A04; Wed, 3 Dec 2008 05:48:05 -0800 (PST) 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 5B7BD3A6A00 for ; Wed, 3 Dec 2008 05:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa4R7mWPc3JH for ; Wed, 3 Dec 2008 05:48:04 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4EC863A6A04 for ; Wed, 3 Dec 2008 05:48:04 -0800 (PST) Received: from [128.89.255.228] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L7s52-0007fw-Cl; Wed, 03 Dec 2008 08:47:53 -0500 Message-ID: <49368E08.1000802@bbn.com> Date: Wed, 03 Dec 2008 07:47:52 -0600 From: Richard Barnes User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Keith, So to be clear, under your proposal, I would need IETF review to register "urn:service:sos.foo", but perhaps less review to register "urn:service:foo"? If that's right, this plan makes sense to me. IETF gets to manage the "urn:service:sos" heirarchy, but others could go through with less review. Definitely agree that more guidance is necessary on what OK to go under "urn:service:". --Richard DRAGE, Keith (Keith) wrote: > Does this apply only for top level? > > What I believe we should retain is that any sub-service under the "sos" > top-level should be standards track. I believe that we need IETF review > of those to ensure that they really should be classed as an emergency > situation and not something else. > > If we relax the rules for new top-level identifiers, I believe we do > need to provide more guidance on what is a valid service urn value, and > what is not (and therefore should use some other construct in SIP or > other protocol). > > regards > > Keith > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Wednesday, December 03, 2008 7:45 AM >> To: ECRIT >> Subject: [Ecrit] RFC 5031bis - Service URNs >> >> At the IETF#73 ECRIT meeting we spoke about producing a RFC 5031bis. >> >> The problem is that the current document demands a Standards >> Track document for allocating a new top-level top-level >> service labels. >> >> This turned out to make our own work more difficult. >> >> During the meeting I suggested the following: >> - Work on RFC5031bis to change allocation policy >> - Submit draft-forte-ecrit-service-classification and >> draft-sun-ecrit-shelter-service as informational/experimental >> documents to the RFC Editor after Expert Review from the >> ECRIT working group. >> >> I recall that some folks had some comments about the >> allocation policy they would like to see. Unfortunately, the >> meeting minutes do not capture the issue. I did listen to the >> audio recording (see >> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) and >> noticed that Ted argued for "Specification Required" (instead >> of "Expert Review"). >> >> When you look at RFC 5226 then you will find a description of >> what the difference between "Specification Required" and >> "Expert Review" is. Here is the description for >> "Specification Required": >> >> Specification Required - Values and their meanings must be >> documented in a permanent and readily available public >> specification, in sufficient detail so that >> interoperability >> between independent implementations is possible. >> When used, >> Specification Required also implies use of a Designated >> Expert, who will review the public specification and >> evaluate whether it is sufficiently clear to allow >> interoperable implementations. The intention behind >> "permanent and readily available" is that a document can >> reasonably be expected to be findable and retrievable long >> after IANA assignment of the requested value. Publication >> of an RFC is an ideal means of achieving this requirement, >> but Specification Required is intended to also cover the >> case of a document published outside of the RFC path. For >> RFC publication, the normal RFC review process is expected >> to provide the necessary review for >> interoperability, though >> the Designated Expert may be a particularly well-qualified >> person to perform such a review. >> >> Examples: Diffserv-aware TE Bandwidth Constraints Model >> Identifiers [RFC4124], TLS ClientCertificateType >> Identifiers >> [RFC4346], ROHC Profile Identifiers [RFC4995]. >> >> Are you happy about this approach? >> >> 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 ecrit-bounces@ietf.org Wed Dec 3 05:50:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4484D3A6A51; Wed, 3 Dec 2008 05:50:35 -0800 (PST) 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 4F5353A6A51 for ; Wed, 3 Dec 2008 05:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 BToUGvHG+7q3 for ; Wed, 3 Dec 2008 05:50:33 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 332893A6810 for ; Wed, 3 Dec 2008 05:50:33 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mB3Do9f0022457; Wed, 3 Dec 2008 07:50:22 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 07:50:16 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 14:50:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 14:50:13 +0100 Message-ID: <5D1A7985295922448D5550C94DE291800255A5D7@DEEXC1U01.de.lucent.com> In-Reply-To: <49368E08.1000802@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RFC 5031bis - Service URNs Thread-Index: AclVTcM0NnAg5UH9RwuOOzYBex7lrAAACWQA References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> <49368E08.1000802@bbn.com> From: "DRAGE, Keith \(Keith\)" To: "Richard Barnes" X-OriginalArrivalTime: 03 Dec 2008 13:50:14.0067 (UTC) FILETIME=[112BE830:01C9554E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Correct. Keith > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Wednesday, December 03, 2008 1:48 PM > To: DRAGE, Keith (Keith) > Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > Subject: Re: [Ecrit] RFC 5031bis - Service URNs > > Keith, > > So to be clear, under your proposal, I would need IETF review > to register "urn:service:sos.foo", but perhaps less review to > register "urn:service:foo"? > > If that's right, this plan makes sense to me. IETF gets to > manage the "urn:service:sos" heirarchy, but others could go > through with less review. Definitely agree that more > guidance is necessary on what OK to go under "urn:service:". > > --Richard > > > > DRAGE, Keith (Keith) wrote: > > Does this apply only for top level? > > > > What I believe we should retain is that any sub-service > under the "sos" > > top-level should be standards track. I believe that we need IETF > > review of those to ensure that they really should be classed as an > > emergency situation and not something else. > > > > If we relax the rules for new top-level identifiers, I > believe we do > > need to provide more guidance on what is a valid service urn value, > > and what is not (and therefore should use some other > construct in SIP > > or other protocol). > > > > regards > > > > Keith > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > >> Sent: Wednesday, December 03, 2008 7:45 AM > >> To: ECRIT > >> Subject: [Ecrit] RFC 5031bis - Service URNs > >> > >> At the IETF#73 ECRIT meeting we spoke about producing a > RFC 5031bis. > >> > >> The problem is that the current document demands a Standards Track > >> document for allocating a new top-level top-level service labels. > >> > >> This turned out to make our own work more difficult. > >> > >> During the meeting I suggested the following: > >> - Work on RFC5031bis to change allocation policy > >> - Submit draft-forte-ecrit-service-classification and > >> draft-sun-ecrit-shelter-service as informational/experimental > >> documents to the RFC Editor after Expert Review from the ECRIT > >> working group. > >> > >> I recall that some folks had some comments about the allocation > >> policy they would like to see. Unfortunately, the meeting > minutes do > >> not capture the issue. I did listen to the audio recording (see > >> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) and noticed > >> that Ted argued for "Specification Required" (instead of "Expert > >> Review"). > >> > >> When you look at RFC 5226 then you will find a description of what > >> the difference between "Specification Required" and > "Expert Review" > >> is. Here is the description for "Specification Required": > >> > >> Specification Required - Values and their meanings must be > >> documented in a permanent and readily available public > >> specification, in sufficient detail so that > >> interoperability > >> between independent implementations is possible. > >> When used, > >> Specification Required also implies use of a Designated > >> Expert, who will review the public specification and > >> evaluate whether it is sufficiently clear to allow > >> interoperable implementations. The intention behind > >> "permanent and readily available" is that a > document can > >> reasonably be expected to be findable and > retrievable long > >> after IANA assignment of the requested value. > Publication > >> of an RFC is an ideal means of achieving this > requirement, > >> but Specification Required is intended to also > cover the > >> case of a document published outside of the > RFC path. For > >> RFC publication, the normal RFC review process > is expected > >> to provide the necessary review for interoperability, > >> though > >> the Designated Expert may be a particularly > well-qualified > >> person to perform such a review. > >> > >> Examples: Diffserv-aware TE Bandwidth Constraints Model > >> Identifiers [RFC4124], TLS ClientCertificateType > >> Identifiers > >> [RFC4346], ROHC Profile Identifiers [RFC4995]. > >> > >> Are you happy about this approach? > >> > >> 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 ecrit-bounces@ietf.org Wed Dec 3 06:32:58 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5283A6B3A; Wed, 3 Dec 2008 06:32:58 -0800 (PST) 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 8FB783A6B63 for ; Wed, 3 Dec 2008 06:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 pfGuvHSK9av4 for ; Wed, 3 Dec 2008 06:32:56 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0F22B3A6B3A for ; Wed, 3 Dec 2008 06:32:55 -0800 (PST) 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 mB3EWlLU025170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 15:32:47 +0100 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 mB3EWl6d030166; Wed, 3 Dec 2008 15:32:47 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 15:32:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 16:34:57 +0200 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RFC 5031bis - Service URNs Thread-Index: AclVGwrdQkNb6NKzQVy/rEvvCy1NTgAMLQZwAAIFpbA= References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "ECRIT" X-OriginalArrivalTime: 03 Dec 2008 14:32:46.0789 (UTC) FILETIME=[02B65F50:01C95554] Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Good that you raised this issue. My comment was only about the allocation of top-level services. The allocation strategy for sub-services depends on what is defined by the specification standardizing the top-level service. For the sub-services of the 'sos service the allocation strategy is currently expert review: " Additional sub-services can be added after expert review and must be of general public interest and have a similar emergency nature. The expert is designated by the ECRIT working group, its successor, or, in their absence, the IESG. The expert review should only approve emergency services that are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered. The 'sos' service is not meant to invoke general government, public information, counseling, or social services. " I did not plan to change this part. Ciao Hannes >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 03 December, 2008 15:42 >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: RE: [Ecrit] RFC 5031bis - Service URNs > >Does this apply only for top level? > >What I believe we should retain is that any sub-service under the "sos" >top-level should be standards track. I believe that we need >IETF review of those to ensure that they really should be >classed as an emergency situation and not something else. > >If we relax the rules for new top-level identifiers, I believe >we do need to provide more guidance on what is a valid service >urn value, and what is not (and therefore should use some >other construct in SIP or other protocol). > >regards > >Keith > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Wednesday, December 03, 2008 7:45 AM >> To: ECRIT >> Subject: [Ecrit] RFC 5031bis - Service URNs >> >> At the IETF#73 ECRIT meeting we spoke about producing a RFC 5031bis. >> >> The problem is that the current document demands a Standards Track >> document for allocating a new top-level top-level service labels. >> >> This turned out to make our own work more difficult. >> >> During the meeting I suggested the following: >> - Work on RFC5031bis to change allocation policy >> - Submit draft-forte-ecrit-service-classification and >> draft-sun-ecrit-shelter-service as informational/experimental >> documents to the RFC Editor after Expert Review from the >ECRIT working >> group. >> >> I recall that some folks had some comments about the >allocation policy >> they would like to see. Unfortunately, the meeting minutes do not >> capture the issue. I did listen to the audio recording (see >> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) and noticed >> that Ted argued for "Specification Required" (instead of "Expert >> Review"). >> >> When you look at RFC 5226 then you will find a description >of what the >> difference between "Specification Required" and "Expert Review" is. >> Here is the description for "Specification Required": >> >> Specification Required - Values and their meanings must be >> documented in a permanent and readily available public >> specification, in sufficient detail so that >> interoperability >> between independent implementations is possible. >> When used, >> Specification Required also implies use of a Designated >> Expert, who will review the public specification and >> evaluate whether it is sufficiently clear to allow >> interoperable implementations. The intention behind >> "permanent and readily available" is that a document can >> reasonably be expected to be findable and >retrievable long >> after IANA assignment of the requested value. >Publication >> of an RFC is an ideal means of achieving this >requirement, >> but Specification Required is intended to also cover the >> case of a document published outside of the RFC >path. For >> RFC publication, the normal RFC review process >is expected >> to provide the necessary review for interoperability, >> though >> the Designated Expert may be a particularly >well-qualified >> person to perform such a review. >> >> Examples: Diffserv-aware TE Bandwidth Constraints Model >> Identifiers [RFC4124], TLS ClientCertificateType >> Identifiers >> [RFC4346], ROHC Profile Identifiers [RFC4995]. >> >> Are you happy about this approach? >> >> 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 ecrit-bounces@ietf.org Wed Dec 3 06:33:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A363A6B63; Wed, 3 Dec 2008 06:33:36 -0800 (PST) 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 634C83A6B63 for ; Wed, 3 Dec 2008 06:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-1.133, 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 djtTvPjI4Mjc for ; Wed, 3 Dec 2008 06:33:33 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 25AA23A6B3A for ; Wed, 3 Dec 2008 06:33:32 -0800 (PST) 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 mB3EXKqZ026362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 15:33:20 +0100 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 mB3EXKaN031523; Wed, 3 Dec 2008 15:33:20 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 15:33:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 16:35:32 +0200 Message-ID: In-Reply-To: <49368E08.1000802@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RFC 5031bis - Service URNs Thread-Index: AclVTcIgqhKZHC2SRbKxoumJXeZGVAABpv5A References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> <49368E08.1000802@bbn.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Richard Barnes" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 03 Dec 2008 14:33:19.0953 (UTC) FILETIME=[167ACC10:01C95554] Cc: ECRIT Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is not what RFC 5031 says. >-----Original Message----- >From: ext Richard Barnes [mailto:rbarnes@bbn.com] >Sent: 03 December, 2008 15:48 >To: DRAGE, Keith (Keith) >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: Re: [Ecrit] RFC 5031bis - Service URNs > >Keith, > >So to be clear, under your proposal, I would need IETF review >to register "urn:service:sos.foo", but perhaps less review to >register "urn:service:foo"? > >If that's right, this plan makes sense to me. IETF gets to >manage the "urn:service:sos" heirarchy, but others could go >through with less review. Definitely agree that more guidance >is necessary on what OK to go under "urn:service:". > >--Richard > > > >DRAGE, Keith (Keith) wrote: >> Does this apply only for top level? >> >> What I believe we should retain is that any sub-service >under the "sos" >> top-level should be standards track. I believe that we need IETF >> review of those to ensure that they really should be classed as an >> emergency situation and not something else. >> >> If we relax the rules for new top-level identifiers, I believe we do >> need to provide more guidance on what is a valid service urn value, >> and what is not (and therefore should use some other >construct in SIP >> or other protocol). >> >> regards >> >> Keith >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >>> Sent: Wednesday, December 03, 2008 7:45 AM >>> To: ECRIT >>> Subject: [Ecrit] RFC 5031bis - Service URNs >>> >>> At the IETF#73 ECRIT meeting we spoke about producing a RFC >5031bis. >>> >>> The problem is that the current document demands a Standards Track >>> document for allocating a new top-level top-level service labels. >>> >>> This turned out to make our own work more difficult. >>> >>> During the meeting I suggested the following: >>> - Work on RFC5031bis to change allocation policy >>> - Submit draft-forte-ecrit-service-classification and >>> draft-sun-ecrit-shelter-service as informational/experimental >>> documents to the RFC Editor after Expert Review from the ECRIT >>> working group. >>> >>> I recall that some folks had some comments about the allocation >>> policy they would like to see. Unfortunately, the meeting >minutes do >>> not capture the issue. I did listen to the audio recording (see >>> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) and noticed >>> that Ted argued for "Specification Required" (instead of "Expert >>> Review"). >>> >>> When you look at RFC 5226 then you will find a description of what >>> the difference between "Specification Required" and "Expert Review" >>> is. Here is the description for "Specification Required": >>> >>> Specification Required - Values and their meanings must be >>> documented in a permanent and readily available public >>> specification, in sufficient detail so that >>> interoperability >>> between independent implementations is possible. >>> When used, >>> Specification Required also implies use of a Designated >>> Expert, who will review the public specification and >>> evaluate whether it is sufficiently clear to allow >>> interoperable implementations. The intention behind >>> "permanent and readily available" is that a document can >>> reasonably be expected to be findable and >retrievable long >>> after IANA assignment of the requested value. >Publication >>> of an RFC is an ideal means of achieving this >requirement, >>> but Specification Required is intended to also cover the >>> case of a document published outside of the RFC >path. For >>> RFC publication, the normal RFC review process >is expected >>> to provide the necessary review for interoperability, >>> though >>> the Designated Expert may be a particularly >well-qualified >>> person to perform such a review. >>> >>> Examples: Diffserv-aware TE Bandwidth Constraints Model >>> Identifiers [RFC4124], TLS ClientCertificateType >>> Identifiers >>> [RFC4346], ROHC Profile Identifiers [RFC4995]. >>> >>> Are you happy about this approach? >>> >>> 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 ecrit-bounces@ietf.org Wed Dec 3 06:36:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890D13A6965; Wed, 3 Dec 2008 06:36:16 -0800 (PST) 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 5FD733A68D1 for ; Wed, 3 Dec 2008 06:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.673 X-Spam-Level: X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.926, 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 SDotDUZ-tmyQ for ; Wed, 3 Dec 2008 06:36:14 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B4ABA3A68F4 for ; Wed, 3 Dec 2008 06:36:13 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mB3EZvBx005305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 15:35:58 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mB3EZvdX005180; Wed, 3 Dec 2008 15:35:57 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 15:35:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 16:38:19 +0200 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE291800255A5D7@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RFC 5031bis - Service URNs Thread-Index: AclVTcM0NnAg5UH9RwuOOzYBex7lrAAACWQAAAGgRNA= References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com><49368E08.1000802@bbn.com> <5D1A7985295922448D5550C94DE291800255A5D7@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Richard Barnes" X-OriginalArrivalTime: 03 Dec 2008 14:35:57.0575 (UTC) FILETIME=[746E0170:01C95554] Cc: ECRIT Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Why do you see a problem with the current allocation policy of expert review the IETF ECRIT WG (its successor, or, in their absence, the IESG)? >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext DRAGE, Keith (Keith) >Sent: 03 December, 2008 15:50 >To: Richard Barnes >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: Re: [Ecrit] RFC 5031bis - Service URNs > >Correct. > >Keith > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, December 03, 2008 1:48 PM >> To: DRAGE, Keith (Keith) >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> Subject: Re: [Ecrit] RFC 5031bis - Service URNs >> >> Keith, >> >> So to be clear, under your proposal, I would need IETF review to >> register "urn:service:sos.foo", but perhaps less review to register >> "urn:service:foo"? >> >> If that's right, this plan makes sense to me. IETF gets to >manage the >> "urn:service:sos" heirarchy, but others could go through with less >> review. Definitely agree that more guidance is necessary on what OK >> to go under "urn:service:". >> >> --Richard >> >> >> >> DRAGE, Keith (Keith) wrote: >> > Does this apply only for top level? >> > >> > What I believe we should retain is that any sub-service >> under the "sos" >> > top-level should be standards track. I believe that we need IETF >> > review of those to ensure that they really should be classed as an >> > emergency situation and not something else. >> > >> > If we relax the rules for new top-level identifiers, I >> believe we do >> > need to provide more guidance on what is a valid service >urn value, >> > and what is not (and therefore should use some other >> construct in SIP >> > or other protocol). >> > >> > regards >> > >> > Keith >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> >> Sent: Wednesday, December 03, 2008 7:45 AM >> >> To: ECRIT >> >> Subject: [Ecrit] RFC 5031bis - Service URNs >> >> >> >> At the IETF#73 ECRIT meeting we spoke about producing a >> RFC 5031bis. >> >> >> >> The problem is that the current document demands a >Standards Track >> >> document for allocating a new top-level top-level service labels. >> >> >> >> This turned out to make our own work more difficult. >> >> >> >> During the meeting I suggested the following: >> >> - Work on RFC5031bis to change allocation policy >> >> - Submit draft-forte-ecrit-service-classification and >> >> draft-sun-ecrit-shelter-service as informational/experimental >> >> documents to the RFC Editor after Expert Review from the ECRIT >> >> working group. >> >> >> >> I recall that some folks had some comments about the allocation >> >> policy they would like to see. Unfortunately, the meeting >> minutes do >> >> not capture the issue. I did listen to the audio recording (see >> >> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) >and noticed >> >> that Ted argued for "Specification Required" (instead of "Expert >> >> Review"). >> >> >> >> When you look at RFC 5226 then you will find a >description of what >> >> the difference between "Specification Required" and >> "Expert Review" >> >> is. Here is the description for "Specification Required": >> >> >> >> Specification Required - Values and their meanings must be >> >> documented in a permanent and readily available public >> >> specification, in sufficient detail so that >> >> interoperability >> >> between independent implementations is possible. >> >> When used, >> >> Specification Required also implies use of a >Designated >> >> Expert, who will review the public specification and >> >> evaluate whether it is sufficiently clear to allow >> >> interoperable implementations. The intention behind >> >> "permanent and readily available" is that a >> document can >> >> reasonably be expected to be findable and >> retrievable long >> >> after IANA assignment of the requested value. >> Publication >> >> of an RFC is an ideal means of achieving this >> requirement, >> >> but Specification Required is intended to also >> cover the >> >> case of a document published outside of the >> RFC path. For >> >> RFC publication, the normal RFC review process >> is expected >> >> to provide the necessary review for interoperability, >> >> though >> >> the Designated Expert may be a particularly >> well-qualified >> >> person to perform such a review. >> >> >> >> Examples: Diffserv-aware TE Bandwidth >Constraints Model >> >> Identifiers [RFC4124], TLS ClientCertificateType >> >> Identifiers >> >> [RFC4346], ROHC Profile Identifiers [RFC4995]. >> >> >> >> Are you happy about this approach? >> >> >> >> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 3 06:43:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B3C3A69E6; Wed, 3 Dec 2008 06:43:57 -0800 (PST) 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 4A4993A69E6 for ; Wed, 3 Dec 2008 06:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 7HdPc02kN161 for ; Wed, 3 Dec 2008 06:43:54 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 3601F3A6987 for ; Wed, 3 Dec 2008 06:43:53 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mB3EhdoC004969; Wed, 3 Dec 2008 08:43:47 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 08:43:38 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 15:43:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 15:43:32 +0100 Message-ID: <5D1A7985295922448D5550C94DE291800255A61F@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RFC 5031bis - Service URNs Thread-Index: AclVTcIgqhKZHC2SRbKxoumJXeZGVAABpv5AAAArqQA= References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> <49368E08.1000802@bbn.com> From: "DRAGE, Keith \(Keith\)" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ext Richard Barnes" X-OriginalArrivalTime: 03 Dec 2008 14:43:33.0640 (UTC) FILETIME=[84440080:01C95555] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: ECRIT Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Well I must admit I looked quickly and read something different and wrongly. If I was starting from scratch, I think I would write "standards track" for the subservices of sos, but I cannot point to any problems with the existing strategy, so on that basis there is no need to change it. The main point I was making anyway is that we must not have a lower level for "sos" and that we do need clear guidance to stop people registering urns where there are more appropriate places to put information other than a URI. Keith > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Wednesday, December 03, 2008 2:36 PM > To: ext Richard Barnes; DRAGE, Keith (Keith) > Cc: ECRIT > Subject: RE: [Ecrit] RFC 5031bis - Service URNs > > This is not what RFC 5031 says. > > >-----Original Message----- > >From: ext Richard Barnes [mailto:rbarnes@bbn.com] > >Sent: 03 December, 2008 15:48 > >To: DRAGE, Keith (Keith) > >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >Subject: Re: [Ecrit] RFC 5031bis - Service URNs > > > >Keith, > > > >So to be clear, under your proposal, I would need IETF review to > >register "urn:service:sos.foo", but perhaps less review to register > >"urn:service:foo"? > > > >If that's right, this plan makes sense to me. IETF gets to > manage the > >"urn:service:sos" heirarchy, but others could go through with less > >review. Definitely agree that more guidance is necessary on > what OK to > >go under "urn:service:". > > > >--Richard > > > > > > > >DRAGE, Keith (Keith) wrote: > >> Does this apply only for top level? > >> > >> What I believe we should retain is that any sub-service > >under the "sos" > >> top-level should be standards track. I believe that we need IETF > >> review of those to ensure that they really should be classed as an > >> emergency situation and not something else. > >> > >> If we relax the rules for new top-level identifiers, I > believe we do > >> need to provide more guidance on what is a valid service > urn value, > >> and what is not (and therefore should use some other > >construct in SIP > >> or other protocol). > >> > >> regards > >> > >> Keith > >> > >> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > >>> Sent: Wednesday, December 03, 2008 7:45 AM > >>> To: ECRIT > >>> Subject: [Ecrit] RFC 5031bis - Service URNs > >>> > >>> At the IETF#73 ECRIT meeting we spoke about producing a RFC > >5031bis. > >>> > >>> The problem is that the current document demands a > Standards Track > >>> document for allocating a new top-level top-level service labels. > >>> > >>> This turned out to make our own work more difficult. > >>> > >>> During the meeting I suggested the following: > >>> - Work on RFC5031bis to change allocation policy > >>> - Submit draft-forte-ecrit-service-classification and > >>> draft-sun-ecrit-shelter-service as informational/experimental > >>> documents to the RFC Editor after Expert Review from the ECRIT > >>> working group. > >>> > >>> I recall that some folks had some comments about the allocation > >>> policy they would like to see. Unfortunately, the meeting > >minutes do > >>> not capture the issue. I did listen to the audio recording (see > >>> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) > and noticed > >>> that Ted argued for "Specification Required" (instead of "Expert > >>> Review"). > >>> > >>> When you look at RFC 5226 then you will find a > description of what > >>> the difference between "Specification Required" and > "Expert Review" > >>> is. Here is the description for "Specification Required": > >>> > >>> Specification Required - Values and their meanings must be > >>> documented in a permanent and readily available public > >>> specification, in sufficient detail so that > >>> interoperability > >>> between independent implementations is possible. > >>> When used, > >>> Specification Required also implies use of a > Designated > >>> Expert, who will review the public specification and > >>> evaluate whether it is sufficiently clear to allow > >>> interoperable implementations. The intention behind > >>> "permanent and readily available" is that a > document can > >>> reasonably be expected to be findable and > >retrievable long > >>> after IANA assignment of the requested value. > >Publication > >>> of an RFC is an ideal means of achieving this > >requirement, > >>> but Specification Required is intended to > also cover the > >>> case of a document published outside of the RFC > >path. For > >>> RFC publication, the normal RFC review process > >is expected > >>> to provide the necessary review for interoperability, > >>> though > >>> the Designated Expert may be a particularly > >well-qualified > >>> person to perform such a review. > >>> > >>> Examples: Diffserv-aware TE Bandwidth > Constraints Model > >>> Identifiers [RFC4124], TLS ClientCertificateType > >>> Identifiers > >>> [RFC4346], ROHC Profile Identifiers [RFC4995]. > >>> > >>> Are you happy about this approach? > >>> > >>> 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 ecrit-bounces@ietf.org Wed Dec 3 09:56:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3003A69C5; Wed, 3 Dec 2008 09:56:49 -0800 (PST) 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 342643A683F for ; Wed, 3 Dec 2008 09:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=-0.265, 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 02TeFDocXNaS for ; Wed, 3 Dec 2008 09:56:47 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BF0DB28C13E for ; Wed, 3 Dec 2008 09:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1228326986; x=1259862986; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<5D1A7985295922448D5550C 94DE291800255A61F@DEEXC1U01.de.lucent.com>|References:=20 =0D=0A=20<5D1A7985295922448D5550C94DE291800255A5C F@DEEXC1U01.de.lucent.com>=0D=0A=20<49368E08.1000802@bbn. com>=0D=0A=20=20=0D=0A=20<5D1A7985295922448D5550C 94DE291800255A61F@DEEXC1U01.de.lucent.com>|Date:=20Wed, =203=20Dec=202008=2009:56:27=20-0800|To:=20"DRAGE,=20Keit h=20(Keith)"=20,=0D=0A=20=20=20 =20=20=20=20=20"Tschofenig,=20Hannes=0D=0A=20(NSN=20-=20F I/Espoo)"=20,=0D=0A=20=20=20 =20=20=20=20=20ext=20Richard=20Barnes=0D=0A=09|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20RFC=205031bis=20-=20Service =20URNs|CC:=20ECRIT=20|Content-Type:=20te xt/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5100,188,5452"=3B=20a=3D"13628104"; bh=zqBsBEOIn3a7/SUKEyMIB7FaYpAj/D9LtOMRgmwmEUM=; b=Z5rUz/PQlxEetxHzcxVlnRXYiKHqWdfMCPs4FR3sW8kat5C5t+KxjhyM VcjE58LSy0OtaWtjSMKgy57vm3xAfatN5Ly5NIba81hb/tlLc3YnRioIk fIJqaB+a/rxvRckCwMjz+nWXPQzyFf+uAxfmjQ7pPDVe20D9LLnPDYvZb 4=; X-IronPort-AV: E=McAfee;i="5100,188,5452"; a="13628104" 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; 03 Dec 2008 09:56:25 -0800 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 mB3HuPje027730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 09:56:25 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mB3HuKdK004432 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Dec 2008 09:56:20 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 3 Dec 2008 09:56:20 -0800 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.311.2; Wed, 3 Dec 2008 09:56:19 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE291800255A61F@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> <49368E08.1000802@bbn.com> <5D1A7985295922448D5550C94DE291800255A61F@DEEXC1U01.de.lucent.com> Date: Wed, 3 Dec 2008 09:56:27 -0800 To: "DRAGE, Keith (Keith)" , "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Richard Barnes From: Ted Hardie Cc: ECRIT Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 6:43 AM -0800 12/3/08, DRAGE, Keith (Keith) wrote: >Well I must admit I looked quickly and read something different and >wrongly. > >If I was starting from scratch, I think I would write "standards track" >for the subservices of sos, but I cannot point to any problems with the >existing strategy, so on that basis there is no need to change it. > >The main point I was making anyway is that we must not have a lower >level for "sos" and that we do need clear guidance to stop people >registering urns where there are more appropriate places to put >information other than a URI. > >Keith I'm not sure what "lower level for 'sos'" means, exactly, but I believe using "specification required" for top-level and expert review for those under sos is reasonable. The Designated Expert for "specification required" may or may not be the same as for "sos". Ted > > -----Original Message----- >> From: Tschofenig, Hannes (NSN - FI/Espoo) >> [mailto:hannes.tschofenig@nsn.com] >> Sent: Wednesday, December 03, 2008 2:36 PM >> To: ext Richard Barnes; DRAGE, Keith (Keith) >> Cc: ECRIT >> Subject: RE: [Ecrit] RFC 5031bis - Service URNs >> >> This is not what RFC 5031 says. >> >> >-----Original Message----- >> >From: ext Richard Barnes [mailto:rbarnes@bbn.com] >> >Sent: 03 December, 2008 15:48 >> >To: DRAGE, Keith (Keith) >> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> >Subject: Re: [Ecrit] RFC 5031bis - Service URNs >> > >> >Keith, >> > >> >So to be clear, under your proposal, I would need IETF review to >> >register "urn:service:sos.foo", but perhaps less review to register >> >"urn:service:foo"? >> > >> >If that's right, this plan makes sense to me. IETF gets to >> manage the >> >"urn:service:sos" heirarchy, but others could go through with less >> >review. Definitely agree that more guidance is necessary on >> what OK to >> >go under "urn:service:". >> > >> >--Richard >> > >> > >> > >> >DRAGE, Keith (Keith) wrote: >> >> Does this apply only for top level? >> >> >> >> What I believe we should retain is that any sub-service >> >under the "sos" >> >> top-level should be standards track. I believe that we need IETF >> >> review of those to ensure that they really should be classed as an >> >> emergency situation and not something else. >> >> >> >> If we relax the rules for new top-level identifiers, I >> believe we do >> >> need to provide more guidance on what is a valid service >> urn value, >> >> and what is not (and therefore should use some other >> >construct in SIP >> >> or other protocol). >> >> >> >> regards >> >> >> >> Keith >> >> >> >> >> >>> -----Original Message----- >> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >>> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> >>> Sent: Wednesday, December 03, 2008 7:45 AM >> >>> To: ECRIT >> >>> Subject: [Ecrit] RFC 5031bis - Service URNs >> >>> >> >>> At the IETF#73 ECRIT meeting we spoke about producing a RFC >> >5031bis. >> >>> >> >>> The problem is that the current document demands a >> Standards Track >> >>> document for allocating a new top-level top-level service labels. >> >>> >> >>> This turned out to make our own work more difficult. >> >>> >> >>> During the meeting I suggested the following: >> >>> - Work on RFC5031bis to change allocation policy >> >>> - Submit draft-forte-ecrit-service-classification and >> >>> draft-sun-ecrit-shelter-service as informational/experimental >> >>> documents to the RFC Editor after Expert Review from the ECRIT >> >>> working group. >> >>> >> >>> I recall that some folks had some comments about the allocation >> >>> policy they would like to see. Unfortunately, the meeting >> >minutes do >> >>> not capture the issue. I did listen to the audio recording (see >> >>> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) >> and noticed >> >>> that Ted argued for "Specification Required" (instead of "Expert >> >>> Review"). > > >>> >> >>> When you look at RFC 5226 then you will find a >> description of what >> >>> the difference between "Specification Required" and >> "Expert Review" >> >>> is. Here is the description for "Specification Required": >> >>> >> >>> Specification Required - Values and their meanings must be >> >>> documented in a permanent and readily available public >> >>> specification, in sufficient detail so that >> >>> interoperability >> >>> between independent implementations is possible. >> >>> When used, >> >>> Specification Required also implies use of a >> Designated >> >>> Expert, who will review the public specification and >> >>> evaluate whether it is sufficiently clear to allow >> >>> interoperable implementations. The intention behind >> >>> "permanent and readily available" is that a >> document can >> >>> reasonably be expected to be findable and >> >retrievable long >> >>> after IANA assignment of the requested value. >> >Publication >> >>> of an RFC is an ideal means of achieving this >> >requirement, >> >>> but Specification Required is intended to >> also cover the >> >>> case of a document published outside of the RFC >> >path. For >> >>> RFC publication, the normal RFC review process >> >is expected >> >>> to provide the necessary review for interoperability, >> >>> though >> >>> the Designated Expert may be a particularly >> >well-qualified >> >>> person to perform such a review. >> >>> >> >>> Examples: Diffserv-aware TE Bandwidth >> Constraints Model >> >>> Identifiers [RFC4124], TLS ClientCertificateType >> >>> Identifiers >> >>> [RFC4346], ROHC Profile Identifiers [RFC4995]. >> >>> >> >>> Are you happy about this approach? >> >>> >> >>> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 3 16:43:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE093A6BE4; Wed, 3 Dec 2008 16:43:19 -0800 (PST) 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 A92503A6BE4 for ; Wed, 3 Dec 2008 16:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 KlAdjPWFU56P for ; Wed, 3 Dec 2008 16:43:17 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 3B0F33A68CE for ; Wed, 3 Dec 2008 16:43:17 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id mB40g3Th006035; Wed, 3 Dec 2008 18:43:09 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 18:42:29 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Dec 2008 01:42:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Dec 2008 01:42:32 +0100 Message-ID: <5D1A7985295922448D5550C94DE291800255A6EA@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RFC 5031bis - Service URNs Thread-Index: AclVcHjjsXZg5L78R8ase4LVHdt66QAOIE1w References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> <49368E08.1000802@bbn.com> <5D1A7985295922448D5550C94DE291800255A61F@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "Ted Hardie" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ext Richard Barnes" X-OriginalArrivalTime: 04 Dec 2008 00:42:27.0579 (UTC) FILETIME=[2E8FF4B0:01C955A9] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: ECRIT Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I would like to keep sub-services at the same strength of review as the top level. For the existing top-levels that requires no change to keep it at specification required. Keith > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, December 03, 2008 5:56 PM > To: DRAGE, Keith (Keith); Tschofenig, Hannes (NSN - > FI/Espoo); ext Richard Barnes > Cc: ECRIT > Subject: Re: [Ecrit] RFC 5031bis - Service URNs > > At 6:43 AM -0800 12/3/08, DRAGE, Keith (Keith) wrote: > >Well I must admit I looked quickly and read something different and > >wrongly. > > > >If I was starting from scratch, I think I would write > "standards track" > >for the subservices of sos, but I cannot point to any > problems with the > >existing strategy, so on that basis there is no need to change it. > > > >The main point I was making anyway is that we must not have a lower > >level for "sos" and that we do need clear guidance to stop people > >registering urns where there are more appropriate places to put > >information other than a URI. > > > >Keith > > I'm not sure what "lower level for 'sos'" means, exactly, but > I believe using "specification required" for top-level and > expert review for those > under sos is reasonable. The Designated Expert for > "specification required" > may or may not be the same as for "sos". > > Ted > > > > > > > > > > -----Original Message----- > >> From: Tschofenig, Hannes (NSN - FI/Espoo) > >> [mailto:hannes.tschofenig@nsn.com] > >> Sent: Wednesday, December 03, 2008 2:36 PM > >> To: ext Richard Barnes; DRAGE, Keith (Keith) > >> Cc: ECRIT > >> Subject: RE: [Ecrit] RFC 5031bis - Service URNs > >> > >> This is not what RFC 5031 says. > >> > >> >-----Original Message----- > >> >From: ext Richard Barnes [mailto:rbarnes@bbn.com] > >> >Sent: 03 December, 2008 15:48 > >> >To: DRAGE, Keith (Keith) > >> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >> >Subject: Re: [Ecrit] RFC 5031bis - Service URNs > >> > > >> >Keith, > >> > > >> >So to be clear, under your proposal, I would need IETF review to > >> >register "urn:service:sos.foo", but perhaps less review > to register > >> >"urn:service:foo"? > >> > > >> >If that's right, this plan makes sense to me. IETF gets to > >> manage the > >> >"urn:service:sos" heirarchy, but others could go through > with less > >> >review. Definitely agree that more guidance is necessary on > >> what OK to > >> >go under "urn:service:". > >> > > >> >--Richard > >> > > >> > > >> > > >> >DRAGE, Keith (Keith) wrote: > >> >> Does this apply only for top level? > >> >> > >> >> What I believe we should retain is that any sub-service > >> >under the "sos" > >> >> top-level should be standards track. I believe that we > need IETF > >> >> review of those to ensure that they really should be > classed as an > >> >> emergency situation and not something else. > >> >> > >> >> If we relax the rules for new top-level identifiers, I > >> believe we do > >> >> need to provide more guidance on what is a valid service > >> urn value, > >> >> and what is not (and therefore should use some other > >> >construct in SIP > >> >> or other protocol). > >> >> > >> >> regards > >> >> > >> >> Keith > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > >> >>> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > >> >>> Sent: Wednesday, December 03, 2008 7:45 AM > >> >>> To: ECRIT > >> >>> Subject: [Ecrit] RFC 5031bis - Service URNs > >> >>> > >> >>> At the IETF#73 ECRIT meeting we spoke about producing a RFC > >> >5031bis. > >> >>> > >> >>> The problem is that the current document demands a > >> Standards Track > >> >>> document for allocating a new top-level top-level > service labels. > >> >>> > >> >>> This turned out to make our own work more difficult. > >> >>> > >> >>> During the meeting I suggested the following: > >> >>> - Work on RFC5031bis to change allocation policy > >> >>> - Submit draft-forte-ecrit-service-classification and > >> >>> draft-sun-ecrit-shelter-service as informational/experimental > >> >>> documents to the RFC Editor after Expert Review from the ECRIT > >> >>> working group. > >> >>> > >> >>> I recall that some folks had some comments about the > allocation > >> >>> policy they would like to see. Unfortunately, the meeting > >> >minutes do > >> >>> not capture the issue. I did listen to the audio recording (see > >> >>> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) > >> and noticed > >> >>> that Ted argued for "Specification Required" (instead > of "Expert > >> >>> Review"). > > > >>> > >> >>> When you look at RFC 5226 then you will find a > >> description of what > >> >>> the difference between "Specification Required" and > >> "Expert Review" > >> >>> is. Here is the description for "Specification Required": > >> >>> > >> >>> Specification Required - Values and their > meanings must be > >> >>> documented in a permanent and readily > available public > >> >>> specification, in sufficient detail so that > >> >>> interoperability > >> >>> between independent implementations is possible. > >> >>> When used, > >> >>> Specification Required also implies use of a > >> Designated > >> >>> Expert, who will review the public > specification and > >> >>> evaluate whether it is sufficiently clear to allow > >> >>> interoperable implementations. The > intention behind > >> >>> "permanent and readily available" is that a > >> document can > >> >>> reasonably be expected to be findable and > >> >retrievable long > >> >>> after IANA assignment of the requested value. > >> >Publication > >> >>> of an RFC is an ideal means of achieving this > >> >requirement, > >> >>> but Specification Required is intended to > >> also cover the > >> >>> case of a document published outside of the RFC > >> >path. For > >> >>> RFC publication, the normal RFC review process > >> >is expected > >> >>> to provide the necessary review for > interoperability, > >> >>> though > >> >>> the Designated Expert may be a particularly > >> >well-qualified > >> >>> person to perform such a review. > >> >>> > >> >>> Examples: Diffserv-aware TE Bandwidth > >> Constraints Model > >> >>> Identifiers [RFC4124], TLS ClientCertificateType > >> >>> Identifiers > >> >>> [RFC4346], ROHC Profile Identifiers [RFC4995]. > >> >>> > >> >>> Are you happy about this approach? > >> >>> > >> >>> 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 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 22 06:52:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426923A6971; Mon, 22 Dec 2008 06:52:29 -0800 (PST) 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 553683A6971 for ; Mon, 22 Dec 2008 06:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14dswqNbLdem for ; Mon, 22 Dec 2008 06:52:27 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 3E32D3A68AD for ; Mon, 22 Dec 2008 06:52:27 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mBMEqFn28251 for ; Mon, 22 Dec 2008 14:52:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Dec 2008 14:50:11 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E9007EB6BD8@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-patel-ecrit-sos-parameter thread-index: AclkRJd78uffke4/Tz+undxlleBwCQ== From: "Milan Patel" To: Subject: [Ecrit] 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: , Content-Type: multipart/mixed; boundary="===============2115301624==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2115301624== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C96444.980FD877" This is a multi-part message in MIME format. ------_=_NextPart_001_01C96444.980FD877 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Folks, A new version (-02) is available. Please let me know if this version of = the draft reflects the outcome of discussions in IETF73.=20 http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-02.txt Major changes: The requirements other than the registration requirement have been = removed and the introduction has has been revised.=20 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 =20 Confidentiality Notice: This message and any attachments may contain = information that is privileged and confidential. If you have reason to believe that you are not the = intended recipient or a person responsible for delivering this message to an intended recipient, you = are hereby notified that any review, dissemination, distribution, or copying of this message is = strictly prohibited. If you have reason to believe that you are not the intended recipient or a person = responsible for delivering this message to an intended recipient, please contact the sender immediately = by reply email and destroy all copies of the original message. ------_=_NextPart_001_01C96444.980FD877 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-patel-ecrit-sos-parameter

Hi = Folks,

A new version = (-02) is available. Please let me know if this version of the draft = reflects the outcome of discussions in IETF73.

= http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-0= 2.txt

Major = changes:
The requirements = other than the registration requirement have been removed and the = introduction has has been revised.

Regards,
Milan

Milan = Patel
Carrier Networks = Core Standards
Nortel
milanpa@nortel.com
Telephone=A0+44 162 = 843 2381 / ESN 560 2381
Mobile +44 774 = 053 9261 / ESN 748 9261
=A0
Confidentiality = Notice: This message and any attachments may contain information that is = privileged
and confidential. = If you have reason to believe that you are not the intended recipient or = a person
responsible for = delivering this message to an intended recipient, you are hereby = notified that any
review, = dissemination, distribution, or copying of this message is strictly = prohibited. If you have
reason to believe = that you are not the intended recipient or a person responsible for = delivering this
message to an = intended recipient, please contact the sender immediately by reply email = and destroy
all copies of the = original message.


------_=_NextPart_001_01C96444.980FD877-- --===============2115301624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============2115301624==-- From ecrit-bounces@ietf.org Sat Dec 27 04:06:39 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E3A3A682C; Sat, 27 Dec 2008 04:06:39 -0800 (PST) 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 C741A3A682C for ; Sat, 27 Dec 2008 04:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 c78gs25WX-Kx for ; Sat, 27 Dec 2008 04:06:38 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 402CF3A66B4 for ; Sat, 27 Dec 2008 04:06:33 -0800 (PST) Received: (qmail invoked by alias); 27 Dec 2008 11:59:42 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp029) with SMTP; 27 Dec 2008 12:59:42 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/5gxQc5WL5x5eiM5ULuorhXu52PGBguZp+9R+hPC qW24VPA0441Lao From: "Hannes Tschofenig" To: "ECRIT" Date: Sat, 27 Dec 2008 14:00:03 +0200 Message-ID: <009a01c9681a$a82cb370$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acle8iic/muVwsRMQP+7e3Oblad20wBYIQ7zAfGrQoA= X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: GEOPRIV , RjS@estacado.net Subject: [Ecrit] FW: ESIF Issue 58 Technical Report Correspondence 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI = We received a liaison request from ATIS ESIF with a report with the title "PARAMETER CONVEYANCE FOR LOCATION DETERMINATION OF DEVICES ATTACHED TO ACCESS NETWORKS" that talks about FLAP. = Since ECRIT isn't really the place for a discussion about that topic we will reply to the email saying something like: = "Thank you for sharing your report with us but the IETF ECRIT working group is not chartered to discuss protocols like FLAP. However, the IETF GEOPRIV working group is the right place and we have forwarded your document to the GEOPRIV mailing list and to the GEOPRIV WG chairs." = Due to the size of the documents I have uploaded them to: = http://www.tschofenig.priv.at/TEMP/esif/ Ciao Hannes ------ Forwarded Message From: April Nowicki Date: Mon, 15 Dec 2008 15:17:31 -0500 To: April Nowicki Cc: Jim Shepard , , "Goerke, Jim" , "Akundi, Anand V" , "Militeau, Christian" , Steve Barclay Subject: ESIF Issue 58 Technical Report Correspondence = Good afternoon, = Please find correspondence from Jim Shepard, ESIF Chair, attached to this email for your review and comment, as well as the current baseline text of the draft technical report. = = It would be greatly appreciated if a response could be made by March 1, 2009. = Please refer questions to April Nowicki at anowicki@atis.org. Thank you! = April Nowicki ESIF Committee Administrator ATIS 1200 G Street NW, Suite 500 Washington, DC 20005 P: 202.434.8856 F: 202.393.5453 =FC Please consider the environment before printing this e-mail = = = ------ End of Forwarded Message = _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 30 05:50:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEE13A6A41; Tue, 30 Dec 2008 05:50:07 -0800 (PST) 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 72F1B3A6A50 for ; Tue, 30 Dec 2008 05:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.431, 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 k4QnjYWWRvZq for ; Tue, 30 Dec 2008 05:50:05 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C3E473A6A32 for ; Tue, 30 Dec 2008 05:50:04 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2008 13:49:53 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp069) with SMTP; 30 Dec 2008 14:49:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ju7dwlHfjQ5vPWRKOZ/NeE6p6zXvmNhgQiNB7fv a4HBoct20Gsjp/ From: "Hannes Tschofenig" To: "'ext Henning Schulzrinne'" , "Milan Patel" References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net><2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu><5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com><0913B6CD18F370498CD65864CF254E900763513B@zharhxm1.corp.nortel.com><0671D971-1FA1-4024-951E-4DC75555C8FD@cs.columbia.edu><0913B6CD18F370498CD65864CF254E90076A4850@zharhxm1.corp.nortel.com> <039FDECD-29A7-4A57-A759-CC3A61E19EB7@cs.columbia.edu> Date: Tue, 30 Dec 2008 15:50:16 +0200 Message-ID: <004f01c96a85$8c57d1d0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <039FDECD-29A7-4A57-A759-CC3A61E19EB7@cs.columbia.edu> thread-index: AclJtiDdcZij0C+JSkmyBmaHFC0wMAgytcWg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: ECRIT Subject: Re: [Ecrit] What's up with 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Henning, I understand your concern. It is true that we do not have anything in the IETF emergency services architecture where the mechanism of http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02.txt, i.e. sos SIP REGISTER, plays a role. Maybe we have not yet thought about that problem hard enough. May it is a pure 3GPP IMS problem. There is obviously the question about why the 3GPP IMS emergency services architecture is different than the one developed in the IETF (despite all the talks we had in various meetings and workshops). The reason for this can most likely be found in the desire of those players working in the 3GPP (and related organizations) to have P-CSCF (a SIP proxy) in the visited network so that it more closely reessembles a PSTN model. Is that a good communication model? Does not really matter that much. What matters is that almost all of the companies we see participating in the discussion here on the mailing list regarding all our documents and that are also strong advocates of the IETF emergency services model react very different in the 3GPP and just recently decided to vote against a further alignment between these two emergency services architectures. The companies that supported this misalignment include Ericsson, Alcatel-Lucent, Cisco, Qualcomm, etc. (as far as I was told; I am not traveling to 3GPP meetings myself). There is certainly no consistent thinking within larger companies regarding the desired communication models and hence it is not suprising that this aspect again surfaces when it comes to emergency services. Hence, we have to deal with this disconnect between the 3GPP and the IETF emergency services architecture. So, why does the 3GPP comes to us and asks for a document to be worked on even if we in the IETF cannot make use of it? Why cannot they just do it alone without us? Well. In this case it is the fault of the IETF: the SIP process (see http://www.rfc-editor.org/bcp/bcp67.txt) prevents them from doing something useful within the 3GPP (without coming to the IETF). This process was established many years ago and probably has not worked as well as some of us would have liked it. This document might get updated based on the fact that many folks aren't too happy with it. But this takes time. I hope that this makes more sense now. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Henning Schulzrinne >Sent: 18 November, 2008 21:42 >To: Milan Patel >Cc: ECRIT >Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter > >Milan, > >thanks for your explanation. I think it raises a larger issue: >You seem to treat this as a 3GPP-specific issue, i.e., >something that only should be used in the 3GPP case. For >example, the P-Associated-URI facility is not something >available outside that context. In general, I consider it a >bad idea to have deployment-specific SIP variants, even more >so in the emergency calling case. The goal should be that any >SIP terminal can place emergency calls, rather than creating >non- compatible versions of SIP based on access networks. >Maybe we should have this larger-issue first before worrying >about parameter syntax. > >Henning > >On Nov 18, 2008, at 12:38 PM, Milan Patel wrote: > >> Hi Henning, >> >> Firstly, your previous email you asked: >> Why not just have the normal registration be accepted for emergency >> calls only, without the parameter? >> This is perfectly OK when the user is not roaming. >> >> At least in 3GPP, the addition of "sos" in the INVITE's >contact header >> can be associated with the sos URN in the Request-URI. But let's >> concentrate on the REGISTER request for now in this email. >> >> I'll deal with the restricted case first: if you do not have >> sufficient credentials to register with the network, you can't >> register, so yes, this is similar to the unauthenticated access. In >> this case, we are using Equipment identity to identify the user, but >> doesn't help in the call-back case. Since the user is not registered >> at an S-CSCF, there is no way the call can be routed back to >the user. >> >> Normal user: if the user isn't roaming, and registered as >one normally >> does. The UE registers with a SIP URI. In the >P-Associated-URI in the >> 200 (OK) to the REGISTER, the UE receives all the identities >> implicitly registered by the UE, including a tel-URI. In the >event of >> an emergency, the user may use any of these identities when >initiating >> an emergency call. >> >> Now in the case when the user wasn't registered, or was roaming >> (regardless of being registered or not), and has sufficient >> credentials to be authenticated by the network, the user makes an >> emergency call - the UE registers with the network. It needs to tell >> the registrar this registration is due to an emergency call, please >> don't barr my identities, or restrict me from roaming. >> >> Do I need to provide further explanation in the draft on the >> conditions for emergency registration? Isn't it sufficient to refer >> out to 3GPP TS 23.167? >> >> Cheers, >> Milan > >_______________________________________________ >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 ecrit-bounces@ietf.org Tue Dec 30 05:50:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F8E3A6A41; Tue, 30 Dec 2008 05:50:54 -0800 (PST) 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 829C03A6A41 for ; Tue, 30 Dec 2008 05:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 xBycNNOZUvEA for ; Tue, 30 Dec 2008 05:50:52 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 48E5E3A68B5 for ; Tue, 30 Dec 2008 05:50:52 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2008 13:50:40 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp038) with SMTP; 30 Dec 2008 14:50:40 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/5Jjcnzxz52iC943RhX6+WvfBrCdwe0ObUM+wt5X xGH5034tAdyyPk From: "Hannes Tschofenig" To: "ECRIT" Date: Tue, 30 Dec 2008 15:51:03 +0200 Message-ID: <005001c96a85$a8b86060$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 thread-index: AclqhafYuIRcumlHSuuCLaYFdmjUTQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Subject: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, At IETF#73 we had a discussion regarding draft-patel-ecrit-sos-parameter-01.txt and the feedback that was provided lead to an updated draft: http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02 This new document focuses on the "sos" registration only as described by Milan in his recent mail to the list: http://www.ietf.org/mail-archive/web/ecrit/current/msg05779.html This document is work we would be doing for the 3GPP. According to the meeting minutes there was positive support for working on this document during IETF#73, see http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt. Please let me us know whether you have objections or whether you are in support of this document (if you haven't stated your opinion already). Deadline: 16. Jan. 2009 Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 30 08:40:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD66D3A6A64; Tue, 30 Dec 2008 08:40:32 -0800 (PST) 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 037D13A6A59 for ; Tue, 30 Dec 2008 08:40:32 -0800 (PST) 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 6hOumDIibVJw for ; Tue, 30 Dec 2008 08:40:30 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5CE0C3A6A64 for ; Tue, 30 Dec 2008 08:40:30 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LHhdb-0000N6-Ef; Tue, 30 Dec 2008 10:40:11 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ext Henning Schulzrinne'" , "'Milan Patel'" References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net><2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu><5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com><0913B6CD18F370498CD65864CF254E900763513B@zharhxm1.corp.nortel.com><0671D971-1FA1-4024-951E-4DC75555C8FD@cs.columbia.edu><0913B6CD18F370498CD65864CF254E90076A4850@zharhxm1.corp.nortel.com> <039FDECD-29A7-4A57-A759-CC3A61E19EB7@cs.columbia.edu> <004f01c96a85$8c57d1d0$0201a8c0@nsnintra.net> In-Reply-To: <004f01c96a85$8c57d1d0$0201a8c0@nsnintra.net> Date: Tue, 30 Dec 2008 11:40:15 -0500 Message-ID: <02ac01c96a9d$4de6a260$e9b3e720$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclJtiDdcZij0C+JSkmyBmaHFC0wMAgytcWgAAbb50A= 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] What's up with 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Nice argument, and true. However, in this case, I think we have a simpler problem. In some countries, it's a regulatory requirement that devices be able to place emergency calls in circumstances where other calls may not be permitted. This may be because there is no subscription for services, or because of some kind of failure (perhaps a home network is not reachable, but the visited network is, and is subject to regulation that it must enable emergency calls). In other circumstances, the notion of "home" and "visited" is defined such that the visited network always handles emergency calls, regardless of regulation or failure. It seems to me that the notion of a special registration for emergency calls makes sense in those circumstances. Such a registration ought to be explicitly marked as an emergency registration, and not the normal one, I think. Therefore, I think this makes sense. I've never been completely sold on a parameter, but I agree that it's a reasonable way to solve what I think is a reasonable problem worth solving. So this is not directly tied to 3GPP; they are simply an example of the "visited network handles emergency calls". Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, December 30, 2008 8:50 AM To: 'ext Henning Schulzrinne'; Milan Patel Cc: ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter Hi Henning, I understand your concern. It is true that we do not have anything in the IETF emergency services architecture where the mechanism of http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02.txt, i.e. sos SIP REGISTER, plays a role. Maybe we have not yet thought about that problem hard enough. May it is a pure 3GPP IMS problem. There is obviously the question about why the 3GPP IMS emergency services architecture is different than the one developed in the IETF (despite all the talks we had in various meetings and workshops). The reason for this can most likely be found in the desire of those players working in the 3GPP (and related organizations) to have P-CSCF (a SIP proxy) in the visited network so that it more closely reessembles a PSTN model. Is that a good communication model? Does not really matter that much. What matters is that almost all of the companies we see participating in the discussion here on the mailing list regarding all our documents and that are also strong advocates of the IETF emergency services model react very different in the 3GPP and just recently decided to vote against a further alignment between these two emergency services architectures. The companies that supported this misalignment include Ericsson, Alcatel-Lucent, Cisco, Qualcomm, etc. (as far as I was told; I am not traveling to 3GPP meetings myself). There is certainly no consistent thinking within larger companies regarding the desired communication models and hence it is not suprising that this aspect again surfaces when it comes to emergency services. Hence, we have to deal with this disconnect between the 3GPP and the IETF emergency services architecture. So, why does the 3GPP comes to us and asks for a document to be worked on even if we in the IETF cannot make use of it? Why cannot they just do it alone without us? Well. In this case it is the fault of the IETF: the SIP process (see http://www.rfc-editor.org/bcp/bcp67.txt) prevents them from doing something useful within the 3GPP (without coming to the IETF). This process was established many years ago and probably has not worked as well as some of us would have liked it. This document might get updated based on the fact that many folks aren't too happy with it. But this takes time. I hope that this makes more sense now. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Henning Schulzrinne >Sent: 18 November, 2008 21:42 >To: Milan Patel >Cc: ECRIT >Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter > >Milan, > >thanks for your explanation. I think it raises a larger issue: >You seem to treat this as a 3GPP-specific issue, i.e., >something that only should be used in the 3GPP case. For >example, the P-Associated-URI facility is not something >available outside that context. In general, I consider it a >bad idea to have deployment-specific SIP variants, even more >so in the emergency calling case. The goal should be that any >SIP terminal can place emergency calls, rather than creating >non- compatible versions of SIP based on access networks. >Maybe we should have this larger-issue first before worrying >about parameter syntax. > >Henning > >On Nov 18, 2008, at 12:38 PM, Milan Patel wrote: > >> Hi Henning, >> >> Firstly, your previous email you asked: >> Why not just have the normal registration be accepted for emergency >> calls only, without the parameter? >> This is perfectly OK when the user is not roaming. >> >> At least in 3GPP, the addition of "sos" in the INVITE's >contact header >> can be associated with the sos URN in the Request-URI. But let's >> concentrate on the REGISTER request for now in this email. >> >> I'll deal with the restricted case first: if you do not have >> sufficient credentials to register with the network, you can't >> register, so yes, this is similar to the unauthenticated access. In >> this case, we are using Equipment identity to identify the user, but >> doesn't help in the call-back case. Since the user is not registered >> at an S-CSCF, there is no way the call can be routed back to >the user. >> >> Normal user: if the user isn't roaming, and registered as >one normally >> does. The UE registers with a SIP URI. In the >P-Associated-URI in the >> 200 (OK) to the REGISTER, the UE receives all the identities >> implicitly registered by the UE, including a tel-URI. In the >event of >> an emergency, the user may use any of these identities when >initiating >> an emergency call. >> >> Now in the case when the user wasn't registered, or was roaming >> (regardless of being registered or not), and has sufficient >> credentials to be authenticated by the network, the user makes an >> emergency call - the UE registers with the network. It needs to tell >> the registrar this registration is due to an emergency call, please >> don't barr my identities, or restrict me from roaming. >> >> Do I need to provide further explanation in the draft on the >> conditions for emergency registration? Isn't it sufficient to refer >> out to 3GPP TS 23.167? >> >> Cheers, >> Milan > >_______________________________________________ >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 ecrit-bounces@ietf.org Tue Dec 30 11:43:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43963A6A65; Tue, 30 Dec 2008 11:43:47 -0800 (PST) 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 774E33A6A65 for ; Tue, 30 Dec 2008 11:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOuf0bxqITfM for ; Tue, 30 Dec 2008 11:43:45 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 7D1DE3A6A3B for ; Tue, 30 Dec 2008 11:43:45 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1230666213!25268579!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 24948 invoked from network); 30 Dec 2008 19:43:33 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 30 Dec 2008 19:43:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mBUJhWue002951; Tue, 30 Dec 2008 14:43:33 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mBUJhOqt002846; Tue, 30 Dec 2008 14:43:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Dec 2008 14:43:24 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01238DA6@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <005001c96a85$a8b86060$0201a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt Thread-Index: AclqhafYuIRcumlHSuuCLaYFdmjUTQAMP47g References: <005001c96a85$a8b86060$0201a8c0@nsnintra.net> From: "DOLLY, MARTIN C, ATTLABS" To: "Hannes Tschofenig" , "ECRIT" Subject: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, We are in support of this draft. Happy New Year, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, December 30, 2008 8:51 AM To: ECRIT Subject: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt Hi all, At IETF#73 we had a discussion regarding draft-patel-ecrit-sos-parameter-01.txt and the feedback that was provided lead to an updated draft: http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02 This new document focuses on the "sos" registration only as described by Milan in his recent mail to the list: http://www.ietf.org/mail-archive/web/ecrit/current/msg05779.html This document is work we would be doing for the 3GPP. According to the meeting minutes there was positive support for working on this document during IETF#73, see http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt. Please let me us know whether you have objections or whether you are in support of this document (if you haven't stated your opinion already). Deadline: 16. Jan. 2009 Ciao Hannes & 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 From ecrit-bounces@ietf.org Tue Dec 30 15:53:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDA83A687E; Tue, 30 Dec 2008 15:53:26 -0800 (PST) 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 475AA3A67C0 for ; Tue, 30 Dec 2008 15:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.407, 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 tF0D+xdAyMqG for ; Tue, 30 Dec 2008 15:53:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DDB223A687E for ; Tue, 30 Dec 2008 15:53:23 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2008 23:53:12 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp023) with SMTP; 31 Dec 2008 00:53:12 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19qm2FwZxVqN3rgaOo5vpz7qL3J4CyzWTaT+HSWVw IAtRJzifpTZgeL From: "Hannes Tschofenig" To: "ECRIT" Date: Wed, 31 Dec 2008 01:53:35 +0200 Message-ID: <00e701c96ad9$d4af1020$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 thread-index: Aclq2dQgBuNV02qURfq5St5R2U9z5Q== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: [Ecrit] ECRIT Status Update - December 2008 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ECRIT Status Update - December 2008 =================================== 1) draft-ietf-ecrit-framework / draft-ietf-ecrit-phonebcp Action Item: Brian to resubmit a new draft version covering the discussions around location protocols. Date: Early January 2009 2) draft-ietf-ecrit-lost-sync Roger Marshall is the PROTO shepherd for this document. Action Item: Roger is going todo a pre-WGLC review of the document. Date: Early January 2009 3) draft-patel-ecrit-sos-parameter Updated draft based on IETF #73 discussions posted by Milan, see http://www.ietf.org/mail-archive/web/ecrit/current/msg05779.html Action item: Hannes to ask working group to confirm IETF#73 discussion. 4) RFC5031bis Action item: Henning to submit a proposal for RFC5031bis with a modified allocation policy, as described in http://www.ietf.org/mail-archive/web/ecrit/current/msg05769.html Date: Early January 2009 5) draft-rosen-ecrit-premature-disconnect-rqmts We are a bit in a deadlock situation with this document. So far, the group did not accept the document as is and there was a bit of "unhappiness" with the current draft editor, Brian. Since the document is not a WG item the working group chairs cannot change the editor. No other draft proposal has been made so far either. There are four options: a) We have to wait for Brian to come up with a version that is acceptable to the group. b) We wait for someone else to make a proposal (in the form of a draft) that is acceptable. c) We chairs ask the group whether the current document is acceptable as a STARTING POINT and provide the commitment that the draft editor will be changed once the doc is a WG item. We will try item (c) and see what the group thinks about it. Action item: Hannes to post a mail to the list. 6) PSAP Call Back We currently have at least 3 solutions for dealing with callbacks from PSAPs. We have to pick one. Action item: Hannes to post a mail to the list about this aspect to the list. 7) Rechartering Action item: Hannes to post a proposal to the list. Long overdue already. 8) draft-ietf-ecrit-local-emergency-rph-namespace We had some discussions about this document triggered by mails around IETF#73 asking for the purpose and the scope. I read through the e-mail exchange but I need to read through some RFCs/drafts as well in order to summarize the topic. A few folks have provided feedback (James, Brian, Janet, Keith) but more reviews from the rest of the group would be useful. Action item: Hannes to summarize the discussions and to draw a conclusion. 9) Feedback needed for other documents http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-01.txt http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-01.txt http://tools.ietf.org/id/draft-forte-ecrit-service-classification-01.txt http://tools.ietf.org/id/draft-rosen-ecrit-ecall-01.txt http://tools.ietf.org/id/draft-norreys-ecrit-authority2individuals-requireme nts-01.txt http://tools.ietf.org/id/draft-rosen-ecrit-lost-early-warning-00.txt http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-04.t xt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-01.txt http://tools.ietf.org/id/draft-wolf-ecrit-lost-servicelistboundary-00.txt I particularly want to point to the last document. We wanted to give Karl Heinz a possibility to present his document at IETF#73 but then we ran out of time. Please pick a document and read through it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 30 16:22:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E305C3A6810; Tue, 30 Dec 2008 16:22:33 -0800 (PST) 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 EFAE63A6810 for ; Tue, 30 Dec 2008 16:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.266 X-Spam-Level: X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 x5+oGWDmweeV for ; Tue, 30 Dec 2008 16:22:31 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DC0F83A67C0 for ; Tue, 30 Dec 2008 16:22:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,304,1228089600"; d="scan'208";a="221695612" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Dec 2008 00:22:21 +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 mBV0ML0H029744; Tue, 30 Dec 2008 16:22:21 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBV0ML7m023477; Wed, 31 Dec 2008 00:22:21 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Dec 2008 16:22:19 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.22.105]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Dec 2008 16:22:19 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 18:22:18 -0600 To: "Hannes Tschofenig" , "ECRIT" From: "James M. Polk" In-Reply-To: <00e701c96ad9$d4af1020$0201a8c0@nsnintra.net> References: <00e701c96ad9$d4af1020$0201a8c0@nsnintra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 31 Dec 2008 00:22:19.0253 (UTC) FILETIME=[D77F4A50:01C96ADD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1688; t=1230682941; x=1231546941; 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]=20ECRIT=20Status=20Update=20-=2 0December=202008=20(esnet=0A=20=20namespace) |Sender:=20; bh=A1YZqYWgUKnuyVwMilpnf64jGRniU98gMl7WRl9MSNM=; b=hb2DxSBazDEhqO5KiWE8vq8idXj5avHd8S0KQRw4lqiEd/EIWWC/VSZr8S ubCRRNZ8+BvBE8fd7Qfv4mcGkK4zWB2geqBy+xRmaHmp1E0ZGxprJ9xEt6XQ LUFXFqGhdB32KP140Q33e1SXgqvVakp7xGnZUt+daxQW1pesj0ooc=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] ECRIT Status Update - December 2008 (esnet namespace) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:53 PM 12/30/2008, Hannes Tschofenig wrote: >8) draft-ietf-ecrit-local-emergency-rph-namespace > >We had some discussions about this document triggered by mails around >IETF#73 asking for the purpose and the scope. >I read through the e-mail exchange but I need to read through some >RFCs/drafts as well in order to summarize the topic. > >A few folks have provided feedback (James, Brian, Janet, Keith) but more >reviews from the rest of the group would be useful. > >Action item: Hannes to summarize the discussions and to draw a conclusion. Hannes - why are you artificially creating such a high hurdle for this ID to progress? The WG hummed for this ID to become a WG item in Dublin. There hasn't been one other opinion contrary to this (save for yours) on the list or at the Minneapolis meeting. Therefore, it is impossible to conclude with evidence that anyone other than you are delaying this progression. Many have expressed in email to the list, and in person at Minneapolis to you that you are not understanding the topic as much as you believe (SIP signaling and SIP header usage, and this includes the SIP chair that has given you his opinion in front of others), and each of the rest of us (that have voiced an opinion) are in unison in our understanding (and have attempted nearly countless times to explain how you have a misunderstanding of SIP communications). Furthermore - your co-chair does not agree with you, and believes as others do that this ID is needed, necessary and wants it to progress - including other SDOs and organizations (NENA for one) that want to reference this document as an RFC. James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 31 01:29:39 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3077F3A67F7; Wed, 31 Dec 2008 01:29:39 -0800 (PST) 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 C3A463A67F7 for ; Wed, 31 Dec 2008 01:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=1.046, 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 cidJ0zhu9teg for ; Wed, 31 Dec 2008 01:29:36 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 283953A6405 for ; Wed, 31 Dec 2008 01:29:35 -0800 (PST) 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 mBV9TCk9003043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 Dec 2008 10:29:12 +0100 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 mBV9TB9k003871; Wed, 31 Dec 2008 10:29:11 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Dec 2008 10:29:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 11:29:34 +0200 Message-ID: In-Reply-To: <02ac01c96a9d$4de6a260$e9b3e720$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] What's up with draft-patel-ecrit-sos-parameter thread-index: AclJtiDdcZij0C+JSkmyBmaHFC0wMAgytcWgAAbb50AAI26bQA== References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net><2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu><5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com><0913B6CD18F370498CD65864CF254E900763513B@zharhxm1.corp.nortel.com><0671D971-1FA1-4024-951E-4DC75555C8FD@cs.columbia.edu><0913B6CD18F370498CD65864CF254E90076A4850@zharhxm1.corp.nortel.com> <039FDECD-29A7-4A57-A759-CC3A61E19EB7@cs.columbia.edu><004f01c96a85$8c57d1d0$0201a8c0@nsnintra.net> <02ac01c96a9d$4de6a260$e9b3e720$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "Hannes Tschofenig" , "ext Henning Schulzrinne" , "Milan Patel" X-OriginalArrivalTime: 31 Dec 2008 09:29:11.0331 (UTC) FILETIME=[3D050F30:01C96B2A] Cc: ECRIT Subject: Re: [Ecrit] What's up with 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks Brian for your response. Maybe we can even craft some text to be added to the document to capture your reasoning. This would make me feel better. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Brian Rosen >Sent: 30 December, 2008 18:40 >To: 'Hannes Tschofenig'; 'ext Henning Schulzrinne'; 'Milan Patel' >Cc: 'ECRIT' >Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter > >Nice argument, and true. > >However, in this case, I think we have a simpler problem. > >In some countries, it's a regulatory requirement that devices >be able to place emergency calls in circumstances where other >calls may not be permitted. This may be because there is no >subscription for services, or because of some kind of failure >(perhaps a home network is not reachable, but the visited >network is, and is subject to regulation that it must enable >emergency calls). > >In other circumstances, the notion of "home" and "visited" is >defined such that the visited network always handles emergency >calls, regardless of regulation or failure. > >It seems to me that the notion of a special registration for >emergency calls makes sense in those circumstances. Such a >registration ought to be explicitly marked as an emergency >registration, and not the normal one, I think. > >Therefore, I think this makes sense. > >I've never been completely sold on a parameter, but I agree >that it's a reasonable way to solve what I think is a >reasonable problem worth solving. > >So this is not directly tied to 3GPP; they are simply an >example of the "visited network handles emergency calls". > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Hannes Tschofenig >Sent: Tuesday, December 30, 2008 8:50 AM >To: 'ext Henning Schulzrinne'; Milan Patel >Cc: ECRIT >Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter > >Hi Henning, > >I understand your concern. > >It is true that we do not have anything in the IETF emergency >services architecture where the mechanism of >http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02.t >xt, i.e. sos SIP REGISTER, plays a role. Maybe we have not yet >thought about that problem hard enough. May it is a pure 3GPP >IMS problem. > >There is obviously the question about why the 3GPP IMS >emergency services architecture is different than the one >developed in the IETF (despite all the talks we had in various >meetings and workshops). The reason for this can most likely >be found in the desire of those players working in the 3GPP >(and related organizations) to have P-CSCF (a SIP proxy) in >the visited network so that it more closely reessembles a PSTN >model. Is that a good communication model? Does not really >matter that much. What matters is that almost all of the >companies we see participating in the discussion here on the >mailing list regarding all our documents and that are also >strong advocates of the IETF emergency services model react >very different in the 3GPP and just recently decided to vote >against a further alignment between these two emergency >services architectures. The companies that supported this >misalignment include Ericsson, Alcatel-Lucent, Cisco, Qualcomm, etc. >(as far as I was told; I am not traveling to 3GPP meetings myself). >There is certainly no consistent thinking within larger >companies regarding the desired communication models and hence >it is not suprising that this aspect again surfaces when it >comes to emergency services. > >Hence, we have to deal with this disconnect between the 3GPP >and the IETF emergency services architecture. > >So, why does the 3GPP comes to us and asks for a document to >be worked on even if we in the IETF cannot make use of it? Why >cannot they just do it alone without us? > >Well. In this case it is the fault of the IETF: the SIP process (see >http://www.rfc-editor.org/bcp/bcp67.txt) prevents them from >doing something useful within the 3GPP (without coming to the >IETF). This process was established many years ago and >probably has not worked as well as some of us would have liked >it. This document might get updated based on the fact that >many folks aren't too happy with it. But this takes time. > >I hope that this makes more sense now. > >Ciao >Hannes > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of ext Henning Schulzrinne >>Sent: 18 November, 2008 21:42 >>To: Milan Patel >>Cc: ECRIT >>Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter >> >>Milan, >> >>thanks for your explanation. I think it raises a larger issue: >>You seem to treat this as a 3GPP-specific issue, i.e., something that >>only should be used in the 3GPP case. For example, the >P-Associated-URI >>facility is not something available outside that context. In >general, I >>consider it a bad idea to have deployment-specific SIP variants, even >>more so in the emergency calling case. The goal should be >that any SIP >>terminal can place emergency calls, rather than creating >>non- compatible versions of SIP based on access networks. >>Maybe we should have this larger-issue first before worrying about >>parameter syntax. >> >>Henning >> >>On Nov 18, 2008, at 12:38 PM, Milan Patel wrote: >> >>> Hi Henning, >>> >>> Firstly, your previous email you asked: >>> Why not just have the normal registration be accepted for emergency >>> calls only, without the parameter? >>> This is perfectly OK when the user is not roaming. >>> >>> At least in 3GPP, the addition of "sos" in the INVITE's >>contact header >>> can be associated with the sos URN in the Request-URI. But let's >>> concentrate on the REGISTER request for now in this email. >>> >>> I'll deal with the restricted case first: if you do not have >>> sufficient credentials to register with the network, you can't >>> register, so yes, this is similar to the unauthenticated access. In >>> this case, we are using Equipment identity to identify the >user, but >>> doesn't help in the call-back case. Since the user is not >registered >>> at an S-CSCF, there is no way the call can be routed back to >>the user. >>> >>> Normal user: if the user isn't roaming, and registered as >>one normally >>> does. The UE registers with a SIP URI. In the >>P-Associated-URI in the >>> 200 (OK) to the REGISTER, the UE receives all the identities >>> implicitly registered by the UE, including a tel-URI. In the >>event of >>> an emergency, the user may use any of these identities when >>initiating >>> an emergency call. >>> >>> Now in the case when the user wasn't registered, or was roaming >>> (regardless of being registered or not), and has sufficient >>> credentials to be authenticated by the network, the user makes an >>> emergency call - the UE registers with the network. It >needs to tell >>> the registrar this registration is due to an emergency call, please >>> don't barr my identities, or restrict me from roaming. >>> >>> Do I need to provide further explanation in the draft on the >>> conditions for emergency registration? Isn't it sufficient to refer >>> out to 3GPP TS 23.167? >>> >>> Cheers, >>> Milan >> >>_______________________________________________ >>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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 31 01:31:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C983A695B; Wed, 31 Dec 2008 01:31:29 -0800 (PST) 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 3607F3A695B for ; Wed, 31 Dec 2008 01:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=-0.985, 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 rhw-GzG+SOHX for ; Wed, 31 Dec 2008 01:31:26 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 61C983A6405 for ; Wed, 31 Dec 2008 01:31:26 -0800 (PST) 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 mBV9V5J7029632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 Dec 2008 10:31:05 +0100 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 mBV9V5q3030027; Wed, 31 Dec 2008 10:31:05 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Dec 2008 10:31:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 11:31:28 +0200 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE291800255A6EA@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RFC 5031bis - Service URNs thread-index: AclVcHjjsXZg5L78R8ase4LVHdt66QAOIE1wBWBX69A= References: <5D1A7985295922448D5550C94DE291800255A5CF@DEEXC1U01.de.lucent.com> <49368E08.1000802@bbn.com> <5D1A7985295922448D5550C94DE291800255A61F@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE291800255A6EA@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Ted Hardie" , "ext Richard Barnes" X-OriginalArrivalTime: 31 Dec 2008 09:31:05.0186 (UTC) FILETIME=[80E1F420:01C96B2A] Cc: ECRIT Subject: Re: [Ecrit] RFC 5031bis - Service URNs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Keith, Are you saying that the current allocation policy is fine for you? Did you notice that we ran into problems with LoST usage for non-emergency services with the current allocation policy? There is no reason to have the same allocation policy for top-level services as for sub-services. It just depends on the semantic of the sub-service to decide what would be reasonable todo. Ciao Hannes >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 04 December, 2008 02:43 >To: Ted Hardie; Tschofenig, Hannes (NSN - FI/Espoo); ext Richard Barnes >Cc: ECRIT >Subject: RE: [Ecrit] RFC 5031bis - Service URNs > >I would like to keep sub-services at the same strength of >review as the top level. For the existing top-levels that >requires no change to keep it at specification required. > >Keith > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Wednesday, December 03, 2008 5:56 PM >> To: DRAGE, Keith (Keith); Tschofenig, Hannes (NSN - FI/Espoo); ext >> Richard Barnes >> Cc: ECRIT >> Subject: Re: [Ecrit] RFC 5031bis - Service URNs >> >> At 6:43 AM -0800 12/3/08, DRAGE, Keith (Keith) wrote: >> >Well I must admit I looked quickly and read something different and >> >wrongly. >> > >> >If I was starting from scratch, I think I would write >> "standards track" >> >for the subservices of sos, but I cannot point to any >> problems with the >> >existing strategy, so on that basis there is no need to change it. >> > >> >The main point I was making anyway is that we must not have a lower >> >level for "sos" and that we do need clear guidance to stop people >> >registering urns where there are more appropriate places to put >> >information other than a URI. >> > >> >Keith >> >> I'm not sure what "lower level for 'sos'" means, exactly, but I >> believe using "specification required" for top-level and >expert review >> for those >> under sos is reasonable. The Designated Expert for >> "specification required" >> may or may not be the same as for "sos". >> >> Ted >> >> >> >> >> >> >> >> > > -----Original Message----- >> >> From: Tschofenig, Hannes (NSN - FI/Espoo) >> >> [mailto:hannes.tschofenig@nsn.com] >> >> Sent: Wednesday, December 03, 2008 2:36 PM >> >> To: ext Richard Barnes; DRAGE, Keith (Keith) >> >> Cc: ECRIT >> >> Subject: RE: [Ecrit] RFC 5031bis - Service URNs >> >> >> >> This is not what RFC 5031 says. >> >> >> >> >-----Original Message----- >> >> >From: ext Richard Barnes [mailto:rbarnes@bbn.com] >> >> >Sent: 03 December, 2008 15:48 >> >> >To: DRAGE, Keith (Keith) >> >> >Cc: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >> >> >Subject: Re: [Ecrit] RFC 5031bis - Service URNs >> >> > >> >> >Keith, >> >> > >> >> >So to be clear, under your proposal, I would need IETF review to >> >> >register "urn:service:sos.foo", but perhaps less review >> to register >> >> >"urn:service:foo"? >> >> > >> >> >If that's right, this plan makes sense to me. IETF gets to >> >> manage the >> >> >"urn:service:sos" heirarchy, but others could go through >> with less >> >> >review. Definitely agree that more guidance is necessary on >> >> what OK to >> >> >go under "urn:service:". >> >> > >> >> >--Richard >> >> > >> >> > >> >> > >> >> >DRAGE, Keith (Keith) wrote: >> >> >> Does this apply only for top level? >> >> >> >> >> >> What I believe we should retain is that any sub-service >> >> >under the "sos" >> >> >> top-level should be standards track. I believe that we >> need IETF >> >> >> review of those to ensure that they really should be >> classed as an >> >> >> emergency situation and not something else. >> >> >> >> >> >> If we relax the rules for new top-level identifiers, I >> >> believe we do >> >> >> need to provide more guidance on what is a valid service >> >> urn value, >> >> >> and what is not (and therefore should use some other >> >> >construct in SIP >> >> >> or other protocol). >> >> >> >> >> >> regards >> >> >> >> >> >> Keith >> >> >> >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On >> >> >>> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> >> >>> Sent: Wednesday, December 03, 2008 7:45 AM >> >> >>> To: ECRIT >> >> >>> Subject: [Ecrit] RFC 5031bis - Service URNs >> >> >>> >> >> >>> At the IETF#73 ECRIT meeting we spoke about producing a RFC >> >> >5031bis. >> >> >>> >> >> >>> The problem is that the current document demands a >> >> Standards Track >> >> >>> document for allocating a new top-level top-level >> service labels. >> >> >>> >> >> >>> This turned out to make our own work more difficult. >> >> >>> >> >> >>> During the meeting I suggested the following: >> >> >>> - Work on RFC5031bis to change allocation policy >> >> >>> - Submit draft-forte-ecrit-service-classification and >> >> >>> draft-sun-ecrit-shelter-service as informational/experimental >> >> >>> documents to the RFC Editor after Expert Review from >the ECRIT >> >> >>> working group. >> >> >>> >> >> >>> I recall that some folks had some comments about the >> allocation >> >> >>> policy they would like to see. Unfortunately, the meeting >> >> >minutes do >> >> >>> not capture the issue. I did listen to the audio >recording (see >> >> >>> ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/) >> >> and noticed >> >> >>> that Ted argued for "Specification Required" (instead >> of "Expert >> >> >>> Review"). >> > > >>> >> >> >>> When you look at RFC 5226 then you will find a >> >> description of what >> >> >>> the difference between "Specification Required" and >> >> "Expert Review" >> >> >>> is. Here is the description for "Specification Required": >> >> >>> >> >> >>> Specification Required - Values and their >> meanings must be >> >> >>> documented in a permanent and readily >> available public >> >> >>> specification, in sufficient detail so that >> >> >>> interoperability >> >> >>> between independent implementations is possible. >> >> >>> When used, >> >> >>> Specification Required also implies use of a >> >> Designated >> >> >>> Expert, who will review the public >> specification and >> >> >>> evaluate whether it is sufficiently clear to allow >> >> >>> interoperable implementations. The >> intention behind >> >> >>> "permanent and readily available" is that a >> >> document can >> >> >>> reasonably be expected to be findable and >> >> >retrievable long >> >> >>> after IANA assignment of the requested value. >> >> >Publication >> >> >>> of an RFC is an ideal means of achieving this >> >> >requirement, >> >> >>> but Specification Required is intended to >> >> also cover the >> >> >>> case of a document published outside of the RFC >> >> >path. For >> >> >>> RFC publication, the normal RFC review process >> >> >is expected >> >> >>> to provide the necessary review for >> interoperability, >> >> >>> though >> >> >>> the Designated Expert may be a particularly >> >> >well-qualified >> >> >>> person to perform such a review. >> >> >>> >> >> >>> Examples: Diffserv-aware TE Bandwidth >> >> Constraints Model >> >> >>> Identifiers [RFC4124], TLS ClientCertificateType >> >> >>> Identifiers >> >> >>> [RFC4346], ROHC Profile Identifiers [RFC4995]. >> >> >>> >> >> >>> Are you happy about this approach? >> >> >>> >> >> >>> 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 >> >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 31 01:39:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE183A6867; Wed, 31 Dec 2008 01:39:09 -0800 (PST) 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 44BC93A6405 for ; Wed, 31 Dec 2008 01:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=-0.957, 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 Bls7JSrfGRGk for ; Wed, 31 Dec 2008 01:39:08 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 079F83A6867 for ; Wed, 31 Dec 2008 01:39:07 -0800 (PST) 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 mBV9crvd007773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 Dec 2008 10:38:53 +0100 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 mBV9crwt006936; Wed, 31 Dec 2008 10:38:53 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Dec 2008 10:38:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 11:39:16 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Status Update - December 2008 (esnet namespace) thread-index: Aclq3du18h9sZxzJQU2FMz+awdtCIAASsLsw References: <00e701c96ad9$d4af1020$0201a8c0@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 31 Dec 2008 09:38:53.0196 (UTC) FILETIME=[97D69CC0:01C96B2B] Subject: Re: [Ecrit] ECRIT Status Update - December 2008 (esnet namespace) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, >At 05:53 PM 12/30/2008, Hannes Tschofenig wrote: >>8) draft-ietf-ecrit-local-emergency-rph-namespace >> >>We had some discussions about this document triggered by mails around >>IETF#73 asking for the purpose and the scope. >>I read through the e-mail exchange but I need to read through some >>RFCs/drafts as well in order to summarize the topic. >> >>A few folks have provided feedback (James, Brian, Janet, Keith) but >>more reviews from the rest of the group would be useful. >> >>Action item: Hannes to summarize the discussions and to draw >a conclusion. > >Hannes - why are you artificially creating such a high hurdle >for this ID to progress? Summarizing a discussion is not "a high hurdle". > >The WG hummed for this ID to become a WG item in Dublin. I know. Like the group did with a number of other items. Officially, the document is not a WG item yet given that we would require the charter to change as mentioned at the last meeting. > >There hasn't been one other opinion contrary to this (save for >yours) on the list or at the Minneapolis meeting. Well. I raised several issues which I would like to summarize. To pick one "PSAP callback" where there does not seem to be agreement, referencing Brian: http://www.ietf.org/mail-archive/web/ecrit/current/msg05686.html > Therefore, >it is impossible to conclude with evidence that anyone other >than you are delaying this progression. Delaying? Given that we have to change the charter first before this document can actually be picked up as an item (like the other documents as well) I am not delaying anything here. Getting the new charter approved is only possible if we are able to finish our main items, as Jon says. Despite our pushing Phone BCP and Framework are still not finished. > >Many have expressed in email to the list, and in person at >Minneapolis to you that you are not understanding the topic as >much as you believe (SIP signaling and SIP header usage, and >this includes the SIP chair that has given you his opinion in >front of others), and each of the rest of us (that have voiced >an opinion) are in unison in our understanding (and have >attempted nearly countless times to explain how you have a >misunderstanding of SIP communications). Maybe I don't understand this particular item well enough. If I don't understand it given that I am working in this space already for many years gives me the impression that maybe I am not the only one. At least in the past I was never wrong with such an assumption. I don't think it can be wrong to ask questions about documents we have in the group (even if they appear irrelevant to the authors of the mechanism as he knows it better than anybody else). >Furthermore - your co-chair does not agree with you, and >believes as others do that this ID is needed, necessary and >wants it to progress >- including other SDOs and organizations (NENA for one) that >want to reference this document as an RFC. I am actually participating in various NENA conf. calls and have participated in discussions around resource priority for citizen-to-authority emergency calls. I have not heard you on those calls. In short, I am not delaying -- I am trying to understand. No reason to worry. Ciao Hannes > >James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 31 01:44:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131AC3A68F1; Wed, 31 Dec 2008 01:44:50 -0800 (PST) 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 10A183A68F1 for ; Wed, 31 Dec 2008 01:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.415 X-Spam-Level: X-Spam-Status: No, score=-5.415 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8e+oPpFSP0Y for ; Wed, 31 Dec 2008 01:44:48 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 09F6F3A6405 for ; Wed, 31 Dec 2008 01:44:47 -0800 (PST) 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 mBV9iamj024165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 Dec 2008 10:44:36 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mBV9iZ44001231 for ; Wed, 31 Dec 2008 10:44:35 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Dec 2008 10:44:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 11:44:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Early Review by the 3GPP required for draft-rosen-ecrit-premature-disconnect-rqmts-01.txt thread-index: AclrLHDeVWangwKKRG+wA+dDE2tsoQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 31 Dec 2008 09:44:35.0816 (UTC) FILETIME=[640E4680:01C96B2C] Cc: ECRIT Subject: [Ecrit] Early Review by the 3GPP required for draft-rosen-ecrit-premature-disconnect-rqmts-01.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Hannu, in ECRIT we have received input from NENA regarding "Requirements for handling abandoned calls and premature disconnects in emergency calls on the Internet", see http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-01 .txt Since this document also puts requirements on end devices it would be good to get some feedback from the 3GPP and end host manufacturers early enough so that we can address them appropriately. Could you please pick some reviewers from the 3GPP community? Thanks in advance. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 31 01:51:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D56C3A68F1; Wed, 31 Dec 2008 01:51:03 -0800 (PST) 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 26ABB3A68F1 for ; Wed, 31 Dec 2008 01:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GeV4JOTD08d for ; Wed, 31 Dec 2008 01:51:01 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 95CF03A6889 for ; Wed, 31 Dec 2008 01:51:00 -0800 (PST) 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 mBV9omMw023044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 Dec 2008 10:50:48 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mBV9omdO021402 for ; Wed, 31 Dec 2008 10:50:48 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Dec 2008 10:50:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 11:51:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts thread-index: AclrLVAIpzZ7YixAQam2k1f6APiSoQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 31 Dec 2008 09:50:47.0933 (UTC) FILETIME=[41DAD2D0:01C96B2D] Subject: [Ecrit] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, We had a fair amount of discussions regarding this item and, as mentioned in my status update, we would like to resolve the deadlock we currently have. We would like to get some feedback from the group. Are you OK with turning draft-rosen-ecrit-premature-disconnect-rqmts into a working group item (after rechartering) (under the assumption that the editor of the document is changed once the document is a WG item)? Deadline: 19. Jan. 2009 Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 31 02:22:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6A93A6923; Wed, 31 Dec 2008 02:22:13 -0800 (PST) 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 5F3D13A67F3 for ; Wed, 31 Dec 2008 02:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=1.072, 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 2LMjBwZh7hv7 for ; Wed, 31 Dec 2008 02:22:11 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 598A33A6923 for ; Wed, 31 Dec 2008 02:22:10 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mBVALtl4011819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 Dec 2008 11:21:56 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mBVALrU6031148 for ; Wed, 31 Dec 2008 11:21:55 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Dec 2008 11:21:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 12:21:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PSAP Call Backs thread-index: AclrMYhWX5h2YhMUQG6w52bdJHGgeA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 31 Dec 2008 10:21:00.0657 (UTC) FILETIME=[7A528E10:01C96B31] Subject: [Ecrit] PSAP Call Backs 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, In the last few months we have seen increased interest in the topic of PSAP call backs. Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 says: SP-36 Call backs to the Contact: header URI recieved within 30 minutes of an emergency call must reach the device regardless of call features or services that would normally cause the call to be routed to some other entity. More importantly, Section 13 says: ED-73 Call backs SHOULD be determined by retaining the domain of the PSAP which answers an outgoing emergency call and instantiating a timer which starts when the call is terminated. If a call is received from the same domain and within the timer period, sent to the Contact: or AoR used in the emergency call, it should be assumed to be a call back. The suggested timer period is 5 minutes. http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt proposed another solution based on marking the callback using the "sos" URI parameter. http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergency-rph-name space/ proposes another solution by utilizing the Resource Priority Header. So, here are my high-level questions: A) Do you think that you understand the requirements that lead to a need for a technical solution? B) Do you believe that more work beyond the mechanism described in Phone BCP is needed? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 31 03:00:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2439D3A686C; Wed, 31 Dec 2008 03:00:06 -0800 (PST) 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 7A6BD3A686C for ; Wed, 31 Dec 2008 03:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=1.045, 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 3ZT1a+P4zyCG for ; Wed, 31 Dec 2008 03:00:03 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E45E23A67ED for ; Wed, 31 Dec 2008 03:00:02 -0800 (PST) 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 mBVAxolv030831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 Dec 2008 11:59:50 +0100 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 mBVAxoVk020095 for ; Wed, 31 Dec 2008 11:59:50 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Dec 2008 11:59:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 13:00:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT WG RECHARTER (Proposal Version 1) thread-index: AclrNvTKdzIm1rzTSkGAIL2XpuYBfQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 31 Dec 2008 10:59:50.0103 (UTC) FILETIME=[E6C7CE70:01C96B36] Subject: [Ecrit] ECRIT WG RECHARTER (Proposal Version 1) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here is a proposal for ECRIT rechartering. Please let me know if you disagree with something or if something is missing Note that I was not quite sure whether it would be necessary to actually include the following two items in the charter at all after the change to the Service URN RFC has been made: * draft-forte-ecrit-service-classification * draft-sun-ecrit-shelter-service I believe they could be sent directly to the RFC editor and then the review would be done by the ECRIT working group. Please provide me feedback on this issue. Ciao Hannes ---------------- Emergency Context Resolution with Internet Technologies (ecrit) Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will maintain and extend the Location to Service Translation (LoST) protocol for emergency services related aspects but also for usage outside the emergency services context. Additionally, the group is chartered to work on descriptions and extensions regarding citizen-to- authority services (such as defining a Resource Priority header for usage with emergency services). While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be independent. This working group cares about privacy and security concerns, and will address them within its documents. Goals and Milestones: Done Submit "Requirements for Emergency Context Resolution with Internet Technologies" to the IESG for consideration as an Informational RFC Done Submit "Security Threats and Requirements for Emergency Call Marking and Mapping" to the IESG for consideration as an Informational RFC Done Submit "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services" to the IESG for consideration as a Standards Track RFC Done Submit "LoST: A Location-to-Service Translation Protocol" to the IESG for consideration as a Standards Track RFC Done Submit "Discovering LoST Servers Using DHCP" to the IESG for consideration as Informational RFC Done Submit "Location-to-URL Mapping Architecture and Framework" to the IESG for consideration as an Informational RFC Done Submit "Location Hiding: Problem Statement and Requirements" to the IESG for consideration as an Informational RFC Done Submit "Specifying Holes in LoST Service Boundaries" to the IESG for consideration as a BCP RFC Feb 2009 Submit "Synchronizing Location-to-Service Translation (LoST) Servers" to the IESG for consideration as a Standards Track RFC Feb 2009 Submit "Best Current Practice for Communications Services in support of Emergency Calling" to the IESG for consideration as a BCP RFC Feb 2009 Submit "Framework for Emergency Calling using Internet Multimedia" to the IESG for consideration as a Standards Track RFC Mar 2009 Submit "IANA Registering a SIP RPH Namespace for Local Emergency Communications" to the IESG for consideration as a Standards Track RFC Mar 2009 Submit "RFC 5031bis" to the IESG for consideration as a Standards Track RFC Apr 2009 Submit "Using Imprecise Location for Emergency Context Resolution" to the IESG for consideration as an Informational RFC May 2009 Submit "Location-to-Service Translation Protocol (LoST) Extensions" to the IESG for consideration as an Informational RFC May 2009 Submit "LoST Classification of Location-based Services" to the IESG for consideration as an Experimental RFC May 2009 Submit "LoST Usage for discovering Shelter Services" to the IESG for consideration as an Experimental RFC _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit