From Hannes.Tschofenig@gmx.net Sat Aug 1 03:56:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EA33A6A1A for ; Sat, 1 Aug 2009 03:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_20=-0.74, SARE_SUB_LET=0.72] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upkR-0PzZIuk for ; Sat, 1 Aug 2009 03:56:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C12153A69C1 for ; Sat, 1 Aug 2009 03:56:21 -0700 (PDT) Received: (qmail invoked by alias); 01 Aug 2009 10:56:21 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp049) with SMTP; 01 Aug 2009 12:56:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+hgrhb+LqhXorFRmH2ziUI2d4+Yku8oKhmIPJBpo s36GFYeKnYKKu7 From: "Hannes Tschofenig" To: "'Winterbottom, James'" , "'DRAGE, Keith \(Keith\)'" , "'Brian Rosen'" , "'Elwell, John'" , "'Marc Linsner'" , "'ecrit'" References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net> Date: Sat, 1 Aug 2009 13:58:49 +0300 Message-ID: <000001ca1297$0e4672a0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAJBBMsADBKxIA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.00 Subject: [Ecrit] Let us focus on the HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 10:56:22 -0000 ... and avoid discussing the same old stuff again. Ciao Hannes From randy@qualcomm.com Sat Aug 1 15:06:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470453A6B68 for ; Sat, 1 Aug 2009 15:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.942 X-Spam-Level: X-Spam-Status: No, score=-104.942 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 r-kp7yeCF1jh for ; Sat, 1 Aug 2009 15:06:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id AE0AD3A6B52 for ; Sat, 1 Aug 2009 15:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1249164366; x=1280700366; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<580F3FFD9207B545B48957A92BECEE0A508EB5@S TNTEXCH11.cis.neustar.com>|References:=20<580F3FFD9207B54 5B48957A92BECEE0A508EB5@STNTEXCH11.cis.neustar.com> |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-Note: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Sat,=201=20Aug=202 009=2007:23:43=20-0700|To:=20"Rosen,=20Brian"=20,=20|From:=20Randall=20Ge llens=20|Subject:=20Re:=20[Ecrit]=20P roblem=20statement=20for=20Premature=20Disconnect |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,56 95"=3B=20a=3D"21536836"; bh=qdvLGViiU0tWY0zrNLthKwG9zr7+Iokt7BEWEgpa8l4=; b=cMDsSpphmZrgQXdiTQYvQU2ezqNBK59h+7yP4eoLCDTQV02mL5621vvP ozz4ZVK/ptOR1WcUIY9ePAbIBoaw27XfBbo3hKutC2RWVyqc6idUPSD/W zq4po5pZOGa3p5Z7YrPf8HonbyW/P4zmawBjcLRGGQBd1YGoGCcxYVHFR o=; X-IronPort-AV: E=McAfee;i="5300,2777,5695"; a="21536836" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2009 15:05:50 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n71M5oQm010641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 1 Aug 2009 15:05:50 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n71M5oRg022435 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 Aug 2009 15:05:50 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Sat, 1 Aug 2009 15:05:49 -0700 Received: from [78.64.88.186] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 1 Aug 2009 15:05:48 -0700 Message-ID: In-Reply-To: <580F3FFD9207B545B48957A92BECEE0A508EB5@STNTEXCH11.cis.neustar.com> References: <580F3FFD9207B545B48957A92BECEE0A508EB5@STNTEXCH11.cis.neustar.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Sat, 1 Aug 2009 07:23:43 -0700 To: "Rosen, Brian" , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] Problem statement for Premature Disconnect X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 22:06:05 -0000 At 5:31 AM -0400 7/29/09, Brian Rosen wrote: > I was asked to reword a problem statement on premature disconnect that > might be acceptable to begin work on, probably a design team on > requirements. Hi Brian, I think this problem statement is much better. I made a few small suggested changes: > In emergency calls, people are stressed. They sometimes try to > disconnect a call where communication between the caller and the call > taker has begun, but before the call taker has acquired enough > information to direct appropriate response. That circumstance is known > as "premature disconnect". > In those circumstances the device should > behave differently. I suggest replacing this sentence with "Special behavior by the device during emergency calls can help avoid premature disconnect." > For example, the device may alert rather than > disconnect. I suggest changing this sentence to "For example, the device may respond to a disconnection request by first alerting rather than immediately disconnecting." > The behavior of the device would be UI driven, and thus not > specifiable by the IETF, although advice might be given. > > Special behavior is not always desirable. For example, in high call > volume circumstances, the call may be answered by the PSAP at an IVR, in > which case no special behavior is desired. The device may not implement > the specification, or for some reason, it may not be available for a > particular emergency call. For this reason, some form of signaling at > the beginning of the call is needed to negotiate enabling the special > behavior. > It is desirable that the PSAP be aware that the user has attempted to > disconnect/reconnect, and it may be useful for the PSAP to be able to > influence the behavior of the device. Some form of signaling for this > purpose is desirable, but need not be reliable, since it is advisory. Perhaps we can change this to: "An additional desire expressed by some PSAPs is to be aware that the user has attempted to disconnect or reconnect, and in such cases it may be useful for the PSAP to be able to influence the behavior of the device. Some form of signaling for this purpose is desirable, but need not be reliable, since it is advisory." > In all circumstances the user must maintain control of his device, and > it must be possible for the user to take some action to complete a > disconnect. Can we add "The device must opt-in to any such special handling (as an example, based on a user preference or setting)." -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The most savage controversies are those about matters as to which there is no good evidence either way. --Bertrand Russell From Hannes.Tschofenig@gmx.net Sun Aug 2 02:24:48 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35863A6B0A for ; Sun, 2 Aug 2009 02:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.164 X-Spam-Level: X-Spam-Status: No, score=-1.164 tagged_above=-999 required=5 tests=[AWL=1.435, 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 grd+FxCHNcRv for ; Sun, 2 Aug 2009 02:24:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E7E6B3A69A0 for ; Sun, 2 Aug 2009 02:23:32 -0700 (PDT) Received: (qmail invoked by alias); 02 Aug 2009 09:23:33 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 02 Aug 2009 11:23:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18hTGBPuPkhdOkcKuzPNW9VKmJHrkIrR00BdG+1OM 8UP/aIlj/3ziME From: "Hannes Tschofenig" To: "'Randall Gellens'" , "'Rosen, Brian'" , References: <580F3FFD9207B545B48957A92BECEE0A508EB5@STNTEXCH11.cis.neustar.com> Date: Sun, 2 Aug 2009 12:26:02 +0300 Message-ID: <039c01ca1353$41b4c620$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoS9EakrfDmzn4YQqiCUw4YMkHhzgAXmfig X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Subject: Re: [Ecrit] Problem statement for Premature Disconnect X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 09:24:48 -0000 A few minor changes: -------- In emergency calls, people are stressed. They sometimes try to disconnect a call where communication between the caller and the call taker has begun, but before the call taker has acquired enough information to direct appropriate response. That circumstance is known as "premature disconnect". Special behavior by the device during emergency calls can help avoid premature disconnect. For example, the device may respond to a disconnection request by first alerting rather than immediately disconnecting. Unfortunately, the device of the emergency caller does not by itself know at what point in time enough information has been obtained by the call taker so that it would be safe to disconnect. As such, it appears desirable to let the call taker disconnect the call rather than the emergency caller. The behavior of the device in case of a premature disconnect would be user interface (UI) driven, and thus not specifiable by the IETF, although advice might be given. Note that this special behavior may not always be desirable. For example, in high call volume circumstances, the call may be answered by the PSAP at an Interactive Voice Response (IVR), in which case no special behavior is desired. The device may not implement the specification, or for some reason, it may not be available for a particular emergency call. For this reason, some form of signaling at the beginning of the call is needed to negotiate enabling the special behavior. An additional desire expressed by some PSAPs is to be aware that the user has attempted to disconnect or reconnect, and in such cases it may be useful for the PSAP to be able to influence the behavior of the device. Some form of signaling for this purpose is desirable, but need not be reliable, since it is advisory. The device must opt-in to any such special handling (as an example, based on a user preference or setting). -------- >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Randall Gellens >Sent: 01 August, 2009 17:24 >To: Rosen, Brian; ecrit@ietf.org >Subject: Re: [Ecrit] Problem statement for Premature Disconnect > >At 5:31 AM -0400 7/29/09, Brian Rosen wrote: > >> I was asked to reword a problem statement on premature disconnect >> that might be acceptable to begin work on, probably a >design team on >> requirements. > >Hi Brian, > >I think this problem statement is much better. I made a few >small suggested changes: > >> In emergency calls, people are stressed. They sometimes try to >> disconnect a call where communication between the caller and >the call >> taker has begun, but before the call taker has acquired enough >> information to direct appropriate response. That circumstance is >> known as "premature disconnect". > > >> In those circumstances the device should behave differently. > >I suggest replacing this sentence with "Special behavior by >the device during emergency calls can help avoid premature disconnect." > >> For example, the device may alert rather than disconnect. > >I suggest changing this sentence to "For example, the device >may respond to a disconnection request by first alerting >rather than immediately disconnecting." > >> The behavior of the device would be UI driven, and thus not >> specifiable by the IETF, although advice might be given. >> >> Special behavior is not always desirable. For example, in >high call >> volume circumstances, the call may be answered by the PSAP >at an IVR, >> in which case no special behavior is desired. The device may not >> implement the specification, or for some reason, it may not be >> available for a particular emergency call. For this reason, some >> form of signaling at the beginning of the call is needed to >negotiate >> enabling the special behavior. > > > >> It is desirable that the PSAP be aware that the user has >attempted to >> disconnect/reconnect, and it may be useful for the PSAP to >be able to >> influence the behavior of the device. Some form of >signaling for this >> purpose is desirable, but need not be reliable, since it is advisory. > >Perhaps we can change this to: "An additional desire expressed >by some PSAPs is to be aware that the user has attempted to >disconnect or reconnect, and in such cases it may be useful >for the PSAP to be able to influence the behavior of the >device. Some form of signaling for this purpose is desirable, >but need not be reliable, since it is advisory." > >> In all circumstances the user must maintain control of his device, >> and it must be possible for the user to take some action to >complete >> a disconnect. > >Can we add "The device must opt-in to any such special >handling (as an example, based on a user preference or setting)." > >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- The most >savage controversies are those about matters as to which there >is no good evidence either way. > --Bertrand Russell >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From fmenard@xittel.net Sun Aug 2 17:31:08 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97BB3A6CB4; Sun, 2 Aug 2009 17:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4ad5EtX7HZG; Sun, 2 Aug 2009 17:31:08 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 428823A6CB6; Sun, 2 Aug 2009 17:31:08 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MXlSH-0001N4-Uh; Sun, 02 Aug 2009 20:31:10 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MXlSH-0003m1-Ov; Sun, 02 Aug 2009 20:31:09 -0400 Message-Id: <54A3EF51-9255-402F-A915-E3FB186B42D6@xittel.net> From: Francois Menard To: ecrit@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) X-Priority: 1 Date: Sun, 2 Aug 2009 20:31:09 -0400 X-Mailer: Apple Mail (2.935.3) Cc: sipcore@ietf.org Subject: [Ecrit] updating of section 6.7 of draft-ietf-ecrit-phonebcp-13.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 04:11:29 -0000 I propose to change section 6.7 of draft-ietf-ecrit-phonebcp-13.txt to reflect the switch to sipcore-location-conveyance, i.e. http://www.ietf.org/id/draft-ietf-sipcore-location-conveyance-01.txt Text should now read ED-33/SP-15 Location sent between SIP elements MUST be conveyed using [I-D.ietf-sipcore-location-conveyance]. F. Francois Menard fmenard@xittel.net From br@brianrosen.net Mon Aug 3 06:35:41 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD1A28C1CE; Mon, 3 Aug 2009 06:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 L95VE1gjWPaW; Mon, 3 Aug 2009 06:35:40 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2E57328C1D1; Mon, 3 Aug 2009 06:35:18 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MXxgh-0005QS-0Y; Mon, 03 Aug 2009 08:35:13 -0500 From: "Brian Rosen" To: "'Francois Menard'" , References: <54A3EF51-9255-402F-A915-E3FB186B42D6@xittel.net> In-Reply-To: <54A3EF51-9255-402F-A915-E3FB186B42D6@xittel.net> Date: Mon, 3 Aug 2009 09:34:51 -0400 Message-ID: <018401ca143f$3e6768a0$bb3639e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoT8HzHZUDjMDiQRKiYDQxBXGBrSgATcL5g 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: sipcore@ietf.org Subject: Re: [Ecrit] updating of section 6.7 of draft-ietf-ecrit-phonebcp-13.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:35:41 -0000 This problem was noted before, and will be addressed in the next version Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Francois Menard > Sent: Sunday, August 02, 2009 8:31 PM > To: ecrit@ietf.org > Cc: sipcore@ietf.org > Subject: [Ecrit] updating of section 6.7 of draft-ietf-ecrit-phonebcp- > 13.txt > Importance: High > > I propose to change section 6.7 of draft-ietf-ecrit-phonebcp-13.txt > > to reflect the switch to sipcore-location-conveyance, i.e. > > http://www.ietf.org/id/draft-ietf-sipcore-location-conveyance-01.txt > > Text should now read > > ED-33/SP-15 Location sent between SIP elements MUST be conveyed using > [I-D.ietf-sipcore-location-conveyance]. > > F. > > > Francois Menard > fmenard@xittel.net > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Gabor.Bajko@nokia.com Mon Aug 3 07:39:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9F128C17B for ; Mon, 3 Aug 2009 07:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 uszKLOj9G1yr for ; Mon, 3 Aug 2009 07:39:14 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1D5903A6D04 for ; Mon, 3 Aug 2009 07:39:06 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n73Ec5kW017802; Mon, 3 Aug 2009 09:38:14 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 17:37:59 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 17:37:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 17:37:49 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 3 Aug 2009 16:37:46 +0200 From: To: , , , , Date: Mon, 3 Aug 2009 16:37:49 +0200 Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcA= Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> <000901ca1139$590fb490$0b2f1db0$@net> <003501ca1153$77db50e0$6791f2a0$@net> <01a501ca123a$fe05da40$fa118ec0$@net> In-Reply-To: <01a501ca123a$fe05da40$fa118ec0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Aug 2009 14:37:49.0681 (UTC) FILETIME=[F9A14610:01CA1447] X-Nokia-AV: Clean Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 14:39:15 -0000 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Brian Rosen >Sent: Friday, July 31, 2009 5:00 PM >To: 'DRAGE, Keith (Keith)'; 'Elwell, John'; 'Marc Linsner'; 'ecrit' >Subject: Re: [Ecrit] HUM on PhoneBCP > >Haha, yes, a browser, or even an app using the raw packet=20 >service in a 3GPP GPRS device is on the Internet, although=20 >there are some subtle differences (the DNS root for=20 >example), These are deployment and operational decisions, which have nothing to do wi= th the ongoing discussion. > but then, a service using that raw packet=20 >interface to make, say, an IM to an emergency service would=20 >probably have to make use of the phonebcp procedures, a fact=20 >3GPP is studiously ignoring. 3gpp has defined a set of different procedures for emergency calls, and car= riers will likely ask vendors to implement as specified. Then users will al= so use it as specified. > I would not go so far as to=20 >say most people would prefer the 3GPP specified procedures=20 >vs the IETF phonebcp procedures, especially if they=20 >understood the tradeoffs. It is not a question of preference. Carriers want to have a solution which = is reliable and operational 99.99999% of the cases. It has to be a stricly = managed network. >However, a 3GPP mobile telephone service is not an Internet=20 >service, no matter how you stretch it. Wow. What is your definition of Internet Service? I do remember statements = on this mailing list that cellular networks are not IP capable. I guess you= didn't want to go that far. I access the same content regardless of whether I use the comcast cable end= ing in the house or t-mobile's packet data service anywhere else. The only = difference is the speed and the cost.=20 Looks the same to me, no matter how I strech it. - gabor >Brian > >> -----Original Message----- >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> Sent: Friday, July 31, 2009 7:20 AM >> To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' >> Subject: RE: [Ecrit] HUM on PhoneBCP >>=20 >> Just to outline one of the issues. >>=20 >> Take any 3GPP GPRS enabled mobile phone where you have a=20 >browser open=20 >> and it is browsing the general internet. In your=20 >understanding that=20 >> would be a device on the Internet. >>=20 >> However if the user attempts to make an emergency call from that=20 >> device, 3GPP specifies that certain things should happen=20 >if the user=20 >> happens to press the keys associated with making an=20 >emergency call,=20 >> and the device then recognises an emergency call. It then=20 >goes on to=20 >> specify how the emergency call is made from such a device.=20 >That set of=20 >> procedures is not the same as specified in phonebcp. >>=20 >> In this case 3GPP assumes in their specifications that the 3GPP=20 >> procedures take precedence, and indeed most people would=20 >consider that=20 >> for this particular device, despite it being a device=20 >attached to the=20 >> Internet, those procedures are the best first mechanism to=20 >attempt to=20 >> make an emergency call. >>=20 >> regards >>=20 >> Keith >>=20 >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Thursday, July 30, 2009 9:22 PM >> > To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc Linsner'; 'ecrit' >> > Subject: RE: [Ecrit] HUM on PhoneBCP >> > >> > I specified the Internet, and not an internet. Usually=20 >we mean the=20 >> > public Internet. I think we have a decent definition of=20 >that. It=20 >> > wouldn't cover, for example, a closed network like a =20 >IMS call on a=20 >> > cellular 3G network. >> > Might include, however, something like a call on an IMS=20 >network from=20 >> > a nomading customer on some random public access=20 >network, depends. >> > >> > Anyway, I said I was willing to do the edit in a effort to gain=20 >> > consensus. >> > >> > Brian >> > >> > > -----Original Message----- >> > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> > > Sent: Thursday, July 30, 2009 4:13 PM >> > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' >> > > Subject: RE: [Ecrit] HUM on PhoneBCP >> > > >> > > I don't believe you can use the word "Internet" to target a >> > distinct >> > > scope of phonebcp from other SDOs work in this area. >> > > >> > > But I'll follow the argument through if you really want. Which=20 >> > > well known definition of internet are you using so we=20 >start from >> > a common >> > > baseline? >> > > >> > > regards >> > > >> > > Keith >> > > >> > > > -----Original Message----- >> > > > From: Brian Rosen [mailto:br@brianrosen.net] >> > > > Sent: Thursday, July 30, 2009 6:15 PM >> > > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc=20 >Linsner'; 'ecrit' >> > > > Subject: RE: [Ecrit] HUM on PhoneBCP >> > > > >> > > > The IETF does work targeted to the Internet. Other SDOs >> > do work on >> > > > different kinds of networks other than the Internet. >> > > > The document describes best current practice for >> > emergency calls on >> > > > the Internet. >> > > > >> > > > Brian >> > > > >> > > > > -----Original Message----- >> > > > > From: ecrit-bounces@ietf.org >> > > > [mailto:ecrit-bounces@ietf.org] On Behalf >> > > > > Of Elwell, John >> > > > > Sent: Thursday, July 30, 2009 1:02 PM >> > > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit >> > > > > Subject: Re: [Ecrit] HUM on PhoneBCP >> > > > > >> > > > > >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: ecrit-bounces@ietf.org >> > [mailto:ecrit-bounces@ietf.org] On >> > > > > > Behalf Of DRAGE, Keith (Keith) >> > > > > > Sent: 30 July 2009 09:01 >> > > > > > To: Marc Linsner; 'ecrit' >> > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP >> > > > > > >> > > > > > I don't agree. >> > > > > > >> > > > > > Some background. >> > > > > > >> > > > > > There was a set of comments provided by Stephen Edge on >> > > > 5th February >> > > > > > 2009. I can find no response to that set of comments on >> > > > the mailing >> > > > > > list. >> > > > > > >> > > > > > The gist of that set of comments was that phonebcp claims >> > > > to cover >> > > > > > all access technologies and it identified a >> > significant number >> > > > > > of requirements within phonebcp that the author >> > considered were >> > > > > > not requirements on 3GPP accesses. >> > > > > > >> > > > > > So my position is that the document is not ready >> > because all the >> > > > > > valid comments on the document were not addressed. >> > > > > > >> > > > > > There are two ways of dealing with this set of comments: >> > > > > > >> > > > > > - going through and modifying all the identified >> > > > > > requirements where the comment is upheld. >> > > > > > >> > > > > > - making more clear in the abstract and / or=20 >introduction >> > > > > > that this is solely the view of IETF in regard to IP >> > > > capable devices >> > > > > > and that other organisations may specify other=20 >requirements. >> > > > > > >> > > > > > I would note at this point that the current=20 >abstract says: >> > > > > > >> > > > > > The IETF and other standards organization have efforts >> > > > targeted at >> > > > > > standardizing various aspects of placing emergency >> > calls on IP >> > > > > > networks. This memo describes best current >> > practice on how >> > > > > > devices, >> > > > > > networks and services should use such standards to >> > > > make emergency >> > > > > > calls. >> > > > > > >> > > > > > Because the two sentences follow each other, it implies >> > > > that other >> > > > > > SDOs that have efforts targetted at addressing these >> > > > solutions are >> > > > > > complicit in the requirements so stated, and=20 >this is untrue. >> > > > > [JRE] I agree that this juxtaposition of=20 >statements is rather=20 >> > > > > misleading, and would suggest we try to improve. In >> > fact the only >> > > > > "other standards organization" responsible for "such >> > standards" >> > > > > is ANSI/TIA, since LLDP-MED is the only normative reference >> > > > (and I would >> > > > > argue that LLDP-MED is not specifically targeted at >> > > > emergency calls). >> > > > > So perhaps we can reword the abstract to say "The IETF has >> > > > efforts..." >> > > > > >> > > > > John >> > > > > >> > > > > >> > > > > Certainly the current status of this document >> > > > > > as addressed by various informal 3GPP discussions is to >> > > > ensure that >> > > > > > things do not fall apart in entities using the 3GPP >> > mechanisms, >> > > > > > however 3GPP devices do not use these requirements >> > (no do these >> > > > > > requirements represent the 3GPP requires. >> > > > > > >> > > > > > One solution to the issue would just be to make much >> > > > clearer which >> > > > > > SDOs have participated in this work and which have >> > not and the >> > > > > > status of that progress - however that was also what >> > people keep >> > > > > > calling the "applicability statement" was trying to do. >> > > > > > >> > > > > > regards >> > > > > > >> > > > > > Keith >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > ________________________________ >> > > > > > >> > > > > > From: ecrit-bounces@ietf.org=20 >> > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner >> > > > > > Sent: Wednesday, July 29, 2009 2:53 PM >> > > > > > To: 'ecrit' >> > > > > > Subject: [Ecrit] HUM on PhoneBCP >> > > > > > >> > > > > > >> > > > > > During today's meeting there was discussion as to why >> > > > the chairs >> > > > > > Publication Requested PhoneBCP version 13 when there are >> > > > unresolved >> > > > > > issues. This discussion led us to call for a hum. >> > We are now >> > > > > > asking the same question on the list. >> > > > > > >> > > > > > Do you agree or disagree that PhoneBCP -13 is ready to >> > > > Publication >> > > > > > Request? >> > > > > > >> > > > > > Please respond by close of business on Wednesday August >> > > 5th. >> > > > > > >> > > > > > Thanks, >> > > > > > >> > > > > > Marc & Hannes >> > > > > > >> > > > > > >> > > > > > >> > > > > _______________________________________________ >> > > > > Ecrit mailing list >> > > > > Ecrit@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/ecrit >> > > > >> > > > =3D >> > >> > =3D > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit >= From bs7652@att.com Mon Aug 3 11:46:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B15328C207 for ; Mon, 3 Aug 2009 11:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.683 X-Spam-Level: X-Spam-Status: No, score=-105.683 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y3-+OWYYNel for ; Mon, 3 Aug 2009 11:46:02 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id EB85128C203 for ; Mon, 3 Aug 2009 11:46:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-4.tower-146.messagelabs.com!1249325161!10649800!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 4886 invoked from network); 3 Aug 2009 18:46:01 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-4.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Aug 2009 18:46:01 -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 n73Ik1pK007666 for ; Mon, 3 Aug 2009 14:46:01 -0400 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n73IjtP8007095 for ; Mon, 3 Aug 2009 14:45:55 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 14:45:54 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 14:45:55 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA146A.A18D8BDC" Date: Mon, 3 Aug 2009 14:45:51 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0F5E672A@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP thread-index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQADLR/gAQJ5YEA= From: "Stark, Barbara" To: "ecrit" X-OriginalArrivalTime: 03 Aug 2009 18:45:55.0098 (UTC) FILETIME=[A207A7A0:01CA146A] Subject: [Ecrit] FW: HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 18:46:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA146A.A18D8BDC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending to the entire list... My hum of "It's ready". Barbara =20 From: Stark, Barbara=20 Sent: Wednesday, July 29, 2009 11:25 AM To: 'Marc Linsner' Subject: RE: [Ecrit] HUM on PhoneBCP =20 It's ready. =20 Barbara =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, July 29, 2009 9:53 AM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP =20 During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? Please respond by close of business on Wednesday August 5th. Thanks, Marc & Hannes ***** 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. GA621 ------_=_NextPart_001_01CA146A.A18D8BDC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HUM on PhoneBCP

Resending to the entire list…

My hum of “It’s = ready”.

Barbara

 

From:= Stark, = Barbara
Sent: Wednesday, July 29, 2009 11:25 AM
To: 'Marc Linsner'
Subject: RE: [Ecrit] HUM on PhoneBCP

 

It’s ready.

 

Barbara

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Marc Linsner
Sent: Wednesday, July 29, 2009 9:53 AM
To: 'ecrit'
Subject: [Ecrit] HUM on PhoneBCP

 

During today’s meeting there was discussion as to why the chairs = Publication Requested PhoneBCP version 13 when there are unresolved issues. =  This discussion led us to call for a hum.  We are now asking the same = question on the list.

Do you agree or disagree that PhoneBCP -13 = is ready to Publication Request?

Please respond by close of business on Wednesday August 5th.

Thanks,

Marc & Hannes

*****

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. GA621

 ------_=_NextPart_001_01CA146A.A18D8BDC-- From andy@hxr.us Mon Aug 3 12:16:33 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813293A68E7 for ; Mon, 3 Aug 2009 12:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obA6NXotrstT for ; Mon, 3 Aug 2009 12:16:32 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id CB69F3A6A2D for ; Mon, 3 Aug 2009 12:16:32 -0700 (PDT) Received: from zx80.arin.net ([::ffff:192.149.252.11]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 03 Aug 2009 15:16:30 -0400 id 015842F1.4A77378E.00003BB7 Message-Id: From: Andrew Newton To: Hannes Tschofenig In-Reply-To: <000001ca1297$0e4672a0$0301a8c0@nsnintra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 15:16:30 -0400 References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net> <000001ca1297$0e4672a0$0301a8c0@nsnintra.net> X-Mailer: Apple Mail (2.935.3) Cc: ECRIT Subject: Re: [Ecrit] Let us focus on the HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:16:33 -0000 But isn't it fun to debate the meaning of the "Internet"? I don't think Stephen's concerns should hold up either document. -andy On Aug 1, 2009, at 6:58 AM, Hannes Tschofenig wrote: > ... and avoid discussing the same old stuff again. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@andrew.com Mon Aug 3 21:19:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3953A6F2F for ; Mon, 3 Aug 2009 21:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NQuVDknz8KK for ; Mon, 3 Aug 2009 21:19:34 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 617FD3A6F36 for ; Mon, 3 Aug 2009 21:18:49 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_03_23_41_30 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, 03 Aug 2009 23:41:30 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 23:18:51 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Aug 2009 23:18:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8A== References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net> From: "Dawson, Martin" To: , , , , , X-OriginalArrivalTime: 04 Aug 2009 04:18:51.0156 (UTC) FILETIME=[ABC1D540:01CA14BA] Subject: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 04:19:36 -0000 I interpret Brian's comment as being that a conventional *switched=0D=0Acir= cuit* mobile phone service is not the same as an Internet [call]=0D=0Aservi= ce. I think that's pretty apparent from the context. Would you=0D=0Aclaim t= hat it is, in fact, the Internet when a switched circuit call is=0D=0Amade = Gabor=3F=0D=0A=0D=0AComments about reliability are misleading. Either archi= tectural solution=0D=0Acan be made arbitrarily reliable. Both can be deploy= ed in the context of=0D=0Amanaged access according to the requirements appl= ied by the=0D=0Ajurisdiction.=0D=0A=0D=0AThere's been a presumption in this= debate that somehow ECRIT needs=0D=0A"apologists" relative to IMS because = IMS has a complete, definitive, and=0D=0Aapparently infinitely versatile de= finition for handling emergency calls=0D=0Ain 3GPP access. It would be reas= onable to infer from the representations=0D=0Amade with respect to the IMS = model that this definition is clear, well=0D=0Aunderstood, and unambiguous = to those familiar with the domain. I'd like=0D=0Ato explore that premise a = little.=0D=0A=0D=0AWhile you're contributing your knowledge to the discussi= on then Gabor,=0D=0Acould you please elaborate on the detailed procedures, = including which=0D=0Aprotocols are employed, when an emergency call is invo= ked according to=0D=0A3GPP 23.167=3F=0D=0A=0D=0AI'll grant that, somehow, t= he UE has recognized the appropriate E-CSCF=0D=0Ain that managed network an= d now needs to invoke the emergency service=0D=0Aprocedures. As the spec po= ints out, there's the Ml interface to the=0D=0Alocation routing function (L= RF). Can you please describe the details as=0D=0Adefined by 3GPP from then = on=3F Or, alternatively, could you point to the=0D=0Adetailed procedure spe= cification that explains what actually occurs=3F The=0D=0Aanalogue from the= ECRIT perspective is quite well elaborated, including=0D=0Athe use of LoST= for the routing query and the use of candidate LCPs for=0D=0Athe location = determination by value and by reference, the associated=0D=0Aconveyance of = location value/reference in SIP etc.=0D=0A=0D=0AI'm sure IETF participants = would appreciate and benefit from elucidation=0D=0Aof just what the 3GPP "s= ecret sauce" is. I don't want to leave anyone=0D=0Aout and, of course, invi= te other 3GPP knowledgeable and vocal parties to=0D=0Acontribute.=0D=0A=0D=0A= Cheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-= bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Gabor.Ba= jko@nokia.com=0D=0ASent: Tuesday, 4 August 2009 12:38 AM=0D=0ATo: br@brianr= osen.net; drage@alcatel-lucent.com;=0D=0Ajohn.elwell@siemens-enterprise.com= ; mlinsner@cisco.com; ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] HUM on Phone= BCP=0D=0A=0D=0A=0D=0A=0D=0A >-----Original Message-----=0D=0A >From: ecri= t-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20=0D=0A >On Behalf Of = ext Brian Rosen=0D=0A >Sent: Friday, July 31, 2009 5:00 PM=0D=0A >To: 'DR= AGE, Keith (Keith)'; 'Elwell, John'; 'Marc Linsner'; 'ecrit'=0D=0A >Subjec= t: Re: [Ecrit] HUM on PhoneBCP=0D=0A >=0D=0A >Haha, yes, a browser, or ev= en an app using the raw packet=20=0D=0A >service in a 3GPP GPRS device is = on the Internet, although=20=0D=0A >there are some subtle differences (the= DNS root for=20=0D=0A >example),=0D=0A=0D=0AThese are deployment and oper= ational decisions, which have nothing to do=0D=0Awith the ongoing discussio= n.=0D=0A=0D=0A > but then, a service using that raw packet=20=0D=0A >inte= rface to make, say, an IM to an emergency service would=20=0D=0A >probably= have to make use of the phonebcp procedures, a fact=20=0D=0A >3GPP is stu= diously ignoring.=0D=0A=0D=0A3gpp has defined a set of different procedures= for emergency calls, and=0D=0Acarriers will likely ask vendors to implemen= t as specified. Then users=0D=0Awill also use it as specified.=0D=0A=0D=0A = > I would not go so far as to=20=0D=0A >say most people would prefer the= 3GPP specified procedures=20=0D=0A >vs the IETF phonebcp procedures, espe= cially if they=20=0D=0A >understood the tradeoffs.=0D=0A=0D=0AIt is not a = question of preference. Carriers want to have a solution=0D=0Awhich is reli= able and operational 99.99999% of the cases. It has to be a=0D=0Astricly ma= naged network.=0D=0A=0D=0A >However, a 3GPP mobile telephone service is no= t an Internet=20=0D=0A >service, no matter how you stretch it.=0D=0A=0D=0A= Wow. What is your definition of Internet Service=3F I do remember=0D=0Astat= ements on this mailing list that cellular networks are not IP=0D=0Acapable.= I guess you didn't want to go that far.=0D=0AI access the same content reg= ardless of whether I use the comcast cable=0D=0Aending in the house or t-mo= bile's packet data service anywhere else. The=0D=0Aonly difference is the s= peed and the cost.=20=0D=0ALooks the same to me, no matter how I strech it.=0D= =0A=0D=0A- gabor=0D=0A=0D=0A >Brian=0D=0A >=0D=0A >> -----Original Messa= ge-----=0D=0A >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.c= om]=0D=0A >> Sent: Friday, July 31, 2009 7:20 AM=0D=0A >> To: Brian Rosen= ; 'Elwell, John'; 'Marc Linsner'; 'ecrit'=0D=0A >> Subject: RE: [Ecrit] HU= M on PhoneBCP=0D=0A >>=20=0D=0A >> Just to outline one of the issues.=0D=0A= >>=20=0D=0A >> Take any 3GPP GPRS enabled mobile phone where you have a =0D= =0A >browser open=20=0D=0A >> and it is browsing the general internet. In= your=20=0D=0A >understanding that=20=0D=0A >> would be a device on the I= nternet.=0D=0A >>=20=0D=0A >> However if the user attempts to make an eme= rgency call from that=20=0D=0A >> device, 3GPP specifies that certain thin= gs should happen=20=0D=0A >if the user=20=0D=0A >> happens to press the k= eys associated with making an=20=0D=0A >emergency call,=20=0D=0A >> and t= he device then recognises an emergency call. It then=20=0D=0A >goes on to =0D= =0A >> specify how the emergency call is made from such a device.=20=0D=0A= >That set of=20=0D=0A >> procedures is not the same as specified in phon= ebcp.=0D=0A >>=20=0D=0A >> In this case 3GPP assumes in their specificati= ons that the 3GPP=20=0D=0A >> procedures take precedence, and indeed most = people would=20=0D=0A >consider that=20=0D=0A >> for this particular devi= ce, despite it being a device=20=0D=0A >attached to the=20=0D=0A >> Inter= net, those procedures are the best first mechanism to=20=0D=0A >attempt to= =20=0D=0A >> make an emergency call.=0D=0A >>=20=0D=0A >> regards=0D=0A = >>=20=0D=0A >> Keith=0D=0A >>=20=0D=0A >> > -----Original Message-----=0D= =0A >> > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A >> > Sent: Th= ursday, July 30, 2009 9:22 PM=0D=0A >> > To: DRAGE, Keith (Keith); 'Elwell= , John'; 'Marc Linsner'; 'ecrit'=0D=0A >> > Subject: RE: [Ecrit] HUM on Ph= oneBCP=0D=0A >> >=0D=0A >> > I specified the Internet, and not an interne= t. Usually=20=0D=0A >we mean the=20=0D=0A >> > public Internet. I think= we have a decent definition of=20=0D=0A >that. It=20=0D=0A >> > wouldn'= t cover, for example, a closed network like a =20=0D=0A >IMS call on a=20=0D= =0A >> > cellular 3G network.=0D=0A >> > Might include, however, somethin= g like a call on an IMS=20=0D=0A >network from=20=0D=0A >> > a nomading c= ustomer on some random public access=20=0D=0A >network, depends.=0D=0A >>= >=0D=0A >> > Anyway, I said I was willing to do the edit in a effort to g= ain=20=0D=0A >> > consensus.=0D=0A >> >=0D=0A >> > Brian=0D=0A >> >=0D=0A= >> > > -----Original Message-----=0D=0A >> > > From: DRAGE, Keith (Keith= ) [mailto:drage@alcatel-lucent.com]=0D=0A >> > > Sent: Thursday, July 30, = 2009 4:13 PM=0D=0A >> > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner';= 'ecrit'=0D=0A >> > > Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A >> > >=0D= =0A >> > > I don't believe you can use the word "Internet" to target a=0D=0A= >> > distinct=0D=0A >> > > scope of phonebcp from other SDOs work in thi= s area.=0D=0A >> > >=0D=0A >> > > But I'll follow the argument through if= you really want. Which=20=0D=0A >> > > well known definition of internet = are you using so we=20=0D=0A >start from=0D=0A >> > a common=0D=0A >> > = > baseline=3F=0D=0A >> > >=0D=0A >> > > regards=0D=0A >> > >=0D=0A >> >= > Keith=0D=0A >> > >=0D=0A >> > > > -----Original Message-----=0D=0A >>= > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A >> > > > Sent: T= hursday, July 30, 2009 6:15 PM=0D=0A >> > > > To: 'Elwell, John'; DRAGE, K= eith (Keith); 'Marc=20=0D=0A >Linsner'; 'ecrit'=0D=0A >> > > > Subject: R= E: [Ecrit] HUM on PhoneBCP=0D=0A >> > > >=0D=0A >> > > > The IETF does wo= rk targeted to the Internet. Other SDOs=0D=0A >> > do work on=0D=0A >> > = > > different kinds of networks other than the Internet.=0D=0A >> > > > Th= e document describes best current practice for=0D=0A >> > emergency calls = on=0D=0A >> > > > the Internet.=0D=0A >> > > >=0D=0A >> > > > Brian=0D=0A= >> > > >=0D=0A >> > > > > -----Original Message-----=0D=0A >> > > > > F= rom: ecrit-bounces@ietf.org=0D=0A >> > > > [mailto:ecrit-bounces@ietf.org]= On Behalf=0D=0A >> > > > > Of Elwell, John=0D=0A >> > > > > Sent: Thursd= ay, July 30, 2009 1:02 PM=0D=0A >> > > > > To: DRAGE, Keith (Keith); Marc = Linsner; ecrit=0D=0A >> > > > > Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A= >> > > > >=0D=0A >> > > > >=0D=0A >> > > > >=0D=0A >> > > > > > -----O= riginal Message-----=0D=0A >> > > > > > From: ecrit-bounces@ietf.org=0D=0A= >> > [mailto:ecrit-bounces@ietf.org] On=0D=0A >> > > > > > Behalf Of DRA= GE, Keith (Keith)=0D=0A >> > > > > > Sent: 30 July 2009 09:01=0D=0A >> > = > > > > To: Marc Linsner; 'ecrit'=0D=0A >> > > > > > Subject: Re: [Ecrit] = HUM on PhoneBCP=0D=0A >> > > > > >=0D=0A >> > > > > > I don't agree.=0D=0A= >> > > > > >=0D=0A >> > > > > > Some background.=0D=0A >> > > > > >=0D=0A= >> > > > > > There was a set of comments provided by Stephen Edge on=0D=0A= >> > > > 5th February=0D=0A >> > > > > > 2009. I can find no response to= that set of comments on=0D=0A >> > > > the mailing=0D=0A >> > > > > > li= st.=0D=0A >> > > > > >=0D=0A >> > > > > > The gist of that set of comment= s was that phonebcp claims=0D=0A >> > > > to cover=0D=0A >> > > > > > all= access technologies and it identified a=0D=0A >> > significant number=0D=0A= >> > > > > > of requirements within phonebcp that the author=0D=0A >> > = considered were=0D=0A >> > > > > > not requirements on 3GPP accesses.=0D=0A= >> > > > > >=0D=0A >> > > > > > So my position is that the document is n= ot ready=0D=0A >> > because all the=0D=0A >> > > > > > valid comments on = the document were not addressed.=0D=0A >> > > > > >=0D=0A >> > > > > > Th= ere are two ways of dealing with this set of comments:=0D=0A >> > > > > >=0D= =0A >> > > > > > - going through and modifying all the identified=0D=0A= >> > > > > > requirements where the comment is upheld.=0D=0A >> > > > > = >=0D=0A >> > > > > > - making more clear in the abstract and / or=20=0D= =0A >introduction=0D=0A >> > > > > > that this is solely the view of IETF= in regard to IP=0D=0A >> > > > capable devices=0D=0A >> > > > > > and th= at other organisations may specify other=20=0D=0A >requirements.=0D=0A >>= > > > > >=0D=0A >> > > > > > I would note at this point that the current =0D= =0A >abstract says:=0D=0A >> > > > > >=0D=0A >> > > > > > The IETF an= d other standards organization have efforts=0D=0A >> > > > targeted at=0D=0A= >> > > > > > standardizing various aspects of placing emergency=0D=0A = >> > calls on IP=0D=0A >> > > > > > networks. This memo describes bes= t current=0D=0A >> > practice on how=0D=0A >> > > > > > devices,=0D=0A >= > > > > > > networks and services should use such standards to=0D=0A >>= > > > make emergency=0D=0A >> > > > > > calls.=0D=0A >> > > > > >=0D=0A= >> > > > > > Because the two sentences follow each other, it implies=0D=0A= >> > > > that other=0D=0A >> > > > > > SDOs that have efforts targetted = at addressing these=0D=0A >> > > > solutions are=0D=0A >> > > > > > compl= icit in the requirements so stated, and=20=0D=0A >this is untrue.=0D=0A >= > > > > > [JRE] I agree that this juxtaposition of=20=0D=0A >statements is= rather=20=0D=0A >> > > > > misleading, and would suggest we try to improv= e. In=0D=0A >> > fact the only=0D=0A >> > > > > "other standards organiza= tion" responsible for "such=0D=0A >> > standards"=0D=0A >> > > > > is AN= SI/TIA, since LLDP-MED is the only normative reference=0D=0A >> > > > (and= I would=0D=0A >> > > > > argue that LLDP-MED is not specifically targeted= at=0D=0A >> > > > emergency calls).=0D=0A >> > > > > So perhaps we can r= eword the abstract to say "The IETF has=0D=0A >> > > > efforts..."=0D=0A = >> > > > >=0D=0A >> > > > > John=0D=0A >> > > > >=0D=0A >> > > > >=0D=0A= >> > > > > Certainly the current status of this document=0D=0A >> > > > = > > as addressed by various informal 3GPP discussions is to=0D=0A >> > > >= ensure that=0D=0A >> > > > > > things do not fall apart in entities using= the 3GPP=0D=0A >> > mechanisms,=0D=0A >> > > > > > however 3GPP devices = do not use these requirements=0D=0A >> > (no do these=0D=0A >> > > > > > = requirements represent the 3GPP requires.=0D=0A >> > > > > >=0D=0A >> > >= > > > One solution to the issue would just be to make much=0D=0A >> > > >= clearer which=0D=0A >> > > > > > SDOs have participated in this work and = which have=0D=0A >> > not and the=0D=0A >> > > > > > status of that progr= ess - however that was also what=0D=0A >> > people keep=0D=0A >> > > > > = > calling the "applicability statement" was trying to do.=0D=0A >> > > > >= >=0D=0A >> > > > > > regards=0D=0A >> > > > > >=0D=0A >> > > > > > Keit= h=0D=0A >> > > > > >=0D=0A >> > > > > >=0D=0A >> > > > > >=0D=0A >> > >= > > >=0D=0A >> > > > > > ________________________________=0D=0A >> > > >= > >=0D=0A >> > > > > > =09From: ecrit-bounces@ietf.org=20=0D=0A >> > > >= > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner=0D=0A >> > = > > > > =09Sent: Wednesday, July 29, 2009 2:53 PM=0D=0A >> > > > > > =09To= : 'ecrit'=0D=0A >> > > > > > =09Subject: [Ecrit] HUM on PhoneBCP=0D=0A >>= > > > > >=0D=0A >> > > > > >=0D=0A >> > > > > > =09During today's meetin= g there was discussion as to why=0D=0A >> > > > the chairs=0D=0A >> > > >= > > Publication Requested PhoneBCP version 13 when there are=0D=0A >> > >= > unresolved=0D=0A >> > > > > > issues. This discussion led us to call f= or a hum.=0D=0A >> > We are now=0D=0A >> > > > > > asking the same questi= on on the list.=0D=0A >> > > > > >=0D=0A >> > > > > > =09Do you agree or = disagree that PhoneBCP -13 is ready to=0D=0A >> > > > Publication=0D=0A >= > > > > > > Request=3F=0D=0A >> > > > > >=0D=0A >> > > > > > =09Please re= spond by close of business on Wednesday August=0D=0A >> > > 5th.=0D=0A >>= > > > > >=0D=0A >> > > > > > =09Thanks,=0D=0A >> > > > > >=0D=0A >> > >= > > > =09Marc & Hannes=0D=0A >> > > > > >=0D=0A >> > > > > >=0D=0A >> >= > > > >=0D=0A >> > > > > _______________________________________________=0D= =0A >> > > > > Ecrit mailing list=0D=0A >> > > > > Ecrit@ietf.org=0D=0A = >> > > > > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A >> > > >=0D=0A= >> > > > =3D=0D=0A >> >=0D=0A >> > =3D=0D=0A >=0D=0A >_______________= ________________________________=0D=0A >Ecrit mailing list=0D=0A >Ecrit@i= etf.org=0D=0A >https://www.ietf.org/mailman/listinfo/ecrit=0D=0A >=0D=0A_= ______________________________________________=0D=0AEcrit mailing list=0D=0A= Ecrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A From fmenard@xittel.net Mon Aug 3 23:49:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030DA28C296 for ; Mon, 3 Aug 2009 23:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJmiuyRCKVpm for ; Mon, 3 Aug 2009 23:49:38 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id D25E728C2CB for ; Mon, 3 Aug 2009 23:49:02 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MYDpY-0004ZV-Lq; Tue, 04 Aug 2009 02:49:04 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MYDpX-0002RS-1L; Tue, 04 Aug 2009 02:49:04 -0400 Message-Id: From: Francois Menard To: Marc Linsner In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-6-478403316 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 02:49:02 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 06:49:39 -0000 --Apple-Mail-6-478403316 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hum for me, however, I remember that back in june, John Lange =20 suggested making reference to: http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery-02 Its still missing from version 13... f. On 29-Jul-09, at 9:53 AM, Marc Linsner wrote: > During today=92s meeting there was discussion as to why the chairs =20 > Publication Requested PhoneBCP version 13 when there are unresolved =20= > issues. This discussion led us to call for a hum. We are now =20 > asking the same question on the list. > > Do you agree or disagree that PhoneBCP -13 is ready to Publication =20 > Request? > > Please respond by close of business on Wednesday August 5th. > > Thanks, > > Marc & Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Francois Menard fmenard@xittel.net --Apple-Mail-6-478403316 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hum for me, however, I remember = that back in june, John Lange suggested making reference = to:


Its still missing from version = 13...

f.


=
On 29-Jul-09, at 9:53 AM, Marc Linsner wrote:

= During today=92s meeting there was discussion = as to why the chairs Publication Requested PhoneBCP version 13 when = there are unresolved issues.  This discussion led us to call for a = hum.  We are now asking the same question on the list.

= Do you agree or disagree that PhoneBCP -13 is = ready to Publication Request?

Please respond by close of = business on Wednesday August 5th.

Thanks,

Marc & = Hannes
= _______________________________________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

fmenard@xittel.net


=

= --Apple-Mail-6-478403316-- From hannes.tschofenig@nsn.com Tue Aug 4 00:05:08 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156D428C2DD for ; Tue, 4 Aug 2009 00:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKN12zvmpkRr for ; Tue, 4 Aug 2009 00:05:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id A0EC428C2D1 for ; Tue, 4 Aug 2009 00:03:48 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7473k25009165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2009 09:03:47 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7473jo3010788; Tue, 4 Aug 2009 09:03:46 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 09:03:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA14D1.B57C98D1" Date: Tue, 4 Aug 2009 10:06:16 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019140B9@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoUz8PzJqPTYtWAQnubN46XJNb0AAAAj/RA References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Francois Menard" , "Marc Linsner" X-OriginalArrivalTime: 04 Aug 2009 07:03:45.0736 (UTC) FILETIME=[B562EC80:01CA14D1] Cc: ecrit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 07:05:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA14D1.B57C98D1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Francois,=20 =20 I hope not a normative reference. Right?=20 =20 Ciao Hannes ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Francois Menard Sent: 04 August, 2009 09:49 To: Marc Linsner Cc: 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 Hum for me, however, I remember that back in june, John Lange suggested making reference to:=20 =09 http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery-02 Its still missing from version 13... f. On 29-Jul-09, at 9:53 AM, Marc Linsner wrote: During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. =09 Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? =09 Please respond by close of business on Wednesday August 5th. =09 Thanks, =09 Marc & Hannes =09 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit =09 Francois Menard fmenard@xittel.net ------_=_NextPart_001_01CA14D1.B57C98D1 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Francois,
 
I hope not a normative reference. Right?=20
 
Ciao
Hannes

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Francois=20 Menard
Sent: 04 August, 2009 09:49
To: Marc=20 Linsner
Cc: 'ecrit'
Subject: Re: [Ecrit] HUM on=20 PhoneBCP

Hum for me, however, I remember that back in june, John = Lange=20 suggested making reference to:

http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-disc= overy-02

Its still missing from version 13...

f.



On 29-Jul-09, at 9:53 AM, Marc Linsner wrote:
During today’s meeting there was = discussion as to=20 why the chairs Publication Requested PhoneBCP version 13 when there = are=20 unresolved issues.  This discussion led us to call for a hum. =  We=20 are now asking the same question on the list.

Do=20 you agree or disagree that PhoneBCP -13 is ready to Publication=20 Request?

Please respond by close of business on Wednesday = August=20 5th.

Thanks,

Marc &=20 = Hannes
____________________________________= ___________
Ecrit=20 mailing list
Ecrit@ietf.org
https://www.ietf.org= /mailman/listinfo/ecrit

Francois Menard


------_=_NextPart_001_01CA14D1.B57C98D1-- From fmenard@xittel.net Tue Aug 4 04:40:17 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCC23A6882 for ; Tue, 4 Aug 2009 04:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmy7pJXcFOCl for ; Tue, 4 Aug 2009 04:40:16 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 150E63A6EB4 for ; Tue, 4 Aug 2009 04:39:47 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MYIMv-0002ec-6J; Tue, 04 Aug 2009 07:39:49 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MYIMs-0007uX-Ub; Tue, 04 Aug 2009 07:39:49 -0400 Message-Id: <119F545F-A81B-494F-A3A4-96588FEF7A76@xittel.net> From: Francois Menard To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45019140B9@FIESEXC015.nsn-intra.net> Content-Type: multipart/alternative; boundary=Apple-Mail-1-495846717 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 07:39:46 -0400 References: <3D3C75174CB95F42AD6BCC56E5555B45019140B9@FIESEXC015.nsn-intra.net> X-Mailer: Apple Mail (2.935.3) Cc: ecrit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 11:40:17 -0000 --Apple-Mail-1-495846717 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable I would agree that under a simplified architecture, where the =20 operator's network supports DHCP-based PIDF-LO download, and the end-=20 point supports sipcore-loc-conveyance, that there is no need for a LIS =20= discovery process, so it should not be made mandatory. As per the =20 BCP, the end-point should still have a HELD client built into it, but =20= would not need to use it in this case. Hum is maintained. What does 'entitlement' to publication actually gives... does the BCP =20= still remains a document which will be subject to further revisions? F. On 4-Aug-09, at 3:06 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Francois, > > I hope not a normative reference. Right? > > Ciao > Hannes > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On =20 > Behalf Of ext Francois Menard > Sent: 04 August, 2009 09:49 > To: Marc Linsner > Cc: 'ecrit' > Subject: Re: [Ecrit] HUM on PhoneBCP > > Hum for me, however, I remember that back in june, John Lange =20 > suggested making reference to: > > = http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery-02 > > Its still missing from version 13... > > f. > > > > On 29-Jul-09, at 9:53 AM, Marc Linsner wrote: > >> During today=92s meeting there was discussion as to why the chairs =20= >> Publication Requested PhoneBCP version 13 when there are unresolved =20= >> issues. This discussion led us to call for a hum. We are now =20 >> asking the same question on the list. >> >> Do you agree or disagree that PhoneBCP -13 is ready to Publication =20= >> Request? >> >> Please respond by close of business on Wednesday August 5th. >> >> Thanks, >> >> Marc & Hannes >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > Francois Menard > fmenard@xittel.net > > > Francois Menard fmenard@xittel.net --Apple-Mail-1-495846717 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I would agree that under a = simplified architecture, where the operator's network supports = DHCP-based PIDF-LO download, and the end-point supports = sipcore-loc-conveyance, that there is no need for a LIS discovery = process, so it should not be made mandatory.  As per the BCP, the = end-point should still have a HELD client built into it, but would not = need to use it in this case.

Hum is = maintained.

What does 'entitlement' to = publication actually gives... does the BCP still remains a document = which will be subject to further = revisions?

F.

On = 4-Aug-09, at 3:06 AM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote:

Hi Francois,
 
=
I hope not a normative = reference. Right?
 
Ciao
Hannes

=
From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On Behalf Of ext Francois Menard
Sent: 04 August, = 2009 09:49
To: Marc Linsner
Cc: = 'ecrit'
Subject: Re: [Ecrit] HUM on = PhoneBCP

Hum for me, however, I = remember that back in june, John Lange suggested making reference to: =


Its still missing from version = 13...

f.

=


On 29-Jul-09, at 9:53 AM, Marc = Linsner wrote:

=
During today=92s = meeting there was discussion as to why the chairs Publication = Requested PhoneBCP version 13 when there are unresolved issues. =  This discussion led us to call for a hum.  We are now = asking the same question on the list.

Do = you agree or disagree that PhoneBCP -13 is ready to Publication = Request?

Please respond by close of business on Wednesday August = 5th.

Thanks,

Marc & = Hannes
_____________________________________= __________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

=
Francois Menard
=




Francois Menard


=

= --Apple-Mail-1-495846717-- From Gabor.Bajko@nokia.com Tue Aug 4 11:41:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20A23A6A4D for ; Tue, 4 Aug 2009 11:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 X+9HYmqXJ+AA for ; Tue, 4 Aug 2009 11:41:36 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 47B293A6895 for ; Tue, 4 Aug 2009 11:41:36 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n74IdnUE031231; Tue, 4 Aug 2009 13:41:03 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 21:40:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 21:40:43 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 4 Aug 2009 20:40:43 +0200 From: To: , , , , , Date: Tue, 4 Aug 2009 20:40:39 +0200 Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvg Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Aug 2009 18:40:43.0783 (UTC) FILETIME=[12E28170:01CA1533] X-Nokia-AV: Clean Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 18:41:40 -0000 >-----Original Message----- >From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] >Sent: Monday, August 03, 2009 9:19 PM >To: Bajko Gabor (Nokia-CIC/MtView); br@brianrosen.net; >drage@alcatel-lucent.com; >john.elwell@siemens-enterprise.com; mlinsner@cisco.com; >ecrit@ietf.org >Subject: ECRIT/IMS - independent discussion from the PhoneBCP hum > >I interpret Brian's comment as being that a conventional *switched >circuit* mobile phone service is not the same as an Internet >[call] service. I think that's pretty apparent from the >context. This might have been what Brian meant, but it wasn't obvious for me, especi= ally as circuit switching is not part of 3G (HSPA or LTE), that is 2G. >Would you claim that it is, in fact, the Internet >when a switched circuit call is made Gabor? No, I don't say that. But would you claim that a VoIP call made on a 3G (pa= cket switched) network is not an Internet Service? >Comments about reliability are misleading. Either >architectural solution can be made arbitrarily reliable. Yes, they can. But as we can see, unless it is required by regulation, reli= ability is missing. Carriers operating in licenced bands have to meet certa= in conditions, while a network operating in an unlicenced band is free to t= urn on/off its operation. >Both can be deployed in the context of managed access >according to the requirements applied by the jurisdiction. Certain radio access protocols are inherently unreliable. >There's been a presumption in this debate that somehow ECRIT >needs "apologists" relative to IMS because IMS has a >complete, definitive, and apparently infinitely versatile >definition for handling emergency calls in 3GPP access. ;) I am by far not an IMS evangelist, nor an ECRIT one, so I'd rather stay out= from these kind of debates. What people seem to have trouble understanding is that some networks (eg th= e ones operating in licenced bands) can not afford to rely on the client to= do all the procedures needed to place an emergency call. They need to assi= st the client and make sure the call ends up in the right place. They are l= iable for that. That's the difference. > It >would be reasonable to infer from the representations made >with respect to the IMS model that this definition is clear, >well understood, and unambiguous to those familiar with the >domain. I'd like to explore that premise a little. > >While you're contributing your knowledge to the discussion >then Gabor, could you please elaborate on the detailed >procedures, including which protocols are employed, when an >emergency call is invoked according to 3GPP 23.167? > >I'll grant that, somehow, the UE has recognized the >appropriate E-CSCF in that managed network and now needs to >invoke the emergency service procedures. As the spec points >out, there's the Ml interface to the location routing >function (LRF). Can you please describe the details as >defined by 3GPP from then on? Or, alternatively, could you >point to the detailed procedure specification that explains >what actually occurs? The analogue from the ECRIT >perspective is quite well elaborated, including the use of >LoST for the routing query and the use of candidate LCPs for >the location determination by value and by reference, the >associated conveyance of location value/reference in SIP etc. Brian sent me off-list a pretty comprehensive list of issues where the 3GPP= procedures differ from the ones defined in ECRIT. Since that list is by fa= r more complete than the one I could produce, I will copy paste it below. I= hope Brian doesn't mind it: " At the moment, the major differences between 3GPP and phonebcp are: a) Who inserts location, and what protocols are used b) LoST (3GPP doesn't say LoST can't be used; it basically leaves this as l= ocal practice. Since in North America, LoST will be mandated, that's not a= difference. However, 3GPP would say that LoST, if used, would be queried = by the E-CSCF, and not the endpoint, which differs from -phonebcp c) SIP termination: present 3GPP specs make no provision for packet mode te= rmination. There are some relatively minor signaling issues. To be phonebcp compatible, 3GPP networks would have to implement one of the= -phonebcp LCPs, and provide access to a LoST server. The former is a big = issue, the latter is a small issue." My request was to either restrict the scope of the document to 'Internet', = or make it a requirements document (instead of bcp) with intended status st= andards track. Writing a bcp which excludes the most likely near future pra= ctice looks weird to me. - Gabor >I'm sure IETF participants would appreciate and benefit from >elucidation of just what the 3GPP "secret sauce" is. I don't >want to leave anyone out and, of course, invite other 3GPP >knowledgeable and vocal parties to contribute. > >Cheers, >Martin > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Gabor.Bajko@nokia.com >Sent: Tuesday, 4 August 2009 12:38 AM >To: br@brianrosen.net; drage@alcatel-lucent.com; >john.elwell@siemens-enterprise.com; mlinsner@cisco.com; >ecrit@ietf.org >Subject: Re: [Ecrit] HUM on PhoneBCP > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of ext Brian Rosen > >Sent: Friday, July 31, 2009 5:00 PM > >To: 'DRAGE, Keith (Keith)'; 'Elwell, John'; 'Marc >Linsner'; 'ecrit' > >Subject: Re: [Ecrit] HUM on PhoneBCP > > > >Haha, yes, a browser, or even an app using the raw packet > >service in a 3GPP GPRS device is on the Internet, although > >there are some subtle differences (the DNS root for > >example), > >These are deployment and operational decisions, which have >nothing to do with the ongoing discussion. > > > but then, a service using that raw packet > >interface to make, say, an IM to an emergency service would > >probably have to make use of the phonebcp procedures, a fact > >3GPP is studiously ignoring. > >3gpp has defined a set of different procedures for emergency >calls, and carriers will likely ask vendors to implement as >specified. Then users will also use it as specified. > > > I would not go so far as to > >say most people would prefer the 3GPP specified procedures > >vs the IETF phonebcp procedures, especially if they > >understood the tradeoffs. > >It is not a question of preference. Carriers want to have a >solution which is reliable and operational 99.99999% of the >cases. It has to be a stricly managed network. > > >However, a 3GPP mobile telephone service is not an Internet > >service, no matter how you stretch it. > >Wow. What is your definition of Internet Service? I do >remember statements on this mailing list that cellular >networks are not IP capable. I guess you didn't want to go that far. >I access the same content regardless of whether I use the >comcast cable ending in the house or t-mobile's packet data >service anywhere else. The only difference is the speed and >the cost. >Looks the same to me, no matter how I strech it. > >- gabor > > >Brian > > > >> -----Original Message----- > >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> Sent: Friday, July 31, 2009 7:20 AM > >> To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' > >> Subject: RE: [Ecrit] HUM on PhoneBCP > >> > >> Just to outline one of the issues. > >> > >> Take any 3GPP GPRS enabled mobile phone where you have a > >browser open > >> and it is browsing the general internet. In your > >understanding that > >> would be a device on the Internet. > >> > >> However if the user attempts to make an emergency call from that > >> device, 3GPP specifies that certain things should happen > >if the user > >> happens to press the keys associated with making an > >emergency call, > >> and the device then recognises an emergency call. It then > >goes on to > >> specify how the emergency call is made from such a device. > >That set of > >> procedures is not the same as specified in phonebcp. > >> > >> In this case 3GPP assumes in their specifications that the 3GPP > >> procedures take precedence, and indeed most people would > >consider that > >> for this particular device, despite it being a device > >attached to the > >> Internet, those procedures are the best first mechanism to > >attempt to > >> make an emergency call. > >> > >> regards > >> > >> Keith > >> > >> > -----Original Message----- > >> > From: Brian Rosen [mailto:br@brianrosen.net] > >> > Sent: Thursday, July 30, 2009 9:22 PM > >> > To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc >Linsner'; 'ecrit' > >> > Subject: RE: [Ecrit] HUM on PhoneBCP > >> > > >> > I specified the Internet, and not an internet. Usually > >we mean the > >> > public Internet. I think we have a decent definition of > >that. It > >> > wouldn't cover, for example, a closed network like a > >IMS call on a > >> > cellular 3G network. > >> > Might include, however, something like a call on an IMS > >network from > >> > a nomading customer on some random public access > >network, depends. > >> > > >> > Anyway, I said I was willing to do the edit in a >effort to gain > >> > consensus. > >> > > >> > Brian > >> > > >> > > -----Original Message----- > >> > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> > > Sent: Thursday, July 30, 2009 4:13 PM > >> > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' > >> > > Subject: RE: [Ecrit] HUM on PhoneBCP > >> > > > >> > > I don't believe you can use the word "Internet" to target a > >> > distinct > >> > > scope of phonebcp from other SDOs work in this area. > >> > > > >> > > But I'll follow the argument through if you really >want. Which > >> > > well known definition of internet are you using so we > >start from > >> > a common > >> > > baseline? > >> > > > >> > > regards > >> > > > >> > > Keith > >> > > > >> > > > -----Original Message----- > >> > > > From: Brian Rosen [mailto:br@brianrosen.net] > >> > > > Sent: Thursday, July 30, 2009 6:15 PM > >> > > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc > >Linsner'; 'ecrit' > >> > > > Subject: RE: [Ecrit] HUM on PhoneBCP > >> > > > > >> > > > The IETF does work targeted to the Internet. Other SDOs > >> > do work on > >> > > > different kinds of networks other than the Internet. > >> > > > The document describes best current practice for > >> > emergency calls on > >> > > > the Internet. > >> > > > > >> > > > Brian > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: ecrit-bounces@ietf.org > >> > > > [mailto:ecrit-bounces@ietf.org] On Behalf > >> > > > > Of Elwell, John > >> > > > > Sent: Thursday, July 30, 2009 1:02 PM > >> > > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > >> > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > >> > > > > > >> > > > > > >> > > > > > >> > > > > > -----Original Message----- > >> > > > > > From: ecrit-bounces@ietf.org > >> > [mailto:ecrit-bounces@ietf.org] On > >> > > > > > Behalf Of DRAGE, Keith (Keith) > >> > > > > > Sent: 30 July 2009 09:01 > >> > > > > > To: Marc Linsner; 'ecrit' > >> > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > >> > > > > > > >> > > > > > I don't agree. > >> > > > > > > >> > > > > > Some background. > >> > > > > > > >> > > > > > There was a set of comments provided by >Stephen Edge on > >> > > > 5th February > >> > > > > > 2009. I can find no response to that set of >comments on > >> > > > the mailing > >> > > > > > list. > >> > > > > > > >> > > > > > The gist of that set of comments was that >phonebcp claims > >> > > > to cover > >> > > > > > all access technologies and it identified a > >> > significant number > >> > > > > > of requirements within phonebcp that the author > >> > considered were > >> > > > > > not requirements on 3GPP accesses. > >> > > > > > > >> > > > > > So my position is that the document is not ready > >> > because all the > >> > > > > > valid comments on the document were not addressed. > >> > > > > > > >> > > > > > There are two ways of dealing with this set >of comments: > >> > > > > > > >> > > > > > - going through and modifying all the identified > >> > > > > > requirements where the comment is upheld. > >> > > > > > > >> > > > > > - making more clear in the abstract and / or > >introduction > >> > > > > > that this is solely the view of IETF in regard to IP > >> > > > capable devices > >> > > > > > and that other organisations may specify other > >requirements. > >> > > > > > > >> > > > > > I would note at this point that the current > >abstract says: > >> > > > > > > >> > > > > > The IETF and other standards organization >have efforts > >> > > > targeted at > >> > > > > > standardizing various aspects of placing emergency > >> > calls on IP > >> > > > > > networks. This memo describes best current > >> > practice on how > >> > > > > > devices, > >> > > > > > networks and services should use such standards to > >> > > > make emergency > >> > > > > > calls. > >> > > > > > > >> > > > > > Because the two sentences follow each other, >it implies > >> > > > that other > >> > > > > > SDOs that have efforts targetted at addressing these > >> > > > solutions are > >> > > > > > complicit in the requirements so stated, and > >this is untrue. > >> > > > > [JRE] I agree that this juxtaposition of > >statements is rather > >> > > > > misleading, and would suggest we try to improve. In > >> > fact the only > >> > > > > "other standards organization" responsible for "such > >> > standards" > >> > > > > is ANSI/TIA, since LLDP-MED is the only >normative reference > >> > > > (and I would > >> > > > > argue that LLDP-MED is not specifically targeted at > >> > > > emergency calls). > >> > > > > So perhaps we can reword the abstract to say >"The IETF has > >> > > > efforts..." > >> > > > > > >> > > > > John > >> > > > > > >> > > > > > >> > > > > Certainly the current status of this document > >> > > > > > as addressed by various informal 3GPP >discussions is to > >> > > > ensure that > >> > > > > > things do not fall apart in entities using the 3GPP > >> > mechanisms, > >> > > > > > however 3GPP devices do not use these requirements > >> > (no do these > >> > > > > > requirements represent the 3GPP requires. > >> > > > > > > >> > > > > > One solution to the issue would just be to make much > >> > > > clearer which > >> > > > > > SDOs have participated in this work and which have > >> > not and the > >> > > > > > status of that progress - however that was also what > >> > people keep > >> > > > > > calling the "applicability statement" was >trying to do. > >> > > > > > > >> > > > > > regards > >> > > > > > > >> > > > > > Keith > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > ________________________________ > >> > > > > > > >> > > > > > From: ecrit-bounces@ietf.org > >> > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of >Marc Linsner > >> > > > > > Sent: Wednesday, July 29, 2009 2:53 PM > >> > > > > > To: 'ecrit' > >> > > > > > Subject: [Ecrit] HUM on PhoneBCP > >> > > > > > > >> > > > > > > >> > > > > > During today's meeting there was >discussion as to why > >> > > > the chairs > >> > > > > > Publication Requested PhoneBCP version 13 >when there are > >> > > > unresolved > >> > > > > > issues. This discussion led us to call for a hum. > >> > We are now > >> > > > > > asking the same question on the list. > >> > > > > > > >> > > > > > Do you agree or disagree that PhoneBCP >-13 is ready to > >> > > > Publication > >> > > > > > Request? > >> > > > > > > >> > > > > > Please respond by close of business on >Wednesday August > >> > > 5th. > >> > > > > > > >> > > > > > Thanks, > >> > > > > > > >> > > > > > Marc & Hannes > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > _______________________________________________ > >> > > > > Ecrit mailing list > >> > > > > Ecrit@ietf.org > >> > > > > https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > >> > > > =3D > >> > > >> > =3D > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > >------------------------------------------------------------- >----------------------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use >of this email is prohibited. >------------------------------------------------------------- >----------------------------------- >[mf2] > > From James.Winterbottom@andrew.com Tue Aug 4 16:12:00 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB033A710E for ; Tue, 4 Aug 2009 16:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVG+ABqOxUJE for ; Tue, 4 Aug 2009 16:11:58 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3DE4D3A7103 for ; Tue, 4 Aug 2009 16:11:58 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_04_18_34_40 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 04 Aug 2009 18:34:40 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 18:12:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 18:11:58 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAAtaVdo= References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net> From: "Winterbottom, James" To: , "Dawson, Martin" , , , , , X-OriginalArrivalTime: 04 Aug 2009 23:12:00.0343 (UTC) FILETIME=[F8787670:01CA1558] Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 23:12:00 -0000 Hi Gabor,=0D=0A=0D=0AI would like to point out what I see as a problem in y= our reasoning, and to do that I will use the analogy of a DSL service.=0D=0A=0D= =0AFirstly, I agree with you that 3G SHOULD be regarded as just another Int= ernet access technology, the fact that certain applications are unreasonabl= y disabled by the providers of these access services aside.=0D=0A=0D=0AWhen= I buy a wireline broadband service I buy that service form an ISP. That pr= ovider may or may not have any underlying access infrastructure of their ow= n, certainly in Australia it is very likely that they whole the access from= the large carrier here. I can then go to one of many of the independent Vo= IP service providers and buy a service from them that I expect to just work= over my newly bought wireline Internet access service.=0D=0A=0D=0AYour arg= ument seems to be that this model can't apply to the 3G space because the u= nderlying access provider is somehow obliged to route emergency calls.=20=0D= =0A=0D=0AMy counter argument is this, that the 3G carrier is no more oblige= d to route these calls than the ISP or the underlying copper wire owner in = my DSL example. The content of my packets should be largely invisible to th= e access provider. This is what happens with other broadband technologies o= perating in licensed spectrum, why is 3GPP somehow special here=3F =20=0D=0A=0D= =0AI believe that your argument doesn't apply if the service is just a broa= dband pipe, it only applies if I also buy other things such as a voice serv= ice from the operator.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org on be= half of Gabor.Bajko@nokia.com=0D=0ASent: Tue 8/4/2009 1:40 PM=0D=0ATo: Daws= on, Martin; br@brianrosen.net; drage@alcatel-lucent.com; john.elwell@siemen= s-enterprise.com; mlinsner@cisco.com; ecrit@ietf.org=0D=0ASubject: Re: [Ecr= it] ECRIT/IMS - independent discussion from the PhoneBCP hum=0D=0A=20=0D=0A=0D= =0A=0D=0A >-----Original Message-----=0D=0A >From: ext Dawson, Martin [ma= ilto:Martin.Dawson@andrew.com]=0D=0A >Sent: Monday, August 03, 2009 9:19 P= M=0D=0A >To: Bajko Gabor (Nokia-CIC/MtView); br@brianrosen.net;=0D=0A >dr= age@alcatel-lucent.com;=0D=0A >john.elwell@siemens-enterprise.com; mlinsne= r@cisco.com;=0D=0A >ecrit@ietf.org=0D=0A >Subject: ECRIT/IMS - independen= t discussion from the PhoneBCP hum=0D=0A >=0D=0A >I interpret Brian's com= ment as being that a conventional *switched=0D=0A >circuit* mobile phone s= ervice is not the same as an Internet=0D=0A >[call] service. I think that'= s pretty apparent from the=0D=0A >context.=0D=0A=0D=0AThis might have been= what Brian meant, but it wasn't obvious for me, especially as circuit swit= ching is not part of 3G (HSPA or LTE), that is 2G.=0D=0A=0D=0A >Would you = claim that it is, in fact, the Internet=0D=0A >when a switched circuit cal= l is made Gabor=3F=0D=0A=0D=0ANo, I don't say that. But would you claim tha= t a VoIP call made on a 3G (packet switched) network is not an Internet Ser= vice=3F=0D=0A=0D=0A >Comments about reliability are misleading. Either=0D=0A= >architectural solution can be made arbitrarily reliable.=0D=0A=0D=0AYes,= they can. But as we can see, unless it is required by regulation, reliabil= ity is missing. Carriers operating in licenced bands have to meet certain c= onditions, while a network operating in an unlicenced band is free to turn = on/off its operation.=0D=0A=0D=0A >Both can be deployed in the context of = managed access=0D=0A >according to the requirements applied by the jurisdi= ction.=0D=0A=0D=0ACertain radio access protocols are inherently unreliable.=0D= =0A=0D=0A >There's been a presumption in this debate that somehow ECRIT=0D= =0A >needs "apologists" relative to IMS because IMS has a=0D=0A >complete= , definitive, and apparently infinitely versatile=0D=0A >definition for ha= ndling emergency calls in 3GPP access.=0D=0A=0D=0A;)=0D=0AI am by far not a= n IMS evangelist, nor an ECRIT one, so I'd rather stay out from these kind = of debates.=0D=0AWhat people seem to have trouble understanding is that som= e networks (eg the ones operating in licenced bands) can not afford to rely= on the client to do all the procedures needed to place an emergency call. = They need to assist the client and make sure the call ends up in the right = place. They are liable for that. That's the difference.=0D=0A=0D=0A > It=0D= =0A >would be reasonable to infer from the representations made=0D=0A >wi= th respect to the IMS model that this definition is clear,=0D=0A >well und= erstood, and unambiguous to those familiar with the=0D=0A >domain. I'd lik= e to explore that premise a little.=0D=0A >=0D=0A >While you're contribut= ing your knowledge to the discussion=0D=0A >then Gabor, could you please e= laborate on the detailed=0D=0A >procedures, including which protocols are = employed, when an=0D=0A >emergency call is invoked according to 3GPP 23.16= 7=3F=0D=0A >=0D=0A >I'll grant that, somehow, the UE has recognized the=0D= =0A >appropriate E-CSCF in that managed network and now needs to=0D=0A >i= nvoke the emergency service procedures. As the spec points=0D=0A >out, the= re's the Ml interface to the location routing=0D=0A >function (LRF). Can y= ou please describe the details as=0D=0A >defined by 3GPP from then on=3F O= r, alternatively, could you=0D=0A >point to the detailed procedure specifi= cation that explains=0D=0A >what actually occurs=3F The analogue from the = ECRIT=0D=0A >perspective is quite well elaborated, including the use of=0D= =0A >LoST for the routing query and the use of candidate LCPs for=0D=0A >= the location determination by value and by reference, the=0D=0A >associate= d conveyance of location value/reference in SIP etc.=0D=0A=0D=0ABrian sent = me off-list a pretty comprehensive list of issues where the 3GPP procedures= differ from the ones defined in ECRIT. Since that list is by far more comp= lete than the one I could produce, I will copy paste it below. I hope Brian= doesn't mind it:=0D=0A=0D=0A" At the moment, the major differences between= 3GPP and phonebcp are:=0D=0Aa) Who inserts location, and what protocols ar= e used=0D=0Ab) LoST (3GPP doesn't say LoST can't be used; it basically leav= es this as local practice. Since in North America, LoST will be mandated, = that's not a difference. However, 3GPP would say that LoST, if used, would= be queried by the E-CSCF, and not the endpoint, which differs from -phoneb= cp=0D=0Ac) SIP termination: present 3GPP specs make no provision for packet= mode termination.=0D=0A=0D=0AThere are some relatively minor signaling iss= ues.=0D=0A=0D=0ATo be phonebcp compatible, 3GPP networks would have to impl= ement one of the -phonebcp LCPs, and provide access to a LoST server. The = former is a big issue, the latter is a small issue."=0D=0A=0D=0A=0D=0AMy re= quest was to either restrict the scope of the document to 'Internet', or ma= ke it a requirements document (instead of bcp) with intended status standar= ds track. Writing a bcp which excludes the most likely near future practice= looks weird to me.=0D=0A=0D=0A- Gabor=0D=0A=0D=0A=0D=0A >I'm sure IETF pa= rticipants would appreciate and benefit from=0D=0A >elucidation of just wh= at the 3GPP "secret sauce" is. I don't=0D=0A >want to leave anyone out and= , of course, invite other 3GPP=0D=0A >knowledgeable and vocal parties to c= ontribute.=0D=0A >=0D=0A >Cheers,=0D=0A >Martin=0D=0A >=0D=0A >-----Or= iginal Message-----=0D=0A >From: ecrit-bounces@ietf.org [mailto:ecrit-boun= ces@ietf.org]=0D=0A >On Behalf Of Gabor.Bajko@nokia.com=0D=0A >Sent: Tues= day, 4 August 2009 12:38 AM=0D=0A >To: br@brianrosen.net; drage@alcatel-lu= cent.com;=0D=0A >john.elwell@siemens-enterprise.com; mlinsner@cisco.com;=0D= =0A >ecrit@ietf.org=0D=0A >Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A >=0D= =0A >=0D=0A >=0D=0A > >-----Original Message-----=0D=0A > >From: ecri= t-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=0D=0A > >On Behalf Of = ext Brian Rosen=0D=0A > >Sent: Friday, July 31, 2009 5:00 PM=0D=0A > >T= o: 'DRAGE, Keith (Keith)'; 'Elwell, John'; 'Marc=0D=0A >Linsner'; 'ecrit'=0D= =0A > >Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A > >=0D=0A > >Haha, = yes, a browser, or even an app using the raw packet=0D=0A > >service in a= 3GPP GPRS device is on the Internet, although=0D=0A > >there are some su= btle differences (the DNS root for=0D=0A > >example),=0D=0A >=0D=0A >Th= ese are deployment and operational decisions, which have=0D=0A >nothing to= do with the ongoing discussion.=0D=0A >=0D=0A > > but then, a service u= sing that raw packet=0D=0A > >interface to make, say, an IM to an emergen= cy service would=0D=0A > >probably have to make use of the phonebcp proce= dures, a fact=0D=0A > >3GPP is studiously ignoring.=0D=0A >=0D=0A >3gpp= has defined a set of different procedures for emergency=0D=0A >calls, and= carriers will likely ask vendors to implement as=0D=0A >specified. Then u= sers will also use it as specified.=0D=0A >=0D=0A > > I would not go so= far as to=0D=0A > >say most people would prefer the 3GPP specified proce= dures=0D=0A > >vs the IETF phonebcp procedures, especially if they=0D=0A = > >understood the tradeoffs.=0D=0A >=0D=0A >It is not a question of pre= ference. Carriers want to have a=0D=0A >solution which is reliable and ope= rational 99.99999% of the=0D=0A >cases. It has to be a stricly managed net= work.=0D=0A >=0D=0A > >However, a 3GPP mobile telephone service is not a= n Internet=0D=0A > >service, no matter how you stretch it.=0D=0A >=0D=0A= >Wow. What is your definition of Internet Service=3F I do=0D=0A >remembe= r statements on this mailing list that cellular=0D=0A >networks are not IP= capable. I guess you didn't want to go that far.=0D=0A >I access the same= content regardless of whether I use the=0D=0A >comcast cable ending in th= e house or t-mobile's packet data=0D=0A >service anywhere else. The only d= ifference is the speed and=0D=0A >the cost.=0D=0A >Looks the same to me, = no matter how I strech it.=0D=0A >=0D=0A >- gabor=0D=0A >=0D=0A > >Bri= an=0D=0A > >=0D=0A > >> -----Original Message-----=0D=0A > >> From: D= RAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=0D=0A > >> Sent: Fr= iday, July 31, 2009 7:20 AM=0D=0A > >> To: Brian Rosen; 'Elwell, John'; '= Marc Linsner'; 'ecrit'=0D=0A > >> Subject: RE: [Ecrit] HUM on PhoneBCP=0D= =0A > >>=0D=0A > >> Just to outline one of the issues.=0D=0A > >>=0D=0A= > >> Take any 3GPP GPRS enabled mobile phone where you have a=0D=0A > = >browser open=0D=0A > >> and it is browsing the general internet. In your=0D= =0A > >understanding that=0D=0A > >> would be a device on the Internet.=0D= =0A > >>=0D=0A > >> However if the user attempts to make an emergency c= all from that=0D=0A > >> device, 3GPP specifies that certain things shoul= d happen=0D=0A > >if the user=0D=0A > >> happens to press the keys asso= ciated with making an=0D=0A > >emergency call,=0D=0A > >> and the devic= e then recognises an emergency call. It then=0D=0A > >goes on to=0D=0A >= >> specify how the emergency call is made from such a device.=0D=0A > >= That set of=0D=0A > >> procedures is not the same as specified in phonebc= p.=0D=0A > >>=0D=0A > >> In this case 3GPP assumes in their specificati= ons that the 3GPP=0D=0A > >> procedures take precedence, and indeed most = people would=0D=0A > >consider that=0D=0A > >> for this particular devi= ce, despite it being a device=0D=0A > >attached to the=0D=0A > >> Inter= net, those procedures are the best first mechanism to=0D=0A > >attempt to=0D= =0A > >> make an emergency call.=0D=0A > >>=0D=0A > >> regards=0D=0A = > >>=0D=0A > >> Keith=0D=0A > >>=0D=0A > >> > -----Original Message= -----=0D=0A > >> > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A > = >> > Sent: Thursday, July 30, 2009 9:22 PM=0D=0A > >> > To: DRAGE, Keith= (Keith); 'Elwell, John'; 'Marc=0D=0A >Linsner'; 'ecrit'=0D=0A > >> > Su= bject: RE: [Ecrit] HUM on PhoneBCP=0D=0A > >> >=0D=0A > >> > I specifie= d the Internet, and not an internet. Usually=0D=0A > >we mean the=0D=0A = > >> > public Internet. I think we have a decent definition of=0D=0A > = >that. It=0D=0A > >> > wouldn't cover, for example, a closed network li= ke a=0D=0A > >IMS call on a=0D=0A > >> > cellular 3G network.=0D=0A > = >> > Might include, however, something like a call on an IMS=0D=0A > >ne= twork from=0D=0A > >> > a nomading customer on some random public access=0D= =0A > >network, depends.=0D=0A > >> >=0D=0A > >> > Anyway, I said I w= as willing to do the edit in a=0D=0A >effort to gain=0D=0A > >> > consen= sus.=0D=0A > >> >=0D=0A > >> > Brian=0D=0A > >> >=0D=0A > >> > > --= ---Original Message-----=0D=0A > >> > > From: DRAGE, Keith (Keith) [mailt= o:drage@alcatel-lucent.com]=0D=0A > >> > > Sent: Thursday, July 30, 2009 = 4:13 PM=0D=0A > >> > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; '= ecrit'=0D=0A > >> > > Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A > >> >= >=0D=0A > >> > > I don't believe you can use the word "Internet" to targ= et a=0D=0A > >> > distinct=0D=0A > >> > > scope of phonebcp from other = SDOs work in this area.=0D=0A > >> > >=0D=0A > >> > > But I'll follow t= he argument through if you really=0D=0A >want. Which=0D=0A > >> > > well= known definition of internet are you using so we=0D=0A > >start from=0D=0A= > >> > a common=0D=0A > >> > > baseline=3F=0D=0A > >> > >=0D=0A > = >> > > regards=0D=0A > >> > >=0D=0A > >> > > Keith=0D=0A > >> > >=0D=0A= > >> > > > -----Original Message-----=0D=0A > >> > > > From: Brian Ros= en [mailto:br@brianrosen.net]=0D=0A > >> > > > Sent: Thursday, July 30, 2= 009 6:15 PM=0D=0A > >> > > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'M= arc=0D=0A > >Linsner'; 'ecrit'=0D=0A > >> > > > Subject: RE: [Ecrit] HU= M on PhoneBCP=0D=0A > >> > > >=0D=0A > >> > > > The IETF does work targ= eted to the Internet. Other SDOs=0D=0A > >> > do work on=0D=0A > >> > >= > different kinds of networks other than the Internet.=0D=0A > >> > > > = The document describes best current practice for=0D=0A > >> > emergency c= alls on=0D=0A > >> > > > the Internet.=0D=0A > >> > > >=0D=0A > >> > = > > Brian=0D=0A > >> > > >=0D=0A > >> > > > > -----Original Message----= -=0D=0A > >> > > > > From: ecrit-bounces@ietf.org=0D=0A > >> > > > [mai= lto:ecrit-bounces@ietf.org] On Behalf=0D=0A > >> > > > > Of Elwell, John=0D= =0A > >> > > > > Sent: Thursday, July 30, 2009 1:02 PM=0D=0A > >> > > >= > To: DRAGE, Keith (Keith); Marc Linsner; ecrit=0D=0A > >> > > > > Subje= ct: Re: [Ecrit] HUM on PhoneBCP=0D=0A > >> > > > >=0D=0A > >> > > > >=0D= =0A > >> > > > >=0D=0A > >> > > > > > -----Original Message-----=0D=0A = > >> > > > > > From: ecrit-bounces@ietf.org=0D=0A > >> > [mailto:ecrit-= bounces@ietf.org] On=0D=0A > >> > > > > > Behalf Of DRAGE, Keith (Keith)=0D= =0A > >> > > > > > Sent: 30 July 2009 09:01=0D=0A > >> > > > > > To: Ma= rc Linsner; 'ecrit'=0D=0A > >> > > > > > Subject: Re: [Ecrit] HUM on Phon= eBCP=0D=0A > >> > > > > >=0D=0A > >> > > > > > I don't agree.=0D=0A > = >> > > > > >=0D=0A > >> > > > > > Some background.=0D=0A > >> > > > > = >=0D=0A > >> > > > > > There was a set of comments provided by=0D=0A >St= ephen Edge on=0D=0A > >> > > > 5th February=0D=0A > >> > > > > > 2009. = I can find no response to that set of=0D=0A >comments on=0D=0A > >> > > = > the mailing=0D=0A > >> > > > > > list.=0D=0A > >> > > > > >=0D=0A > = >> > > > > > The gist of that set of comments was that=0D=0A >phonebcp cl= aims=0D=0A > >> > > > to cover=0D=0A > >> > > > > > all access technolo= gies and it identified a=0D=0A > >> > significant number=0D=0A > >> > >= > > > of requirements within phonebcp that the author=0D=0A > >> > consi= dered were=0D=0A > >> > > > > > not requirements on 3GPP accesses.=0D=0A = > >> > > > > >=0D=0A > >> > > > > > So my position is that the document= is not ready=0D=0A > >> > because all the=0D=0A > >> > > > > > valid c= omments on the document were not addressed.=0D=0A > >> > > > > >=0D=0A >= >> > > > > > There are two ways of dealing with this set=0D=0A >of comme= nts:=0D=0A > >> > > > > >=0D=0A > >> > > > > > - going through and m= odifying all the identified=0D=0A > >> > > > > > requirements where the c= omment is upheld.=0D=0A > >> > > > > >=0D=0A > >> > > > > > - making= more clear in the abstract and / or=0D=0A > >introduction=0D=0A > >> >= > > > > that this is solely the view of IETF in regard to IP=0D=0A > >> = > > > capable devices=0D=0A > >> > > > > > and that other organisations m= ay specify other=0D=0A > >requirements.=0D=0A > >> > > > > >=0D=0A > = >> > > > > > I would note at this point that the current=0D=0A > >abstrac= t says:=0D=0A > >> > > > > >=0D=0A > >> > > > > > The IETF and other= standards organization=0D=0A >have efforts=0D=0A > >> > > > targeted at=0D= =0A > >> > > > > > standardizing various aspects of placing emergency=0D= =0A > >> > calls on IP=0D=0A > >> > > > > > networks. This memo des= cribes best current=0D=0A > >> > practice on how=0D=0A > >> > > > > > d= evices,=0D=0A > >> > > > > > networks and services should use such sta= ndards to=0D=0A > >> > > > make emergency=0D=0A > >> > > > > > calls= =2E=0D=0A > >> > > > > >=0D=0A > >> > > > > > Because the two sentences= follow each other,=0D=0A >it implies=0D=0A > >> > > > that other=0D=0A = > >> > > > > > SDOs that have efforts targetted at addressing these=0D=0A= > >> > > > solutions are=0D=0A > >> > > > > > complicit in the require= ments so stated, and=0D=0A > >this is untrue.=0D=0A > >> > > > > [JRE] = I agree that this juxtaposition of=0D=0A > >statements is rather=0D=0A >= >> > > > > misleading, and would suggest we try to improve. In=0D=0A > = >> > fact the only=0D=0A > >> > > > > "other standards organization" res= ponsible for "such=0D=0A > >> > standards"=0D=0A > >> > > > > is ANSI/T= IA, since LLDP-MED is the only=0D=0A >normative reference=0D=0A > >> > >= > (and I would=0D=0A > >> > > > > argue that LLDP-MED is not specificall= y targeted at=0D=0A > >> > > > emergency calls).=0D=0A > >> > > > > So = perhaps we can reword the abstract to say=0D=0A >"The IETF has=0D=0A > >= > > > > efforts..."=0D=0A > >> > > > >=0D=0A > >> > > > > John=0D=0A >= >> > > > >=0D=0A > >> > > > >=0D=0A > >> > > > > Certainly the curren= t status of this document=0D=0A > >> > > > > > as addressed by various in= formal 3GPP=0D=0A >discussions is to=0D=0A > >> > > > ensure that=0D=0A = > >> > > > > > things do not fall apart in entities using the 3GPP=0D=0A = > >> > mechanisms,=0D=0A > >> > > > > > however 3GPP devices do not use= these requirements=0D=0A > >> > (no do these=0D=0A > >> > > > > > requ= irements represent the 3GPP requires.=0D=0A > >> > > > > >=0D=0A > >> >= > > > > One solution to the issue would just be to make much=0D=0A > >> = > > > clearer which=0D=0A > >> > > > > > SDOs have participated in this w= ork and which have=0D=0A > >> > not and the=0D=0A > >> > > > > > status= of that progress - however that was also what=0D=0A > >> > people keep=0D= =0A > >> > > > > > calling the "applicability statement" was=0D=0A >tryi= ng to do.=0D=0A > >> > > > > >=0D=0A > >> > > > > > regards=0D=0A > >= > > > > > >=0D=0A > >> > > > > > Keith=0D=0A > >> > > > > >=0D=0A > >= > > > > > >=0D=0A > >> > > > > >=0D=0A > >> > > > > >=0D=0A > >> > > = > > > ________________________________=0D=0A > >> > > > > >=0D=0A > >> = > > > > > From: ecrit-bounces@ietf.org=0D=0A > >> > > > > > [mailto= :ecrit-bounces@ietf.org] On Behalf Of=0D=0A >Marc Linsner=0D=0A > >> > >= > > > Sent: Wednesday, July 29, 2009 2:53 PM=0D=0A > >> > > > > > = To: 'ecrit'=0D=0A > >> > > > > > Subject: [Ecrit] HUM on Phon= eBCP=0D=0A > >> > > > > >=0D=0A > >> > > > > >=0D=0A > >> > > > > > = During today's meeting there was=0D=0A >discussion as to why=0D=0A >= >> > > > the chairs=0D=0A > >> > > > > > Publication Requested PhoneBCP= version 13=0D=0A >when there are=0D=0A > >> > > > unresolved=0D=0A > = >> > > > > > issues. This discussion led us to call for a hum.=0D=0A > >= > > We are now=0D=0A > >> > > > > > asking the same question on the list.=0D= =0A > >> > > > > >=0D=0A > >> > > > > > Do you agree or disagree = that PhoneBCP=0D=0A >-13 is ready to=0D=0A > >> > > > Publication=0D=0A = > >> > > > > > Request=3F=0D=0A > >> > > > > >=0D=0A > >> > > > > > = Please respond by close of business on=0D=0A >Wednesday August=0D=0A = > >> > > 5th.=0D=0A > >> > > > > >=0D=0A > >> > > > > > Thanks,=0D= =0A > >> > > > > >=0D=0A > >> > > > > > Marc & Hannes=0D=0A > >= > > > > > >=0D=0A > >> > > > > >=0D=0A > >> > > > > >=0D=0A > >> > > = > > _______________________________________________=0D=0A > >> > > > > Ec= rit mailing list=0D=0A > >> > > > > Ecrit@ietf.org=0D=0A > >> > > > > h= ttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A > >> > > >=0D=0A > >> = > > > =3D=0D=0A > >> >=0D=0A > >> > =3D=0D=0A > >=0D=0A > >________= _______________________________________=0D=0A > >Ecrit mailing list=0D=0A= > >Ecrit@ietf.org=0D=0A > >https://www.ietf.org/mailman/listinfo/ecrit=0D= =0A > >=0D=0A >_______________________________________________=0D=0A >E= crit mailing list=0D=0A >Ecrit@ietf.org=0D=0A >https://www.ietf.org/mailm= an/listinfo/ecrit=0D=0A >=0D=0A >----------------------------------------= ---------------------=0D=0A >-----------------------------------=0D=0A >T= his message is for the designated recipient only and may=0D=0A >contain pr= ivileged, proprietary, or otherwise private information.=0D=0A >If you hav= e received it in error, please notify the sender=0D=0A >immediately and de= lete the original. Any unauthorized use=0D=0A >of this email is prohibite= d.=0D=0A >-------------------------------------------------------------=0D= =0A >-----------------------------------=0D=0A >[mf2]=0D=0A >=0D=0A >=0D= =0A_______________________________________________=0D=0AEcrit mailing list=0D= =0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A From R.Jesske@telekom.de Wed Aug 5 01:19:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CDE28C4ED for ; Wed, 5 Aug 2009 01:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBqfe1c437+k for ; Wed, 5 Aug 2009 01:19:34 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 9756C3A6E10 for ; Wed, 5 Aug 2009 01:18:36 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 05 Aug 2009 10:18:34 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 10:18:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA15A5.52B1EF79" Date: Wed, 5 Aug 2009 10:18:32 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDsw From: To: X-OriginalArrivalTime: 05 Aug 2009 08:18:33.0637 (UTC) FILETIME=[52CC0550:01CA15A5] Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 08:19:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA15A5.52B1EF79 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Dear all, > We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling = based on location-by-reference and ED> '> s IP-address.=20 > But we can not HUM for the current form of the document.=20 >=20 > Back to the document: Some requirements are far form being realistic, = at least in Germany, some are not realistic at all. Implementing these = requirements cost a carrier a lot of money and there is no ROI for it.=20 >=20 > Just a few examples:=20 >=20 > =B7 Requiring either geo or civic location does not provide carriers = with enough flexibility to reuse their existing mechanisms and location = databases. Routing of emergency calls is currently done in Germany based = on phone area code not on geo or civic location, at least for the fixed = network. For mobile networks the cell-id is used in common. This is = regulated by the german regulator.=20 > 1 LOST as a national, let alone as a global directory is not going to = be implemented. The regulator will provide in the web a static table = which contains the PSAPs and the area for which they are responsible = (one or more area codes). Every carrier has to implement its own routing = database for emergency calls.=20 > 2 We have no intention to rely on end devices for location information = because:=20 > =B7 ED provided location info is not trusted=20 > 1 There are already a lot of existing EDs in usage which don> '> t = send location. =20 > We don> '> t intend to require our ED-vendors to provide location = because it is useless to us. =20 >=20 > We could agree with the document with following changes: > * Other location identifiers then geo or civil are allowed. It must be = possibe that the data foermat is flexible due to different requirements = from regulators over the whole world. (e.G Germany area codes for fixed- = and Cell-Id for moile- providers) > * The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed=20 > * It must be possible for the VoIP-provider> '> s proxy to use a LOST = (or an ESRP) provided by the AN or by other local provider on behalf of = the AN. =20 >=20 > There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. = Currently, neither the IETF- nor the 3GPP-architecture for emergency = calling covers our real needs for the next 2 to 5 years and in the end = everybody still has its own proprietary implementation. =20 >=20 > Best regards >=20 > Roland >=20 >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Zentrum Technik Einf=FChrung=20 > Roland Jesske=20 > Gateways, Protokolle, Konvergenz, TE32-1 > Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,=20 > Postfach, 64307 Darmstadt (Postanschrift)=20 > +496151 628 2766 (Tel) > +491718618445 (Mobile)=20 > E-Mail: r.jesske@telekom.de=20 > http://www.telekom.de =20 >=20 >=20 >=20 > Registerrechtliche Unternehmensangaben: > Deutsche Telekom Netzproduktion (DT NP) GmbH > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 >=20 >=20 ------_=_NextPart_001_01CA15A5.52B1EF79 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP

Dear all,
We would like the document to become a BCP as soon as possible so = the group can move on with other documents related to emergency calling = based on location-by-reference and ED’s IP-address. =

But we can not HUM for the current form of the document. =

Back to the document: Some requirements are far form being = realistic, at least in Germany, some are not realistic at all. = Implementing these requirements cost a carrier a lot of money and there = is no ROI for it.

Just a few examples:

=B7       Requiring either geo or civic = location does not provide carriers with enough flexibility to reuse = their existing mechanisms and location databases. Routing of emergency = calls is currently done in Germany based on phone area code not on geo = or civic location, at least for the fixed network. For mobile networks = the cell-id is used in common. This is regulated by the german = regulator.

1       LOST as a national, let = alone as a global directory is not going to be implemented. The = regulator will provide in the web a static table which contains the = PSAPs and the area for which they are responsible (one or more area = codes). Every carrier has to implement its own routing database for = emergency calls.

2       We have no intention to = rely on end devices for location information because:
=B7       ED provided location info is = not trusted
1       There are already a lot of = existing EDs in usage which don’t send location.    =

      We don’t intend to require our ED-vendors to provide = location because it is useless to us.  

We could agree with the document with following = changes:

    • Other location identifiers then geo or civil are allowed. It must = be possibe that the data foermat is flexible due to different = requirements from regulators over the whole world. (e.G Germany area = codes for fixed- and Cell-Id for moile- providers)
    • The MUST for the end devices to support location information, = DHCP location options and HELD shall be removed
    • It must be possible for the VoIP-provider’s proxy to use a = LOST (or an ESRP) provided by the AN or by other local provider on = behalf of the AN. 

 There is no value in Hum-ing documents which one is not = going to implement and does not fit into regulated schemes like in = Germany. Currently, neither the IETF- nor the 3GPP-architecture for = emergency calling covers our real needs for the next 2 to 5 years and in = the end everybody still has its own proprietary = implementation.   

Best regards

Roland


Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Gateways, Protokolle, Konvergenz, = TE32-1
Heinrich-Hertz-Str. 3-7, 64295 = Darmstadt,
Postfach, 64307 Darmstadt = (Postanschrift)
+496151 628 2766 (Tel)
+491718618445 (Mobile)
E-Mail: r.jesske@telekom.de
http://www.telekom.de =



Registerrechtliche = Unternehmensangaben:
Deutsche Telekom Netzproduktion (DT NP) = GmbH
Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), = Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262


------_=_NextPart_001_01CA15A5.52B1EF79-- From Martin.Dawson@andrew.com Tue Aug 4 18:37:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E243A712D for ; Tue, 4 Aug 2009 18:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ87Ev479oGW for ; Tue, 4 Aug 2009 18:37:23 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id CEFE23A70FA for ; Tue, 4 Aug 2009 18:37:22 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_04_21_00_04 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 04 Aug 2009 21:00:02 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 20:37:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA156D.4735074C" Date: Tue, 4 Aug 2009 20:37:19 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42A= References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net> From: "Dawson, Martin" To: , , , , , X-OriginalArrivalTime: 05 Aug 2009 01:37:22.0941 (UTC) FILETIME=[478B4AD0:01CA156D] X-Mailman-Approved-At: Wed, 05 Aug 2009 01:28:54 -0700 Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 01:37:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA156D.4735074C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20=0D=0A=0D=0A=20=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Gabor.B= ajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20=0D=0ASent: Wednesday, 5 Au= gust 2009 4:41 AM=0D=0ATo: Dawson, Martin; br@brianrosen.net; drage@alcatel= -lucent.com;=0D=0Ajohn.elwell@siemens-enterprise.com; mlinsner@cisco.com; e= crit@ietf.org=0D=0ASubject: RE: ECRIT/IMS - independent discussion from the= PhoneBCP hum=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A >--= ---Original Message-----=0D=0A=0D=0A >From: ext Dawson, Martin [mailto:Mar= tin.Dawson@andrew.com]=0D=0A=0D=0A >Sent: Monday, August 03, 2009 9:19 PM=0D= =0A=0D=0A >To: Bajko Gabor (Nokia-CIC/MtView); br@brianrosen.net;=0D=0A=0D= =0A >drage@alcatel-lucent.com;=0D=0A=0D=0A >john.elwell@siemens-enterpris= e.com; mlinsner@cisco.com;=0D=0A=0D=0A >ecrit@ietf.org=0D=0A=0D=0A >Subje= ct: ECRIT/IMS - independent discussion from the PhoneBCP hum=0D=0A=0D=0A >=0D= =0A=0D=0A >I interpret Brian's comment as being that a conventional *switc= hed=0D=0A=0D=0A >circuit* mobile phone service is not the same as an Inter= net=0D=0A=0D=0A >[call] service. I think that's pretty apparent from the=0D= =0A=0D=0A >context.=0D=0A=0D=0A=20=0D=0A=0D=0AThis might have been what Br= ian meant, but it wasn't obvious for me,=0D=0Aespecially as circuit switchi= ng is not part of 3G (HSPA or LTE), that is=0D=0A2G.=0D=0A=0D=0A[[MCD]] Exa= ctly - but much has been made of how 3GPP/IMS has defined=0D=0Aways of prov= iding transparent hand-off between packet service and=0D=0Acircuit service = in the context of an emergency call, with the subsequent=0D=0Ainference tha= t this makes ECRIT non-applicable in a 3GPP access context.=0D=0AThat's an = incorrect inference and the scenario is orthogonal to the=0D=0Apurpose of E= CRIT. Nevertheless, I'm genuinely interested in the details=0D=0A- i.e. how= does IMS state that this is done (not a description of how it=0D=0A*could*= be done by someone but what are the exact protocols and=0D=0Aprocedures sp= ecified). I'm particularly interested in how these=0D=0Aprocedures appear t= o the end device and the emergency network.=0D=0A=0D=0A=20=0D=0A=0D=0A >Wo= uld you claim that it is, in fact, the Internet=0D=0A=0D=0A >when a switch= ed circuit call is made Gabor=3F=0D=0A=0D=0A=20=0D=0A=0D=0ANo, I don't say = that. But would you claim that a VoIP call made on a 3G=0D=0A(packet switch= ed) network is not an Internet Service=3F=0D=0A=0D=0A[[MCD]] I do think it'= s an Internet context in that case - and that's=0D=0Athe case where I have = no difficulty seeing that ECRIT is applicable.=0D=0A=0D=0A=20=0D=0A=0D=0A = >Comments about reliability are misleading. Either=0D=0A=0D=0A >architectu= ral solution can be made arbitrarily reliable.=0D=0A=0D=0A=20=0D=0A=0D=0AYe= s, they can. But as we can see, unless it is required by regulation,=0D=0Ar= eliability is missing. Carriers operating in licenced bands have to=0D=0Ame= et certain conditions, while a network operating in an unlicenced band=0D=0A= is free to turn on/off its operation.=0D=0A=0D=0A[[MCD]] Legislation imposi= ng reliability and the question of unlicensed=0D=0Abands are both orthogona= l. ECRIT is applicable to a broadband access=0D=0Aregardless of, and indepe= ndently constrained by, those considerations.=0D=0ARegulation is a movable = feast - in the US, the Phase 2 regulation was=0D=0Aaimed at CMRS (circuit s= ervice) E9-1-1. The FCC is still kicking around=0D=0Athe ideas associated w= ith VoIP. There's no doubt that, from a technical=0D=0Aperspective, IMS is = VoIP. The question of how operators choose to=0D=0Ainterpret their own obli= gations wrt IMS is subject to their own risk and=0D=0Abusiness assessments = including how they present that service to their=0D=0Asubscribers. That is,= do they regard it as phase 2 cellular or do they=0D=0Aregard it as VoIP=3F= But that's just the US. Any arbitrary jurisdiction=0D=0Acould say that any= provider of broadband Internet access to the public=0D=0Ais required to su= pport the ECRIT compliant functions of a LIS, access to=0D=0ALoST, and a re= liable route to the PSAP URI(s) applicable to the=0D=0Aoperators' areas of = coverage. They could further require specific levels=0D=0Aof reliability/av= ailability and accuracy. They could require it of=0D=0Amunicipal WiFi netwo= rk operators (unlicensed band) just as much as they=0D=0Acould of licensed = band wireless operators. They could even require it of=0D=0Aenterprises of = a certain size (unlicensed wireless and wired Ethernet).=0D=0AThe point is = that the existence of regulatory requirements or otherwise=0D=0Adoes not mi= litate against the applicability of ECRIT to specific=0D=0Atechnologies.=0D= =0A=0D=0A=20=0D=0A=0D=0A >Both can be deployed in the context of managed a= ccess=0D=0A=0D=0A >according to the requirements applied by the jurisdicti= on.=0D=0A=0D=0A=20=0D=0A=0D=0ACertain radio access protocols are inherently= unreliable.=0D=0A=0D=0A[[MCD]] Well - I certainly have reliability problem= s with GSM and UMTS=0D=0Acoverage in a lot of places... but, again, the rel= iability of any given=0D=0Atechnology does not say anything about the appli= cability of ECRIT to=0D=0Athat or other technologies.=0D=0A=0D=0A=20=0D=0A=0D= =0A >There's been a presumption in this debate that somehow ECRIT=0D=0A=0D= =0A >needs "apologists" relative to IMS because IMS has a=0D=0A=0D=0A >co= mplete, definitive, and apparently infinitely versatile=0D=0A=0D=0A >defin= ition for handling emergency calls in 3GPP access.=0D=0A=0D=0A=20=0D=0A=0D=0A= ;)=0D=0A=0D=0AI am by far not an IMS evangelist, nor an ECRIT one, so I'd r= ather stay=0D=0Aout from these kind of debates.=0D=0A=0D=0AWhat people seem= to have trouble understanding is that some networks (eg=0D=0Athe ones oper= ating in licenced bands) can not afford to rely on the=0D=0Aclient to do al= l the procedures needed to place an emergency call. They=0D=0Aneed to assis= t the client and make sure the call ends up in the right=0D=0Aplace. They a= re liable for that. That's the difference.=0D=0A=0D=0A[[MCD]] I don't actua= lly understand how you infer that people involved=0D=0Ain this debate don't= understand those issues; I don't see the evidence=0D=0Aof that. In any cas= e, all existing licensed mobile networks absolutely=0D=0Arely on functional= ity within the device to make emergency calls;=0D=0Astandards have to be su= pported or the device cannot be used. I'm also=0D=0Anot asking for a positi= on in the debate; I'm asking for elucidation of=0D=0Ahow IMS achieves all t= he things that are claimed for it (exactly) given=0D=0Athe context that ECR= IT is argued to be inadequate in comparison. That=0D=0Adetail, so far, has = been assumed and not provided as part of the debate.=0D=0A=0D=0A=20=0D=0A=0D= =0A > It=0D=0A=0D=0A >would be reasonable to infer from the representati= ons made=0D=0A=0D=0A >with respect to the IMS model that this definition i= s clear,=0D=0A=0D=0A >well understood, and unambiguous to those familiar w= ith the=0D=0A=0D=0A >domain. I'd like to explore that premise a little.=0D= =0A=0D=0A >=0D=0A=0D=0A >While you're contributing your knowledge to the = discussion=0D=0A=0D=0A >then Gabor, could you please elaborate on the deta= iled=0D=0A=0D=0A >procedures, including which protocols are employed, when= an=0D=0A=0D=0A >emergency call is invoked according to 3GPP 23.167=3F=0D=0A=0D= =0A >=0D=0A=0D=0A >I'll grant that, somehow, the UE has recognized the=0D= =0A=0D=0A >appropriate E-CSCF in that managed network and now needs to=0D=0A=0D= =0A >invoke the emergency service procedures. As the spec points=0D=0A=0D=0A= >out, there's the Ml interface to the location routing=0D=0A=0D=0A >func= tion (LRF). Can you please describe the details as=0D=0A=0D=0A >defined by= 3GPP from then on=3F Or, alternatively, could you=0D=0A=0D=0A >point to t= he detailed procedure specification that explains=0D=0A=0D=0A >what actual= ly occurs=3F The analogue from the ECRIT=0D=0A=0D=0A >perspective is quite= well elaborated, including the use of=0D=0A=0D=0A >LoST for the routing q= uery and the use of candidate LCPs for=0D=0A=0D=0A >the location determina= tion by value and by reference, the=0D=0A=0D=0A >associated conveyance of = location value/reference in SIP etc.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian sent m= e off-list a pretty comprehensive list of issues where the=0D=0A3GPP proced= ures differ from the ones defined in ECRIT. Since that list=0D=0Ais by far = more complete than the one I could produce, I will copy paste=0D=0Ait below= =2E I hope Brian doesn't mind it:=0D=0A=0D=0A=20=0D=0A=0D=0A" At the moment= , the major differences between 3GPP and phonebcp are:=0D=0A=0D=0Aa) Who in= serts location, and what protocols are used=0D=0A=0D=0Ab) LoST (3GPP doesn'= t say LoST can't be used; it basically leaves this=0D=0Aas local practice. = Since in North America, LoST will be mandated,=0D=0Athat's not a differenc= e. However, 3GPP would say that LoST, if used,=0D=0Awould be queried by th= e E-CSCF, and not the endpoint, which differs from=0D=0A-phonebcp=0D=0A=0D=0A= c) SIP termination: present 3GPP specs make no provision for packet mode=0D= =0Atermination.=0D=0A=0D=0A=20=0D=0A=0D=0AThere are some relatively minor s= ignaling issues.=0D=0A=0D=0A=20=0D=0A=0D=0ATo be phonebcp compatible, 3GPP = networks would have to implement one of=0D=0Athe -phonebcp LCPs, and provid= e access to a LoST server. The former is=0D=0Aa big issue, the latter is a= small issue."=0D=0A=0D=0A[[MCD]] I understand the philosophical difference= - and how, for=0D=0Aexample, ECRIT could support an emergency call initiat= ed from an=0D=0AECRIT-compliant emergency client on a child's portable game= console=0D=0Aconnected to the in-vehicle WiFi connected to the Internet vi= a an LTE=0D=0Aaccess network (but it's difficult to see how IMS can do that= ). I'm=0D=0Aactually asking for the specific details (end-to-end and includ= ing the=0D=0Aprotocols used) of an IMS call according to 23.167 as part of = an attempt=0D=0Ato ensure that both sides of the debate are equipped with t= he same=0D=0Ainformation.=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AMy reque= st was to either restrict the scope of the document to=0D=0A'Internet', or = make it a requirements document (instead of bcp) with=0D=0Aintended status = standards track. Writing a bcp which excludes the most=0D=0Alikely near fut= ure practice looks weird to me.=0D=0A=0D=0A[[MCD]] I'm comfortable that the= scope of the document is restricted to=0D=0A"Internet" - or certainly to I= P (internet with a lower case 'i')=0D=0Anetworks generally. It's just that = others would like to see some=0D=0Aindication that, somehow, it doesn't app= ly to 3GPP networks - even=0D=0Athough it does.=0D=0A=0D=0A=20=0D=0A=0D=0A-= Gabor=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A >I'm sure IETF participan= ts would appreciate and benefit from=0D=0A=0D=0A >elucidation of just what= the 3GPP "secret sauce" is. I don't=0D=0A=0D=0A >want to leave anyone out= and, of course, invite other 3GPP=0D=0A=0D=0A >knowledgeable and vocal pa= rties to contribute.=0D=0A=0D=0A >=0D=0A=0D=0A >Cheers,=0D=0A=0D=0A >Mar= tin=0D=0A=0D=0A >=0D=0A=0D=0A >-----Original Message-----=0D=0A=0D=0A >F= rom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=0D=0A=0D=0A >O= n Behalf Of Gabor.Bajko@nokia.com=0D=0A=0D=0A >Sent: Tuesday, 4 August 200= 9 12:38 AM=0D=0A=0D=0A >To: br@brianrosen.net; drage@alcatel-lucent.com;=0D= =0A=0D=0A >john.elwell@siemens-enterprise.com; mlinsner@cisco.com;=0D=0A=0D= =0A >ecrit@ietf.org=0D=0A=0D=0A >Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D= =0A >=0D=0A=0D=0A >=0D=0A=0D=0A >=0D=0A=0D=0A > >-----Original Message= -----=0D=0A=0D=0A > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@i= etf.org]=0D=0A=0D=0A > >On Behalf Of ext Brian Rosen=0D=0A=0D=0A > >Sen= t: Friday, July 31, 2009 5:00 PM=0D=0A=0D=0A > >To: 'DRAGE, Keith (Keith)= '; 'Elwell, John'; 'Marc=0D=0A=0D=0A >Linsner'; 'ecrit'=0D=0A=0D=0A > >S= ubject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A > >=0D=0A=0D=0A > >Haha= , yes, a browser, or even an app using the raw packet=0D=0A=0D=0A > >serv= ice in a 3GPP GPRS device is on the Internet, although=0D=0A=0D=0A > >the= re are some subtle differences (the DNS root for=0D=0A=0D=0A > >example),=0D= =0A=0D=0A >=0D=0A=0D=0A >These are deployment and operational decisions, = which have=0D=0A=0D=0A >nothing to do with the ongoing discussion.=0D=0A=0D= =0A >=0D=0A=0D=0A > > but then, a service using that raw packet=0D=0A=0D= =0A > >interface to make, say, an IM to an emergency service would=0D=0A=0D= =0A > >probably have to make use of the phonebcp procedures, a fact=0D=0A=0D= =0A > >3GPP is studiously ignoring.=0D=0A=0D=0A >=0D=0A=0D=0A >3gpp has= defined a set of different procedures for emergency=0D=0A=0D=0A >calls, a= nd carriers will likely ask vendors to implement as=0D=0A=0D=0A >specified= =2E Then users will also use it as specified.=0D=0A=0D=0A >=0D=0A=0D=0A >= > I would not go so far as to=0D=0A=0D=0A > >say most people would pre= fer the 3GPP specified procedures=0D=0A=0D=0A > >vs the IETF phonebcp pro= cedures, especially if they=0D=0A=0D=0A > >understood the tradeoffs.=0D=0A=0D= =0A >=0D=0A=0D=0A >It is not a question of preference. Carriers want to h= ave a=0D=0A=0D=0A >solution which is reliable and operational 99.99999% of= the=0D=0A=0D=0A >cases. It has to be a stricly managed network.=0D=0A=0D=0A= >=0D=0A=0D=0A > >However, a 3GPP mobile telephone service is not an Int= ernet=0D=0A=0D=0A > >service, no matter how you stretch it.=0D=0A=0D=0A = >=0D=0A=0D=0A >Wow. What is your definition of Internet Service=3F I do=0D= =0A=0D=0A >remember statements on this mailing list that cellular=0D=0A=0D= =0A >networks are not IP capable. I guess you didn't want to go that far.=0D= =0A=0D=0A >I access the same content regardless of whether I use the=0D=0A=0D= =0A >comcast cable ending in the house or t-mobile's packet data=0D=0A=0D=0A= >service anywhere else. The only difference is the speed and=0D=0A=0D=0A = >the cost.=0D=0A=0D=0A >Looks the same to me, no matter how I strech it.=0D= =0A=0D=0A >=0D=0A=0D=0A >- gabor=0D=0A=0D=0A >=0D=0A=0D=0A > >Brian=0D= =0A=0D=0A > >=0D=0A=0D=0A > >> -----Original Message-----=0D=0A=0D=0A = > >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=0D=0A=0D= =0A > >> Sent: Friday, July 31, 2009 7:20 AM=0D=0A=0D=0A > >> To: Brian= Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit'=0D=0A=0D=0A > >> Subject:= RE: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A > >>=0D=0A=0D=0A > >> Just to = outline one of the issues.=0D=0A=0D=0A > >>=0D=0A=0D=0A > >> Take any 3= GPP GPRS enabled mobile phone where you have a=0D=0A=0D=0A > >browser ope= n=0D=0A=0D=0A > >> and it is browsing the general internet. In your=0D=0A=0D= =0A > >understanding that=0D=0A=0D=0A > >> would be a device on the Int= ernet.=0D=0A=0D=0A > >>=0D=0A=0D=0A > >> However if the user attempts t= o make an emergency call from that=0D=0A=0D=0A > >> device, 3GPP specifie= s that certain things should happen=0D=0A=0D=0A > >if the user=0D=0A=0D=0A= > >> happens to press the keys associated with making an=0D=0A=0D=0A > = >emergency call,=0D=0A=0D=0A > >> and the device then recognises an emer= gency call. It then=0D=0A=0D=0A > >goes on to=0D=0A=0D=0A > >> specify = how the emergency call is made from such a device.=0D=0A=0D=0A > >That se= t of=0D=0A=0D=0A > >> procedures is not the same as specified in phonebcp= =2E=0D=0A=0D=0A > >>=0D=0A=0D=0A > >> In this case 3GPP assumes in thei= r specifications that the 3GPP=0D=0A=0D=0A > >> procedures take precedenc= e, and indeed most people would=0D=0A=0D=0A > >consider that=0D=0A=0D=0A = > >> for this particular device, despite it being a device=0D=0A=0D=0A >= >attached to the=0D=0A=0D=0A > >> Internet, those procedures are the be= st first mechanism to=0D=0A=0D=0A > >attempt to=0D=0A=0D=0A > >> make a= n emergency call.=0D=0A=0D=0A > >>=0D=0A=0D=0A > >> regards=0D=0A=0D=0A= > >>=0D=0A=0D=0A > >> Keith=0D=0A=0D=0A > >>=0D=0A=0D=0A > >> > --= ---Original Message-----=0D=0A=0D=0A > >> > From: Brian Rosen [mailto:br@= brianrosen.net]=0D=0A=0D=0A > >> > Sent: Thursday, July 30, 2009 9:22 PM=0D= =0A=0D=0A > >> > To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc=0D=0A=0D= =0A >Linsner'; 'ecrit'=0D=0A=0D=0A > >> > Subject: RE: [Ecrit] HUM on Ph= oneBCP=0D=0A=0D=0A > >> >=0D=0A=0D=0A > >> > I specified the Internet, = and not an internet. Usually=0D=0A=0D=0A > >we mean the=0D=0A=0D=0A > = >> > public Internet. I think we have a decent definition of=0D=0A=0D=0A = > >that. It=0D=0A=0D=0A > >> > wouldn't cover, for example, a closed ne= twork like a=0D=0A=0D=0A > >IMS call on a=0D=0A=0D=0A > >> > cellular 3= G network.=0D=0A=0D=0A > >> > Might include, however, something like a ca= ll on an IMS=0D=0A=0D=0A > >network from=0D=0A=0D=0A > >> > a nomading = customer on some random public access=0D=0A=0D=0A > >network, depends.=0D= =0A=0D=0A > >> >=0D=0A=0D=0A > >> > Anyway, I said I was willing to do = the edit in a=0D=0A=0D=0A >effort to gain=0D=0A=0D=0A > >> > consensus.=0D= =0A=0D=0A > >> >=0D=0A=0D=0A > >> > Brian=0D=0A=0D=0A > >> >=0D=0A=0D= =0A > >> > > -----Original Message-----=0D=0A=0D=0A > >> > > From: DRAG= E, Keith (Keith) [mailto:drage@alcatel-lucent.com]=0D=0A=0D=0A > >> > > S= ent: Thursday, July 30, 2009 4:13 PM=0D=0A=0D=0A > >> > > To: Brian Rosen= ; 'Elwell, John'; 'Marc Linsner'; 'ecrit'=0D=0A=0D=0A > >> > > Subject: R= E: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A > >> > >=0D=0A=0D=0A > >> > > I = don't believe you can use the word "Internet" to target a=0D=0A=0D=0A > >= > > distinct=0D=0A=0D=0A > >> > > scope of phonebcp from other SDOs work = in this area.=0D=0A=0D=0A > >> > >=0D=0A=0D=0A > >> > > But I'll follow= the argument through if you really=0D=0A=0D=0A >want. Which=0D=0A=0D=0A = > >> > > well known definition of internet are you using so we=0D=0A=0D=0A= > >start from=0D=0A=0D=0A > >> > a common=0D=0A=0D=0A > >> > > basel= ine=3F=0D=0A=0D=0A > >> > >=0D=0A=0D=0A > >> > > regards=0D=0A=0D=0A >= >> > >=0D=0A=0D=0A > >> > > Keith=0D=0A=0D=0A > >> > >=0D=0A=0D=0A >= >> > > > -----Original Message-----=0D=0A=0D=0A > >> > > > From: Brian = Rosen [mailto:br@brianrosen.net]=0D=0A=0D=0A > >> > > > Sent: Thursday, J= uly 30, 2009 6:15 PM=0D=0A=0D=0A > >> > > > To: 'Elwell, John'; DRAGE, Ke= ith (Keith); 'Marc=0D=0A=0D=0A > >Linsner'; 'ecrit'=0D=0A=0D=0A > >> > = > > Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A > >> > > >=0D=0A=0D=0A= > >> > > > The IETF does work targeted to the Internet. Other SDOs=0D=0A=0D= =0A > >> > do work on=0D=0A=0D=0A > >> > > > different kinds of network= s other than the Internet.=0D=0A=0D=0A > >> > > > The document describes = best current practice for=0D=0A=0D=0A > >> > emergency calls on=0D=0A=0D=0A= > >> > > > the Internet.=0D=0A=0D=0A > >> > > >=0D=0A=0D=0A > >> > >= > Brian=0D=0A=0D=0A > >> > > >=0D=0A=0D=0A > >> > > > > -----Original = Message-----=0D=0A=0D=0A > >> > > > > From: ecrit-bounces@ietf.org=0D=0A=0D= =0A > >> > > > [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0A=0D=0A > = >> > > > > Of Elwell, John=0D=0A=0D=0A > >> > > > > Sent: Thursday, July = 30, 2009 1:02 PM=0D=0A=0D=0A > >> > > > > To: DRAGE, Keith (Keith); Marc = Linsner; ecrit=0D=0A=0D=0A > >> > > > > Subject: Re: [Ecrit] HUM on Phone= BCP=0D=0A=0D=0A > >> > > > >=0D=0A=0D=0A > >> > > > >=0D=0A=0D=0A > >= > > > > >=0D=0A=0D=0A > >> > > > > > -----Original Message-----=0D=0A=0D=0A= > >> > > > > > From: ecrit-bounces@ietf.org=0D=0A=0D=0A > >> > [mailto= :ecrit-bounces@ietf.org] On=0D=0A=0D=0A > >> > > > > > Behalf Of DRAGE, K= eith (Keith)=0D=0A=0D=0A > >> > > > > > Sent: 30 July 2009 09:01=0D=0A=0D= =0A > >> > > > > > To: Marc Linsner; 'ecrit'=0D=0A=0D=0A > >> > > > > >= Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A > >> > > > > >=0D=0A=0D= =0A > >> > > > > > I don't agree.=0D=0A=0D=0A > >> > > > > >=0D=0A=0D=0A= > >> > > > > > Some background.=0D=0A=0D=0A > >> > > > > >=0D=0A=0D=0A= > >> > > > > > There was a set of comments provided by=0D=0A=0D=0A >Ste= phen Edge on=0D=0A=0D=0A > >> > > > 5th February=0D=0A=0D=0A > >> > > >= > > 2009. I can find no response to that set of=0D=0A=0D=0A >comments on=0D= =0A=0D=0A > >> > > > the mailing=0D=0A=0D=0A > >> > > > > > list.=0D=0A=0D= =0A > >> > > > > >=0D=0A=0D=0A > >> > > > > > The gist of that set of c= omments was that=0D=0A=0D=0A >phonebcp claims=0D=0A=0D=0A > >> > > > to = cover=0D=0A=0D=0A > >> > > > > > all access technologies and it identifie= d a=0D=0A=0D=0A > >> > significant number=0D=0A=0D=0A > >> > > > > > of= requirements within phonebcp that the author=0D=0A=0D=0A > >> > consider= ed were=0D=0A=0D=0A > >> > > > > > not requirements on 3GPP accesses.=0D=0A=0D= =0A > >> > > > > >=0D=0A=0D=0A > >> > > > > > So my position is that th= e document is not ready=0D=0A=0D=0A > >> > because all the=0D=0A=0D=0A >= >> > > > > > valid comments on the document were not addressed.=0D=0A=0D=0A= > >> > > > > >=0D=0A=0D=0A > >> > > > > > There are two ways of dealin= g with this set=0D=0A=0D=0A >of comments:=0D=0A=0D=0A > >> > > > > >=0D=0A=0D= =0A > >> > > > > > - going through and modifying all the identified=0D= =0A=0D=0A > >> > > > > > requirements where the comment is upheld.=0D=0A=0D= =0A > >> > > > > >=0D=0A=0D=0A > >> > > > > > - making more clear in= the abstract and / or=0D=0A=0D=0A > >introduction=0D=0A=0D=0A > >> > >= > > > that this is solely the view of IETF in regard to IP=0D=0A=0D=0A > = >> > > > capable devices=0D=0A=0D=0A > >> > > > > > and that other organ= isations may specify other=0D=0A=0D=0A > >requirements.=0D=0A=0D=0A > >= > > > > > >=0D=0A=0D=0A > >> > > > > > I would note at this point that th= e current=0D=0A=0D=0A > >abstract says:=0D=0A=0D=0A > >> > > > > >=0D=0A=0D= =0A > >> > > > > > The IETF and other standards organization=0D=0A=0D=0A= >have efforts=0D=0A=0D=0A > >> > > > targeted at=0D=0A=0D=0A > >> > >= > > > standardizing various aspects of placing emergency=0D=0A=0D=0A >= >> > calls on IP=0D=0A=0D=0A > >> > > > > > networks. This memo des= cribes best current=0D=0A=0D=0A > >> > practice on how=0D=0A=0D=0A > >>= > > > > > devices,=0D=0A=0D=0A > >> > > > > > networks and services s= hould use such standards to=0D=0A=0D=0A > >> > > > make emergency=0D=0A=0D= =0A > >> > > > > > calls.=0D=0A=0D=0A > >> > > > > >=0D=0A=0D=0A > = >> > > > > > Because the two sentences follow each other,=0D=0A=0D=0A >it= implies=0D=0A=0D=0A > >> > > > that other=0D=0A=0D=0A > >> > > > > > S= DOs that have efforts targetted at addressing these=0D=0A=0D=0A > >> > > = > solutions are=0D=0A=0D=0A > >> > > > > > complicit in the requirements = so stated, and=0D=0A=0D=0A > >this is untrue.=0D=0A=0D=0A > >> > > > > = [JRE] I agree that this juxtaposition of=0D=0A=0D=0A > >statements is rat= her=0D=0A=0D=0A > >> > > > > misleading, and would suggest we try to impr= ove. In=0D=0A=0D=0A > >> > fact the only=0D=0A=0D=0A > >> > > > > "othe= r standards organization" responsible for "such=0D=0A=0D=0A > >> > stand= ards"=0D=0A=0D=0A > >> > > > > is ANSI/TIA, since LLDP-MED is the only=0D= =0A=0D=0A >normative reference=0D=0A=0D=0A > >> > > > (and I would=0D=0A=0D= =0A > >> > > > > argue that LLDP-MED is not specifically targeted at=0D=0A=0D= =0A > >> > > > emergency calls).=0D=0A=0D=0A > >> > > > > So perhaps we= can reword the abstract to say=0D=0A=0D=0A >"The IETF has=0D=0A=0D=0A > = >> > > > efforts..."=0D=0A=0D=0A > >> > > > >=0D=0A=0D=0A > >> > > > >= John=0D=0A=0D=0A > >> > > > >=0D=0A=0D=0A > >> > > > >=0D=0A=0D=0A > = >> > > > > Certainly the current status of this document=0D=0A=0D=0A > >= > > > > > > as addressed by various informal 3GPP=0D=0A=0D=0A >discussions= is to=0D=0A=0D=0A > >> > > > ensure that=0D=0A=0D=0A > >> > > > > > th= ings do not fall apart in entities using the 3GPP=0D=0A=0D=0A > >> > mech= anisms,=0D=0A=0D=0A > >> > > > > > however 3GPP devices do not use these = requirements=0D=0A=0D=0A > >> > (no do these=0D=0A=0D=0A > >> > > > > >= requirements represent the 3GPP requires.=0D=0A=0D=0A > >> > > > > >=0D=0A=0D= =0A > >> > > > > > One solution to the issue would just be to make much=0D= =0A=0D=0A > >> > > > clearer which=0D=0A=0D=0A > >> > > > > > SDOs have= participated in this work and which have=0D=0A=0D=0A > >> > not and the=0D= =0A=0D=0A > >> > > > > > status of that progress - however that was also = what=0D=0A=0D=0A > >> > people keep=0D=0A=0D=0A > >> > > > > > calling = the "applicability statement" was=0D=0A=0D=0A >trying to do.=0D=0A=0D=0A = > >> > > > > >=0D=0A=0D=0A > >> > > > > > regards=0D=0A=0D=0A > >> > >= > > >=0D=0A=0D=0A > >> > > > > > Keith=0D=0A=0D=0A > >> > > > > >=0D=0A=0D= =0A > >> > > > > >=0D=0A=0D=0A > >> > > > > >=0D=0A=0D=0A > >> > > > = > >=0D=0A=0D=0A > >> > > > > > ________________________________=0D=0A=0D=0A= > >> > > > > >=0D=0A=0D=0A > >> > > > > > From: ecrit-bounces@ie= tf.org=0D=0A=0D=0A > >> > > > > > [mailto:ecrit-bounces@ietf.org] On Beha= lf Of=0D=0A=0D=0A >Marc Linsner=0D=0A=0D=0A > >> > > > > > Sent: W= ednesday, July 29, 2009 2:53 PM=0D=0A=0D=0A > >> > > > > > To: 'ecr= it'=0D=0A=0D=0A > >> > > > > > Subject: [Ecrit] HUM on PhoneBCP=0D=0A=0D= =0A > >> > > > > >=0D=0A=0D=0A > >> > > > > >=0D=0A=0D=0A > >> > > > = > > During today's meeting there was=0D=0A=0D=0A >discussion as to w= hy=0D=0A=0D=0A > >> > > > the chairs=0D=0A=0D=0A > >> > > > > > Publica= tion Requested PhoneBCP version 13=0D=0A=0D=0A >when there are=0D=0A=0D=0A= > >> > > > unresolved=0D=0A=0D=0A > >> > > > > > issues. This discuss= ion led us to call for a hum.=0D=0A=0D=0A > >> > We are now=0D=0A=0D=0A = > >> > > > > > asking the same question on the list.=0D=0A=0D=0A > >> > = > > > >=0D=0A=0D=0A > >> > > > > > Do you agree or disagree that Ph= oneBCP=0D=0A=0D=0A >-13 is ready to=0D=0A=0D=0A > >> > > > Publication=0D= =0A=0D=0A > >> > > > > > Request=3F=0D=0A=0D=0A > >> > > > > >=0D=0A=0D= =0A > >> > > > > > Please respond by close of business on=0D=0A=0D=0A= >Wednesday August=0D=0A=0D=0A > >> > > 5th.=0D=0A=0D=0A > >> > > > > = >=0D=0A=0D=0A > >> > > > > > Thanks,=0D=0A=0D=0A > >> > > > > >=0D= =0A=0D=0A > >> > > > > > Marc & Hannes=0D=0A=0D=0A > >> > > > > >=0D= =0A=0D=0A > >> > > > > >=0D=0A=0D=0A > >> > > > > >=0D=0A=0D=0A > >> = > > > > _______________________________________________=0D=0A=0D=0A > >> = > > > > Ecrit mailing list=0D=0A=0D=0A > >> > > > > Ecrit@ietf.org=0D=0A=0D= =0A > >> > > > > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A = > >> > > >=0D=0A=0D=0A > >> > > > =3D=0D=0A=0D=0A > >> >=0D=0A=0D=0A = > >> > =3D=0D=0A=0D=0A > >=0D=0A=0D=0A > >___________________________= ____________________=0D=0A=0D=0A > >Ecrit mailing list=0D=0A=0D=0A > >E= crit@ietf.org=0D=0A=0D=0A > >https://www.ietf.org/mailman/listinfo/ecrit=0D= =0A=0D=0A > >=0D=0A=0D=0A >_____________________________________________= __=0D=0A=0D=0A >Ecrit mailing list=0D=0A=0D=0A >Ecrit@ietf.org=0D=0A=0D=0A= >https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A >=0D=0A=0D=0A = >-------------------------------------------------------------=0D=0A=0D=0A = >-----------------------------------=0D=0A=0D=0A >This message is for the= designated recipient only and may=0D=0A=0D=0A >contain privileged, propri= etary, or otherwise private information.=0D=0A=0D=0A >If you have received= it in error, please notify the sender=0D=0A=0D=0A >immediately and delete= the original. Any unauthorized use=0D=0A=0D=0A >of this email is prohibi= ted.=0D=0A=0D=0A >--------------------------------------------------------= -----=0D=0A=0D=0A >-----------------------------------=0D=0A=0D=0A >[mf2]=0D= =0A=0D=0A >=0D=0A=0D=0A >=0D=0A=0D=0A=20=0D=0A=0D=0A---------------------= ---------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA156D.4735074C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

 <= /font>

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

 

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

-----Original Message= -----
=0D=0AFrom: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] <= br>=0D=0ASent: Wednesday, 5 August 2009 4:41 AM
=0D=0ATo: Dawson, Martin= ; br@brianrosen.net; drage@alcatel-lucent.com;=0D=0Ajohn.elwell@siemens-ent= erprise.com; mlinsner@cisco.com; ecrit@ietf.org
=0D=0ASubject: RE: ECRIT= /IMS - independent discussion from the PhoneBCP hum

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

 

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

 

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

 

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

  >-----Original Message-----=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >From: ext Dawson, Martin [= mailto:Martin.Dawson@andrew.com]

=0D=0A=0D=0A  >Sent: Monday, August 03, 2009 9:19 PM=

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

  >To: = Bajko Gabor (Nokia-CIC/MtView); br@brianrosen.net;=

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

  >drage@alcatel-lucent.com= ;

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

  &g= t;john.elwell@siemens-enterprise.com; mlinsner@cisco.com;=

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

  >ecrit@ietf.org

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

  >Su= bject: ECRIT/IMS - independent discussion from the=0D=0APhoneBCP hum

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

  ><= /o:p>

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

  >I int= erpret Brian's comment as being that a conventional=0D=0A*switched

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

  >circuit*= mobile phone service is not the same as an Internet

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

  >[call] service. I thin= k that's pretty apparent from the

=0D=0A=0D=0A<= p class=3DMsoPlainText>  >context.

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

 

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

This might have been what Brian meant, but it wasn't o= bvious for me,=0D=0Aespecially as circuit switching is not part of 3G (HSPA= or LTE), that is 2G.

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

[[MCD]]=0D=0AExactly – but much has been made of how 3GPP/IMS has d= efined ways of=0D=0Aproviding transparent hand-off between packet service a= nd circuit service in=0D=0Athe context of an emergency call, with the subse= quent inference that this makes=0D=0AECRIT non-applicable in a 3GPP access = context. That’s an incorrect=0D=0Ainference and the scenario is ortho= gonal to the purpose of ECRIT. Nevertheless,=0D=0AI’m genuinely inter= ested in the details – i.e. how does IMS state=0D=0Athat this is done= (not a description of how it *could* be done by=0D=0Asomeone but wh= at are the exact protocols and procedures specified). I’m=0D=0Apartic= ularly interested in how these procedures appear to the end device and=0D=0A= the emergency network.

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

= =  

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

&nbs= p; >Would you claim that it is, in fact, the Internet<= /font>

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

  >when a switched ci= rcuit call is made Gabor=3F

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

 

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

No, I don't say that. But would you claim that a VoIP call made = on a 3G=0D=0A(packet switched) network is not an Internet Service=3F

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

[[MCD]]=0D=0AI do think it&#= 8217;s an Internet context in that case – and that’s=0D=0Athe c= ase where I have no difficulty seeing that ECRIT is applicable.<= /span>

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

 

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

  >Comments about = reliability are misleading. Either

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

  >architectural solution can be made arbit= rarily reliable.

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

 

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

Yes, they can. But as we can see, unless it is required by regulation,=0D= =0Areliability is missing. Carriers operating in licenced bands have to mee= t=0D=0Acertain conditions, while a network operating in an unlicenced band = is free to=0D=0Aturn on/off its operation.

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

[[MCD]]=0D=0ALegislation imposing reliability and the que= stion of unlicensed bands are both=0D=0Aorthogonal. ECRIT is applicable to = a broadband access regardless of, and=0D=0Aindependently constrained by, th= ose considerations. Regulation is a movable=0D=0Afeast – in the US,=0D=0Athe Phase 2 regulation was aimed at CMRS (circuit service)= E9-1-1. The FCC is=0D=0Astill kicking around the ideas associated with VoI= P. There’s no doubt=0D=0Athat, from a technical perspective, IMS is V= oIP. The question of how operators=0D=0Achoose to interpret their own oblig= ations wrt IMS is subject to their own risk=0D=0Aand business assessments i= ncluding how they present that service to their=0D=0Asubscribers. That is, = do they regard it as phase 2 cellular or do they regard=0D=0Ait as VoIP=3F = But that’s just the US. Any arbitrary jurisdiction=0D= =0Acould say that any provider of broadband Internet access to the public i= s=0D=0Arequired to support the ECRIT compliant functions of a LIS, access t= o LoST, and=0D=0Aa reliable route to the PSAP URI(s) applicable to the oper= ators’ areas of=0D=0Acoverage. They could further require specific le= vels of=0D=0Areliability/availability and accuracy. They could require it o= f municipal WiFi=0D=0Anetwork operators (unlicensed band) just as much as t= hey could of licensed band=0D=0Awireless operators. They could even require= it of enterprises of a certain size=0D=0A(unlicensed wireless and wired Et= hernet). The point is that the existence of=0D=0Aregulatory requirements or= otherwise does not militate against the=0D=0Aapplicability of ECRIT to spe= cific technologies.

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

 

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

  >Both can be deployed in the context of managed access

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

  >accord= ing to the requirements applied by the jurisdiction.

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

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

<= span style=3D'font-size:=0D=0A10.0pt'>Certain radio access protocols are in= herently unreliable.

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

[= [MCD]]=0D=0AWell – I certainly have reliability problems with GSM and= UMTS coverage=0D=0Ain a lot of places… but, again, the reliability o= f any given technology=0D=0Adoes not say anything about the applicability o= f ECRIT to that or other technologies.

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

 

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

  >There's been a presumption in this debate t= hat somehow ECRIT

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

  >needs "apologists" relative to IMS because IMS = has=0D=0Aa

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

= =   >complete, definitive, and apparently infinitely versatile

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

  >defini= tion for handling emergency calls in 3GPP access.<= /p>=0D=0A=0D=0A

=  

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

;)

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

I am by far not an IMS evangelist, nor an ECRIT one= , so I'd rather stay=0D=0Aout from these kind of debates.=

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

What people seem to have tro= uble understanding is that some networks=0D=0A(eg the ones operating in lic= enced bands) can not afford to rely on the client=0D=0Ato do all the proced= ures needed to place an emergency call. They need to assist=0D=0Athe client= and make sure the call ends up in the right place. They are liable=0D=0Afo= r that. That's the difference.

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

[[MCD]]=0D=0AI don’t actually understand how you infer tha= t people involved in this=0D=0Adebate don’t understand those issues; = I don’t see the evidence of that.=0D=0AIn any case, all existing lice= nsed mobile networks absolutely rely on=0D=0Afunctionality within the devic= e to make emergency calls; standards have to be=0D=0Asupported or the devic= e cannot be used. I’m also not asking for a=0D=0Aposition in the deba= te; I’m asking for elucidation of how IMS achieves=0D=0Aall the thing= s that are claimed for it (exactly) given the context that ECRIT=0D=0Ais ar= gued to be inadequate in comparison. That detail, so far, has been assumed=0D= =0Aand not provided as part of the debate.

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

 

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

  >  It

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

  >would be reasonable to infer from the r= epresentations made

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

  >with respect to the IMS model that this definition is cl= ear,

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

 = >well understood, and unambiguous to those familiar with the=

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

  >domain. I'd= like to explore that premise a little.

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

  >

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

  >While you're contributing your knowledge= to the discussion

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

  >then Gabor, could you please elaborate on the detailed

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

  >pr= ocedures, including which protocols are employed, when an=

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

  >emergency call is= invoked according to 3GPP 23.167=3F

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

  >

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

  >I'll grant that, somehow, the UE has rec= ognized the

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

  >appropriate E-CSCF in that managed network and now needs to

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

  >inv= oke the emergency service procedures. As the spec points<= /font>

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

  >out, there's the M= l interface to the location routing

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

  >function (LRF). Can you please describe = the details as

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

  >defined by 3GPP from then on=3F Or, alternatively, could you=

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

  >= ;point to the detailed procedure specification that explains

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

  >what actually = occurs=3F The analogue from the ECRIT

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

  >perspective is quite well elaborated, i= ncluding the use of

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

  >LoST for the routing query and the use of candidate LCPs= for

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

 = >the location determination by value and by reference, the

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

  >associated c= onveyance of location value/reference in SIP=0D=0Aetc.

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

 =

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

Brian sent me off-list a pretty com= prehensive list of issues where the=0D=0A3GPP procedures differ from the on= es defined in ECRIT. Since that list is by=0D=0Afar more complete than the = one I could produce, I will copy paste it below. I=0D=0Ahope Brian doesn't = mind it:

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

 

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

"= At the moment, the major differences between 3GPP and phonebcp=0D=0Aare:

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

a) Who insert= s location, and what protocols are used

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

b) LoST (3GPP doesn't say LoST can't be used; it b= asically leaves this=0D=0Aas local practice.  Since in North America,=0D=0ALoST will be mandated, that's not a= difference.  However, 3GPP would say=0D=0Athat LoST, if used, would b= e queried by the E-CSCF, and not the endpoint, which=0D=0Adiffers from -pho= nebcp

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

c) SI= P termination: present 3GPP specs make no provision for packet=0D=0Amode te= rmination.

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

= =  

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

Ther= e are some relatively minor signaling issues.

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

 

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

To be phonebcp compatible, 3GPP networks would hav= e to implement one of=0D=0Athe -phonebcp LCPs, and provide access to a LoST= server.  The former is a=0D=0Abig issue, the latter is a small issue.= "

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

<= i>[[MCD]]=0D=0A= I understand the philosophical difference – and how, for example, ECR= IT=0D=0Acould support an emergency call initiated from an ECRIT-compliant e= mergency=0D=0Aclient on a child’s portable game console connected to = the in-vehicle WiFi=0D=0Aconnected to the Internet via an LTE access networ= k (but it’s difficult=0D=0Ato see how IMS can do that). I’m act= ually asking for the specific details=0D=0A(end-to-end and including the pr= otocols used) of an IMS call according to=0D=0A23.167 as part of an attempt= to ensure that both sides of the debate are=0D=0Aequipped with the same in= formation.

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

= =  

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

 

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

My reque= st was to either restrict the scope of the document to=0D=0A'Internet', or = make it a requirements document (instead of bcp) with intended=0D=0Astatus = standards track. Writing a bcp which excludes the most likely near=0D=0Afut= ure practice looks weird to me.

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

 

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

- Gabor<= /span>

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

 

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

 

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

  >I'm sure IETF parti= cipants would appreciate and benefit from

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

  >elucidation of just what the 3GPP "= ;secret sauce"=0D=0Ais. I don't

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

  >want to leave anyone out and, of course,= invite other 3GPP

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

  >knowledgeable and vocal parties to contribute.

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

  >=

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

  >Cheers,

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

  >Mar= tin

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

  = >

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

 = >-----Original Message-----

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

  >From: ecrit-bounces@ietf.org [mailto:ecrit-= bounces@ietf.org]

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

  >On Behalf Of Gabor.Bajko@nokia.com

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

  >Sent: Tuesday, 4 Augus= t 2009 12:38 AM

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

  >To: br@brianrosen.net; drage@alcatel-lucent.com;=

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

  >john.elwell= @siemens-enterprise.com; mlinsner@cisco.com;

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

  >ecrit@ietf.org

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

  >Subject: Re: [Ec= rit] HUM on PhoneBCP

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

  >

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

  >

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

  >

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

  >  >-----Original Message-----<= /font>

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

  >  >From: e= crit-bounces@ietf.org=0D=0A[mailto:ecrit-bounces@ietf.org]

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

  >  >On Be= half Of ext Brian Rosen

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

  >  >Sent: Friday, July 31, 2009 5:00 PM

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

  > = >To: 'DRAGE, Keith (Keith)'; 'Elwell, John'; 'Marc

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

  >Linsner'; 'ecrit'

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

  >&n= bsp; >Subject: Re: [Ecrit] HUM on PhoneBCP

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

  >  >

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

  >  >Haha, ye= s, a browser, or even an app using the=0D=0Araw packet

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

  >  >service i= n a 3GPP GPRS device is on the Internet,=0D=0Aalthough

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

  >  >there are= some subtle differences (the DNS root=0D=0Afor=0D=0A=0D=0A

  >  >example),

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

  ><= /o:p>

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

  >These= are deployment and operational decisions, which have

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

  >nothing to do with th= e ongoing discussion.

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

  >

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

  >  > but then, a service using that raw packet=

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

  >= ;  >interface to make, say, an IM to an emergency=0D=0Aservice woul= d

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

  &g= t;  >probably have to make use of the phonebcp=0D=0Aprocedures, a f= act

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

  = >  >3GPP is studiously ignoring.

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

  >

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

  >3gpp has defined a set of diffe= rent procedures for emergency

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

  >calls, and carriers will likely ask vendors t= o implement as

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

  >specified. Then users will also use it as specified.

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

  >

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

  > = >  I would not go so far as to

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

  >  >say most people would prefer= the 3GPP specified=0D=0Aprocedures

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

  >  >vs the IETF phonebcp procedur= es, especially if=0D=0Athey

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

  >  >understood the tradeoffs.=

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

  >=

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

  >It is not a= question of preference. Carriers want to have a=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >solution which is reliable= and operational 99.99999% of the

=0D=0A=0D=0A<= p class=3DMsoPlainText>  >cases. It has to be a stricly managed net= work.

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

 = ; >

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

&nbs= p; >  >However, a 3GPP mobile telephone service is not=0D=0Aan I= nternet

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

&nb= sp; >  >service, no matter how you stretch it.=

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

  >

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

  >Wow. What is you= r definition of Internet Service=3F I do

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

  >remember statements on this mailing lis= t that cellular

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

  >networks are not IP capable. I guess you didn't want to go=0D= =0Athat far.

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

  >I access the same content regardless of whether I use the=

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

  >comc= ast cable ending in the house or t-mobile's packet data

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

  >service anywhere el= se. The only difference is the speed and

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

  >the cost.

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

  >Looks the same to me, no matter= how I strech it.

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

  >

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

  >- gabor

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

  >

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

  >  >Brian

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

  >  >

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

  >  >> ---= --Original Message-----

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

  >  >> From: DRAGE, Keith (Keith)=0D=0A[mail= to:drage@alcatel-lucent.com]

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

  >  >> Sent: Friday, July 31, 2009 7:= 20 AM

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

 = ; >  >> To: Brian Rosen; 'Elwell, John'; 'Marc=0D=0ALinsner';= 'ecrit'

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

&n= bsp; >  >> Subject: RE: [Ecrit] HUM on PhoneBCP

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

  >  >&g= t;

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

  &= gt;  >> Just to outline one of the issues.

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

  >  >><= /o:p>

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

  > = ; >> Take any 3GPP GPRS enabled mobile phone=0D=0Awhere you have a

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

  >&n= bsp; >browser open

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

  >  >> and it is browsing the general intern= et. In=0D=0Ayour

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

  >  >understanding that=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >  >> would be a= device on the Internet.

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

  >  >>

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

  >  >> However if the user att= empts to make an=0D=0Aemergency call from that

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

  >  >> device, 3GPP sp= ecifies that certain things=0D=0Ashould happen

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

  >  >if the user

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

  >  &= gt;> happens to press the keys associated with=0D=0Amaking an=

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

  >  >= emergency call,

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

  >  >> and the device then recognises an emergency=0D= =0Acall. It then

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

  >  >goes on to

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

  >  >> specify how the emergen= cy call is made from=0D=0Asuch a device.

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

  >  >That set of

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

  >  >> = procedures is not the same as specified in=0D=0Aphonebcp.=

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

  >  >>

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

  >&n= bsp; >> In this case 3GPP assumes in their=0D=0Aspecifications that t= he 3GPP

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

&nb= sp; >  >> procedures take precedence, and indeed most=0D=0Ape= ople would

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

= =   >  >consider that

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

  >  >> for this particular devi= ce, despite it being=0D=0Aa device

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

  >  >attached to the

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

  >  >&g= t; Internet, those procedures are the best=0D=0Afirst mechanism to

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

  >  &= gt;attempt to

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

  >  >> make an emergency call.

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

  >  >><= /o:p>

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

  > = ; >> regards

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

  >  >>

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

  >  >> Keith<= /font>

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

  >  >>

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

  >&n= bsp; >> > -----Original Message-----

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

  >  >> > From: Bria= n Rosen=0D=0A[mailto:br@brianrosen.net]

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

  >  >> > Sent: Thursday, Ju= ly 30, 2009 9:22 PM

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

  >  >> > To: DRAGE, Keith (Keith); 'Elwell,=0D= =0AJohn'; 'Marc

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

  >Linsner'; 'ecrit'

=0D=0A=0D=0A<= p class=3DMsoPlainText>  >  >> > Subject: RE: [Ecrit]= HUM on PhoneBCP

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

  >  >> >

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

  >  >> > I specified the In= ternet, and not an=0D=0Ainternet.  Usually=0D=0A=0D=0A

  >  >we mean the=

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

  >&nbs= p; >> > public Internet.  I think we have=0D=0Aa decent defin= ition of

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

&n= bsp; >  >that.  It

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

  >  >> > wouldn't cover, for= example, a closed=0D=0Anetwork like a

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

  >  >IMS call on a

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

  >  >>= ; > cellular 3G network.

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

  >  >> > Might include, however, so= mething like=0D=0Aa call on an IMS

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

  >  >network from

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

  >  >> = > a nomading customer on some random=0D=0Apublic access

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

  >  >netwo= rk, depends.

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

  >  >> >

=0D=0A=0D=0A<= p class=3DMsoPlainText>  >  >> > Anyway, I said I was= willing to do the=0D=0Aedit in a

=0D=0A=0D=0A<= p class=3DMsoPlainText>  >effort to gain=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >  >> > conse= nsus.

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

 = ; >  >> >

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

  >  >> > Brian

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

  >  >> ><= o:p>

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

  >&n= bsp; >> > > -----Original Message-----=

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

  >  >> > >= ; From: DRAGE, Keith (Keith)=0D=0A[mailto:drage@alcatel-lucent.com]

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

  >  = >> > > Sent: Thursday, July 30, 2009 4:13=0D=0APM

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

  >  >&g= t; > > To: Brian Rosen; 'Elwell, John';=0D=0A'Marc Linsner'; 'ecrit'<= o:p>

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

  >&n= bsp; >> > > Subject: RE: [Ecrit] HUM on=0D=0APhoneBCP

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

  >  >= > > >

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

  >  >> > > I don't believe you can use the=0D= =0Aword "Internet" to target a

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

  >  >> > distinct

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

  >  >= > > > scope of phonebcp from other SDOs=0D=0Awork in this area.

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

  >&n= bsp; >> > >

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

  >  >> > > But I'll follow the argumen= t=0D=0Athrough if you really

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

  >want. Which

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

  >  >> > > well known de= finition of internet=0D=0Aare you using so we

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

  >  >start from

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

  >  >= > > a common

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

  >  >> > > baseline=3F<= /font>

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

  >  >> &g= t; >

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

&nb= sp; >  >> > > regards

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

  >  >> > >

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

  >  >&g= t; > > Keith

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

  >  >> > >

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

  >  >> > > > = -----Original Message-----

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

  >  >> > > > From: Brian Rosen=0D= =0A[mailto:br@brianrosen.net]

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

  >  >> > > > Sent: Thursday= , July 30, 2009=0D=0A6:15 PM

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

  >  >> > > > To: 'Elwell, Jo= hn'; DRAGE,=0D=0AKeith (Keith); 'Marc

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

  >  >Linsner'; 'ecrit'=

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

  >  >= > > > > Subject: RE: [Ecrit] HUM on=0D=0APhoneBCP

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

  >  >&g= t; > > >

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

  >  >> > > > The IETF does work targete= d=0D=0Ato the Internet. Other SDOs

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

  >  >> > do work on

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

  >  &= gt;> > > > different kinds of networks=0D=0Aother than the Inte= rnet.

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

 = ; >  >> > > > The document describes best=0D=0Acurre= nt practice for

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

  >  >> > emergency calls on

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

  >  >> >= ; > > the Internet.

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

  >  >> > > >

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

  >  >> > &= gt; > Brian

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

  >  >> > > >

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

  >  >> > > > = > -----Original=0D=0AMessage-----

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

  >  >> > > > > From= :=0D=0Aecrit-bounces@ietf.org

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

  >  >> > > >=0D=0A[mailto:e= crit-bounces@ietf.org] On Behalf

=0D=0A=0D=0A  >  >> > > > > Of Elw= ell, John

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

<= font size=3D2 face=3D"Courier New">&= nbsp; >  >> > > > > Sent: Thursday, July 30,=0D=0A= 2009 1:02 PM

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

  >  >> > > > > To: DRAGE, Keith=0D=0A(Kei= th); Marc Linsner; ecrit

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

  >  >> > > > > Subject: Re: [Ecr= it] HUM=0D=0Aon PhoneBCP

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

  >  >> > > > >=

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

  >  >> &= gt; > > >

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

  >  >> > > > >

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

  >  >> >= > > > > -----Original=0D=0AMessage-----

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

  >  >> > &= gt; > > > From:=0D=0Aecrit-bounces@ietf.org

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

  >  >> > [= mailto:ecrit-bounces@ietf.org] On

=0D=0A=0D=0A<= p class=3DMsoPlainText>  >  >> > > > > > = Behalf Of DRAGE,=0D=0AKeith (Keith)

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

  >  >> > > > > >= Sent: 30 July 2009=0D=0A09:01

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

  >  >> > > > > > To:= Marc Linsner;=0D=0A'ecrit'

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

  >  >> > > > > > Subjec= t: Re:=0D=0A[Ecrit] HUM on PhoneBCP

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

  >  >> > > > > >=

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

  >= ;  >> > > > > > I don't agree.<= /font>

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

  >  >> &g= t; > > > >

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

  >  >> > > > > > Some backgro= und.

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

 = >  >> > > > > >

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

  >  >> > > > = > > There was a set of=0D=0Acomments provided by

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

  >Stephen Edge on=

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

  >&nbs= p; >> > > > 5th February

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

  >  >> > > > > >= ; 2009. I can find no=0D=0Aresponse to that set of=

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

  >comments on

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

  >  >&= gt; > > > the mailing

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

  >  >> > > > > > lis= t.

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

  &= gt;  >> > > > > >

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

  >  >> > > > = > > The gist of that=0D=0Aset of comments was that<= /font>

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

  >phonebcp claims

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

  >&n= bsp; >> > > > to cover

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

  >  >> > > > > >= ; all access=0D=0Atechnologies and it identified a=

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

  >  >> > sig= nificant number

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

  >  >> > > > > > of requirements=0D= =0Awithin phonebcp that the author

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

  >  >> > considered were

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

  >&nb= sp; >> > > > > > not requirements on=0D=0A3GPP accesse= s.

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

  &= gt;  >> > > > > >

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

  >  >> > > > = > > So my position is=0D=0Athat the document is not ready<= /span>

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

  >  >= > > because all the

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

  >  >> > > > > > valid commen= ts on=0D=0Athe document were not addressed.

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

  >  >> > > > = > >

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

<= font size=3D2 face=3D"Courier New">&= nbsp; >  >> > > > > > There are two ways=0D=0A= of dealing with this set

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

  >of comments:

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

  >  >> > > > > >=

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

  >= ;  >> > > > > > -   =0D=0Agoing th= rough and modifying all the identified

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

  >  >> > > > > >= ; requirements where=0D=0Athe comment is upheld.=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >  >> > > = > > >

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

  >  >> > > > > > -   =0D= =0Amaking more clear in the abstract and / or

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

  >  >introduction

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

  >  = >> > > > > > that this is solely=0D=0Athe view of IETF= in regard to IP

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

  >  >> > > > capable devices

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

  >  >= > > > > > > and that other=0D=0Aorganisations may specify= other

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

&nbs= p; >  >requirements.

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

  >  >> > > > > >

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

  >&n= bsp; >> > > > > > I would note at=0D=0Athis point that= the current

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

  >  >abstract says:

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

  >  >> > > > > >= ;

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

  &g= t;  >> > > > > >   =0D=0AThe IETF = and other standards organization

=0D=0A=0D=0A  >have efforts

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

  >  >> > > > = targeted at

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

  >  >> > > > > >   =0D=0A= standardizing various aspects of placing emergency=

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

  >  >> > cal= ls on IP

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

&n= bsp; >  >> > > > > >   =0D=0Ane= tworks.  This memo describes best current

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

  >  >> > practice o= n how

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

 = ; >  >> > > > > > devices,

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

  >  >> >= ; > > > >   =0D=0Anetworks and services should u= se such standards to

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

  >  >> > > > make emergency=

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

  >  >= > > > > > >   =0D=0Acalls.

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

  >  >>= > > > > >

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

  >  >> > > > > > Because the = two=0D=0Asentences follow each other,

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

  >it implies

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

  >  >> > > > = that other

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

= =   >  >> > > > > > SDOs that have=0D=0Aeff= orts targetted at addressing these

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

  >  >> > > > solutions= are

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

 = >  >> > > > > > complicit in the=0D=0Arequire= ments so stated, and

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

  >  >this is untrue.

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

  >  >> > > > = > [JRE] I agree that this=0D=0Ajuxtaposition of=

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

  >  >statements is= rather

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

&nb= sp; >  >> > > > > misleading, and would suggest=0D= =0Awe try to improve. In

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

  >  >> > fact the only<= /font>

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

  >  >> &g= t; > > > "other standards=0D=0Aorganization"  respo= nsible for "such

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

  >  >> > standards"

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

  >  >> = > > > > is ANSI/TIA, since=0D=0ALLDP-MED is the only=

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

  >normative r= eference

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

&n= bsp; >  >> > > > (and I would

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

  >  >> > &= gt; > > argue that LLDP-MED is=0D=0Anot specifically targeted at=

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

  >&nbs= p; >> > > > emergency calls).

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

  >  >> > > > = > So perhaps we can reword=0D=0Athe abstract to say

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

  >"The IETF has

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

  >&n= bsp; >> > > > efforts..."

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

  >  >> > > > = >

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

 = >  >> > > > > John

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

  >  >> > > > = >

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

 = >  >> > > > >

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

  >  >> > > > > Cer= tainly the current=0D=0Astatus of this document=0D=0A=0D=0A

  >  >> > > &= gt; > > as addressed by=0D=0Avarious informal 3GPP<= /font>

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

  >discussions is to<= o:p>

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

  >&n= bsp; >> > > > ensure that

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

  >  >> > > > > >= ; things do not fall=0D=0Aapart in entities using the 3GPP

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

  >  >> = > mechanisms,

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

  >  >> > > > > > however 3GPP=0D= =0Adevices do not use these requirements

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

  >  >> > (no do these<= /o:p>

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

  > = ; >> > > > > > requirements=0D=0Arepresent the 3GPP re= quires.

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

&nb= sp; >  >> > > > > >=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >  >> > > = > > > One solution to the=0D=0Aissue would just be to make much

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

  >&n= bsp; >> > > > clearer which

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

  >  >> > > > > >= ; SDOs have=0D=0Aparticipated in this work and which have=

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

  >  >> &= gt; not and the

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

  >  >> > > > > > status of that=0D=0A= progress - however that was also what

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

  >  >> > people keep

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

  > = >> > > > > > calling the=0D=0A"applicability sta= tement" was

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

  >trying to do.

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

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

  >&n= bsp; >> > > > > > regards

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

  >  >> > > > = > >

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

<= font size=3D2 face=3D"Courier New">&= nbsp; >  >> > > > > > Keith<= /font>

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

  >  >> &g= t; > > > >

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

  >  >> > > > > >

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

  >  >&= gt; > > > > >

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

  >  >> > > > > ><= /o:p>

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

  > = ; >> > > > > >=0D=0A________________________________

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

  >&n= bsp; >> > > > > >

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

  >  >> > > > >=0D=0A= >       From: ecrit-bounces@ietf.org<= /o:p>

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

  > = ; >> > > > > >=0D=0A[mailto:ecrit-bounces@ietf.org] On= Behalf Of

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

= =   >Marc Linsner

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

  >  >> > > > >=0D=0A> &n= bsp;     Sent: Wednesday, July 29, 2009 2:53 PM

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

  >  = >> > > > >=0D=0A>       = To: 'ecrit'

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

  >  >> > > > >=0D=0A>   =     Subject: [Ecrit] HUM on PhoneBCP

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

  >  >> > > > > >

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

  >  >> = > > > >=0D=0A>       During to= day's meeting there was

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

  >discussion as to why

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

  >  >> > > > the chai= rs

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

  &= gt;  >> > > > > > Publication=0D=0ARequested Phon= eBCP version 13

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

  >when there are

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

  >  >> > > > unresolved

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

  >&n= bsp; >> > > > > > issues.  This=0D=0Adiscussion l= ed us to call for a hum.

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

  >  >> > We are now

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

  >  >> > = > > > > asking the same=0D=0Aquestion on the list.

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

  >  >&= gt; > > > > >

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

  >  >> > > > >=0D=0A>&= nbsp;      Do you agree or disagree that PhoneBCP<= o:p>

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

  >-1= 3 is ready to

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

  >  >> > > > Publication<= /font>

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

  >  >> &g= t; > > > > Request=3F

=0D=0A=0D=0A<= p class=3DMsoPlainText>  >  >> > > > > ><= o:p>

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

  >&n= bsp; >> > > > >=0D=0A>     &n= bsp; Please respond by close of business on

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

  >Wednesday August

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

  >  >>= ; > > 5th.

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

  >  >> > > > > >

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

  >  >>= > > > >=0D=0A>       Thanks,<= o:p>

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

  >&n= bsp; >> > > > > >

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

  >  >> > > > >=0D=0A= >       Marc & Hannes

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

  >  >> = > > > > >

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

  >  >> > > > > >

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

  >  >&= gt; > > > > >

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

  >  >> > > > >=0D=0A_____= __________________________________________

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

  >  >> > > > > Ecr= it mailing list

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

  >  >> > > > > Ecrit@ietf.org

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

  >  &= gt;> > > > > https://www.ietf.org/mailman/listinfo/ecrit

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

  >&nb= sp; >> > > >

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

  >  >> > > > =3D

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

  >  >&= gt; >

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

&n= bsp; >  >> > =3D

=0D=0A=0D=0A<= p class=3DMsoPlainText>  >  >

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

  >  >____________________= ___________________________

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

  >  >Ecrit mailing list=

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

  >  >Ecrit@= ietf.org

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

&n= bsp; >  >https://www.ietf.org/mailman/listinfo/ecrit<= /span>

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

  >  >=

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

  >= ;_______________________________________________=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >Ecrit mailing list

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

  >Ecrit@i= etf.org

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

&nb= sp; >https://www.ietf.org/mailman/listinfo/ecrit

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

 =0D=0A>-----------------= --------------------------------------------

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

  >-------------------------------= ----

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

 = >This message is for the designated recipient only and may

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

  >contain priv= ileged, proprietary, or otherwise private=0D=0Ainformation.

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

  >If you have rec= eived it in error, please notify the sender

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

  >immediately and delete the orig= inal.  Any unauthorized=0D=0Ause

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

  >of this email is prohibited.<= /o:p>

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

 =0D=0A>= -------------------------------------------------------------

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

  >-------------= ----------------------

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

  >[mf2]

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

  >

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

  >

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

 

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


-= ---------------------------------------------------------------------------= --------------------
=0D=0AThis message is for the&n= bsp;designated recipient only and may
=0D=0Acontain&= nbsp;privileged, proprietary, or otherwise private = ;information.  
=0D=0AIf you have received = ;it in error, please notify the sender
=0D= =0Aimmediately and delete the original.  Any&= nbsp;unauthorized use of
=0D=0Athis email is pr= ohibited.
=0D=0A--------------------------------------------------------= ----------------------------------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01CA156D.4735074C-- From Martin.Dawson@andrew.com Wed Aug 5 02:00:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D233A7199 for ; Wed, 5 Aug 2009 02:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytwDH98v6p-f for ; Wed, 5 Aug 2009 02:00:03 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 47FD53A7189 for ; Wed, 5 Aug 2009 02:00:03 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_05_04_22_33 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 05 Aug 2009 04:22:32 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 03:59:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA15AB.18115637" Date: Wed, 5 Aug 2009 03:59:51 -0500 Message-ID: In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfA= References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> From: "Dawson, Martin" To: , X-OriginalArrivalTime: 05 Aug 2009 08:59:52.0697 (UTC) FILETIME=[186E8E90:01CA15AB] Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 09:00:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA15AB.18115637 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roland,=0D=0A=0D=0A=20=0D=0A=0D=0AI think what you're saying is that you= don't think that Germany will go on to implement full ECRIT support but wi= ll peg development at an interim phase. That would be disappointing - not l= east because full ECRIT compliance would ultimately decrease the overhead a= ssociated with emergency service support for operators as well as providing= a more universal service.=0D=0A=0D=0A=20=0D=0A=0D=0ANevertheless, I don't = think that decision invalidates the BCP; I think it just means that the Ger= man regulator and technical advisory committees would point out the subset = aspects of compliance that would be applicable to that jurisdiction. Actual= ly, based on your description below, the NENA i2 architecture would probabl= y be a more straightforward baseline for analysis - as has been done in the= UK and Canada. Of course, it's generally recognized as only an interim ste= p, even in those jurisdictions.=0D=0A=0D=0A=20=0D=0A=0D=0AOther comments be= low.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: ecrit-bounces@ietf.org= [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de=0D=0ASent= : Wednesday, 5 August 2009 6:19 PM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: Re= : [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0ADear all= ,=20=0D=0AWe would like the document to become a BCP as soon as possible so= the group can move on with other documents related to emergency calling ba= sed on location-by-reference and ED's IP-address.=20=0D=0A=0D=0A[[MCD]] I t= hink you might mean "identity extensions" rather than location-by-reference= because LbyR still requires the ED to obtain the reference - e.g. by HELD.=0D= =0A=0D=0ABut we can not HUM for the current form of the document.=20=0D=0A=0D= =0ABack to the document: Some requirements are far form being realistic, at= least in Germany, some are not realistic at all. Implementing these requir= ements cost a carrier a lot of money and there is no ROI for it.=20=0D=0A=0D= =0AJust a few examples:=20=0D=0A=0D=0A=B7 Requiring either geo or civ= ic location does not provide carriers with enough flexibility to reuse thei= r existing mechanisms and location databases. Routing of emergency calls is= currently done in Germany based on phone area code not on geo or civic loc= ation, at least for the fixed network. For mobile networks the cell-id is u= sed in common. This is regulated by the german regulator.=20=0D=0A=0D=0A[[M= CD]] How many unique PSAP routes are required in Germany=3F The US has lots= (6000 plus) and Australia has two (and they are redundant so it doesn't ma= tter which one). Presumably geographic information, for PSAP catchment area= s, is the basis for determining which area codes are relevant to begin with= =3F After all, an area code is not intrinsically geographic; it's a network= routing value. If so, then some geographic discriminator is already in pla= y in terms of constructing the area code based routing data (something like= zip codes perhaps=3F) - and in that case, it should be straightforward to = by-pass the area code step in the construction of routing that goes the cor= rect PSAP URI. With nomadic VoIP devices (and it's no good being in denial = about this being the norm in the future) area code is no more reliable than= it is for conventional mobile phones. And, presumably, area code is not us= ed for conventional cellular emergency call routing=3F=0D=0A=0D=0A1 = LOST as a national, let alone as a global directory is not going to b= e implemented. The regulator will provide in the web a static table which c= ontains the PSAPs and the area for which they are responsible (one or more = area codes). Every carrier has to implement its own routing database for em= ergency calls.=20=0D=0A=0D=0A[[MCD]] Whatever the carriers implement (and t= hey have to implement something) could just as readily be done using LoST. = Then visiting devices, with no association with any local VoIP proxy server= would still be able to determine a route to the correct PSAP. Alternativel= y, as long as the regulator is maintaining a web service with the routing i= nformation, why not make that directly accessible using LoST and save the o= perators the cost of duplicating the service at all=3F=0D=0A=0D=0A2 W= e have no intention to rely on end devices for location information because= :=20=0D=0A=B7 ED provided location info is not trusted=20=0D=0A=0D=0A= [[MCD]] Location by reference mitigates this trust issue. The emergency net= work can (automatically and before human resources are engaged) assess the = source of the reference, and the validity of the location by dereference, w= ithout having to trust location provided directly from the ED. There are mo= re sophisticated approaches to trustability even using LbyV - based on digi= tal signatures across appropriate attributes. This WG and Geopriv haven't r= eally got to grips with that... yet.=0D=0A=0D=0A=0D=0A1 There are alr= eady a lot of existing EDs in usage which don't send location. =20=0D=0A=0D= =0A[[MCD]] Quite right. ECRIT doesn't overly concern itself with that inter= im situation. The UK and Canadian definitions for an interim solution (limi= ting service to in-country VoIP proxy operators) both assume third-party qu= ery via identity-extension to allow the proxy or the VPC to make the query = to the LIS. This isn't extensible to universal emergency service access by = all visiting devices but it does put the necessary LIS functionality in pla= ce as a very good starting point. It would be a pity if Germany were to cea= se the evolution there as it would not fulfil the real promise of the Inter= net and the ECRIT model. Think about it; all the complexity of putting loca= tion determination infrastructure in place for the purposes of dispatch is = done - and then the next, simpler step, of using that to support the routin= g procedure isn't taken... that would be a waste.=0D=0A=0D=0A We don't int= end to require our ED-vendors to provide location because it is useless to = us. =20=0D=0A=0D=0AWe could agree with the document with following changes= :=20=0D=0A=0D=0A=09*=09Other location identifiers then geo or civil are all= owed. It must be possibe that the data foermat is flexible due to different= requirements from regulators over the whole world. (e.G Germany area codes= for fixed- and Cell-Id for moile- providers)=0D=0A=09*=09The MUST for the = end devices to support location information, DHCP location options and HELD= shall be removed=20=0D=0A=09*=09It must be possible for the VoIP-provider'= s proxy to use a LOST (or an ESRP) provided by the AN or by other local pro= vider on behalf of the AN. =20=0D=0A=0D=0A=20=0D=0A=0D=0A There is no value= in Hum-ing documents which one is not going to implement and does not fit = into regulated schemes like in Germany. Currently, neither the IETF- nor th= e 3GPP-architecture for emergency calling covers our real needs for the nex= t 2 to 5 years and in the end everybody still has its own proprietary imple= mentation. =20=0D=0A=0D=0ABest regards=20=0D=0A=0D=0ARoland=20=0D=0A=0D=0A= =20=0D=0A=0D=0ADeutsche Telekom Netzproduktion GmbH=0D=0AZentrum Technik Ei= nf=FChrung=0D=0ARoland Jesske=0D=0AGateways, Protokolle, Konvergenz, TE32-1=0D= =0AHeinrich-Hertz-Str. 3-7, 64295 Darmstadt,=0D=0APostfach, 64307 Darmstadt= (Postanschrift)=0D=0A+496151 628 2766 (Tel)=0D=0A+491718618445 (Mobile)=0D= =0AE-Mail: r.jesske@telekom.de =20=0D=0Ahttp:/= /www.telekom.de =20=0D=0A=0D=0A=20=0D=0A=0D=0ARegi= sterrechtliche Unternehmensangaben:=0D=0ADeutsche Telekom Netzproduktion (D= T NP) GmbH=0D=0AAufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=0D=0AGesch= =E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, K= laus Peren=0D=0AHandelsregister: Amtsgericht Bonn HRB 14190=0D=0ASitz der G= esellschaft: Bonn=0D=0AUSt-IdNr.: DE 814645262=20=0D=0A=0D=0A=20=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA15AB.18115637 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ARe: [Ecrit]= HUM on PhoneBCP=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A

I think it just means that the Germ= an=0D=0Aregulator and technical advisory committees would point out the sub= set aspects=0D=0Aof compliance that would be applicable to that jurisdictio= n.  <= /font>
=0D=0A[[LLi]]  Again, the draft is not flexible=0D=0Aen= ough for it.  If the BCP contains requirements which are not=0D= =0Arealistic, people will just discard the BCP and implement prop= rietary=0D=0Astuff. My expectation from a standard body is to define p= rotocols and=0D=0Aarchitecture which people are willing to implement in the= ir network or products=0D=0A, not only in the lab.

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

[[MCD]] What I= mean is that compliance isn’t=0D=0Acompulsory. It’s OK to say = “we have decided to deviate from the=0D=0Aspecification in this way&#= 8221;.<= span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>

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

 

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

[[LLi]] 

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

We are not against the draft in princi= ple.=0D=0AECRIT provides&n= bsp; us with very valu= able specifications as LbyR, HELD, identity=0D=0Aextensions. But targe= ting an architecture which requires everbody to=0D=0Ainvest witho= ut a business case will not help the draft in=0D=0Athe end, = also if it becomes a BCP.  It would make sense to make it=0D=0Amo= re flexible so people are willing to adopt it.    =

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

[[MCD]] = Lots of the elements you mention exist outside of=0D=0Athe BCP – LbyR= , HELD, identity extensions… they aren’t=0D=0Adefined by the BC= P and can be used in any other context. The BCP has a very=0D=0Aspecific go= al of defining a way that emergency calls can be made by any=0D=0AInternet = connected device/proxy anywhere that follows the specification; it=0D=0Adoe= sn’t seek to be more than that – which I think is what you̵= 7;re=0D=0Alooking for. As I say, check out the interim recommendations by t= he CRTC in Canada= and NICC in the UK.

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

 

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

 Actually, based on your descript= ion=0D=0Abelow, the NENA i2 architecture would probably be a more straightf= orward=0D=0Abaseline for analysis – as has been done in the UK and Canada. Of course, it’s=0D=0Agenerally recognized as only an interim = step, even in those jurisdictions.

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

Other comments below.=

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

 

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

Cheers,

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

M= artin

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

 

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

From:=0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@ie= tf.org] On Behalf Of R.= Jesske@telekom.de
=0D=0ASent:= Wednesday, 5 August 2009=0D=0A6:19 PM
=0D=0ATo: ecrit@ietf.org
=0D=0ASubject: Re: [Ecrit] HUM on=0D=0APhoneBCP

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

Hi Roland,

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

 

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

I think wha= t you’re saying is that=0D=0Ayou don’t think that Germany=0D=0Awill go on to implement full ECRIT support but will peg develo= pment at an=0D=0Ainterim phase. That would be disappointing – not lea= st because full ECRIT=0D=0Acompliance would ultimately decrease the overhea= d associated with emergency=0D=0Aservice support for operators as well as p= roviding a more universal service.

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

 

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

Nevertheless, I don’t think that=0D=0Adecision invalidates the = BCP; I think it just means that the German regulator=0D=0Aand technical adv= isory committees would point out the subset aspects of=0D=0Acompliance that= would be applicable to that jurisdiction. Actually, based on=0D=0Ayour des= cription below, the NENA i2 architecture would probably be a more=0D=0Astra= ightforward baseline for analysis – as has been done in the UK and Canada. Of course, it’s=0D=0Agenerally recognized as only an interim = step, even in those jurisdictions.

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

 

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

Other comments below.

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

 

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

C= heers,

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

Martin

=0D=0A=0D=0A<= p class=3DMsoNormal> 

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

From:=0D=0Aecrit-bounces@ietf.= org [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
=0D=0ASent: Wednesday, 5 August 2009=0D=0A6:19 PM
=0D= =0ATo: ecrit@ietf.org
=0D= =0ASubject: Re: [Ecrit] HUM = on=0D=0APhoneBCP

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

 

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

 <= /p>=0D=0A=0D=0A

Dear all,
=0D=0AWe would like the=0D=0Adocument to become a BCP as soon as possible so= the group can move on with=0D=0Aother documents related to emergency calli= ng based on location-by-reference and=0D=0AED’s IP-address.

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

[[MCD]] I=0D=0A= think you might mean “identity extensions” rather than=0D=0Aloc= ation-by-reference because LbyR still requires the ED to obtain the=0D=0Are= ference – e.g. by HELD.

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

But we can not HUM for the current form of=0D=0Athe docu= ment.

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

Back to the document: Some requirements=0D=0Aare far form = being realistic, at least in Germany, some are not realist= ic at=0D=0Aall. Implementing these requirements cost a carrier a lot of mon= ey and there is=0D=0Ano ROI for it.

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

Just a few examples:

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

=B7=        = Requiring either geo or=0D=0A= civic location does not provide carriers with enough flexibility to reuse t= heir=0D=0Aexisting mechanisms and location databases. Routing of emergency = calls is=0D=0Acurrently done in Germany=0D=0Abased on phone ar= ea code not on geo or civic location, at least for the fixed=0D=0Anetwork. = For mobile networks the cell-id is used in common. This is regulated=0D=0Ab= y the german regulator.

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

= = [[MCD]] How=0D=0Amany unique PSAP routes are required in Germany=3F The US has lots (6000 plus) and Australia has=0D=0Atwo (and th= ey are redundant so it doesn’t matter which one). Presumably=0D=0Ageo= graphic information, for PSAP catchment areas, is the basis for determining=0D= =0Awhich area codes are relevant to begin with=3F After all, an area code i= s not=0D=0Aintrinsically geographic; it’s a network routing value. If= so, then some=0D=0Ageographic discriminator is already in play in terms of= constructing the area=0D=0Acode based routing data (something like zip cod= es perhaps=3F) – and in that=0D=0Acase, it should be straightforward = to by-pass the area code step in the=0D=0Aconstruction of routing that goes= the correct PSAP URI. With nomadic VoIP=0D=0Adevices (and it’s no go= od being in denial about this being the norm in=0D=0Athe future) area code = is no more reliable than it is for conventional mobile=0D=0Aphones. And, pr= esumably, area code is not used for conventional cellular=0D=0Aemergency ca= ll routing=3F

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

1LOST as a national, let alon= e as a global=0D=0Adirectory is not going to be implemented. The regulator = will provide in the web=0D=0Aa static table which contains the PSAPs and th= e area for which they are=0D=0Aresponsible (one or more area codes). Every = carrier has to implement its own=0D=0Arouting database for emergency calls.=

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

[[MCD]]=0D=0AWha= tever the carriers implement (and they have to implement something) could=0D= =0Ajust as readily be done using LoST. Then visiting devices, with no assoc= iation=0D=0Awith any local VoIP proxy server would still be able to determi= ne a route to=0D=0Athe correct PSAP. Alternatively, as long as the regulato= r is maintaining a web=0D=0Aservice with the routing information, why not m= ake that directly accessible=0D=0Ausing LoST and save the operators the cos= t of duplicating the service at all=3F

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

2    &n= bsp;  We=0D=0Ahave no intention to rely on end devices for location in= formation because:
=0D=0A=B7      <= /font> ED provided location=0D=0Ainfo is not trusted

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

[[MCD]] Location=0D=0Aby reference mitigates this trust issue. The em= ergency network can=0D=0A(automatically and before human resources are enga= ged) assess the source of the=0D=0Areference, and the validity of the locat= ion by dereference, without having to=0D=0Atrust location provided directly= from the ED. There are more sophisticated=0D=0Aapproaches to trustability = even using LbyV – based on digital signatures=0D=0Aacross appropriate= attributes. This WG and Geopriv haven’t really got to=0D=0Agrips wit= h that… yet.

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


=0D= =0A1      =0D=0AThere are already a lot of ex= isting EDs in usage which don’t send=0D=0Alocation.   =

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

<= i>[[MCD]]= Quite=0D=0Aright. ECRIT doesn’t overly concern itself with that inte= rim situation. The=0D=0AUK=0D=0Aand Canadian definitions for a= n interim solution (limiting service to=0D=0Ain-country VoIP proxy operator= s) both assume third-party query via identity-extension=0D=0Ato allow the p= roxy or the VPC to make the query to the LIS. This isn’t=0D=0Aextensi= ble to universal emergency service access by all visiting devices but it=0D= =0Adoes put the necessary LIS functionality in place as a very good startin= g=0D=0Apoint. It would be a pity if Germany=0D=0Awere to cease= the evolution there as it would not fulfil the real promise of=0D=0Athe In= ternet and the ECRIT model. Think about it; all the complexity of putting=0D= =0Alocation determination infrastructure in place for the purposes of dispa= tch is=0D=0Adone – and then the next, simpler step, of using that to = support the=0D=0Arouting procedure isn’t taken… that would be a= waste.=

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

  We don’t intend to=0D=0Arequire= our ED-vendors to provide location because it is useless to=0D=0Aus. =  

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

We could agree with the document with=0D=0Afollowing ch= anges:

=0D=0A=0D=0A<= ul type=3Ddisc>=0D=0A
    =0D=0A
  • Th= e MUST for the end devices to support location=0D=0A information, DHCP= location options and HELD shall be removed
    • =0D= =0A
  • It must be possible for the VoIP-provider= ’s proxy to=0D=0A use a LOST (or an ESRP) provided by the AN or = by other local provider on=0D=0A behalf of the AN. 
    • =0D=0A
=0D=0A=0D=0A=0D=0A

 

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

 There is no value in Hum-in= g=0D=0Adocuments which one is not going to implement and does not fit into = regulated=0D=0Aschemes like in Germany.=0D=0ACurrently, neithe= r the IETF- nor the 3GPP-architecture for emergency calling=0D=0Acovers our= real needs for the next 2 to 5 years and in the end everybody still=0D=0Ah= as its own proprietary implementation.   

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

Best re= gards

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

Roland

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

 

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

Deutsche Telekom Netzproduktion GmbH
=0D=0AZentrum Tec= hnik Einf=FChrung
=0D=0ARoland Jesske
=0D=0AGateways, Protokolle, Konvergenz, TE32-1
=0D=0AHeinrich-Hertz-Str. 3-7, 642= 95 Darmstadt,
=0D=0APostfach, 64307 Darmstadt (Postanschrift)
=0D=0A+496151 628 2766 (Tel)
=0D=0A+491718618445 = (Mobile)
=0D=0AE-= Mail: r.jesske@telekom.de
=0D= =0Ahttp://www.telekom= =2Ede=0D=0A

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

 

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

Registerrechtliche Unternehmensangaben:<= /font>
=0D=0ADeutsche Tele= kom Netzproduktion (DT NP) GmbH
=0D=0AAufsichtsrat: Timotheus H=F6ttges = (Vorsitzender)
=0D=0AGesch=E4ftsf=FChrung: Dr. Bruno=0D=0AJacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
=0D=0AHandelsregister: Amtsgericht Bonn HR= B 14190
=0D=0ASitz der Gesellschaft: Bonn
=0D=0AUSt-IdNr.: DE 8146452= 62

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

 

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


-------= ---------------------------------------------------------------------------= --------------
=0D=0AThis message is for the de= signated recipient only and may
=0D=0Acontain p= rivileged, proprietary, or otherwise private infor= mation.  
=0D=0AIf you have received it&nb= sp;in error, please notify the sender
=0D=0Aimm= ediately and delete the original.  Any u= nauthorized use of
=0D=0Athis email is prohibit= ed.
=0D=0A--------------------------------------------------------------= ----------------------------------
=0D=0A[mf2]
=0D= =0A=0D=0A=0D=0A ------_=_NextPart_001_01CA15AB.18115637-- From Hannes.Tschofenig@gmx.net Wed Aug 5 03:16:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634B73A6B03 for ; Wed, 5 Aug 2009 03:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=1.281, 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 gxvRT5D5EUw7 for ; Wed, 5 Aug 2009 03:16:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F32833A6B32 for ; Wed, 5 Aug 2009 03:16:43 -0700 (PDT) Received: (qmail invoked by alias); 05 Aug 2009 10:16:38 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp003) with SMTP; 05 Aug 2009 12:16:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19UKaMlHaBUXXyT9Ty9l4OQ9U8/65OloYARJVzmnI 69P247ltB+7SPB From: "Hannes Tschofenig" To: "'ecrit'" Date: Wed, 5 Aug 2009 13:19:09 +0300 Message-ID: <023801ca15b6$2bfa3710$625aa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVqwrnypjSesBJQdywZdZWkC+5JgACtCIw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Subject: [Ecrit] Review request for draft-ohba-802dot21-basic-schema X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 10:16:45 -0000 We would need someone to review draft-ohba-802dot21-basic-schema with a focus on the emergency services aspects (which are quite small). It would be good to have someone who is also familiar with the IEEE 802.21 work. Ciao Hannes >-----Original Message----- >From: Jari Arkko [mailto:jari.arkko@piuha.net] >Sent: 05 August, 2009 11:59 >To: Yoshihiro Ohba; Lisa Dusseault; Alexey Melnikov >Cc: Ecrit Chairs; Subir Das >Subject: Re: draft-ohba-802dot21-basic-schema > >Yoshihiro, Lisa, Alexey, > >Is there a new version of the draft that addresses the small >issues that I raised in my review? And Lisa/Alexey, is there a >way for me to get an RDF expert to review this document? I'm >not expert enough myself... > >Jari > >Jari Arkko wrote: >> Yoshihiro, Subir, >> >> I apologize for taking too long with this. Is this matter >still relevant? >> >> I have finally reviewed the draft. I ended up doing a complete >> re-review, because the diffs from last time were too big, >and I didn't >> remember all my comments anyway. I think the contents of the scheme >> are largely OK, though there were a number of small issues noted >> below. The larger issues are whether the RDF schema is done >correctly, >> and various specialized content (specifics of some link layers, >> emergency call information, ..) in the draft. I would like >to ask help >> from Alexey and Lisa to find an RDF reviewer, and from >Hannes and Marc >> about the emergency issues. Do you know what kind of review >happened in 802.21 vs. >> .11, .16, 3GPP, and 3GPP2 for their respective link-layer >related stuff? >> >> Anyway, my general idea is that my review and the above two reviews >> would be used to improve the scheme (if needed) and then we should >> just publish it. I confess that I'm on the fence about an IETF >> Informational document that goes through a Last Call, and an >RFC Editor submission. >> But either, way I think these reviews are necessary and useful. >> >> Here are my review comments: >> >> * There are some acronyms used before definition: PLMN, CDMA (at >> least) >> >> * There are several references to Annex something in the draft, >> presumably these should be to 802.21 specs, or somewhere >else in this >> spec. The spec says "Section numbers cited in comment tags without a >> reference to a ... ", maybe it should say "Section and >appendix .." or >> something that effect? >> >> * "subtype" isn't referenced by anything else. Is that correct? >> >> * I do not understand who can allocate "type_ext" values. Has this >> been defined in more detail in 802.21? The text does not live up to >> the preciseness that we would normally require from IANA >> considerations section, for instance. >> >> * Is there a better reference than an URL for unicode-xml? >> >> * ie_network_aux_id makes a point that it contains a HESSID. Is >> ie_network_id then an ESSID? Shouldn't this be documented? >> >> * I see that you have implemented some of the changes from >my previous >> review, and these now show up as differences wrt 802.21 >original spec. >> I want to give you an opportunity to change some of these back to >> avoid the discrepancy *if* the issue was merely a different way to >> represent the same thing, not a bug. But don't unfix bugs... and >> clearly, the addition of comments has rendered this version >of the document readable! >> Thank you for that. >> >> * Typo: "acronims" >> >> * Bit 0 (Security) ie_net_capabilities is a VERY weak definition. >> >> * It would be good to get standard references (e.g. RFC numbers) in >> the comment for ie_net_supported_lcp. >> >> * ie_net_mob_management_prot has a bit that is set when there's a >> MOBIKE node in the network. I guess you can set the bit whenever >> there's a Windows 7 PC in the network :-) Seriously though, I think >> you should rather indicate the existence of a MOBIKE node in a >> home-agent like role in the network or remove this altogether. I am >> not aware of MOBIKE being used in this mode, though I would >of course personally like that. >> >> * I don't understand how "3gpp_addr" can have anything to do >with the >> mobile's address (TMSI and so on). Are you trying to simulate the >> address of the WLAN access point? I think that is the PLMN and cell >> IDs, or possibly the empty string, not the mobile node's >address. But >> maybe I'm missing something. >> >> Jari >> >> >> > From khwolf1@gmail.com Wed Aug 5 05:01:25 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7263D3A67D7 for ; Wed, 5 Aug 2009 05:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95GT1B9PQu8u for ; Wed, 5 Aug 2009 05:01:24 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 9585B3A68DB for ; Wed, 5 Aug 2009 05:01:23 -0700 (PDT) Received: by fxm26 with SMTP id 26so32679fxm.42 for ; Wed, 05 Aug 2009 05:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AVBs8VnnTTvJIITptpVQXxbEZG77fJLirakUJ/prj4Y=; b=Gs5cdBxqMo3IpK51Ac8v3vfStybt2Z2aI/Q/9g2NYuTq85OzZWwfVXoNECCwkRh1ye kNmOvJiu9x8WQWgFA+WIE2PScI4xPDkweeKj8w0MPHEwbAIkvJW6ISfKKU0iFbXzLC/o 4YCwzNk/RP+ejnoCf4jhbB55ONVhpsdIZCv1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Xf2X6iqqSH5vm6TRJYTe9UcU2Xnb9RyVBtPI/lipGo3ZLu0j7lkWjLqZp/kwbgHMcM Xr7eDtwTrvVl3+Z9jVnOAdbRH7EfKxU+CrOwOoZHiebHPPRmq5KP75100lRgcnknaAj5 so1oAEI82GzjxKpo71ZoCPOeoiy6izHG0Bn44= MIME-Version: 1.0 Received: by 10.103.131.8 with SMTP id i8mr4743163mun.124.1249473683962; Wed, 05 Aug 2009 05:01:23 -0700 (PDT) In-Reply-To: <025101ca1054$218e9490$64abbdb0$@net> References: <024101ca1051$26a6c720$73f45560$@net> <025101ca1054$218e9490$64abbdb0$@net> Date: Wed, 5 Aug 2009 14:01:23 +0200 Message-ID: From: Karl Heinz Wolf To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 12:01:25 -0000 My idea was actually to have the service boundary as a role model since it is pretty much the same problem. So I'm not sure if the definition of a separate service or subservice is necessary. The service boundary is optional in RFC 5222, why not have an optional boundary information for the service list? If the server knows the boundary for urn:service:sos, it can hand it out. If it does not know it for urn:service:pizza, it returns no servicelistboundary. Is there a problem with this approach? karl heinz On Wed, Jul 29, 2009 at 3:54 PM, Brian Rosen wrote: > Well, I was thinking of either explicitly defining a subservice, much as = we > have defined sos and sos.police OR perhaps defining the urn so that any > token(s) after servicelistboundary be treated as a filter for which servi= ces > were composed into the servicelistboundary, with the default being all of > the services the LoST server handles. > > Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Brian Rosen >> Sent: Wednesday, July 29, 2009 9:33 AM >> To: 'Karl Heinz Wolf'; 'Ted Hardie' >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting >> today >> >> Perhaps the service URN has some sub urns, like >> urn:service:servicelistboundary.sos >> >> >> > -----Original Message----- >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> > Of Karl Heinz Wolf >> > Sent: Wednesday, July 29, 2009 9:21 AM >> > To: Ted Hardie >> > Cc: ECRIT >> > Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting >> > today >> > >> > Ted, >> > >> > thank you for your clarification. >> > >> > You might be correct, I probably focused too much on emergency >> > services. But there it hurts the most: if you're unaware of the >> > service, you don't have the dialstring and you definitely cannot >> > detect the emergency call to this service. >> > >> > On Wed, Jul 29, 2009 at 2:27 PM, Ted Hardie >> wrote: >> > > At 5:01 AM -0700 7/29/09, Karl Heinz Wolf wrote: >> > >>There was some discussion during the meeting today on my draft >> > >>http://tools.ietf.org/html/draft-wolf-ecrit-lost- >> servicelistboundary- >> > 01 >> > >> >> > >>My main concern is how to ensure that a client never misses a >> change >> > >>in available services and consequently learns all location >> dependent >> > >>dialstrings for the current location in order to be able to detect >> an >> > >>emergency call based on the dialstring. >> > > >> > > I think this is where the draft is a bit unclear. =A0Let's start fro= m >> > > what RFC 5222 says: >> > > >> > > =A0A LoST client can ask a LoST server for the list of services it >> > knows >> > > =A0 about for a particular area. =A0The que= ry >> > > =A0 contains one or more elements, each from a different >> > > =A0 location profile (Section 12), and may contain the >> > element. >> > > =A0 As for , the server selects the first location >> element >> > > =A0 that has a profile the server understands and it can operate >> either >> > > =A0 recursively or iteratively; elements track the progress of >> > the >> > > =A0 request. =A0The query indicates the services that the server can >> > > =A0 enumerate from within the forest structure of which it is a part= . >> > > =A0 Because LoST does not presume a single, overarching organization >> of >> > > =A0 all potential service types, there may be services available >> within >> > a >> > > =A0 geographic area that could be described by other LoST servers >> > > =A0 connected to other forest structures. =A0As an example, the >> emergency >> > > =A0 services forest for a region may be distinct from the forests >> that >> > > =A0 locate commercial services within the same region. >> > > >> > > =A0 If the query contains the element, the LoST server >> > returns >> > > =A0 only immediate child services of the queried service that are >> > > =A0 available for the provided location. =A0If the element= is >> > > =A0 absent, the LoST service returns all top-level services availabl= e >> > for >> > > =A0 the provided location that it knows about. >> > > >> > > The current mechanism only works within a single forest structure. >> > > This draft is not clear, at least to me, in being scoped to a >> single >> > > forest structure, and the discussion in the room wandered around >> > > that topic (partly by referring to the services for which the >> > responding >> > > servers are authoritative). >> > > >> > right, the draft does not explicitly say this at the moment. >> > Thank you for pointing this out, it helps me understanding the >> > discussion better. >> > > >> > >>Currently the listServiceByLocation response does not give any >> > >>information on the area the service list is valid for. So a client >> > >>might miss a change in the available services, so it won't have the >> > >>dialstring configured and is not able to detect an emergency call. >> > > >> > > But there are many more available services than emergency services. >> > > These will also change. =A0Are we clear that this only captures >> changes >> > > to those within a service hierarchy? >> > > >> > >> > but you don't need to know the dialstring for pizza in advance: if >> you >> > press the pizza button on your device, it can simply do the service >> > discovery. >> > >> > > >> > >>The problem arises in countries not having a single emergency >> > >>dialstring, like 911, but having different dialstrings for >> different >> > >>services and dialstrings as well as services depend on location. >> When >> > >>travelling around, the availability of services may change, as well >> > as >> > >>the dialstrings. So there needs to be some kind of rule on when to >> > >>update the service list. Since the service boundary tells when to >> do >> > a >> > >>findService again, I thought it would be consistent to introduce >> > >>another boundary to tell the client when to update the service list >> > >>(as proposed in the draft). >> > > >> > > In the past, we discussed this in terms of time, rather than >> > movement; >> > > this was because the list could also change because of additions >> > (again, >> > > not so much for emergency servies, but potentially for other >> > services) >> > > >> > >> > I wasn't talking about changes in time - sorry if didn't express that >> > clearly. Besides, the changes in time would be addressed by the >> > expires attribute. >> > >> > > >> > >>Since I was just listening remotely to the discussion, I'd like to >> > ask >> > >>if I understood Ted's idea correctly: instead of a boundary >> > indicating >> > >>the area, the service list is valid for, the LoST Server should >> also >> > >>return services that are NOT available at the current location. >> > >>This would mean: when a client does a findService for >> > >>urn:service:sos.ambulance for its current location, it would also >> get >> > >>back a mapping for urn:service:sos.physician for a different >> > location? >> > > >> > > No; it sounds like something got lost here. =A0I was first proposing >> > that >> > > this should be limited in applicability, essentially to a single >> > forest or >> > > service type. =A0Then I was suggesting that a server able to travers= e >> > that >> > > forest respond with a list of relevant services but without >> location >> > > boundary information for those not available in the area relevant >> > > to the query. =A0That is, you do a query using findServicebyLocation >> > for >> > > urn:service:geg and get back urn:service:geg.orthozog with a >> > boundary, >> > > and urn:service:geg.mumblefratz. with no boundary. =A0That avoids >> > > dumping the database (and the current server having to collect the >> > > information about where geg.mumblefratz is available); it simply >> > > lets the client know that there are other services out there which >> > > are explicitly not available at the target site of the first query. >> > > >> > > If the client wants to use geg.mumblefratz, it needs to re-query. >> > > It can requery at some specified time scale, or it can requery on >> > > only when it wants to use geg.mumblefratz. >> > > >> > >> > hm, as I understand it, the client has still the same problem: when >> > does the service become available? The only information the client >> > gets is that this service is available "somewhere". I'm not sure this >> > is helpful? >> > Moreover, considering the emergency service case, you have to know >> the >> > dialstring right before the call. I know I'm concentrating on >> > emergency services... >> > >> > > I was somewhat surprised, honestly, to see Henning arguing >> > > for this, since he has argued against this idea in the past. =A0This >> > > makes me suspect I am missing some subtle difference, >> > > and I would not be surprised to find that this is so. =A0I would >> > > like, however, if we did not concentrate on the emergency >> > > services use case to the exclusion of other use cases; that >> > > tends to skew the design in ways that will limit LoST's usefulness >> > > in other realms. >> > >> > I'm afraid we need some kind of rule on when to update the service >> > list when travelling. And this is crucial for figuring out the >> > dialstings as long as there is not a single emergency dialstring all >> > over the world. >> > I'm not sure if the servicelistboundary makes much sense for other >> > services, since as you pointed out, they may just get discovered on >> > demand without any problems. >> > However, also the service boundary is optional in LoST, also the >> > servicelistboundary could just be optional and only be returned in >> > case the server knows it or it's about emergency services. >> > >> > karl heinz >> > >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ted H= ardie >> > > >> > >>So when moving to this other area, the client already knows which >> > >>services and dialstrings are available there. >> > >>I'm afraid this approach would just solve the problem in case the >> > LoST >> > >>Server would dump more or less it's complete database to the >> client. >> > >>If the LoST Server would just send a couple of mappings, and others >> > >>not, the client could still be lost. >> > >>Besides, traffic and complexity for the client would increase. The >> > >>servicelistboundary wouldn't increase complexity too much for a >> > client >> > >>already evaluating the service boundary, since all the necessary >> > >>functionality should be already in place. On the server side, the >> > >>complexity should also be manageable (the servicelistboundary could >> > be >> > >>pre-calculated for the area the server has data for). >> > >> >> > >>Please let me know if I missed something in the discussion. >> > >> >> > >>karl heinz >> > >>_______________________________________________ >> > >>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 dirk.kroeselberg@nsn.com Wed Aug 5 05:35:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3943A6B82 for ; Wed, 5 Aug 2009 05:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 WzAPItq8sMr2 for ; Wed, 5 Aug 2009 05:35:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D40B53A6906 for ; Wed, 5 Aug 2009 05:35:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n75CZQHL023565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2009 14:35:26 +0200 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 n75CZQkC017485; Wed, 5 Aug 2009 14:35:26 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:35:26 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 5 Aug 2009 14:32:28 +0200 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6701A5AB6A@DEMUEXC030.nsn-intra.net> In-Reply-To: <023801ca15b6$2bfa3710$625aa20a@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review request for draft-ohba-802dot21-basic-schema Thread-Index: AcoVqwrnypjSesBJQdywZdZWkC+5JgACtCIwAALcvKA= References: <023801ca15b6$2bfa3710$625aa20a@nsnintra.net> From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "ecrit" X-OriginalArrivalTime: 05 Aug 2009 12:35:26.0230 (UTC) FILETIME=[356B1360:01CA15C9] Subject: Re: [Ecrit] Review request for draft-ohba-802dot21-basic-schema X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 12:35:27 -0000 Hi Hannes,=20 looking at the -05 draft, here is one comment that is similar to one of Jari's comments:=20 The only explicit place where emergency support seems of relevance is in the NETWORK type for the network capabilities.=20 I have the same comment as Jari for bit#0 security. Also bit#8 emergency services seems to be a weak definition. If there is some related logic behind it would be good to add or reference it. Otherwise, it seems questionable what the use of this could be in practice: - looking at it from the underlying access technology, the bit would not help to provide further information about support for specific options to support emergency within the access technology.=20 - it also cannot help to tell what sort of suitable emergency service is out there and how to discover it. - regarding the regulatory domain: there is a separate data type property REGU_DOMAIN. I am not sure what information is covered by the REGU_DOMAIN besides country code, but it seems unclear whether any combination of REGU_DOMAIN and bit#8 would provide any additional useful information. In general, something like indication for support of unauthorized or unauthenticated calls (that can in general be supported by the access but may be enabled/disabled based on regional requirements) might be of some use, but it would be really hard to define this as it already seems hard to agree on consistent terminology in this area. Without any clear use (that I might just be missing) it might be safer to drop this instead of risking implementations to interpret it in different ways. Dirk > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of ext Hannes Tschofenig > Sent: Wednesday, August 05, 2009 12:19 PM > To: 'ecrit' > Subject: [Ecrit] Review request for draft-ohba-802dot21-basic-schema >=20 > We would need someone to review=20 > draft-ohba-802dot21-basic-schema with a > focus on the emergency services aspects (which are quite=20 > small). It would be > good to have someone who is also familiar with the IEEE 802.21 work.=20 >=20 > Ciao > Hannes >=20 > >-----Original Message----- > >From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > >Sent: 05 August, 2009 11:59 > >To: Yoshihiro Ohba; Lisa Dusseault; Alexey Melnikov > >Cc: Ecrit Chairs; Subir Das > >Subject: Re: draft-ohba-802dot21-basic-schema > > > >Yoshihiro, Lisa, Alexey, > > > >Is there a new version of the draft that addresses the small=20 > >issues that I raised in my review? And Lisa/Alexey, is there a=20 > >way for me to get an RDF expert to review this document? I'm=20 > >not expert enough myself... > > > >Jari > > > >Jari Arkko wrote: > >> Yoshihiro, Subir, > >> > >> I apologize for taking too long with this. Is this matter=20 > >still relevant? > >> > >> I have finally reviewed the draft. I ended up doing a complete=20 > >> re-review, because the diffs from last time were too big,=20 > >and I didn't=20 > >> remember all my comments anyway. I think the contents of=20 > the scheme=20 > >> are largely OK, though there were a number of small issues noted=20 > >> below. The larger issues are whether the RDF schema is done=20 > >correctly,=20 > >> and various specialized content (specifics of some link layers,=20 > >> emergency call information, ..) in the draft. I would like=20 > >to ask help=20 > >> from Alexey and Lisa to find an RDF reviewer, and from=20 > >Hannes and Marc=20 > >> about the emergency issues. Do you know what kind of review=20 > >happened in 802.21 vs. > >> .11, .16, 3GPP, and 3GPP2 for their respective link-layer=20 > >related stuff? > >> > >> Anyway, my general idea is that my review and the above=20 > two reviews=20 > >> would be used to improve the scheme (if needed) and then we should=20 > >> just publish it. I confess that I'm on the fence about an IETF=20 > >> Informational document that goes through a Last Call, and an=20 > >RFC Editor submission. > >> But either, way I think these reviews are necessary and useful. > >> > >> Here are my review comments: > >> > >> * There are some acronyms used before definition: PLMN, CDMA (at=20 > >> least) > >> > >> * There are several references to Annex something in the draft,=20 > >> presumably these should be to 802.21 specs, or somewhere=20 > >else in this=20 > >> spec. The spec says "Section numbers cited in comment tags=20 > without a=20 > >> reference to a ... ", maybe it should say "Section and=20 > >appendix .." or=20 > >> something that effect? > >> > >> * "subtype" isn't referenced by anything else. Is that correct? > >> > >> * I do not understand who can allocate "type_ext" values. Has this=20 > >> been defined in more detail in 802.21? The text does not=20 > live up to=20 > >> the preciseness that we would normally require from IANA=20 > >> considerations section, for instance. > >> > >> * Is there a better reference than an URL for unicode-xml? > >> > >> * ie_network_aux_id makes a point that it contains a HESSID. Is=20 > >> ie_network_id then an ESSID? Shouldn't this be documented? > >> > >> * I see that you have implemented some of the changes from=20 > >my previous=20 > >> review, and these now show up as differences wrt 802.21=20 > >original spec.=20 > >> I want to give you an opportunity to change some of these back to=20 > >> avoid the discrepancy *if* the issue was merely a different way to=20 > >> represent the same thing, not a bug. But don't unfix bugs... and=20 > >> clearly, the addition of comments has rendered this version=20 > >of the document readable! > >> Thank you for that. > >> > >> * Typo: "acronims" > >> > >> * Bit 0 (Security) ie_net_capabilities is a VERY weak definition. > >> > >> * It would be good to get standard references (e.g. RFC=20 > numbers) in=20 > >> the comment for ie_net_supported_lcp. > >> > >> * ie_net_mob_management_prot has a bit that is set when there's a=20 > >> MOBIKE node in the network. I guess you can set the bit whenever=20 > >> there's a Windows 7 PC in the network :-) Seriously=20 > though, I think=20 > >> you should rather indicate the existence of a MOBIKE node in a=20 > >> home-agent like role in the network or remove this=20 > altogether. I am=20 > >> not aware of MOBIKE being used in this mode, though I would=20 > >of course personally like that. > >> > >> * I don't understand how "3gpp_addr" can have anything to do=20 > >with the=20 > >> mobile's address (TMSI and so on). Are you trying to simulate the=20 > >> address of the WLAN access point? I think that is the PLMN=20 > and cell=20 > >> IDs, or possibly the empty string, not the mobile node's=20 > >address. But=20 > >> maybe I'm missing something. > >> > >> Jari > >> > >> > >> =20 > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From RMarshall@telecomsys.com Wed Aug 5 11:15:51 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864B63A68F2 for ; Wed, 5 Aug 2009 11:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMPChaGKhsSz for ; Wed, 5 Aug 2009 11:15:50 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id 04E9A3A6768 for ; Wed, 5 Aug 2009 11:15:49 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 5 Aug 2009 11:15:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA15F8.B8133DAE" Date: Wed, 5 Aug 2009 11:15:54 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750D94EB32@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoREt1onZENnh8yQoqYnBaz4pX1ZAE5O0lQ References: From: "Roger Marshall" To: "Randall Gellens" , "DRAGE, Keith (Keith)" , "Marc Linsner" , "ecrit" Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:15:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA15F8.B8133DAE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on a little more detail, I agree that the document is NOT ready. =20 =20 I have been told that 3GPP's intent is to discuss this at their next formal meeting. If we say that we want to work together with 3GPP, then we should hold off moving it forward until we receive their feedback. =20 -roger marshall. ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: Thursday, July 30, 2009 5:40 AM To: DRAGE, Keith (Keith); Marc Linsner; 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 +1. The document is not ready. Further, there is a liaison from 3GPP SA2 that says that they intend to send further liaison on this document. We should wait at least a little while for this liaison. At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote: I don't agree. =20 Some background. =20 There was a set of comments provided by Stephen Edge on 5th February 2009. I can find no response to that set of comments on the mailing list. =20 The gist of that set of comments was that phonebcp claims to cover all access technologies and it identified a significant number of requirements within phonebcp that the author considered were not requirements on 3GPP accesses. =20 So my position is that the document is not ready because all the valid comments on the document were not addressed. =20 There are two ways of dealing with this set of comments: =20 - going through and modifying all the identified requirements where the comment is upheld. =20 - making more clear in the abstract and / or introduction that this is solely the view of IETF in regard to IP capable devices and that other organisations may specify other requirements. =20 I would note at this point that the current abstract says: =20 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. =09 Because the two sentences follow each other, it implies that other SDOs that have efforts targetted at addressing these solutions are complicit in the requirements so stated, and this is untrue. Certainly the current status of this document as addressed by various informal 3GPP discussions is to ensure that things do not fall apart in entities using the 3GPP mechanisms, however 3GPP devices do not use these requirements (no do these requirements represent the 3GPP requires. =20 One solution to the issue would just be to make much clearer which SDOs have participated in this work and which have not and the status of that progress - however that was also what people keep calling the "applicability statement" was trying to do. =20 regards =20 Keith =20 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, July 29, 2009 2:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP =09 During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. =09 Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? =09 Please respond by close of business on Wednesday August 5th. =09 Thanks, =09 Marc & Hannes --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I worry that the person who thought up Muzak may be thinking up something else. --Lily Tomlin =09 CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_001_01CA15F8.B8133DAE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP
Based on a little more detail, I agree that the do= cument is=20 NOT ready. 
 
I have been told that 3GPP's intent is to discuss = this at=20 their next formal meeting.  If we say that we want to work togeth= er=20 with 3GPP, then we should hold off moving it forward until we receive = their=20 feedback.
 
-roger marshall.

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall=20 Gellens
Sent: Thursday, July 30, 2009 5:40 AM
To: DRA= GE,=20 Keith (Keith); Marc Linsner; 'ecrit'
Subject: Re: [Ecrit] HUM o= n=20 PhoneBCP

+1.  The document is not ready.

Further, there is a liaison from 3GPP SA2 that says that they intend= to=20 send further liaison on this document.  We should wait at least a li= ttle=20 while for this liaison.

At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote:

I = don't=20 agree.
 
So= me=20 background.
 
Th= ere was a=20 set of comments provided by Stephen Edge on 5th February 2009. I can fi= nd no=20 response to that set of comments on the mailing list.
 
Th= e gist of=20 that set of comments was that phonebcp claims to cover all access=20 technologies and it identified a significant number of requirements wit= hin=20 phonebcp that the author considered were not requirements on 3GPP=20 accesses.
 
So= my=20 position is that the document is not ready because all the valid commen= ts on=20 the document were not addressed.
 
Th= ere are two=20 ways of dealing with this set of comments:
 
-    going through and modifying all the= =20 identified requirements where the comment is upheld.
 
-    making more clear in the abstract a= nd / or=20 introduction that this is solely the view of IETF in regard to IP capab= le=20 devices and that other organisations may specify other=20 requirements.
 
I = would note=20 at this point that the current abstract says:
 
&n= bsp; =20 The IETF and other standards organization have efforts targeted=20 at
&n= bsp; =20 standardizing various aspects of placing emergency calls on=20 IP
   networks.  This memo describes best current pra= ctice=20 on how devices,
   networks and services should use such=20 standards to make emergency
   calls.
Be= cause the=20 two sentences follow each other, it implies that other SDOs that have=20 efforts targetted at addressing these solutions are complicit in the=20 requirements so stated, and this is untrue. Certainly the current statu= s of=20 this document as addressed by various informal 3GPP discussions is to e= nsure=20 that things do not fall apart in entities using the 3GPP mechanisms, ho= wever=20 3GPP devices do not use these requirements (no do these requirements=20 represent the 3GPP requires.
 
On= e solution=20 to the issue would just be to make much clearer which SDOs have partici= pated=20 in this work and which have not and the status of that progress - howev= er=20 that was also what people keep calling the "applicability statement" wa= s=20 trying to do.
 
regards
 
Keith
 
 

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc=20 Linsner
Sent: Wednesday, July 29, 2009 2:53 PM
To:=20 'ecrit'
Subject: [Ecrit] HUM on PhoneBCP
During today's meeting there was discu= ssion=20 as to why the chairs Publication Requested PhoneBCP version 13 when t= here=20 are unresolved issues.  This discussion led us to call for a hum= .=20  We are now asking the same question on the list.

Do you agree or disagree that PhoneBCP -13 is ready t= o=20 Publication Request?

Please respond by close of business on=20 Wednesday August 5th.

Thanks,
Marc &=20 Hannes

--=20
Randall Gellens
Opinions are=20 personal;    facts are suspect;    I speak = for=20 myself only
-------------- Randomly selected tag: ---------------
I= =20 worry that the person who thought up Muzak may be thinking up
somethin= g=20 else.
 --Lily Tomlin

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

------_=_NextPart_001_01CA15F8.B8133DAE-- From KENNETH.G.CARLBERG@saic.com Wed Aug 5 11:22:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3E328C4AE for ; Wed, 5 Aug 2009 11:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+PLOOu1kj0e for ; Wed, 5 Aug 2009 11:22:15 -0700 (PDT) Received: from mclmx2.mail.saic.com (mclmx2.mail.saic.com [149.8.64.32]) by core3.amsl.com (Postfix) with ESMTP id 2A57B3A68F2 for ; Wed, 5 Aug 2009 11:22:15 -0700 (PDT) Received: from 0015-its-sbg01.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP id BT-MMP-4766196; Wed, 5 Aug 2009 14:22:06 -0400 X-AuditID: 9508401a-b7c3aae00000420b-a1-4a79cdcdc177 Received: from 0015-its-exbh03.us.saic.com (mcl-sixl-nat.saic.com [149.8.64.21]) by (Symantec Brightmail Gateway) with SMTP id C0.7C.16907.DCDC97A4; Wed, 5 Aug 2009 14:22:06 -0400 (EDT) Received: from 0015-its-exmb11.us.saic.com ([10.43.229.22]) by 0015-its-exbh03.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:22:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA15F9.A2F20EF8" Date: Wed, 5 Aug 2009 14:22:05 -0400 Message-Id: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750D94EB32@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoREt1onZENnh8yQoqYnBaz4pX1ZAE5O0lQAABQl0A= References: <8C837214C95C864C9F34F3635C2A65750D94EB32@SEA-EXCHVS-2.telecomsys.com> From: "Carlberg, Kenneth G." To: "Roger Marshall" , "Randall Gellens" , "DRAGE, Keith (Keith)" , "Marc Linsner" , "ecrit" X-OriginalArrivalTime: 05 Aug 2009 18:22:05.0758 (UTC) FILETIME=[A2E72DE0:01CA15F9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:22:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA15F9.A2F20EF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable out of curiousity, when is their next meeting, and how strong is this "intent"? Is it firm on their calendar, or is there a reasonable possibility that it won't be discussed but deferred until some future time? =20 (speaking as one who has no stake in the matter other than wishing it get resolved soon) =20 -ken =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, August 05, 2009 2:16 PM To: Randall Gellens; DRAGE, Keith (Keith); Marc Linsner; ecrit Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 Based on a little more detail, I agree that the document is NOT ready. =20 =20 I have been told that 3GPP's intent is to discuss this at their next formal meeting. If we say that we want to work together with 3GPP, then we should hold off moving it forward until we receive their feedback. =20 -roger marshall. ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: Thursday, July 30, 2009 5:40 AM To: DRAGE, Keith (Keith); Marc Linsner; 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 +1. The document is not ready. Further, there is a liaison from 3GPP SA2 that says that they intend to send further liaison on this document. We should wait at least a little while for this liaison. At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote: I don't agree. =20 Some background. =20 There was a set of comments provided by Stephen Edge on 5th February 2009. I can find no response to that set of comments on the mailing list. =20 The gist of that set of comments was that phonebcp claims to cover all access technologies and it identified a significant number of requirements within phonebcp that the author considered were not requirements on 3GPP accesses. =20 So my position is that the document is not ready because all the valid comments on the document were not addressed. =20 There are two ways of dealing with this set of comments: =20 - going through and modifying all the identified requirements where the comment is upheld. =20 - making more clear in the abstract and / or introduction that this is solely the view of IETF in regard to IP capable devices and that other organisations may specify other requirements. =20 I would note at this point that the current abstract says: =20 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. =09 Because the two sentences follow each other, it implies that other SDOs that have efforts targetted at addressing these solutions are complicit in the requirements so stated, and this is untrue. Certainly the current status of this document as addressed by various informal 3GPP discussions is to ensure that things do not fall apart in entities using the 3GPP mechanisms, however 3GPP devices do not use these requirements (no do these requirements represent the 3GPP requires. =20 One solution to the issue would just be to make much clearer which SDOs have participated in this work and which have not and the status of that progress - however that was also what people keep calling the "applicability statement" was trying to do. =20 regards =20 Keith =20 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, July 29, 2009 2:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP =09 During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. =09 Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? =09 Please respond by close of business on Wednesday August 5th. =09 Thanks, =09 Marc & Hannes --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I worry that the person who thought up Muzak may be thinking up something else. --Lily Tomlin =09 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. ------_=_NextPart_001_01CA15F9.A2F20EF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP
out of curiousity, when is their next meeting, = and how=20 strong is this "intent"?  Is it firm on their calendar, or is there = a=20 reasonable possibility that it won't be discussed but deferred until = some future=20 time?
 
(speaking as one who has no stake in the matter = other than=20 wishing it get resolved soon)
 

 
-ken
From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger=20 Marshall
Sent: Wednesday, August 05, 2009 2:16 = PM
To:=20 Randall Gellens; DRAGE, Keith (Keith); Marc Linsner; = ecrit
Subject:=20 Re: [Ecrit] HUM on PhoneBCP

Based on a little more detail, I agree that = the document=20 is NOT ready. 
 
I have been told that 3GPP's intent is to = discuss this at=20 their next formal meeting.  If we say that we want to work = together=20 with 3GPP, then we should hold off moving it forward until we = receive=20 their feedback.
 
-roger marshall.

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall=20 Gellens
Sent: Thursday, July 30, 2009 5:40 = AM
To: DRAGE,=20 Keith (Keith); Marc Linsner; 'ecrit'
Subject: Re: [Ecrit] = HUM on=20 PhoneBCP

+1.  The document is not ready.

Further, there is a liaison from 3GPP SA2 that says that they = intend to=20 send further liaison on this document.  We should wait at least = a=20 little while for this liaison.

At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote:

I don't=20 agree.
 
Some=20 background.
 
There was a=20 set of comments provided by Stephen Edge on 5th February 2009. I = can find=20 no response to that set of comments on the mailing = list.
 
The gist of=20 that set of comments was that phonebcp claims to cover all access=20 technologies and it identified a significant number of = requirements within=20 phonebcp that the author considered were not requirements on 3GPP=20 accesses.
 
So my=20 position is that the document is not ready because all the valid = comments=20 on the document were not addressed.
 
There are=20 two ways of dealing with this set of comments:
 
-    going through and modifying = all the=20 identified requirements where the comment is = upheld.
 
-    making more clear in the = abstract and /=20 or introduction that this is solely the view of IETF in regard to = IP=20 capable devices and that other organisations may specify other=20 requirements.
 
I would=20 note at this point that the current abstract = says:
 
   The IETF and other standards = organization have=20 efforts targeted at
   standardizing various aspects of = placing=20 emergency calls on IP
   networks.  This memo = describes=20 best current practice on how devices,
   networks and = services should use such standards to make = emergency
  =20 calls.
Because the=20 two sentences follow each other, it implies that other SDOs that = have=20 efforts targetted at addressing these solutions are complicit in = the=20 requirements so stated, and this is untrue. Certainly the current = status=20 of this document as addressed by various informal 3GPP discussions = is to=20 ensure that things do not fall apart in entities using the 3GPP=20 mechanisms, however 3GPP devices do not use these requirements (no = do=20 these requirements represent the 3GPP = requires.
 
One=20 solution to the issue would just be to make much clearer which = SDOs have=20 participated in this work and which have not and the status of = that=20 progress - however that was also what people keep calling the=20 "applicability statement" was trying to do.
 
regards
 
Keith
 
 

From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc=20 Linsner
Sent: Wednesday, July 29, 2009 2:53 = PM
To:=20 'ecrit'
Subject: [Ecrit] HUM on = PhoneBCP
During today's meeting there was=20 discussion as to why the chairs Publication Requested PhoneBCP = version=20 13 when there are unresolved issues.  This discussion led = us to=20 call for a hum.  We are now asking the same question on the = list.

Do you agree or disagree that = PhoneBCP=20 -13 is ready to Publication Request?

Please respond by = close of=20 business on Wednesday August = 5th.

Thanks,
Marc &=20 Hannes

--=20
Randall Gellens
Opinions are=20 personal;    facts are suspect;    I = speak for=20 myself only
-------------- Randomly selected tag: = ---------------
I=20 worry that the person who thought up Muzak may be thinking = up
something=20 else.
 --Lily Tomlin

CONFIDENTIALITY NOTICE:=20 The information contained in this message may be privileged and/or=20 confidential. If you are not the intended recipient, or responsible = for=20 delivering this message to the intended recipient, any review, = forwarding,=20 dissemination, distribution or copying of this communication or any=20 attachment(s) is strictly prohibited. If you have received this = message in=20 error, please notify the sender immediately, and delete it and all = attachments=20 from your computer and network.

------_=_NextPart_001_01CA15F9.A2F20EF8-- From mlinsner@cisco.com Wed Aug 5 11:39:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0DF3A71F4 for ; Wed, 5 Aug 2009 11:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.265 X-Spam-Level: X-Spam-Status: No, score=-5.265 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOkhs60U6Tgm for ; Wed, 5 Aug 2009 11:39:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 97A4D3A68F2 for ; Wed, 5 Aug 2009 11:39:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEABpveUqrR7PD/2dsb2JhbACCKC2WR6NQiCmQbQWCN4Fh X-IronPort-AV: E=Sophos;i="4.43,330,1246838400"; d="scan'208,217";a="192837329" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 Aug 2009 18:39:14 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n75IdED1031705; Wed, 5 Aug 2009 11:39:14 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n75IdDBF012002; Wed, 5 Aug 2009 18:39:14 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:39:14 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:39:12 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 05 Aug 2009 14:39:09 -0400 From: Marc Linsner To: "Carlberg, Kenneth G." , ecrit Message-ID: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoREt1onZENnh8yQoqYnBaz4pX1ZAE5O0lQAABQl0AAAL35+Q== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3332327952_1328169" X-OriginalArrivalTime: 05 Aug 2009 18:39:12.0967 (UTC) FILETIME=[072AD570:01CA15FC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20942; t=1249497554; x=1250361554; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20HUM=20on=20PhoneBCP |Sender:=20; bh=eo2+qPkP6vc33hTObYv1DsCwPV1p1pHSeAzGX/8wmos=; b=uY09M12EhxmLGE9rGnDgFiIhn3KJMj4szoB/8ZLvMrtPDEWLnB0P5S5SHD bxj/AuyDbg9n0MARSwQbse5I1abWkBUOhuhL7oQqqksfyBmDzAO6tRIH81vY lT+7Cb7njQ; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:39:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3332327952_1328169 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Ken, Take a look at the liaison. https://datatracker.ietf.org/liaison/551/ Cullen committed to handling any comments/issues they bring to us during IESG review or IETF last call. Of course, that commitment includes keeping the ECRIT wg involved. -Marc- On 8/5/09 2:22 PM, "Carlberg, Kenneth G." wrote: > out of curiousity, when is their next meeting, and how strong is this > "intent"? Is it firm on their calendar, or is there a reasonable possibility > that it won't be discussed but deferred until some future time? > > (speaking as one who has no stake in the matter other than wishing it get > resolved soon) > > -ken > > >> >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Roger Marshall >> Sent: Wednesday, August 05, 2009 2:16 PM >> To: Randall Gellens; DRAGE, Keith (Keith); Marc Linsner; ecrit >> Subject: Re: [Ecrit] HUM on PhoneBCP >> >> >> >> Based on a little more detail, I agree that the document is NOT ready. >> >> >> >> I have been told that 3GPP's intent is to discuss this at their next formal >> meeting. If we say that we want to work together with 3GPP, then we should >> hold off moving it forward until we receive their feedback. >> >> >> >> -roger marshall. >> >> >>> >>> >>> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>> Randall Gellens >>> Sent: Thursday, July 30, 2009 5:40 AM >>> To: DRAGE, Keith (Keith); Marc Linsner; 'ecrit' >>> Subject: Re: [Ecrit] HUM on PhoneBCP >>> >>> >>> >>> +1. The document is not ready. >>> >>> >>> >>> Further, there is a liaison from 3GPP SA2 that says that they intend to >>> send further liaison on this document. We should wait at least a little >>> while for this liaison. >>> >>> >>> >>> At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote: >>> >>> >>> >>>> I don't agree. >>> >>>> >>> >>>> Some background. >>> >>>> >>> >>>> There was a set of comments provided by Stephen Edge on 5th February 2009. >>>> I can find no response to that set of comments on the mailing list. >>> >>>> >>> >>>> The gist of that set of comments was that phonebcp claims to cover all >>>> access technologies and it identified a significant number of requirements >>>> within phonebcp that the author considered were not requirements on 3GPP >>>> accesses. >>> >>>> >>> >>>> So my position is that the document is not ready because all the valid >>>> comments on the document were not addressed. >>> >>>> >>> >>>> There are two ways of dealing with this set of comments: >>> >>>> >>> >>>> - going through and modifying all the identified requirements where the >>>> comment is upheld. >>> >>>> >>> >>>> - making more clear in the abstract and / or introduction that this is >>>> solely the view of IETF in regard to IP capable devices and that other >>>> organisations may specify other requirements. >>> >>>> >>> >>>> I would note at this point that the current abstract says: >>> >>>> >>> >>>> The IETF and other standards organization have efforts targeted at >>> >>>> standardizing various aspects of placing emergency calls on IP >>>> networks. This memo describes best current practice on how devices, >>>> networks and services should use such standards to make emergency >>>> calls. >>> >>>> Because the two sentences follow each other, it implies that other SDOs >>>> that have efforts targetted at addressing these solutions are complicit in >>>> the requirements so stated, and this is untrue. Certainly the current >>>> status of this document as addressed by various informal 3GPP discussions >>>> is to ensure that things do not fall apart in entities using the 3GPP >>>> mechanisms, however 3GPP devices do not use these requirements (no do >>>> these requirements represent the 3GPP requires. >>> >>>> >>> >>>> One solution to the issue would just be to make much clearer which SDOs >>>> have participated in this work and which have not and the status of that >>>> progress - however that was also what people keep calling the >>>> "applicability statement" was trying to do. >>> >>>> >>> >>>> regards >>> >>>> >>> >>>> Keith >>> >>>> >>> >>>> >>> >>>> >>>> >>>>> >>>>> >>>>> >>>> >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>>>> Marc Linsner >>>>> Sent: Wednesday, July 29, 2009 2:53 PM >>>>> To: 'ecrit' >>>>> Subject: [Ecrit] HUM on PhoneBCP >>>> >>>>> During today's meeting there was discussion as to why the chairs >>>>> Publication Requested PhoneBCP version 13 when there are unresolved >>>>> issues. This discussion led us to call for a hum. We are now asking the >>>>> same question on the list. >>>>> >>>>> Do you agree or disagree that PhoneBCP -13 is ready to Publication >>>>> Request? >>>>> >>>>> Please respond by close of business on Wednesday August 5th. >>>>> >>>>> Thanks, >>>> >>>>> Marc & Hannes >>> --B_3332327952_1328169 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP Ken,

Take a look at the liaison.

https://datatracker.iet= f.org/liaison/551/

Cullen committed to handling any comments/issues they bring to us during IE= SG review or IETF last call.  Of course, that commitment includes keepi= ng the ECRIT wg involved.

-Marc-

On 8/5/09 2:22 PM, "Carlberg, Kenneth G." <KENNETH.G.CARLBERG@saic.com> wrote:

out of curiousity, when is their next meeting, and how = strong is this "intent"?  Is it firm on their calendar, or is= there a reasonable possibility that it won't be discussed but deferred unti= l some future time?
(speaking as one who has no= stake in the matter other than wishing it get resolved soon)
-ken

 

 
From: ecrit-bounc= es@ietf.org  [mailto:ecrit-= bounces@ietf.org] On Behalf Of Roger  Marshall
Sent: Wednesday, August 05, 2009 2:16 PM
To:  Randall Gellens; DRAGE, Keith (Keith); Marc Linsner; ecrit=
Subject:  Re: [Ecrit] HUM on PhoneBCP

 
 
Based on a little more deta= il, I agree that the document  is NOT ready.  
 
 
I have been told that 3GPP'= s intent is to discuss this at  their next formal meeting.  If we = say that we want to work together  with 3GPP, then we should hold off m= oving it forward until we receive  their feedback.
 
 
-roger marshall.

 

 
From: ecrit-bounc= es@ietf.org  [mailto:ecrit-= bounces@ietf.org] On Behalf Of Randall  Gellens
Sent: Thursday, July 30, 2009 5:40 AM
To: DRAGE,  Keith (Keith); Marc Linsner; 'ecrit'
Subject: Re: [Ecrit] HUM on  PhoneBCP

 
 
+1.  The document is not ready.
 

 
Further, there is a liaison from 3GPP SA2 that says that they intend to &nb= sp;send further liaison on this document.  We should wait at least a &n= bsp;little while for this liaison.
 

 
At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote:
 

 
I don't  agree.



Some  background.



There was a  set of comments provided by Stephen E= dge on 5th February 2009. I can find  no response to that set of commen= ts on the mailing list.



The gist of  that set of comments was that phonebc= p claims to cover all access  technologies and it identified a signific= ant number of requirements within  phonebcp that the author considered = were not requirements on 3GPP  accesses.



So my  position is that the document is not ready = because all the valid comments  on the document were not addressed.



There are  two ways of dealing with this set of co= mments:



-    going through and modifying all the=  identified requirements where the comment is upheld.



-    making more clear in the abstract a= nd /  or introduction that this is solely the view of IETF in regard to= IP  capable devices and that other organisations may specify other &nb= sp;requirements.



I would  note at this point that the current abstr= act says:



  The IETF and other standards organization = have  efforts targeted at

  standardizing various aspects of placing &= nbsp;emergency calls on IP
   networks.  This memo describes  best current pr= actice on how devices,
   networks and  services should use such standards to = make emergency
    calls.

Because the  two sentences follow each other, it i= mplies that other SDOs that have  efforts targetted at addressing these= solutions are complicit in the  requirements so stated, and this is un= true. Certainly the current status  of this document as addressed by va= rious informal 3GPP discussions is to  ensure that things do not fall a= part in entities using the 3GPP  mechanisms, however 3GPP devices do no= t use these requirements (no do  these requirements represent the 3GPP = requires.



One  solution to the issue would just be to make m= uch clearer which SDOs have  participated in this work and which have n= ot and the status of that  progress - however that was also what people= keep calling the  "applicability statement" was trying to do= .



regards



Keith






 



From: ecr= it-bounces@ietf.org  [mailt= o:ecrit-bounces@ietf.org] On Behalf Of Marc  Linsner
Sent: Wednesday, July 29, 2009 2:53 PM
To:  'ecrit'
Subject: [Ecrit] HUM on PhoneBCP

During today's meeting there was  discussio= n as to why the chairs Publication Requested PhoneBCP version  13 when = there are unresolved issues.  This discussion led us to  call for = a hum.  We are now asking the same question on the  list.

Do you agree or disagree that PhoneBCP  -13 is r= eady to Publication Request?

Please respond by close of  business on Wednesday August 5th.

Thanks,

Marc &  Hannes

--B_3332327952_1328169-- From Gabor.Bajko@nokia.com Wed Aug 5 11:50:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78C928C5AF for ; Wed, 5 Aug 2009 11:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLn7paDv-DMx for ; Wed, 5 Aug 2009 11:50:43 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D8D5C3A6803 for ; Wed, 5 Aug 2009 11:50:42 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n75Il944026265; Wed, 5 Aug 2009 13:50:09 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 21:50:24 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 21:50:23 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 5 Aug 2009 20:50:23 +0200 From: To: , , , , , Date: Wed, 5 Aug 2009 20:50:21 +0200 Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42AAJDiUoAAA+bkA Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A99B171D26E1564B92D36826128CD6613A707CB4ADNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 05 Aug 2009 18:50:23.0903 (UTC) FILETIME=[97138AF0:01CA15FD] X-Nokia-AV: Clean Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:50:57 -0000 --_000_A99B171D26E1564B92D36826128CD6613A707CB4ADNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Tuesday, August 04, 2009 6:37 PM To: Bajko Gabor (Nokia-CIC/MtView); br@brianrosen.net; drage@alcatel-lucent= .com; john.elwell@siemens-enterprise.com; mlinsner@cisco.com; ecrit@ietf.or= g Subject: RE: ECRIT/IMS - independent discussion from the PhoneBCP hum -----Original Message----- From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Wednesday, 5 August 2009 4:41 AM To: Dawson, Martin; br@brianrosen.net; drage@alcatel-lucent.com; john.elwel= l@siemens-enterprise.com; mlinsner@cisco.com; ecrit@ietf.org Subject: RE: ECRIT/IMS - independent discussion from the PhoneBCP hum >-----Original Message----- >From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] >Sent: Monday, August 03, 2009 9:19 PM >To: Bajko Gabor (Nokia-CIC/MtView); br@brianrosen.net; >drage@alcatel-lucent.com; >john.elwell@siemens-enterprise.com; mlinsner@cisco.com; >ecrit@ietf.org >Subject: ECRIT/IMS - independent discussion from the PhoneBCP hum > >I interpret Brian's comment as being that a conventional *switched >circuit* mobile phone service is not the same as an Internet >[call] service. I think that's pretty apparent from the >context. This might have been what Brian meant, but it wasn't obvious for me, especi= ally as circuit switching is not part of 3G (HSPA or LTE), that is 2G. [[MCD]] Exactly - but much has been made of how 3GPP/IMS has defined ways o= f providing transparent hand-off between packet service and circuit service= in the context of an emergency call, with the subsequent inference that th= is makes ECRIT non-applicable in a 3GPP access context. That's an incorrect= inference and the scenario is orthogonal to the purpose of ECRIT. Neverthe= less, I'm genuinely interested in the details - i.e. how does IMS state tha= t this is done (not a description of how it *could* be done by someone but = what are the exact protocols and procedures specified). I'm particularly in= terested in how these procedures appear to the end device and the emergency= network. >Would you claim that it is, in fact, the Internet >when a switched circuit call is made Gabor? No, I don't say that. But would you claim that a VoIP call made on a 3G (pa= cket switched) network is not an Internet Service? [[MCD]] I do think it's an Internet context in that case - and that's the c= ase where I have no difficulty seeing that ECRIT is applicable. >Comments about reliability are misleading. Either >architectural solution can be made arbitrarily reliable. Yes, they can. But as we can see, unless it is required by regulation, reli= ability is missing. Carriers operating in licenced bands have to meet certa= in conditions, while a network operating in an unlicenced band is free to t= urn on/off its operation. [[MCD]] Legislation imposing reliability and the question of unlicensed ban= ds are both orthogonal. But reliability and mobility were the main architectural design cho= ices in 3GPP. That is why they ended up with that complex architecture! The= procedures themselves are a consequence of the architecture. Carriers plan to switch emergency call handling from CS to PS domain, and t= hey wanted a network controlled ES, they did not want to rely on the handse= t doing the whole procedure because of the liability. Support for emergency= calls is not a revenue generator for carriers, they'd be happy leaving the= tasks up to the client if there were no consequences of emergency calls fa= iling for whatever reason. And just to answer James point, ISPs offering broadband internet service ca= n not be paralelled with carriers operating networks using 3GPP standards. = The ISPs do not commit to offer you service with less than a few minutes ou= tage per year, they provide no mobility and they are not mandated to suppor= t emergency services. - gabor ECRIT is applicable to a broadband access regardless of, and independently= constrained by, those considerations. Regulation is a movable feast - in t= he US, the Phase 2 regulation was aimed at CMRS (circuit service) E9-1-1. T= he FCC is still kicking around the ideas associated with VoIP. There's no d= oubt that, from a technical perspective, IMS is VoIP. The question of how o= perators choose to interpret their own obligations wrt IMS is subject to th= eir own risk and business assessments including how they present that servi= ce to their subscribers. That is, do they regard it as phase 2 cellular or = do they regard it as VoIP? But that's just the US. Any arbitrary jurisdicti= on could say that any provider of broadband Internet access to the public i= s required to support the ECRIT compliant functions of a LIS, access to LoS= T, and a reliable route to the PSAP URI(s) applicable to the operators' are= as of coverage. They could further require specific levels of reliability/a= vailability and accuracy. They could require it of municipal WiFi network o= perators (unlicensed band) just as much as they could of licensed band wire= less operators. They could even require it of enterprises of a certain size= (unlicensed wireless and wired Ethernet). The point is that the existence = of regulatory requirements or otherwise does not militate against the appli= cability of ECRIT to specific technologies. >Both can be deployed in the context of managed access >according to the requirements applied by the jurisdiction. Certain radio access protocols are inherently unreliable. [[MCD]] Well - I certainly have reliability problems with GSM and UMTS cove= rage in a lot of places... but, again, the reliability of any given technol= ogy does not say anything about the applicability of ECRIT to that or other= technologies. >There's been a presumption in this debate that somehow ECRIT >needs "apologists" relative to IMS because IMS has a >complete, definitive, and apparently infinitely versatile >definition for handling emergency calls in 3GPP access. ;) I am by far not an IMS evangelist, nor an ECRIT one, so I'd rather stay out= from these kind of debates. What people seem to have trouble understanding is that some networks (eg th= e ones operating in licenced bands) can not afford to rely on the client to= do all the procedures needed to place an emergency call. They need to assi= st the client and make sure the call ends up in the right place. They are l= iable for that. That's the difference. [[MCD]] I don't actually understand how you infer that people involved in t= his debate don't understand those issues; I don't see the evidence of that.= In any case, all existing licensed mobile networks absolutely rely on func= tionality within the device to make emergency calls; standards have to be s= upported or the device cannot be used. I'm also not asking for a position i= n the debate; I'm asking for elucidation of how IMS achieves all the things= that are claimed for it (exactly) given the context that ECRIT is argued t= o be inadequate in comparison. That detail, so far, has been assumed and no= t provided as part of the debate. > It >would be reasonable to infer from the representations made >with respect to the IMS model that this definition is clear, >well understood, and unambiguous to those familiar with the >domain. I'd like to explore that premise a little. > >While you're contributing your knowledge to the discussion >then Gabor, could you please elaborate on the detailed >procedures, including which protocols are employed, when an >emergency call is invoked according to 3GPP 23.167? > >I'll grant that, somehow, the UE has recognized the >appropriate E-CSCF in that managed network and now needs to >invoke the emergency service procedures. As the spec points >out, there's the Ml interface to the location routing >function (LRF). Can you please describe the details as >defined by 3GPP from then on? Or, alternatively, could you >point to the detailed procedure specification that explains >what actually occurs? The analogue from the ECRIT >perspective is quite well elaborated, including the use of >LoST for the routing query and the use of candidate LCPs for >the location determination by value and by reference, the >associated conveyance of location value/reference in SIP etc. Brian sent me off-list a pretty comprehensive list of issues where the 3GPP= procedures differ from the ones defined in ECRIT. Since that list is by fa= r more complete than the one I could produce, I will copy paste it below. I= hope Brian doesn't mind it: " At the moment, the major differences between 3GPP and phonebcp are: a) Who inserts location, and what protocols are used b) LoST (3GPP doesn't say LoST can't be used; it basically leaves this as l= ocal practice. Since in North America, LoST will be mandated, that's not a= difference. However, 3GPP would say that LoST, if used, would be queried = by the E-CSCF, and not the endpoint, which differs from -phonebcp c) SIP termination: present 3GPP specs make no provision for packet mode te= rmination. There are some relatively minor signaling issues. To be phonebcp compatible, 3GPP networks would have to implement one of the= -phonebcp LCPs, and provide access to a LoST server. The former is a big = issue, the latter is a small issue." [[MCD]] I understand the philosophical difference - and how, for example, E= CRIT could support an emergency call initiated from an ECRIT-compliant emer= gency client on a child's portable game console connected to the in-vehicle= WiFi connected to the Internet via an LTE access network (but it's difficu= lt to see how IMS can do that). I'm actually asking for the specific detail= s (end-to-end and including the protocols used) of an IMS call according to= 23.167 as part of an attempt to ensure that both sides of the debate are e= quipped with the same information. My request was to either restrict the scope of the document to 'Internet', = or make it a requirements document (instead of bcp) with intended status st= andards track. Writing a bcp which excludes the most likely near future pra= ctice looks weird to me. [[MCD]] I'm comfortable that the scope of the document is restricted to "In= ternet" - or certainly to IP (internet with a lower case 'i') networks gene= rally. It's just that others would like to see some indication that, someho= w, it doesn't apply to 3GPP networks - even though it does. - Gabor >I'm sure IETF participants would appreciate and benefit from >elucidation of just what the 3GPP "secret sauce" is. I don't >want to leave anyone out and, of course, invite other 3GPP >knowledgeable and vocal parties to contribute. > >Cheers, >Martin --_000_A99B171D26E1564B92D36826128CD6613A707CB4ADNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: ext Dawson, Martin=20 [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, August 04, 2009= 6:37=20 PM
To: Bajko Gabor (Nokia-CIC/MtView); br@brianrosen.net;=20 drage@alcatel-lucent.com; john.elwell@siemens-enterprise.com;=20 mlinsner@cisco.com; ecrit@ietf.org
Subject: RE: ECRIT/IMS -=20 independent discussion from the PhoneBCP hum

 

 

-----Original Message-----
From:=20 Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
Sent: Wednesda= y, 5=20 August 2009 4:41 AM
To: Dawson, Martin; br@brianrosen.net;=20 drage@alcatel-lucent.com; john.elwell@siemens-enterprise.com;=20 mlinsner@cisco.com; ecrit@ietf.org
Subject: RE: ECRIT/IMS - independ= ent=20 discussion from the PhoneBCP hum

 

 

 

  >-----Original=20 Message-----

  >From: ext Dawson, Martin=20 [mailto:Martin.Dawson@andrew.com]

  >Sent: Monday, August 03, 2009 9:19= =20 PM

  >To: Bajko Gabor (Nokia-CIC/MtView)= ;=20 br@brianrosen.net;

 =20 >drage@alcatel-lucent.com;

  >john.elwell@siemens-enterprise.com= ;=20 mlinsner@cisco.com;

 =20 >ecrit@ietf.org

  >Subject: ECRIT/IMS - independent=20 discussion from the PhoneBCP hum

  >

  >I interpret Brian's comment as bei= ng that=20 a conventional *switched

  >circuit* mobile phone service is n= ot the=20 same as an Internet

  >[call] service. I think that's pre= tty=20 apparent from the

  >context.<= /P>

 

This might have been what Brian meant, but it= wasn't=20 obvious for me, especially as circuit switching is not part of 3G (HSPA= or=20 LTE), that is 2G.

[[MCD]]=20 Exactly – but much has been made of how 3GPP/IMS has defined ways= of=20 providing transparent hand-off between packet service and circuit servi= ce in=20 the context of an emergency call, with the subsequent inference that th= is=20 makes ECRIT non-applicable in a 3GPP access context. That’s an in= correct=20 inference and the scenario is orthogonal to the purpose of ECRIT.=20 Nevertheless, I’m genuinely interested in the details – i.e= . how does IMS=20 state that this is done (not a description of how it *could* be = done=20 by someone but what are the exact protocols and procedures specified). = I’m=20 particularly interested in how these procedures appear to the end devic= e and=20 the emergency network.

 

  >Would you claim that it is, in fac= t, the=20 Internet

  >when a switched circuit call is ma= de=20 Gabor?

 

No, I don't say that. But would you claim tha= t a=20 VoIP call made on a 3G (packet switched) network is not an Internet=20 Service?

[[MCD]]=20 I do think it’s an Internet context in that case – and that= ’s the case where=20 I have no difficulty seeing that ECRIT is=20 applicable.

 

  >Comments about reliability are=20 misleading. Either

  >architectural solution can be made= =20 arbitrarily reliable.

 

Yes, they can. But as we can see, unless it i= s=20 required by regulation, reliability is missing. Carriers operating in=20 licenced bands have to meet certain conditions, while a network operati= ng in=20 an unlicenced band is free to turn on/off its=20 operation.

[[MCD]]=20 Legislation imposing reliability and the question of unlicensed bands a= re=20 both orthogonal.  

 

<Gabor> But reliability and mobilit= y were=20 the main architectural design choices in 3GPP. That is why they ended u= p=20 with that complex architecture! The procedures themselves are a consequ= ence=20 of the architecture.

Carriers plan to switch emergency call ha= ndling=20 from CS to PS domain, and they wanted a network controlled ES, they did= not=20 want to rely on the handset doing the whole procedure because of the=20 liability. Support for emergency calls is not a revenue generator=20 for carriers, they'd be happy leaving the tasks up to the client i= f=20 there were no consequences of emergency calls failing for whatever=20 reason.

And just to answer James point, ISPs offe= ring=20 broadband internet service can not be paralelled with carriers operatin= g=20 networks using 3GPP standards. The ISPs do not commit to offer you serv= ice=20 with less than a few minutes outage per year, they provide no mobility = and=20 they are not mandated to support emergency=20 services.

 

- gabor

 

 

 ECRIT is applicable to a broadb= and=20 access regardless of, and independently constrained by, those=20 considerations. Regulation is a movable feast – in the US,= the=20 Phase 2 regulation was aimed at CMRS (circuit service) E9-1-1. The FCC = is=20 still kicking around the ideas associated with VoIP. There’s no d= oubt that,=20 from a technical perspective, IMS is VoIP. The question of how operator= s=20 choose to interpret their own obligations wrt IMS is subject to their o= wn=20 risk and business assessments including how they present that service t= o=20 their subscribers. That is, do they regard it as phase 2 cellular or do= they=20 regard it as VoIP? But that’s just the US.= Any=20 arbitrary jurisdiction could say that any provider of broadband Interne= t=20 access to the public is required to support the ECRIT compliant functio= ns of=20 a LIS, access to LoST, and a reliable route to the PSAP URI(s) applicab= le to=20 the operators’ areas of coverage. They could further require spec= ific levels=20 of reliability/availability and accuracy. They could require it of muni= cipal=20 WiFi network operators (unlicensed band) just as much as they could of= =20 licensed band wireless operators. They could even require it of enterpr= ises=20 of a certain size (unlicensed wireless and wired Ethernet). The point i= s=20 that the existence of regulatory requirements or otherwise does not mil= itate=20 against the applicability of ECRIT to specific=20 technologies.

 

  >Both can be deployed in the contex= t of=20 managed access

  >according to the requirements appl= ied by=20 the jurisdiction.

 

Certain radio access protocols are inherently= =20 unreliable.

[[MCD]]=20 Well – I certainly have reliability problems with GSM and UMTS co= verage in a=20 lot of places… but, again, the reliability of any given technolog= y does not=20 say anything about the applicability of ECRIT to that or other=20 technologies.

 

  >There's been a presumption in this= debate=20 that somehow ECRIT

  >needs "apologists" relative to IMS= =20 because IMS has a

  >complete, definitive, and apparent= ly=20 infinitely versatile

  >definition for handling emergency = calls=20 in 3GPP access.

 

;)

I am by far not an IMS evangelist, nor an ECR= IT one,=20 so I'd rather stay out from these kind of=20 debates.

What people seem to have trouble understandin= g is=20 that some networks (eg the ones operating in licenced bands) can not af= ford=20 to rely on the client to do all the procedures needed to place an emerg= ency=20 call. They need to assist the client and make sure the call ends up in = the=20 right place. They are liable for that. That's the=20 difference.

[[MCD]]=20 I don’t actually understand how you infer that people involved in= this=20 debate don’t understand those issues; I don’t see the evide= nce of that. In=20 any case, all existing licensed mobile networks absolutely rely on=20 functionality within the device to make emergency calls; standards have= to=20 be supported or the device cannot be used. I’m also not asking fo= r a=20 position in the debate; I’m asking for elucidation of how IMS ach= ieves all=20 the things that are claimed for it (exactly) given the context that ECR= IT is=20 argued to be inadequate in comparison. That detail, so far, has been as= sumed=20 and not provided as part of the debate.

 

  >  It=

  >would be reasonable to infer from = the=20 representations made

  >with respect to the IMS model that= this=20 definition is clear,

  >well understood, and unambiguous t= o those=20 familiar with the

  >domain. I'd like to explore that p= remise=20 a little.

  >

  >While you're contributing your kno= wledge=20 to the discussion

  >then Gabor, could you please elabo= rate on=20 the detailed

  >procedures, including which protoc= ols are=20 employed, when an

  >emergency call is invoked accordin= g to=20 3GPP 23.167?

  >

  >I'll grant that, somehow, the UE h= as=20 recognized the

  >appropriate E-CSCF in that managed= =20 network and now needs to

  >invoke the emergency service proce= dures.=20 As the spec points

  >out, there's the Ml interface to t= he=20 location routing

  >function (LRF). Can you please des= cribe=20 the details as

  >defined by 3GPP from then on? Or,= =20 alternatively, could you

  >point to the detailed procedure=20 specification that explains

  >what actually occurs? The analogue= from=20 the ECRIT

  >perspective is quite well elaborat= ed,=20 including the use of

  >LoST for the routing query and the= use of=20 candidate LCPs for

  >the location determination by valu= e and=20 by reference, the

  >associated conveyance of location= =20 value/reference in SIP etc.

 

Brian sent me off-list a pretty comprehensive= list=20 of issues where the 3GPP procedures differ from the ones defined in ECR= IT.=20 Since that list is by far more complete than the one I could produce, I= will=20 copy paste it below. I hope Brian doesn't mind=20 it:

 

" At the moment, the major differences betwee= n 3GPP=20 and phonebcp are:

a) Who inserts location, and what protocols a= re=20 used

b) LoST (3GPP doesn't say LoST can't be used;= it=20 basically leaves this as local practice.  Since in North America, LoST will be mandated, that's no= t a=20 difference.  However, 3GPP would say that LoST, if used, would be= =20 queried by the E-CSCF, and not the endpoint, which differs from=20 -phonebcp

c) SIP termination: present 3GPP specs make n= o=20 provision for packet mode termination.

 

There are some relatively minor signaling=20 issues.

 

To be phonebcp compatible, 3GPP networks woul= d have=20 to implement one of the -phonebcp LCPs, and provide access to a LoST=20 server.  The former is a big issue, the latter is a small=20 issue."

[[MCD]]=20 I understand the philosophical difference – and how, for example,= ECRIT=20 could support an emergency call initiated from an ECRIT-compliant emerg= ency=20 client on a child’s portable game console connected to the in-veh= icle WiFi=20 connected to the Internet via an LTE access network (but it’s dif= ficult to=20 see how IMS can do that). I’m actually asking for the specific de= tails=20 (end-to-end and including the protocols used) of an IMS call according = to=20 23.167 as part of an attempt to ensure that both sides of the debate ar= e=20 equipped with the same information.

 

 

My request was to either restrict the scope o= f the=20 document to 'Internet', or make it a requirements document (instead of = bcp)=20 with intended status standards track. Writing a bcp which excludes the = most=20 likely near future practice looks weird to me.=

[[MCD]]=20 I’m comfortable that the scope of the document is restricted to &= #8220;Internet” –=20 or certainly to IP (internet with a lower case ‘i’) network= s generally. It’s=20 just that others would like to see some indication that, somehow, it do= esn’t=20 apply to 3GPP networks – even though it does.

 

- Gabor

 

 

  >I'm sure IETF participants would=20 appreciate and benefit from

  >elucidation of just what the 3GPP = "secret=20 sauce" is. I don't

  >want to leave anyone out and, of c= ourse,=20 invite other 3GPP

  >knowledgeable and vocal parties to= =20 contribute.

  >

  >Cheers,

  >Martin

 

--_000_A99B171D26E1564B92D36826128CD6613A707CB4ADNOKEUMSG01mgd_-- From RMarshall@telecomsys.com Wed Aug 5 11:51:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381AC3A6C3C for ; Wed, 5 Aug 2009 11:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZo3Wj4cQSgZ for ; Wed, 5 Aug 2009 11:51:48 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id 6DD593A6803 for ; Wed, 5 Aug 2009 11:51:48 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 5 Aug 2009 11:51:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA15FD.A8C877A0" Date: Wed, 5 Aug 2009 11:51:16 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750D94EBB5@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoREt1onZENnh8yQoqYnBaz4pX1ZAE5O0lQAABQl0AAAL35+QAAQ2EQ References: From: "Roger Marshall" To: "Marc Linsner" , "Carlberg, Kenneth G." , "ecrit" Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:51:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA15FD.A8C877A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ken: My understanding is that the next meeting will be held from Aug 31 to Sept 4. Based on the initial liaison response referenced, it appears that the "intent" is real - as to them having an adequate discussion in SA WG2 (SA2) on the topic. =20 -roger marshall. ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, August 05, 2009 11:39 AM To: Carlberg, Kenneth G.; ecrit Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 Ken, =09 Take a look at the liaison. =09 https://datatracker.ietf.org/liaison/551/ =09 Cullen committed to handling any comments/issues they bring to us during IESG review or IETF last call. Of course, that commitment includes keeping the ECRIT wg involved. =09 -Marc- =09 On 8/5/09 2:22 PM, "Carlberg, Kenneth G." wrote: =09 =09 out of curiousity, when is their next meeting, and how strong is this "intent"? Is it firm on their calendar, or is there a reasonable possibility that it won't be discussed but deferred until some future time? =09 (speaking as one who has no stake in the matter other than wishing it get resolved soon) =09 -ken =09 =20 =09 =09 =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, August 05, 2009 2:16 PM To: Randall Gellens; DRAGE, Keith (Keith); Marc Linsner; ecrit Subject: Re: [Ecrit] HUM on PhoneBCP =09 =20 =20 Based on a little more detail, I agree that the document is NOT ready. =20 =09 =20 =20 I have been told that 3GPP's intent is to discuss this at their next formal meeting. If we say that we want to work together with 3GPP, then we should hold off moving it forward until we receive their feedback. =09 =20 =20 -roger marshall. =09 =20 =09 =09 =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: Thursday, July 30, 2009 5:40 AM To: DRAGE, Keith (Keith); Marc Linsner; 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP =09 =20 =20 +1. The document is not ready. =20 =09 =20 Further, there is a liaison from 3GPP SA2 that says that they intend to send further liaison on this document. We should wait at least a little while for this liaison. =20 =09 =20 At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote: =20 =09 =20 =09 I don't agree. =09 =09 =09 =09 =09 =09 =09 Some background. =09 =09 =09 =09 =09 =09 =09 There was a set of comments provided by Stephen Edge on 5th February 2009. I can find no response to that set of comments on the mailing list. =09 =09 =09 =09 =09 =09 =09 The gist of that set of comments was that phonebcp claims to cover all access technologies and it identified a significant number of requirements within phonebcp that the author considered were not requirements on 3GPP accesses. =09 =09 =09 =09 =09 =09 =09 So my position is that the document is not ready because all the valid comments on the document were not addressed. =09 =09 =09 =09 =09 =09 =09 There are two ways of dealing with this set of comments: =09 =09 =09 =09 =09 =09 =09 - going through and modifying all the identified requirements where the comment is upheld. =09 =09 =09 =09 =09 =09 =09 - making more clear in the abstract and / or introduction that this is solely the view of IETF in regard to IP capable devices and that other organisations may specify other requirements. =09 =09 =09 =09 =09 =09 =09 I would note at this point that the current abstract says: =09 =09 =09 =09 =09 =09 =09 The IETF and other standards organization have efforts targeted at =09 =09 =09 standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. =09 =09 =09 Because the two sentences follow each other, it implies that other SDOs that have efforts targetted at addressing these solutions are complicit in the requirements so stated, and this is untrue. Certainly the current status of this document as addressed by various informal 3GPP discussions is to ensure that things do not fall apart in entities using the 3GPP mechanisms, however 3GPP devices do not use these requirements (no do these requirements represent the 3GPP requires. =09 =09 =09 =09 =09 =09 =09 One solution to the issue would just be to make much clearer which SDOs have participated in this work and which have not and the status of that progress - however that was also what people keep calling the "applicability statement" was trying to do. =09 =09 =09 =09 =09 =09 =09 regards =09 =09 =09 =09 =09 =09 =09 Keith =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =09 =09 =09 ________________________________ =09 =09 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, July 29, 2009 2:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP =09 =09 =09 During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. =09 Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? =09 Please respond by close of business on Wednesday August 5th. =09 Thanks, =09 =09 =09 Marc & Hannes =09 =09 =09 CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_001_01CA15FD.A8C877A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP
Ken:
My understa= nding is=20 that the next meeting will be held from Aug 31 to Sept=20 4. Based on the initial liaison= =20 response referenced, it appears that the “intent” is rea= l - as to them having=20 an adequate discussion in SA WG2= =20 (SA2) on the topic.
 
-rog= er=20 marshall.

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc=20 Linsner
Sent: Wednesday, August 05, 2009 11:39 AM
To:= =20 Carlberg, Kenneth G.; ecrit
Subject: Re: [Ecrit] HUM on=20 PhoneBCP

Ken,

Take a look at the liaison.

= https://datatracker.ie= tf.org/liaison/551/

Cullen=20 committed to handling any comments/issues they bring to us during IESG re= view=20 or IETF last call.  Of course, that commitment includes keeping the = ECRIT=20 wg involved.

-Marc-

On 8/5/09 2:22 PM, "Carlberg, Kenneth G= ."=20 <KENNETH.G.CARLBERG@saic.com>=20 wrote:
out of curiousity, when is their next meeting, and how str= ong is=20 this "intent"?  Is it firm on their calendar, or is there a reason= able=20 possibility that it won't be discussed but deferred until some future=20 time?

(speaking as one who has no stake in= the=20 matter other than wishing it get resolved soon)

-ken

 

 
From: = ecrit-bounces@ietf.org  [mailto:ecrit-bounces@ietf.org<= /A>]=20 On Behalf Of Roger  Marshall
Sent: Wednesday, A= ugust=20 05, 2009 2:16 PM
To:  Randall Gellens; DRAGE, Keith=20 (Keith); Marc Linsner; ecrit
Subject:  Re: [Ecrit] HUM= on=20 PhoneBCP

 
 
<= /FONT>Based on a little more detail, I a= gree that=20 the document  is NOT ready.  

 
 
<= /FONT>I have been told that 3GPP's inten= t is to=20 discuss this at  their next formal meeting.  If we say that= we=20 want to work together  with 3GPP, then we should hold off moving= it=20 forward until we receive  their feedback.

 
 
<= /FONT>-roger marshall.
=
 

 
From: ecrit-bounces@ietf.org  [<= A=20 href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.or= g]=20 On Behalf Of Randall  Gellens
Sent: Thursday,= July=20 30, 2009 5:40 AM
To: DRAGE,  Keith (Keith); Marc Lin= sner;=20 'ecrit'
Subject: Re: [Ecrit] HUM on=20  PhoneBCP

 
 +1.=20  The document is not ready.
 

 
Further= ,=20 there is a liaison from 3GPP SA2 that says that they intend to=20  send further liaison on this document.  We should wait a= t=20 least a  little while for this=20 liaison.
 

 
At 10:00 AM +0200 7/30/09, Keit= h=20 (Keith) DRAGE wrote:
 

 
<= FONT=20 face=3DArial>I don't=20  agree.



<= FONT=20 face=3DArial>Some=20  background.



<= FONT=20 face=3DArial>There was a  set of comments provided by Stephe= n Edge=20 on 5th February 2009. I can find  no response to that set of= =20 comments on the mailing list.



<= FONT=20 face=3DArial>The gist of  that set of comments was that phon= ebcp=20 claims to cover all access  technologies and it identified a= =20 significant number of requirements within  phonebcp that the= =20 author considered were not requirements on 3GPP=20  accesses.



<= FONT=20 face=3DArial>So my  position is that the document is not rea= dy=20 because all the valid comments  on the document were not=20 addressed.



<= FONT=20 face=3DArial>There are  two ways of dealing with this set of= =20 comments:



<= FONT=20 face=3DArial>-    going through and modifying all = the=20  identified requirements where the comment is=20 upheld.



<= FONT=20 face=3DArial>-    making more clear in the abstrac= t and /=20  or introduction that this is solely the view of IETF in reg= ard=20 to IP  capable devices and that other organisations may spec= ify=20 other  requirements.



<= FONT=20 face=3DArial>I would  note at this point that the current ab= stract=20 says:



<= FONT=20 face=3DArial>  The IETF and other standards organizatio= n have=20  efforts targeted at

<= FONT=20 face=3DArial>  standardizing various aspects of placing= =20  emergency calls on IP
   networks.  = This=20 memo describes  best current practice on how=20 devices,
   networks and  services should = use=20 such standards to make=20 emergency
    calls.

<= FONT=20 face=3DArial>Because the  two sentences follow each other, i= t=20 implies that other SDOs that have  efforts targetted at=20 addressing these solutions are complicit in the  requirement= s so=20 stated, and this is untrue. Certainly the current status  of= this=20 document as addressed by various informal 3GPP discussions is to= =20  ensure that things do not fall apart in entities using the = 3GPP=20  mechanisms, however 3GPP devices do not use these requireme= nts=20 (no do  these requirements represent the 3GPP=20 requires.



<= FONT=20 face=3DArial>One  solution to the issue would just be to mak= e much=20 clearer which SDOs have  participated in this work and which= have=20 not and the status of that  progress - however that was also= what=20 people keep calling the  "applicability statement" was tryin= g to=20 do.



<= FONT=20 face=3DArial>regards



<= FONT=20 face=3DArial>Keith






 
=


=
From: ecrit-bounces@ietf.org &nbs= p;[mailto:ecrit-bounces@iet= f.org]=20 On Behalf Of Marc  Linsner
Sent: Wednesday, = July=20 29, 2009 2:53 PM
To:  'ecrit'
Subject:= =20 [Ecrit] HUM on PhoneBCP

During today's meet= ing=20 there was  discussion as to why the chairs Publication=20 Requested PhoneBCP version  13 when there are unresolved=20 issues.  This discussion led us to  call for a hum.=20  We are now asking the same question on the=20  list.

Do you agree or disagr= ee that=20 PhoneBCP  -13 is ready to Publication Request?

Plea= se=20 respond by close of  business on Wednesday August=20 5th.

Thanks,

Marc=20 &=20  Hannes

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

------_=_NextPart_001_01CA15FD.A8C877A0-- From hannes.tschofenig@nsn.com Wed Aug 5 12:24:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE84828C666 for ; Wed, 5 Aug 2009 12:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 N9kuhx9ljvRd for ; Wed, 5 Aug 2009 12:24:54 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 55BD43A71CD for ; Wed, 5 Aug 2009 12:24:16 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n75JOD7I004536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2009 21:24:13 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n75JOChx014532; Wed, 5 Aug 2009 21:24:12 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 21:24:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 22:26:40 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501940E29@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoREt1onZENnh8yQoqYnBaz4pX1ZAE5O0lQAABQl0AAAk8VQA== References: <8C837214C95C864C9F34F3635C2A65750D94EB32@SEA-EXCHVS-2.telecomsys.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Carlberg, Kenneth G." , "Roger Marshall" , "Randall Gellens" , "DRAGE, Keith (Keith)" , "Marc Linsner" , "ecrit" X-OriginalArrivalTime: 05 Aug 2009 19:24:12.0022 (UTC) FILETIME=[4FEDF160:01CA1602] Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 19:24:55 -0000 Please note that comments can be provided during the IETF Last Call. A common procedure in the IETF. The intention was to address comments from the 3GPP, if there are any, during IETF Last Call and to still advance the document to the IESG.=20 Ciao Hannes =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Carlberg, Kenneth G. Sent: 05 August, 2009 21:22 To: Roger Marshall; Randall Gellens; DRAGE, Keith (Keith); Marc Linsner; ecrit Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 out of curiousity, when is their next meeting, and how strong is this "intent"? Is it firm on their calendar, or is there a reasonable possibility that it won't be discussed but deferred until some future time? =20 (speaking as one who has no stake in the matter other than wishing it get resolved soon) =20 -ken =09 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, August 05, 2009 2:16 PM To: Randall Gellens; DRAGE, Keith (Keith); Marc Linsner; ecrit Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 Based on a little more detail, I agree that the document is NOT ready. =20 =20 I have been told that 3GPP's intent is to discuss this at their next formal meeting. If we say that we want to work together with 3GPP, then we should hold off moving it forward until we receive their feedback. =20 -roger marshall. ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: Thursday, July 30, 2009 5:40 AM To: DRAGE, Keith (Keith); Marc Linsner; 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 +1. The document is not ready. Further, there is a liaison from 3GPP SA2 that says that they intend to send further liaison on this document. We should wait at least a little while for this liaison. At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote: I don't agree. =20 Some background. =20 There was a set of comments provided by Stephen Edge on 5th February 2009. I can find no response to that set of comments on the mailing list. =20 The gist of that set of comments was that phonebcp claims to cover all access technologies and it identified a significant number of requirements within phonebcp that the author considered were not requirements on 3GPP accesses. =20 So my position is that the document is not ready because all the valid comments on the document were not addressed. =20 There are two ways of dealing with this set of comments: =20 - going through and modifying all the identified requirements where the comment is upheld. =20 - making more clear in the abstract and / or introduction that this is solely the view of IETF in regard to IP capable devices and that other organisations may specify other requirements. =20 I would note at this point that the current abstract says: =20 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. =09 Because the two sentences follow each other, it implies that other SDOs that have efforts targetted at addressing these solutions are complicit in the requirements so stated, and this is untrue. Certainly the current status of this document as addressed by various informal 3GPP discussions is to ensure that things do not fall apart in entities using the 3GPP mechanisms, however 3GPP devices do not use these requirements (no do these requirements represent the 3GPP requires. =20 One solution to the issue would just be to make much clearer which SDOs have participated in this work and which have not and the status of that progress - however that was also what people keep calling the "applicability statement" was trying to do. =20 regards =20 Keith =20 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, July 29, 2009 2:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP =09 During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. =09 Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? =09 Please respond by close of business on Wednesday August 5th. =09 Thanks, =09 Marc & Hannes --=20 =09 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I worry that the person who thought up Muzak may be thinking up something else. --Lily Tomlin =09 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. From mlinsner@cisco.com Wed Aug 5 12:30:18 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4223A6869 for ; Wed, 5 Aug 2009 12:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.26 X-Spam-Level: X-Spam-Status: No, score=-5.26 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aZCzkrtv6Am for ; Wed, 5 Aug 2009 12:30:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7646B3A7207 for ; Wed, 5 Aug 2009 12:30:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoEAB96eUqrR7PD/2dsb2JhbACCJy6WR6N2iCmQbQWCN4Fh X-IronPort-AV: E=Sophos;i="4.43,330,1246838400"; d="scan'208,217";a="361184103" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Aug 2009 19:29:52 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n75JTquJ010219; Wed, 5 Aug 2009 12:29:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n75JTqsq006311; Wed, 5 Aug 2009 19:29:52 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:29:52 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:29:51 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 05 Aug 2009 15:29:50 -0400 From: Marc Linsner To: , Message-ID: Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42AAJDiUoAAA+bkAAAFk66w= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3332330991_1499217" X-OriginalArrivalTime: 05 Aug 2009 19:29:51.0397 (UTC) FILETIME=[1A367550:01CA1603] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5481; t=1249500592; x=1250364592; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20ECRIT/IMS=20-=20independent=20discussio n=20from=20the=20PhoneBCP=20hum |Sender:=20; bh=V99q3QgXVyQp/uv6S+Qvz+LAqxo8hiHfeONJfT5g40o=; b=Xmxzd7vgKjFa1ai6eLlCi/sTwUCN84/BXL9+w8VUGHC5aBKfh1XdGD/hdq BjDRfx445HvSE52mndr9xdHeynj6doaaGhies89EQCiTBRio+HWYYmZvFyTx QNfhAqFkxb; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 19:30:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3332330991_1499217 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Gabor, >>> >>> >>> But reliability and mobility were the main architectural design >>> choices in 3GPP. That is why they ended up with that complex architecture! >>> The procedures themselves are a consequence of the architecture. >>> >>> Carriers plan to switch emergency call handling from CS to PS domain, and >>> they wanted a network controlled ES, they did not want to rely on the >>> handset doing the whole procedure because of the liability. Support for >>> emergency calls is not a revenue generator for carriers, they'd be happy >>> leaving the tasks up to the client if there were no consequences of >>> emergency calls failing for whatever reason. >>> >>> And just to answer James point, ISPs offering broadband internet service >>> can not be paralelled with carriers operating networks using 3GPP >>> standards. The ISPs do not commit to offer you service with less than a few >>> minutes outage per year, they provide no mobility and they are not mandated >>> to support emergency services. >>> >>> >>> >>> - gabor >>> >>> >>> [Marc] Are you implying that 3GPP carriers operating a packet voice service >>> have a different mandate for supporting emergency services than an OTT >>> provider that sells packet voice services? (my understanding, which could >>> be wrong, is that VoIP is VoIP no matter who is the SP) >>> >>> Or is this a 3GPP self-inflicted mandate that is trying to emulate 2G >>> circuit-switched services? >>> >>> >>> -Marc- >>> >>> >>> > --B_3332330991_1499217 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: ECRIT/IMS - independent discussion from the PhoneBCP hum Gabor,
<Gabor> But reliability and mobility were  the main= architectural design choices in 3GPP. That is why they ended up  with = that complex architecture! The procedures themselves are a consequence  = ;of the architecture.
Carriers plan to switch emergency call handling  from CS = to PS domain, and they wanted a network controlled ES, they did not  wa= nt to rely on the handset doing the whole procedure because of the  lia= bility. Support for emergency calls is not a revenue generator  for car= riers, they'd be happy leaving the tasks up to the client if  there wer= e no consequences of emergency calls failing for whatever  reason.
And just to answer James point, ISPs offering  broadband = internet service can not be paralelled with carriers operating  network= s using 3GPP standards. The ISPs do not commit to offer you service  wi= th less than a few minutes outage per year, they provide no mobility and &nb= sp;they are not mandated to support emergency  services.

- gabor


--B_3332330991_1499217-- From randy@qualcomm.com Wed Aug 5 15:00:21 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E00A3A7212 for ; Wed, 5 Aug 2009 15:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.6 X-Spam-Level: X-Spam-Status: No, score=-105.6 tagged_above=-999 required=5 tests=[AWL=0.999, 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 kb1Sink2mr1J for ; Wed, 5 Aug 2009 15:00:20 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9DD453A6C0A for ; Wed, 5 Aug 2009 15:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1249509623; x=1281045623; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20|References:=20<0D5F89FAC29 E2C41B98A6A7=0D=0A=2062007F5D00233D3C6@GBNTHT12009MSX.gb0 02.siemens.net><000901ca1139$590fb=0D=0A=20490$0b2f1db0$@ net><003501ca1153$77db5 0e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net>=0D=0A=20=09=0D=0A=20=20|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-Note:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20We d,=205=20Aug=202009=2014:53:43=20-0700|To:=20"Dawson,=20M artin"=20,=20,=0D=0A=20=20=20=20=20=20=20=20, =20,=0D=0A=20=20=20=20=20=20=20 =20,=20,=0D=0A=20=20=20=20=20=20=20=20 |From:=20Randall=20Gellens=20 |Subject:=20Re:=20[Ecrit]=20ECRIT/IMS=20-=20independent =20discussion=20from=20the=0D=0A=20PhoneBCP=20hum |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,56 99"=3B=20a=3D"21716364"; bh=CWnAbxmgpqQKFIkIJoEqapziJTyF5EkeFSmCmffEui4=; b=oZbXoDNhHv5iJO+s+5S5+vzFKe/fDT4tjqAFNaNum0uXb+QP2DnV868V 1pwLiUpwp8NF+hx1zvgbPj0rLiV+2AFNzpFFontYS/C6hlvChp1VkU0EJ LTWjO+UDSUDHAitM9/NdOeHEJ/ZB2NuY1j9lPMppW0uHsJ47eL3Vft5E5 s=; X-IronPort-AV: E=McAfee;i="5300,2777,5699"; a="21716364" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Aug 2009 15:00:23 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n75M0Mc3018082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2009 15:00:23 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n75M0KOR010075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Aug 2009 15:00:22 -0700 (PDT) Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 5 Aug 2009 15:00:19 -0700 Received: from [78.64.88.186] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 5 Aug 2009 15:00:19 -0700 Message-ID: In-Reply-To: References: <0D5F89FAC29E2C41B98A6A7 62007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb 490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 5 Aug 2009 14:53:43 -0700 To: "Dawson, Martin" , , , , , , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 22:00:21 -0000 At 8:37 PM -0500 8/4/09, Martin Dawson wrote: > It's just that others would like to see some indication that, > somehow, it doesn't apply to 3GPP networks - even though it does. The compromise text didn't say that the ecrit solution can't or shouldn't be used in 3GPP or any other environment; it was just a brief acknowledgment that there were some key differences between this solution and others, and that interoperability and related issues between them are left for future documents. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There are things that are so serious that you can only joke about them --Heisenberg From Martin.Dawson@andrew.com Wed Aug 5 15:42:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2072D3A68B5 for ; Wed, 5 Aug 2009 15:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRlv4A6q6ENv for ; Wed, 5 Aug 2009 15:42:26 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 360BC3A6C3C for ; Wed, 5 Aug 2009 15:42:26 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_05_18_05_09 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 05 Aug 2009 18:05:07 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 17:42:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA161D.FFBD62A9" Date: Wed, 5 Aug 2009 17:42:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42AAJDiUoAAItYrg References: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net> From: "Dawson, Martin" To: , , , , , X-OriginalArrivalTime: 05 Aug 2009 22:42:26.0395 (UTC) FILETIME=[01873AB0:01CA161E] Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 22:42:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA161D.FFBD62A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gabor,=0D=0A=0D=0A=20=0D=0A=0D=0AI think you're view of the world is mor= e complicated than it needs to=0D=0Abe. Only one key development has happen= ed. The world has moved from=0D=0Ausing circuit switching in a global PSTN = to using packet switching in a=0D=0Aglobal Internet. You may see some detai= ls, and interim fluctuations in=0D=0Aservice standards as consequence of th= at transition, but the=0D=0Afundamentals of operator obligation, regulatory= requirements, and=0D=0Aservice levels will be the same in the long term.=0D= =0A=0D=0A=20=0D=0A=0D=0AMobile network operators are moving from providing = cellular PSTN access=0D=0Ato providing cellular Internet access. Wireline o= perators are moving=0D=0Afrom providing fixed PSTN access to providing fixe= d Internet access.=0D=0ABoth parties can, and will ultimately be required t= o, provide a reliable=0D=0Aservice. I can certainly tell you that, as of no= w, the Internet access=0D=0Aside of cellular is no more reliable than Wirel= ine Internet access is.=0D=0A=0D=0A=20=0D=0A=0D=0AAn ECRIT compliant Intern= et access provider needs to ensure the=0D=0Afollowing (apart from reliable = basic Internet access to begin with of=0D=0Acourse):=0D=0A=0D=0A=20=0D=0A=0D= =0A1.=09Access to LIS functionality for routing and dispatch purposes=0D=0A= 2.=09Access to LoST (either within the network or to a public server)=0D=0A= 3.=09SIP routability to the PSAP URI(s) in their area of coverage=0D=0A=0D=0A= =20=0D=0A=0D=0AThe elements involved in that can be just as reliable as any=0D= =0AIMS-specific elements that 3GPP define. A LoST server can be just as=0D=0A= reliable as an LRF - and is no more complex. There is always a=0D=0Adepende= ncy on the end device but I'll say this - if all that devices=0D=0Ahave to = do is provide a consistent reliable ECRIT-compliant client=0D=0Afunction th= en we'll all get something more reliable when that client is=0D=0Athe same = regardless of the actual access technology compared to if it=0D=0Ahas to be= "re-invented" for every flavour of access technology.=0D=0A=0D=0A=20=0D=0A=0D= =0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A____________________= ____________=0D=0A=0D=0AFrom: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nok= ia.com]=20=0D=0ASent: Thursday, 6 August 2009 4:40 AM=0D=0ATo: Dawson, Mart= in; br@brianrosen.net; drage@alcatel-lucent.com;=0D=0Ajohn.elwell@siemens-e= nterprise.com; mlinsner@cisco.com; ecrit@ietf.org=0D=0ASubject: RE: ECRIT/I= MS - independent discussion from the PhoneBCP hum=0D=0A=0D=0A=20=0D=0A=0D=0A= =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=0D=0A________________________________=0D= =0A=0D=0A=0D=0A=09From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com= ]=20=0D=0A=09Sent: Tuesday, August 04, 2009 6:37 PM=0D=0A=09To: Bajko Gabor= (Nokia-CIC/MtView); br@brianrosen.net;=0D=0Adrage@alcatel-lucent.com; john= =2Eelwell@siemens-enterprise.com;=0D=0Amlinsner@cisco.com; ecrit@ietf.org=0D= =0A=09Subject: RE: ECRIT/IMS - independent discussion from the=0D=0APhoneBC= P hum=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09-----Original Messa= ge-----=0D=0A=09From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] =0D= =0A=09Sent: Wednesday, 5 August 2009 4:41 AM=0D=0A=09To: Dawson, Martin; br= @brianrosen.net; drage@alcatel-lucent.com;=0D=0Ajohn.elwell@siemens-enterpr= ise.com; mlinsner@cisco.com; ecrit@ietf.org=0D=0A=09Subject: RE: ECRIT/IMS = - independent discussion from the=0D=0APhoneBCP hum=0D=0A=0D=0A=09=20=0D=0A=0D= =0A=09=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 >-----Original Message-----=0D=0A=0D= =0A=09 >From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A=0D= =0A=09 >Sent: Monday, August 03, 2009 9:19 PM=0D=0A=0D=0A=09 >To: Bajko G= abor (Nokia-CIC/MtView); br@brianrosen.net;=0D=0A=0D=0A=09 >drage@alcatel-= lucent.com;=0D=0A=0D=0A=09 >john.elwell@siemens-enterprise.com; mlinsner@c= isco.com;=0D=0A=0D=0A=09 >ecrit@ietf.org=0D=0A=0D=0A=09 >Subject: ECRIT/I= MS - independent discussion from the PhoneBCP=0D=0Ahum=0D=0A=0D=0A=09 >=0D= =0A=0D=0A=09 >I interpret Brian's comment as being that a conventional=0D=0A= *switched=0D=0A=0D=0A=09 >circuit* mobile phone service is not the same as= an Internet=0D=0A=0D=0A=09 >[call] service. I think that's pretty apparen= t from the=0D=0A=0D=0A=09 >context.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09This m= ight have been what Brian meant, but it wasn't obvious for=0D=0Ame, especia= lly as circuit switching is not part of 3G (HSPA or LTE),=0D=0Athat is 2G.=0D= =0A=0D=0A=09[[MCD]] Exactly - but much has been made of how 3GPP/IMS has=0D= =0Adefined ways of providing transparent hand-off between packet service=0D= =0Aand circuit service in the context of an emergency call, with the=0D=0As= ubsequent inference that this makes ECRIT non-applicable in a 3GPP=0D=0Aacc= ess context. That's an incorrect inference and the scenario is=0D=0Aorthogo= nal to the purpose of ECRIT. Nevertheless, I'm genuinely=0D=0Ainterested in= the details - i.e. how does IMS state that this is done=0D=0A(not a descri= ption of how it *could* be done by someone but what are the=0D=0Aexact prot= ocols and procedures specified). I'm particularly interested=0D=0Ain how th= ese procedures appear to the end device and the emergency=0D=0Anetwork.=0D=0A=0D= =0A=09=20=0D=0A=0D=0A=09 >Would you claim that it is, in fact, the Interne= t=0D=0A=0D=0A=09 >when a switched circuit call is made Gabor=3F=0D=0A=0D=0A= =09=20=0D=0A=0D=0A=09No, I don't say that. But would you claim that a VoIP = call made=0D=0Aon a 3G (packet switched) network is not an Internet Service= =3F=0D=0A=0D=0A=09[[MCD]] I do think it's an Internet context in that case = - and=0D=0Athat's the case where I have no difficulty seeing that ECRIT is=0D= =0Aapplicable.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 >Comments about reliabilit= y are misleading. Either=0D=0A=0D=0A=09 >architectural solution can be mad= e arbitrarily reliable.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Yes, they can. But = as we can see, unless it is required by=0D=0Aregulation, reliability is mis= sing. Carriers operating in licenced bands=0D=0Ahave to meet certain condit= ions, while a network operating in an=0D=0Aunlicenced band is free to turn = on/off its operation.=0D=0A=0D=0A=09[[MCD]] Legislation imposing reliabilit= y and the question of=0D=0Aunlicensed bands are both orthogonal. =20=0D=0A=0D= =0A=09=20=0D=0A=0D=0A=09 But reliability and mobility were the main = architectural=0D=0Adesign choices in 3GPP. That is why they ended up with t= hat complex=0D=0Aarchitecture! The procedures themselves are a consequence = of the=0D=0Aarchitecture.=0D=0A=0D=0A=09Carriers plan to switch emergency c= all handling from CS to PS=0D=0Adomain, and they wanted a network controlle= d ES, they did not want to=0D=0Arely on the handset doing the whole procedu= re because of the liability.=0D=0ASupport for emergency calls is not a reve= nue generator for carriers,=0D=0Athey'd be happy leaving the tasks up to th= e client if there were no=0D=0Aconsequences of emergency calls failing for = whatever reason.=0D=0A=0D=0A=09And just to answer James point, ISPs offerin= g broadband internet=0D=0Aservice can not be paralelled with carriers opera= ting networks using=0D=0A3GPP standards. The ISPs do not commit to offer yo= u service with less=0D=0Athan a few minutes outage per year, they provide n= o mobility and they=0D=0Aare not mandated to support emergency services.=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09- gabor=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=20=0D= =0A=0D=0A=09 ECRIT is applicable to a broadband access regardless of, and=0D= =0Aindependently constrained by, those considerations. Regulation is a=0D=0A= movable feast - in the US, the Phase 2 regulation was aimed at CMRS=0D=0A(c= ircuit service) E9-1-1. The FCC is still kicking around the ideas=0D=0Aasso= ciated with VoIP. There's no doubt that, from a technical=0D=0Aperspective,= IMS is VoIP. The question of how operators choose to=0D=0Ainterpret their = own obligations wrt IMS is subject to their own risk and=0D=0Abusiness asse= ssments including how they present that service to their=0D=0Asubscribers. = That is, do they regard it as phase 2 cellular or do they=0D=0Aregard it as= VoIP=3F But that's just the US. Any arbitrary jurisdiction=0D=0Acould say = that any provider of broadband Internet access to the public=0D=0Ais requir= ed to support the ECRIT compliant functions of a LIS, access to=0D=0ALoST, = and a reliable route to the PSAP URI(s) applicable to the=0D=0Aoperators' a= reas of coverage. They could further require specific levels=0D=0Aof reliab= ility/availability and accuracy. They could require it of=0D=0Amunicipal Wi= Fi network operators (unlicensed band) just as much as they=0D=0Acould of l= icensed band wireless operators. They could even require it of=0D=0Aenterpr= ises of a certain size (unlicensed wireless and wired Ethernet).=0D=0AThe p= oint is that the existence of regulatory requirements or otherwise=0D=0Adoe= s not militate against the applicability of ECRIT to specific=0D=0Atechnolo= gies.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 >Both can be deployed in the contex= t of managed access=0D=0A=0D=0A=09 >according to the requirements applied = by the jurisdiction.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Certain radio access p= rotocols are inherently unreliable.=0D=0A=0D=0A=09[[MCD]] Well - I certainl= y have reliability problems with GSM=0D=0Aand UMTS coverage in a lot of pla= ces... but, again, the reliability of=0D=0Aany given technology does not sa= y anything about the applicability of=0D=0AECRIT to that or other technolog= ies.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 >There's been a presumption in this = debate that somehow ECRIT=0D=0A=0D=0A=09 >needs "apologists" relative to I= MS because IMS has a=0D=0A=0D=0A=09 >complete, definitive, and apparently = infinitely versatile=0D=0A=0D=0A=09 >definition for handling emergency cal= ls in 3GPP access.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09;)=0D=0A=0D=0A=09I am by= far not an IMS evangelist, nor an ECRIT one, so I'd=0D=0Arather stay out f= rom these kind of debates.=0D=0A=0D=0A=09What people seem to have trouble u= nderstanding is that some=0D=0Anetworks (eg the ones operating in licenced = bands) can not afford to=0D=0Arely on the client to do all the procedures n= eeded to place an emergency=0D=0Acall. They need to assist the client and m= ake sure the call ends up in=0D=0Athe right place. They are liable for that= =2E That's the difference.=0D=0A=0D=0A=09[[MCD]] I don't actually understan= d how you infer that people=0D=0Ainvolved in this debate don't understand t= hose issues; I don't see the=0D=0Aevidence of that. In any case, all existi= ng licensed mobile networks=0D=0Aabsolutely rely on functionality within th= e device to make emergency=0D=0Acalls; standards have to be supported or th= e device cannot be used. I'm=0D=0Aalso not asking for a position in the deb= ate; I'm asking for elucidation=0D=0Aof how IMS achieves all the things tha= t are claimed for it (exactly)=0D=0Agiven the context that ECRIT is argued = to be inadequate in comparison.=0D=0AThat detail, so far, has been assumed = and not provided as part of the=0D=0Adebate.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09= > It=0D=0A=0D=0A=09 >would be reasonable to infer from the representati= ons made=0D=0A=0D=0A=09 >with respect to the IMS model that this definitio= n is clear,=0D=0A=0D=0A=09 >well understood, and unambiguous to those fami= liar with the=0D=0A=0D=0A=09 >domain. I'd like to explore that premise a l= ittle.=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 >While you're contributing your kn= owledge to the discussion=0D=0A=0D=0A=09 >then Gabor, could you please ela= borate on the detailed=0D=0A=0D=0A=09 >procedures, including which protoco= ls are employed, when an=0D=0A=0D=0A=09 >emergency call is invoked accordi= ng to 3GPP 23.167=3F=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 >I'll grant that, so= mehow, the UE has recognized the=0D=0A=0D=0A=09 >appropriate E-CSCF in tha= t managed network and now needs to=0D=0A=0D=0A=09 >invoke the emergency se= rvice procedures. As the spec points=0D=0A=0D=0A=09 >out, there's the Ml i= nterface to the location routing=0D=0A=0D=0A=09 >function (LRF). Can you p= lease describe the details as=0D=0A=0D=0A=09 >defined by 3GPP from then on= =3F Or, alternatively, could you=0D=0A=0D=0A=09 >point to the detailed pro= cedure specification that explains=0D=0A=0D=0A=09 >what actually occurs=3F= The analogue from the ECRIT=0D=0A=0D=0A=09 >perspective is quite well ela= borated, including the use of=0D=0A=0D=0A=09 >LoST for the routing query a= nd the use of candidate LCPs for=0D=0A=0D=0A=09 >the location determinatio= n by value and by reference, the=0D=0A=0D=0A=09 >associated conveyance of = location value/reference in SIP etc.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Brian = sent me off-list a pretty comprehensive list of issues=0D=0Awhere the 3GPP = procedures differ from the ones defined in ECRIT. Since=0D=0Athat list is b= y far more complete than the one I could produce, I will=0D=0Acopy paste it= below. I hope Brian doesn't mind it:=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09" At = the moment, the major differences between 3GPP and phonebcp=0D=0Aare:=0D=0A=0D= =0A=09a) Who inserts location, and what protocols are used=0D=0A=0D=0A=09b)= LoST (3GPP doesn't say LoST can't be used; it basically=0D=0Aleaves this a= s local practice. Since in North America, LoST will be=0D=0Amandated, that= 's not a difference. However, 3GPP would say that LoST,=0D=0Aif used, woul= d be queried by the E-CSCF, and not the endpoint, which=0D=0Adiffers from -= phonebcp=0D=0A=0D=0A=09c) SIP termination: present 3GPP specs make no provi= sion for=0D=0Apacket mode termination.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Ther= e are some relatively minor signaling issues.=0D=0A=0D=0A=09=20=0D=0A=0D=0A= =09To be phonebcp compatible, 3GPP networks would have to implement=0D=0Aon= e of the -phonebcp LCPs, and provide access to a LoST server. The=0D=0Afor= mer is a big issue, the latter is a small issue."=0D=0A=0D=0A=09[[MCD]] I u= nderstand the philosophical difference - and how, for=0D=0Aexample, ECRIT c= ould support an emergency call initiated from an=0D=0AECRIT-compliant emerg= ency client on a child's portable game console=0D=0Aconnected to the in-veh= icle WiFi connected to the Internet via an LTE=0D=0Aaccess network (but it'= s difficult to see how IMS can do that). I'm=0D=0Aactually asking for the s= pecific details (end-to-end and including the=0D=0Aprotocols used) of an IM= S call according to 23.167 as part of an attempt=0D=0Ato ensure that both s= ides of the debate are equipped with the same=0D=0Ainformation.=0D=0A=0D=0A= =09=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09My request was to either restrict th= e scope of the document to=0D=0A'Internet', or make it a requirements docum= ent (instead of bcp) with=0D=0Aintended status standards track. Writing a b= cp which excludes the most=0D=0Alikely near future practice looks weird to = me.=0D=0A=0D=0A=09[[MCD]] I'm comfortable that the scope of the document is=0D= =0Arestricted to "Internet" - or certainly to IP (internet with a lower=0D=0A= case 'i') networks generally. It's just that others would like to see=0D=0A= some indication that, somehow, it doesn't apply to 3GPP networks - even=0D=0A= though it does.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09- Gabor=0D=0A=0D=0A=09=20=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09 >I'm sure IETF participants would appreciat= e and benefit from=0D=0A=0D=0A=09 >elucidation of just what the 3GPP "secr= et sauce" is. I don't=0D=0A=0D=0A=09 >want to leave anyone out and, of cou= rse, invite other 3GPP=0D=0A=0D=0A=09 >knowledgeable and vocal parties to = contribute.=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 >Cheers,=0D=0A=0D=0A=09 >Mar= tin=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 >-----Original Message-----=0D=0A=0D=0A= =09 >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=0D=0A=0D= =0A=09 >On Behalf Of Gabor.Bajko@nokia.com=0D=0A=0D=0A=09 >Sent: Tuesday,= 4 August 2009 12:38 AM=0D=0A=0D=0A=09 >To: br@brianrosen.net; drage@alcat= el-lucent.com;=0D=0A=0D=0A=09 >john.elwell@siemens-enterprise.com; mlinsne= r@cisco.com;=0D=0A=0D=0A=09 >ecrit@ietf.org=0D=0A=0D=0A=09 >Subject: Re: = [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 = >=0D=0A=0D=0A=09 > >-----Original Message-----=0D=0A=0D=0A=09 > >From:= ecrit-bounces@ietf.org=0D=0A[mailto:ecrit-bounces@ietf.org]=0D=0A=0D=0A=09= > >On Behalf Of ext Brian Rosen=0D=0A=0D=0A=09 > >Sent: Friday, July 3= 1, 2009 5:00 PM=0D=0A=0D=0A=09 > >To: 'DRAGE, Keith (Keith)'; 'Elwell, Jo= hn'; 'Marc=0D=0A=0D=0A=09 >Linsner'; 'ecrit'=0D=0A=0D=0A=09 > >Subject: = Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09 > >=0D=0A=0D=0A=09 > >Haha, = yes, a browser, or even an app using the raw packet=0D=0A=0D=0A=09 > >ser= vice in a 3GPP GPRS device is on the Internet, although=0D=0A=0D=0A=09 > = >there are some subtle differences (the DNS root for=0D=0A=0D=0A=09 > >ex= ample),=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 >These are deployment and operati= onal decisions, which have=0D=0A=0D=0A=09 >nothing to do with the ongoing = discussion.=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 > > but then, a service usin= g that raw packet=0D=0A=0D=0A=09 > >interface to make, say, an IM to an e= mergency service=0D=0Awould=0D=0A=0D=0A=09 > >probably have to make use o= f the phonebcp procedures, a=0D=0Afact=0D=0A=0D=0A=09 > >3GPP is studious= ly ignoring.=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 >3gpp has defined a set of d= ifferent procedures for emergency=0D=0A=0D=0A=09 >calls, and carriers will= likely ask vendors to implement as=0D=0A=0D=0A=09 >specified. Then users = will also use it as specified.=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 > > I wo= uld not go so far as to=0D=0A=0D=0A=09 > >say most people would prefer th= e 3GPP specified procedures=0D=0A=0D=0A=09 > >vs the IETF phonebcp proced= ures, especially if they=0D=0A=0D=0A=09 > >understood the tradeoffs.=0D=0A=0D= =0A=09 >=0D=0A=0D=0A=09 >It is not a question of preference. Carriers wan= t to have a=0D=0A=0D=0A=09 >solution which is reliable and operational 99.= 99999% of the=0D=0A=0D=0A=09 >cases. It has to be a stricly managed networ= k.=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 > >However, a 3GPP mobile telephone s= ervice is not an=0D=0AInternet=0D=0A=0D=0A=09 > >service, no matter how y= ou stretch it.=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 >Wow. What is your definit= ion of Internet Service=3F I do=0D=0A=0D=0A=09 >remember statements on thi= s mailing list that cellular=0D=0A=0D=0A=09 >networks are not IP capable. = I guess you didn't want to go=0D=0Athat far.=0D=0A=0D=0A=09 >I access the = same content regardless of whether I use the=0D=0A=0D=0A=09 >comcast cable= ending in the house or t-mobile's packet data=0D=0A=0D=0A=09 >service any= where else. The only difference is the speed and=0D=0A=0D=0A=09 >the cost.=0D= =0A=0D=0A=09 >Looks the same to me, no matter how I strech it.=0D=0A=0D=0A= =09 >=0D=0A=0D=0A=09 >- gabor=0D=0A=0D=0A=09 >=0D=0A=0D=0A=09 > >Brian=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA161D.FFBD62A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A<= !--[if gte mso 9]>=0D=0A =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

Hi Gabor,

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

 

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

I think you’re view of the world is=0D= =0Amore complicated than it needs to be. Only one key development has happe= ned.=0D=0AThe world has moved from using circuit switching in a global PSTN= to using=0D=0Apacket switching in a global Internet. You may see some deta= ils, and interim=0D=0Afluctuations in service standards as consequence of t= hat transition, but the=0D=0Afundamentals of operator obligation, regulator= y requirements, and service=0D=0Alevels will be the same in the long term.<= o:p>

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

 

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

Mobile network operators are= moving from=0D=0Aproviding cellular PSTN access to providing cellular Inte= rnet access. Wireline=0D=0Aoperators are moving from providing fixed PSTN a= ccess to providing fixed=0D=0AInternet access. Both parties can, and will u= ltimately be required to, provide a=0D=0Areliable service. I can certainly = tell you that, as of now, the Internet access=0D=0Aside of cellular is no m= ore reliable than Wireline Internet access is.

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

 =

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

An ECRIT compliant Internet access=0D=0Aprovider needs to e= nsure the following (apart from reliable basic Internet=0D=0Aaccess to begi= n with of course):

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

 

=0D= =0A=0D=0A
    =0D=0A
  1. Access=0D=0A to LIS functionality for routing and dispatch purpo= ses
    2. =0D=0A
  2. Access=0D=0A t= o LoST (either within the network or to a public server)<= /font>
    3. =0D=0A
  3. SIP=0D=0A routability to the PSAP = URI(s) in their area of coverage
    4. =0D=0A
=0D= =0A=0D=0A

 =

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

The elements involved in that can be just=0D=0Aas reliable = as any IMS-specific elements that 3GPP define. A LoST server can be=0D=0Aju= st as reliable as an LRF – and is no more complex. There is always a=0D= =0Adependency on the end device but I’ll say this – if all that=0D= =0Adevices have to do is provide a consistent reliable ECRIT-compliant clie= nt=0D=0Afunction then we’ll all get something more reliable when that= client is=0D=0Athe same regardless of the actual access technology compare= d to if it has to be=0D=0A“re-invented” for every flavour of ac= cess technology.

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

 

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

Cheers,

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

Martin

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

 =

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

From:=0D=0AGabor.Bajko@nokia.com [mailto:G= abor.Bajko@nokia.com]
=0D=0ASent: Thursday, 6 August 2009 4:40=0D=0AAM
=0D=0ATo: Dawson, Martin;=0D=0Abr@brianrosen.net; dra= ge@alcatel-lucent.com;=0D=0Ajohn.elwell@siemens-enterprise.com; mlinsner@ci= sco.com; ecrit@ietf.org
=0D=0ASubjec= t: RE: ECRIT/IMS -=0D=0Aindependent discussion from the PhoneBCP= hum

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

=  

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

 

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

 <= /span>

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>From:=0D=0Aext= Dawson, Martin [mailto:Martin.Dawson@andrew.com]
=0D=0ASent: Tuesday, August 04, 2009=0D=0A6:37 PM=0D=0ATo: Bajko Gabor=0D=0A= (Nokia-CIC/MtView); br@brianrosen.net; drage@alcatel-lucent.com;=0D=0Ajohn.= elwell@siemens-enterprise.com; mlinsner@cisco.com; ecrit@ietf.org
=0D=0A= Subject: RE: ECRIT/IMS -=0D=0A= independent discussion from the PhoneBCP hum

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

 

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

 

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

-----Origin= al Message-----
=0D=0AFrom: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@no= kia.com]
=0D=0ASent: Wednesday, 5 August 2009 4:41 AM
=0D=0ATo: Daws= on, Martin; br@brianrosen.net; drage@alcatel-lucent.com;=0D=0Ajohn.elwell@s= iemens-enterprise.com; mlinsner@cisco.com; ecrit@ietf.org
=0D=0ASubject:= RE: ECRIT/IMS - independent discussion from the PhoneBCP hum

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

 =

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

 

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

 <= /p>=0D=0A=0D=0A

=   >-----Original Message----= -

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

  &g= t;From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com]

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

  >Sent: Monday, = August 03, 2009 9:19 PM

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

  >To: Bajko Gabor (Nokia-CIC/MtView); br@brianrosen.net= ;

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

  &g= t;drage@alcatel-lucent.com;

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

  >john.elwell@siemens-enterprise.com; mlinsner@ci= sco.com;

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

&n= bsp; >ecrit@ietf.org

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

  >Subject: ECRIT/IMS - independent discussion from the=0D= =0APhoneBCP hum

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

  >

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

  >I interpret Brian's comment as being that a conventional=0D= =0A*switched

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

  >circuit* mobile phone service is not the same as an Internet

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

  >[c= all] service. I think that's pretty apparent from the

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

  >context.

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

 

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

This might have been what B= rian meant, but it wasn't obvious for me,=0D=0Aespecially as circuit switch= ing is not part of 3G (HSPA or LTE), that is 2G.=0D=0A=0D=0A

[[MCD]]=0D=0AExactly – but much has been= made of how 3GPP/IMS has defined ways of=0D=0Aproviding transparent hand-o= ff between packet service and circuit service in=0D=0Athe context of an eme= rgency call, with the subsequent inference that this makes=0D=0AECRIT non-a= pplicable in a 3GPP access context. That’s an incorrect=0D=0Ainferenc= e and the scenario is orthogonal to the purpose of ECRIT. Nevertheless,=0D=0A= I’m genuinely interested in the details – i.e. how does IMS sta= te=0D=0Athat this is done (not a description of how it *could* be done by s= omeone but=0D=0Awhat are the exact protocols and procedures specified). I&#= 8217;m particularly=0D=0Ainterested in how these procedures appear to the e= nd device and the emergency=0D=0Anetwork.

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

 

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

  >Would you claim that it is, in fact, the Int= ernet

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

 = ; >when a switched circuit call is made Gabor=3F

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

No, I don't say that. But would you cl= aim that a VoIP call made on a 3G=0D=0A(packet switched) network is not an = Internet Service=3F

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

[= [MCD]]=0D=0AI do think it’s an Internet context in that case – = and that’s=0D=0Athe case where I have no difficulty seeing that ECRIT= is applicable.

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

 

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

= =   >Comments about reliability are misleading. Either

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

  >architectural = solution can be made arbitrarily reliable.

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

 

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

Yes, they can. But as we can see, unless it is require= d by regulation,=0D=0Areliability is missing. Carriers operating in licence= d bands have to meet=0D=0Acertain conditions, while a network operating in = an unlicenced band is free to=0D=0Aturn on/off its operation.

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

[[MCD]]=0D=0ALegislation imposing= reliability and the question of unlicensed bands are both=0D=0Aorthogonal.=  &= nbsp;

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

 

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

<= b><Gabor= >=0D=0ABut reliability and mobility were the main architectural design c= hoices in=0D=0A3GPP. That is why they ended up with that complex architectu= re! The procedures=0D=0Athemselves are a consequence of the architecture.

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

= Carrie= rs=0D=0Aplan to switch emergency call handling from CS to PS domain, and th= ey wanted a=0D=0Anetwork controlled ES, they did not want to rely on the ha= ndset doing the whole=0D=0Aprocedure because of the liability. Support for = emergency calls is not a=0D=0Arevenue generator for carriers, they'd b= e happy leaving the tasks up to=0D=0Athe client if there were no consequenc= es of emergency calls failing for=0D=0Awhatever reason.

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

And=0D=0Ajust to answer = James point, ISPs offering broadband internet service can not be=0D=0Aparal= elled with carriers operating networks using 3GPP standards. The ISPs do=0D= =0Anot commit to offer you service with less than a few minutes outage per = year,=0D=0Athey provide no mobility and they are not mandated to support em= ergency=0D=0Aservices.

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

 

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

- gabor

=0D=0A=0D=0A<= p class=3DMsoPlainText> 

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

 

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

 ECRIT=0D=0Ais applicable to a broadband access regardless of, and i= ndependently=0D=0Aconstrained by, those considerations. Regulation is a mov= able feast – in=0D=0Athe US,=0D=0Athe Phase 2 regulation= was aimed at CMRS (circuit service) E9-1-1. The FCC is=0D=0Astill kicking = around the ideas associated with VoIP. There’s no doubt=0D=0Athat, fr= om a technical perspective, IMS is VoIP. The question of how operators=0D=0A= choose to interpret their own obligations wrt IMS is subject to their own r= isk=0D=0Aand business assessments including how they present that service t= o their=0D=0Asubscribers. That is, do they regard it as phase 2 cellular or= do they regard=0D=0Ait as VoIP=3F But that’s just the US. Any arbitrary jurisdiction=0D=0Acould say that any provider of bro= adband Internet access to the public is=0D=0Arequired to support the ECRIT = compliant functions of a LIS, access to LoST, and=0D=0Aa reliable route to = the PSAP URI(s) applicable to the operators’ areas of=0D=0Acoverage. = They could further require specific levels of=0D=0Areliability/availability= and accuracy. They could require it of municipal WiFi=0D=0Anetwork operato= rs (unlicensed band) just as much as they could of licensed band=0D=0Awirel= ess operators. They could even require it of enterprises of a certain size=0D= =0A(unlicensed wireless and wired Ethernet). The point is that the existenc= e of=0D=0Aregulatory requirements or otherwise does not militate against th= e=0D=0Aapplicability of ECRIT to specific technologies.

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

 

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

  >according to the requirements applied by the= jurisdiction.

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

 

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

= = Certain radio access protocols are inherently unreliable.=

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

[[MCD]]=0D=0AWell – I certainly = have reliability problems with GSM and UMTS coverage=0D=0Ain a lot of place= s… but, again, the reliability of any given technology=0D=0Adoes not = say anything about the applicability of ECRIT to that or other=0D=0Atechnol= ogies.

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

&nbs= p;

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

  >Th= ere's been a presumption in this debate that somehow ECRIT

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

  >needs "apol= ogists" relative to IMS because IMS has=0D=0Aa

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

  >definition for handling emergency calls = in 3GPP access.

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

 

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

;)

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

I am by= far not an IMS evangelist, nor an ECRIT one, so I'd rather stay=0D=0Aout f= rom these kind of debates.

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

What people seem to have trouble understanding is that some= networks=0D=0A(eg the ones operating in licenced bands) can not afford to = rely on the client=0D=0Ato do all the procedures needed to place an emergen= cy call. They need to assist=0D=0Athe client and make sure the call ends up= in the right place. They are liable=0D=0Afor that. That's the difference.<= o:p>

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

[[MCD]]=0D=0AI don&#= 8217;t actually understand how you infer that people involved in this=0D=0A= debate don’t understand those issues; I don’t see the evidence = of=0D=0Athat. In any case, all existing licensed mobile networks absolutely= rely on=0D=0Afunctionality within the device to make emergency calls; stan= dards have to be=0D=0Asupported or the device cannot be used. I’m als= o not asking for a=0D=0Aposition in the debate; I’m asking for elucid= ation of how IMS achieves=0D=0Aall the things that are claimed for it (exac= tly) given the context that ECRIT=0D=0Ais argued to be inadequate in compar= ison. That detail, so far, has been assumed=0D=0Aand not provided as part o= f the debate.

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

 

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

<= font size=3D2 face=3D"Courier New">&= nbsp; >  It

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

  >would be reasonable to infer from the representations ma= de

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

  &= gt;with respect to the IMS model that this definition is clear,<= /span>

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

  >well unders= tood, and unambiguous to those familiar with the=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >domain. I'd like to explor= e that premise a little.

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

  >

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

  >While you're contributing your knowledge to the discu= ssion

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

 = ; >then Gabor, could you please elaborate on the detailed

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

  >procedures, in= cluding which protocols are employed, when an

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

  >emergency call is invoked accor= ding to 3GPP 23.167=3F

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

  >

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

  >I'll grant that, somehow, the UE has recognized the

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

  >ap= propriate E-CSCF in that managed network and now needs to=

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

  >invoke the emerge= ncy service procedures. As the spec points

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

  >out, there's the Ml interface to the lo= cation routing

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

  >function (LRF). Can you please describe the details as<= /o:p>

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

  >defin= ed by 3GPP from then on=3F Or, alternatively, could you

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

  >point to the detail= ed procedure specification that explains

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

  >what actually occurs=3F The analogue fr= om the ECRIT

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

  >perspective is quite well elaborated, including the use of

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

  >LoS= T for the routing query and the use of candidate LCPs for=

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

  >the location dete= rmination by value and by reference, the

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

  >associated conveyance of location value= /reference in SIP=0D=0Aetc.

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

 

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

Brian sent me off-list a pretty comprehensive list of issues whe= re the=0D=0A3GPP procedures differ from the ones defined in ECRIT. Since th= at list is by=0D=0Afar more complete than the one I could produce, I will c= opy paste it below. I=0D=0Ahope Brian doesn't mind it:

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

 =

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

" At the moment, the major dif= ferences between 3GPP and phonebcp=0D=0Aare:

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

a) Who inserts location, and what protocol= s are used

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

= = b) LoST (3GPP doesn't say LoST can't be used; it basically leaves this=0D=0A= as local practice.  Since in North America,=0D=0ALoST will be mandated, that's not a difference.  However= , 3GPP would say that=0D=0ALoST, if used, would be queried by the E-CSCF, a= nd not the endpoint, which=0D=0Adiffers from -phonebcp

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

c) SIP termination: present 3GP= P specs make no provision for packet=0D=0Amode termination.

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

 

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

There are some relatively mino= r signaling issues.

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

 

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

To be phonebcp compatible, 3GPP networks would have to implement one of=0D= =0Athe -phonebcp LCPs, and provide access to a LoST server.  The forme= r is a=0D=0Abig issue, the latter is a small issue."=

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

[[MCD]]=0D=0AI understand the philosop= hical difference – and how, for example, ECRIT=0D=0Acould support an = emergency call initiated from an ECRIT-compliant emergency=0D=0Aclient on a= child’s portable game console connected to the in-vehicle=0D=0AWiFi = connected to the Internet via an LTE access network (but it’s=0D=0Adi= fficult to see how IMS can do that). I’m actually asking for the=0D=0A= specific details (end-to-end and including the protocols used) of an IMS ca= ll=0D=0Aaccording to 23.167 as part of an attempt to ensure that both sides= of the=0D=0Adebate are equipped with the same information.

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

 

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

 

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

[[MCD]]=0D=0AI= ’m comfortable that the scope of the document is restricted to=0D=0A&= #8220;Internet” – or certainly to IP (internet with a lower cas= e=0D=0A‘i’) networks generally. It’s just that others wou= ld like to=0D=0Asee some indication that, somehow, it doesn’t apply t= o 3GPP networks=0D=0A– even though it does.<= /p>=0D=0A=0D=0A

=  

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

- Gabor

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

 

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

 

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

  >I'm sure IETF participants would appreciate and= benefit from

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

  >elucidation of just what the 3GPP "secret sauce"=0D= =0Ais. I don't

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

  >want to leave anyone out and, of course, invite other 3GPP

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

  >kn= owledgeable and vocal parties to contribute.

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

  >

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

  >Cheers,

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

  >

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

  >-----Original M= essage-----

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

  >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]

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

  >On= Behalf Of Gabor.Bajko@nokia.com

=0D=0A=0D=0A  >Sent: Tuesday, 4 August 2009 12:38 AM=

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

  >To: = br@brianrosen.net; drage@alcatel-lucent.com;

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

  >john.elwell@siemens-enterprise.= com; mlinsner@cisco.com;

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

  >ecrit@ietf.org

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

  >Subject: Re: [Ecrit] HUM on PhoneBCP

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

  >

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

  >

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

  >

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

  >&n= bsp; >-----Original Message-----

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

  >  >From: ecrit-bounces@ietf.org=0D= =0A[mailto:ecrit-bounces@ietf.org]

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

  >  >On Behalf Of ext Brian Rosen<= o:p>

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

  >&n= bsp; >Sent: Friday, July 31, 2009 5:00 PM

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

  >  >To: 'DRAGE, Keith (K= eith)'; 'Elwell, John'; 'Marc

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

  >Linsner'; 'ecrit'=0D=0A=0D=0A

  >  >Subject: Re: [Ec= rit] HUM on PhoneBCP

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

  >  >

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

  >  >Haha, yes, a browser, or even an = app using the=0D=0Araw packet

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

  >  >service in a 3GPP GPRS device is o= n the Internet,=0D=0Aalthough

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

  >  >there are some subtle differences = (the DNS root=0D=0Afor

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

  >  >example),

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

  >

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

  >These are deployment and operational dec= isions, which have

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

  >nothing to do with the ongoing discussion.

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

  >

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

  >  > = but then, a service using that raw packet

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

  >  >interface to make, say, an I= M to an emergency=0D=0Aservice would

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

  >  >probably have to make use of = the phonebcp=0D=0Aprocedures, a fact

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

  >  >3GPP is studiously ignoring.<= o:p>

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

  >

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

  >3g= pp has defined a set of different procedures for emergency

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

  >calls, and carri= ers will likely ask vendors to implement as

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

  >specified. Then users will also= use it as specified.

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

  >

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

  >  >  I would not go so far as to

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

  >  = >say most people would prefer the 3GPP specified=0D=0Aprocedures

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

  >  = >vs the IETF phonebcp procedures, especially if=0D=0Athey

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

  >  >und= erstood the tradeoffs.

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

  >

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

  >It is not a question of preference. Carriers want to = have a

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

&nbs= p; >solution which is reliable and operational 99.99999% of the

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

  >cases. I= t has to be a stricly managed network.

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

  >

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

  >  >However, a 3GPP mobile teleph= one service is not=0D=0Aan Internet

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

  >  >service, no matter how you st= retch it.

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

<= font size=3D2 face=3D"Courier New">&= nbsp; >

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

= =   >Wow. What is your definition of Internet Service=3F I do

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

  >remembe= r statements on this mailing list that cellular=0D=0A=0D=0A

  >networks are not IP capable= =2E I guess you didn't want to go=0D=0Athat far.=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>  >I access the same content = regardless of whether I use the

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

  >comcast cable ending in the house or t-mobi= le's packet data

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

  >service anywhere else. The only difference is the speed = and

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

  = >the cost.

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

  >Looks the same to me, no matter how I strech it.

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

  ><= /span>

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

  >- gabor

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

  >

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

  >&n= bsp; >Brian

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

<= tr>

----------------------------------------------------------------= --------------------------------
=0D=0AThis message is fo= r the designated recipient only and may
=0D= =0Acontain privileged, proprietary, or otherwise p= rivate information.  
=0D=0AIf you have re= ceived it in error, please notify the se= nder
=0D=0Aimmediately and delete the original. = ; Any unauthorized use of
=0D=0Athis email = ;is prohibited.
=0D=0A---------------------------------------------= ---------------------------------------------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01CA161D.FFBD62A9-- From Martin.Dawson@andrew.com Wed Aug 5 15:50:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF733A6A50 for ; Wed, 5 Aug 2009 15:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2821-tdoMb8f for ; Wed, 5 Aug 2009 15:50:11 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 394EE3A6C72 for ; Wed, 5 Aug 2009 15:49:26 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_05_18_12_10 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 05 Aug 2009 18:12:09 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 17:49:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 17:49:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoWGCs2sQdifK5ETpOQ6DeQpYvf3AABotTg References: <0D5F89FAC29E2C41B98A6A7 62007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb 490$0b2f1db0$@net><003501ca1153$77db50e0$6791f2a0$@net><01a501ca123a$fe05da40$fa118ec0$@net> From: "Dawson, Martin" To: "Randall Gellens" , , , , , , X-OriginalArrivalTime: 05 Aug 2009 22:49:29.0158 (UTC) FILETIME=[FD83BE60:01CA161E] Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 22:50:12 -0000 Please elaborate on what you mean by "interoperability issues" Randy=3F=0D=0A= What are they=3F=0D=0A=0D=0AAlso - the request stands for a more detailed e= nd-to-end description of=0D=0Athe 3GPP emergency call procedure for the ben= efit of all in this=0D=0Adiscussion. Can you provide that=3F=0D=0A=0D=0AChe= ers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Randall G= ellens [mailto:randy@qualcomm.com]=20=0D=0ASent: Thursday, 6 August 2009 7:= 54 AM=0D=0ATo: Dawson, Martin; Gabor.Bajko@nokia.com; br@brianrosen.net;=0D= =0Adrage@alcatel-lucent.com; john.elwell@siemens-enterprise.com;=0D=0Amlins= ner@cisco.com; ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] ECRIT/IMS - indepen= dent discussion from the=0D=0APhoneBCP hum=0D=0A=0D=0AAt 8:37 PM -0500 8/4/= 09, Martin Dawson wrote:=0D=0A=0D=0A> It's just that others would like to = see some indication that,=20=0D=0A> somehow, it doesn't apply to 3GPP netwo= rks - even though it does.=0D=0A=0D=0AThe compromise text didn't say that t= he ecrit solution can't or=20=0D=0Ashouldn't be used in 3GPP or any other e= nvironment; it was just a=20=0D=0Abrief acknowledgment that there were some= key differences between=20=0D=0Athis solution and others, and that interop= erability and related=20=0D=0Aissues between them are left for future docum= ents.=0D=0A=0D=0A--=20=0D=0ARandall Gellens=0D=0AOpinions are personal; = facts are suspect; I speak for myself only=0D=0A-------------- Randomly = selected tag: ---------------=0D=0AThere are things that are so serious tha= t you can only joke about them=0D=0A = --Heisenberg=0D=0A=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0AThis = message is for the designated recipient only and may=0D=0Acontain privilege= d, proprietary, or otherwise private information. =20=0D=0AIf you have rece= ived it in error, please notify the sender=0D=0Aimmediately and delete the = original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----= ---------------------------------------------------------------------------= -----------------=0D=0A[mf2]=0D=0A From fmenard@xittel.net Thu Aug 6 04:50:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328863A6B07 for ; Thu, 6 Aug 2009 04:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4haNvPLrQKrg for ; Thu, 6 Aug 2009 04:50:55 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 3C10C3A67FE for ; Thu, 6 Aug 2009 04:50:55 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MZ1Un-0005DZ-Og for ecrit@ietf.org; Thu, 06 Aug 2009 07:50:57 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MZ1Uo-0004LO-5h for ecrit@ietf.org; Thu, 06 Aug 2009 07:50:58 -0400 Message-Id: <9B2661AD-4413-49A2-A4E5-D59A43678290@xittel.net> From: Francois Menard To: ecrit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) X-Priority: 1 Date: Thu, 6 Aug 2009 07:50:56 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [Ecrit] ECRIT Simplified E-9-1-1 workflow proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 11:50:56 -0000 Is anything wrong with the following E-9-1-1 workflow to be possible with any ATA that can be upgraded to become Phone-BCP compliant. Step 0) ISP is provided with a copy of the MASTER STREET ADDRESS GUIDE already pre-formatted in PIDF-LO format. ISP provisions a DHCP server/ HELD server with a PIDF-LO object to be associated with the IP address to be assigned to an end-user based on the WIREMAP circut-ID. In DSL wholesale, the ISP uses the CIRCUT-ID acquired by RADIUS for a given MSAG-VALID CIVIC PIDF-LO object. The ISP then simply matches the PPP username and password arriving on a given CIRCUIT-ID to create a binding between the PUBLIC-IP associated dynamically to the CIRCUIT-ID and the PIDF-LO object. The ISP really does not care about the PPP credentials. All it wants to do is BIND a PIDF-LO to a CIRCUIT-ID to an IP address and allow for that PIDF-LO to be retrieved EITHER via HELD, or via DHCP OPTION 99. For instance, ILECs for their L2TP LAC's are transitioning to Juniper E320's - 8.2.3 patch-0.4 which is capable of the following formats to pass along the unique DSLAM port to be associated with a CIVIC address over RADIUS to the wholesale ISP as described in https://www.juniper.net/techpubs/en_US/junose10.0/information-products/topic-collections/broadband-access/l2tp-calling-number-avp.html Step 1) In DSL wholesale, PPPoE will assign an IP. The reverse lookup would be done for this IP by the ATA. Step 2) If the ATA is behind nat, it would be provisioned with a STUN server IP address. The STUN server will return to the ATA, what public IP address the ATA is behind. Step 3) The ATA would then perform an inverse lookup for that IP address in the DNS server of that domain name, and would expect there to be a DNS entry for LOCATIONSERVER.DOMAIN-GATHERED-BY-REVERSE- LOOKUP.DOMAIN-GATHERED-BY-REVERSE-LOOKUP-SUFFIX Step 4) The ATA would then use its HELD stack to download the location object (PIDF-LO). Step 5) ATA Memorizes PIDF-LO. Step 6) Upon having to dial 9-1-1, ATA sends PIDF-LO via SIPCORE LOCATION CONVEYANCE (attached) Step 7) VoIP server provider will steer the call to the an ILEC SIP PROXY and send the 9-1-1 RTP media to the ILEC 9-1-1 media gateway Step 8) ILEC will inspect the content of the PIDF-LO and will route the call to the appropriate PSAP All ILEC needs to do is to stop blocking the CIRCUIT-ID's over the RADIUS accounting interface and accept to implement a SIP-based gateway + media gateway on the INTERNET which would provide access to all the PSAPs the ILEC manages (which is the case in Canada where PSAPs only interconnect directly with the ILEC and no other competitors). I would appreciate answers by the end of the day on friday as I am submitting this to the Canadian FCC (CRTC) friday evening. F. -- Francois Menard fmenard@xittel.net Francois Menard fmenard@xittel.net From L.Liess@telekom.de Thu Aug 6 07:29:43 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15623A6DDC for ; Thu, 6 Aug 2009 07:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOyFZbfJ4Dd6 for ; Thu, 6 Aug 2009 07:29:41 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 7A2223A6DCE for ; Thu, 6 Aug 2009 07:29:05 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 06 Aug 2009 16:29:03 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 16:29:03 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA16A2.3F0094FC" Date: Thu, 6 Aug 2009 16:29:02 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkA== References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> From: To: , , X-OriginalArrivalTime: 06 Aug 2009 14:29:03.0596 (UTC) FILETIME=[3F4C52C0:01CA16A2] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 14:29:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA16A2.3F0094FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 Hi Roland, =20 I think what you're saying is that you don't think that Germany will go = on to implement full ECRIT support but will peg development at an = interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC will = look like in 20 years. Roland's answer only applies to the next 5 to 10 = years.=20 =20 That would be disappointing - not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service. =09 [[LLi]] This may be true for "green field" ISPs and VSPs but not for = incumbent carriers with existing infrastructure. And universal service = is not a requirement for us. Neither the German regulator requires it = nor is it a busines case. =20 =20 Nevertheless, I don't think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP = should be more flexible: =20 *=09 Allow additional location identifiers=20 *=09 Allow AN operated LOST *=09 Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives.=20 *=09 Allow and describe also network-centric, not only ED-centric = architectures. If I remember correctly, John Medland from BT also = recomended to use a more network- centric architecture, at least for the = next years.=20 =20 I think it just means that the German regulator and technical advisory = committees would point out the subset aspects of compliance that would = be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP = contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard = body is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with very = valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a = business case will not help the draft in the end, also if it becomes a = BCP. It would make sense to make it more flexible so people are willing = to adopt it. =20 =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis - as has = been done in the UK and Canada. Of course, it's generally recognized as = only an interim step, even in those jurisdictions. =09 Other comments below. =20 Cheers, Martin =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling = based on location-by-reference and ED's IP-address.=20 [[MCD]] I think you might mean "identity extensions" rather than = location-by-reference because LbyR still requires the ED to obtain the = reference - e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD = but SOAP over HTTP, but anyway similar). The LIS responds with a numeric = string associated to the caller location, in principle a LbyR and with = the PSAP number. The proxy inserts the LbyR into the SIP-message (as = P-Asserted-ID because the PSAPs are in PSTN) and routes the message to = the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being realistic, = at least in Germany, some are not realistic at all. Implementing these = requirements cost a carrier a lot of money and there is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and = location databases. Routing of emergency calls is currently done in = Germany based on phone area code not on geo or civic location, at least = for the fixed network. For mobile networks the cell-id is used in = common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US has = lots (6000 plus) and Australia has two (and they are redundant so it = doesn't matter which one). Presumably geographic information, for PSAP = catchment areas, is the basis for determining which area codes are = relevant to begin with? After all, an area code is not intrinsically = geographic; it's a network routing value. If so, then some geographic = discriminator is already in play in terms of constructing the area code = based routing data (something like zip codes perhaps?) - and in that = case, it should be straightforward to by-pass the area code step in the = construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the = carriers, the regulator and the PSAPs operators (police, the Red Cross) = agreed to do so. This may change in the future, but it will take a quite = long time. =20 With nomadic VoIP devices (and it's no good being in denial about this = being the norm in the future) area code is no more reliable than it is = for conventional mobile phones. And, presumably, area code is not used = for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the = area code, and have a different table than the fixed network operators. = They are not going to change this. As to the nomadic SIP-users...if we = like it or not, very few of our customers use our SIP service nomadic, = let alone call EC from their laptop. =20 1 LOST as a national, let alone as a global directory is = not going to be implemented. The regulator will provide in the web a = static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its = own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement = something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would = still be able to determine a route to the correct PSAP. Alternatively, = as long as the regulator is maintaining a web service with the routing = information, why not make that directly accessible using LoST and save = the operators the cost of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page with = a table which operator can print and implement in their darabases and = operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you = know. The regulator will not do this. =09 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The emergency = network can (automatically and before human resources are engaged) = assess the source of the reference, and the validity of the location by = dereference, without having to trust location provided directly from the = ED. There are more sophisticated approaches to trustability even using = LbyV - based on digital signatures across appropriate attributes. This = WG and Geopriv haven't really got to grips with that... yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is = needed if EC must work for private and enterprise networks and VPNs. We = have no such regulatory requirements. And we don't know of any verdor = of DSL-EDs which provides today SIP with LbyR and is as cheap as the = devices without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. = =20 1 There are already a lot of existing EDs in usage which don't = send location. =20 [[MCD]] Quite right. ECRIT doesn't overly concern itself with that = interim situation. The UK and Canadian definitions for an interim = solution (limiting service to in-country VoIP proxy operators) both = assume third-party query via identity-extension to allow the proxy or = the VPC to make the query to the LIS. This isn't extensible to universal = emergency service access by all visiting devices but it does put the = necessary LIS functionality in place as a very good starting point. It = would be a pity if Germany were to cease the evolution there as it would = not fulfil the real promise of the Internet and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim = solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination = infrastructure in place for the purposes of dispatch is done - and then = the next, simpler step, of using that to support the routing procedure = isn't taken... that would be a waste. =09 [[LLi]] Do you think this is an argument for a product manager? They = need a business case. =20 =20 =20 We don't intend to require our ED-vendors to provide location because = it is useless to us. =20 We could agree with the document with following changes:=20 * Other location identifiers then geo or civil are allowed. It must be = possibe that the data foermat is flexible due to different requirements = from regulators over the whole world. (e.G Germany area codes for fixed- = and Cell-Id for moile- providers)=20 * The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed=20 * It must be possible for the VoIP-provider's proxy to use a LOST (or = an ESRP) provided by the AN or by other local provider on behalf of the = AN. =20 =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. = Currently, neither the IETF- nor the 3GPP-architecture for emergency = calling covers our real needs for the next 2 to 5 years and in the end = everybody still has its own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2]=09 ------_=_NextPart_001_01CA16A2.3F0094FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] = HUM on PhoneBCP
Hi Martin,
 
See comments inline [[LLi]].
 
 
Laura
From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org]=20 On Behalf Of Dawson, Martin
Sent: Wednesday, August = 05, 2009=20 11:00 AM
To: Jesske, Roland; = ecrit@ietf.org
Subject: Re:=20 [Ecrit] HUM on PhoneBCP

Hi=20 Roland,

 

I think = what you=92re=20 saying is that you don=92t think that Germany will go on to = implement=20 full ECRIT support but will peg development at an interim phase. =
[[LLi]]  We don't = know how the=20 realtime application networks or EC will look like in 20=20 years. Roland's answer only applies to the next 5 to 10=20 years. 

 

 That would = be=20 disappointing =96 not least because full ECRIT compliance would = ultimately=20 decrease the overhead associated with emergency service support for = operators=20 as well as providing a more universal service.

[[LLi]]  This = may be true=20 for "green field" ISPs and VSPs but not for incumbent carriers = with=20 existing infrastructure.  And universal service is not a = requirement=20 for us. Neither the German regulator=20 requires it nor is it a busines=20 case.   

 

Nevertheless, I don=92t=20 think that decision invalidates the BCP;
[[LLi]]  We = think it=20 does, because some of the requirements are not flexible = enough to=20 cover the deployments within the next years.  The BCP should = be more=20 flexible:  

  • Allow additional = location=20 identifiers 
  • Allow AN operated=20 LOST
  • Provide a way = to=20 enable LOST-query based on = national or=20 domain-specific location identifier. One posiblility is = to allow=20 the LIS to query the LOST , but there are also other=20 alternatives. 
  • Allow and describe=20 also network-centric, not only ED-centric = architectures. If=20 I  remember correctly, John Medland from BT also = recomended to use=20 a more network- centric architecture, at least for the next years.=20
 

I think it = just means=20 that the German regulator and technical advisory committees would = point out=20 the subset aspects of compliance that would be applicable to that=20 jurisdiction.  
[[LLi]] =20 = Aga= in,=20 the draft is not flexible enough for it.  If the BCP = contains=20 requirements which are not realistic, people will just discard = the=20 BCP and implement proprietary stuff. My expectation from a = standard=20 body is to define protocols and architecture which people are = willing to=20 implement in their network or products , not only in the=20 lab.

 

[[LLi]] 

We are not against = the draft in=20 principle. ECRIT provides  us = with very=20 valuable specifications as LbyR, HELD, identity extensions. But targeting an architecture=20 which requires everbody to invest without a business=20 case will not help the = draft in=20 the end, also if it becomes a BCP.  It would make sense to = make it=20 more flexible so people are willing to adopt=20 = it.    

 

 Actually, based on your = description=20 below, the NENA i2 architecture would probably be a more = straightforward=20 baseline for analysis =96 as has been done in the UK and Canada. Of course, it=92s = generally=20 recognized as only an interim step, even in those = jurisdictions.

Other = comments=20 below.

 

Cheers,

Martin

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of R.Jesske@telekom.de
Sent: Wednesday, 5 August 2009 = 6:19=20 PM
To:=20 ecrit@ietf.org
Subject: Re:=20 [Ecrit] HUM on PhoneBCP

 

 

Dear all, =
We would like = the document=20 to become a BCP as soon as possible so the group can move on with = other=20 documents related to emergency calling based on location-by-reference = and ED=92s=20 IP-address.

[[MCD]]=20 I think you might mean =93identity extensions=94 rather than = location-by-reference=20 because LbyR still requires the ED to obtain the reference =96 e.g. by = HELD.
[[LLi]] We=20 use both, the IP-address as UE identity and LbyR. The SIP-proxy uses = the=20 IP-address to query the LIS using HTTP (it's not HELD but SOAP = over HTTP,=20 but anyway similar). The LIS responds with a numeric string = associated to=20 the caller location, in principle a LbyR and with the=20 PSAP number. The proxy inserts the LbyR into the = SIP-message=20 (as P-Asserted-ID because the PSAPs are in PSTN) and routes = the message=20 to the PSAP.  It's a low cost=20 solution. 

But=20 we can not HUM for the current form of the document.=20

Back to the document: Some = requirements=20 are far form being realistic, at least in Germany, some=20 are not realistic at all. Implementing these requirements cost a = carrier a lot=20 of money and there is no ROI for it.

Just a few examples:=20

=B7       Requiring either geo=20 or civic location does not provide carriers with enough flexibility to = reuse=20 their existing mechanisms and location databases. Routing of emergency = calls=20 is currently done in Germany based on phone = area code=20 not on geo or civic location, at least for the fixed network. For = mobile=20 networks the cell-id is used in common. This is regulated by the = german=20 regulator.

[[MCD]]=20 How many unique PSAP routes are required in Germany? The=20 US has lots (6000 = plus) and=20 Australia has two (and = they are=20 redundant so it doesn=92t matter which one). Presumably geographic = information,=20 for PSAP catchment areas, is the basis for determining which area = codes are=20 relevant to begin with? After all, an area code is not intrinsically=20 geographic; it=92s a network routing value. If so, then some = geographic=20 discriminator is already in play in terms of constructing the area = code based=20 routing data (something like zip codes perhaps?) =96 and in that case, = it should=20 be straightforward to by-pass the area code step in the construction = of=20 routing that goes the correct PSAP URI.
[[LLi]] Currently, fixed networks = carriers in=20 Germany route the ECs based only on the caller's area = code. Sometime=20 in the past, the carriers, the regulator and the PSAPs operators = (police,=20 the Red Cross) agreed to do so. This may change in the future, = but it=20 will take a quite long=20 = time.      

=

 With nomadic VoIP devices (and = it=92s no=20 good being in denial about this being the norm in the future) area = code is no=20 more reliable than it is for conventional mobile phones. And, = presumably, area=20 code is not used for conventional cellular emergency call = routing?
[[LLi]]  As far = as I know,=20 mobile networks use the Cell-ID, not the area code, and have a = different table=20 than the fixed network operators. They are not going to change=20 this.  As to the nomadic SIP-users...if we like it or = not, very=20 few of our customers use our SIP service = nomadic, let=20 alone call EC from their=20 = laptop.         

1           = ;  =20 LOST as a national, let alone as a = global=20 directory is not going to be implemented. The regulator will provide = in the=20 web a static table which contains the PSAPs and the area for which = they are=20 responsible (one or more area codes). Every carrier has to implement = its own=20 routing database for emergency calls.

[[MCD]]=20 Whatever the carriers implement (and they have to implement = something) could=20 just as readily be done using LoST. Then visiting devices, with no=20 association with any local VoIP proxy server would still be able to=20 determine a route to the correct PSAP. Alternatively, as long as the = regulator is maintaining a web service with the routing information, = why not=20 make that directly accessible using LoST and save the operators the = cost of=20 duplicating the service at all?
[[LLi]]  There is a big difference between = maintaining a=20 web page with a table which operator can print and implement in = their=20 darabases and operating a database which is queried for=20 every emergency call in Germany, must have an availablity = of=20 99,99...% ,  is secure enough...you know. The=20 regulator will not do this.


2       We = have no=20 intention to rely on end devices for location information because:=20
=B7       ED = provided=20 location info is not trusted

[[MCD]]=20 Location by reference mitigates this trust issue. The emergency = network can=20 (automatically and before human resources are engaged) assess the = source of=20 the reference, and the validity of the location by dereference, = without having=20 to trust location provided directly from the ED. There are more = sophisticated=20 approaches to trustability even using LbyV =96 based on digital = signatures=20 across appropriate attributes. This WG and Geopriv haven=92t really = got to grips=20 with that=85 yet.
[[LLi]]  We build the SIP-network = and EC=20 now. ED-provided location = is=20 needed if EC must work for private and enterprise = networks and=20 VPNs.  We have no such regulatory requirements.  And we = don't know of any verdor of DSL-EDs which provides = today SIP=20 with LbyR and is as cheap as the devices without it. If you = do,=20 please let me know. 

The regulator ask = us to=20 guarantee that EC works. What if a customer dials 112 and = his end=20 device does not send the location? So I have to implement = both=20 solutions, with and without ED provided location,=20 anyway.  
1       There=20 are already a lot of existing EDs in usage which don=92t send=20 location.   

[[MCD]]=20 Quite right. ECRIT doesn=92t overly concern itself with that interim = situation.=20 The UK and Canadian = definitions for an=20 interim solution (limiting service to in-country VoIP proxy operators) = both=20 assume third-party query via identity-extension to allow the proxy or = the VPC=20 to make the query to the LIS. This isn=92t extensible to universal = emergency=20 service access by all visiting devices but it does put the necessary = LIS=20 functionality in place as a very good starting = point.  It would be a pity if=20 Germany were to cease the = evolution=20 there as it would not fulfil the real promise of the Internet and the = ECRIT=20 model.
[[LLi]]  I=20 wonder who will drive and pay for upgrading the interim = solutions.  Unfortunatelly, it's all about=20 money...

 Think about it; all the = complexity of=20 putting location determination infrastructure in place for the = purposes of=20 dispatch is done =96 and then the next, simpler step, of using that to = support=20 the routing procedure isn=92t taken=85 that would be a = waste.

[[LLi]]  Do you = think this=20 is an argument for a product manager? They need a business = case. =20

 

 

  We don=92t=20 intend to require our ED-vendors to provide location because it is = useless to=20 us.  

We could agree with the = document with=20 following changes: =

    • Other location identifiers = then geo=20 or civil are allowed. It must be possibe that the data foermat is = flexible=20 due to different requirements from regulators over the whole = world. (e.G=20 Germany area codes = for fixed-=20 and Cell-Id for moile- providers)=20
    • The MUST for the end = devices to=20 support location information, DHCP location options and HELD shall = be=20 removed
    • It must be possible for = the=20 VoIP-provider=92s proxy to use a LOST (or an ESRP) provided by the = AN or by=20 other local provider on behalf of the AN. =20

 

 There is no value in = Hum-ing=20 documents which one is not going to implement and does not fit into = regulated=20 schemes like in Germany. Currently, = neither the=20 IETF- nor the 3GPP-architecture for emergency calling covers our real = needs=20 for the next 2 to 5 years and in the end everybody still has its own=20 proprietary implementation.    =

Best = regards

Roland=20

 

Deutsche = Telekom=20 Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland = Jesske
Gateways, Protokolle, = Konvergenz,=20 TE32-1
Heinrich-Hertz-Str. 3-7,=20 64295 Darmstadt,
Postfach,=20 64307 Darmstadt (Postanschrift)
+496151 628 2766=20 (Tel)
+491718618445=20 (Mobile)
E-Mail: = r.jesske@telekom.de=20
http://www.telekom.de=20

 

Registerrechtliche=20 Unternehmensangaben:
Deutsche Telekom = Netzproduktion=20 (DT NP) GmbH
Aufsichtsrat: Timotheus H=F6ttges=20 (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 Albert Matheis, Klaus Peren
Handelsregister: = Amtsgericht Bonn=20 HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE=20 814645262

 



=

-----------------------------------------------------------------= -------------------------------
This message is for&nbs= p;the designated recipient only and may
conta= in privileged, proprietary, or otherwise private=  information.  
If you have received&nbs= p;it in error, please notify the sender
= immediately and delete the original.  Any&n= bsp;unauthorized use of
this email is prohibi= ted.
-----------------------------------------------------------------= -------------------------------
[mf2]
------_=_NextPart_001_01CA16A2.3F0094FC-- From Martin.Dawson@andrew.com Thu Aug 6 07:45:24 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030D93A69B5 for ; Thu, 6 Aug 2009 07:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIj5xKWhzRYa for ; Thu, 6 Aug 2009 07:45:06 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E01EE28C145 for ; Thu, 6 Aug 2009 07:44:43 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_06_10_07_28 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 06 Aug 2009 10:07:27 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 09:44:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA16A4.707F8F85" Date: Thu, 6 Aug 2009 09:44:42 -0500 Message-ID: In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQ References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> From: "Dawson, Martin" To: , , X-OriginalArrivalTime: 06 Aug 2009 14:44:46.0149 (UTC) FILETIME=[711A7F50:01CA16A4] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 14:45:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA16A4.707F8F85 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Laura,=0D=0A=0D=0A=20=0D=0A=0D=0AI regard it as a goal of ECRIT - as der= ived from the goals of the IETF generally - to define a structure that will= allow an Internet capable device to connect to a network anywhere in the w= orld and be able to make emergency calls. Just as FTP, email protocols, SIP= and etc. all work regardless of which network the devices attach to. I don= 't understand how the kind of variations that you are requesting be added t= o the specification will allow that to occur.=0D=0A=0D=0A=20=0D=0A=0D=0AThe= position appears to be that the German regulator doesn't require anything = - and the operators will not be proactive in following a specification if i= t doesn't include what already exists. In that context, I don't understand = why there is a need for the BCP at all. There may be no need to endorse it = but, similarly, there should be no need to object to it - since the operato= rs will only put in place their preferred version of the service in any cas= e. That's OK... insofar as it just means German networks aren't ECRIT compa= tible - "compatibility" isn't a worthy goal in and of itself; it has to act= ually mean any device can work anywhere.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D= =0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D= =0A=0D=0AFrom: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20=0D=0ASent:= Friday, 7 August 2009 12:29 AM=0D=0ATo: Dawson, Martin; R.Jesske@telekom.d= e; ecrit@ietf.org=0D=0ACc: Reinhard.Lauster@t-mobile.at=0D=0ASubject: RE: [= Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=20=0D=0A=0D=0AHi Martin,=20=0D=0A=0D=0A =0D= =0A=0D=0ASee comments inline [[LLi]].=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0ALaura=0D=0A=0D=0A=09From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@i= etf.org] On Behalf Of Dawson, Martin=0D=0A=09Sent: Wednesday, August 05, 20= 09 11:00 AM=0D=0A=09To: Jesske, Roland; ecrit@ietf.org=0D=0A=09Subject: Re:= [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09Hi Roland,=0D=0A=0D=0A=09=20=0D=0A=0D= =0A=09I think what you're saying is that you don't think that Germany will = go on to implement full ECRIT support but will peg development at an interi= m phase.=20=0D=0A=09[[LLi]] We don't know how the realtime application net= works or EC will look like in 20 years. Roland's answer only applies to the= next 5 to 10 years.=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 That would be disa= ppointing - not least because full ECRIT compliance would ultimately decrea= se the overhead associated with emergency service support for operators as = well as providing a more universal service.=0D=0A=09=0D=0A=09[[LLi]] This = may be true for "green field" ISPs and VSPs but not for incumbent carriers = with existing infrastructure. And universal service is not a requirement f= or us. Neither the German regulator requires it nor is it a busines case. = =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Nevertheless, I don't think that decisi= on invalidates the BCP;=20=0D=0A=09[[LLi]] We think it does, because some = of the requirements are not flexible enough to cover the deployments within= the next years. The BCP should be more flexible: =20=0D=0A=0D=0A=09*=09Al= low additional location identifiers=20=0D=0A=0D=0A=09*=09Allow AN operated = LOST=0D=0A=0D=0A=09*=09Provide a way to enable LOST-query based on national= or domain-specific location identifier. One posiblility is to allow the LI= S to query the LOST , but there are also other alternatives.=20=0D=0A=0D=0A= =09*=09Allow and describe also network-centric, not only ED-centric archite= ctures. If I remember correctly, John Medland from BT also recomended to u= se a more network- centric architecture, at least for the next years.=20=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09I think it just means that the German regulat= or and technical advisory committees would point out the subset aspects of = compliance that would be applicable to that jurisdiction. =20=0D=0A=09[[LLi= ]] Again, the draft is not flexible enough for it. If the BCP contains re= quirements which are not realistic, people will just discard the BCP and im= plement proprietary stuff. My expectation from a standard body is to define= protocols and architecture which people are willing to implement in their = network or products , not only in the lab.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09= [[LLi]] =20=0D=0A=0D=0A=09We are not against the draft in principle. ECRIT = provides us with very valuable specifications as LbyR, HELD, identity exte= nsions. But targeting an architecture which requires everbody to invest wit= hout a business case will not help the draft in the end, also if it becomes= a BCP. It would make sense to make it more flexible so people are willing= to adopt it. =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 Actually, based on you= r description below, the NENA i2 architecture would probably be a more stra= ightforward baseline for analysis - as has been done in the UK and Canada. = Of course, it's generally recognized as only an interim step, even in those= jurisdictions.=0D=0A=0D=0A=09Other comments below.=0D=0A=0D=0A=09=20=0D=0A=0D= =0A=09Cheers,=0D=0A=0D=0A=09Martin=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=0D=0A__= ______________________________=0D=0A=0D=0A=0D=0A=09From: ecrit-bounces@ietf= =2Eorg [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de=0D=0A= =09Sent: Wednesday, 5 August 2009 6:19 PM=0D=0A=09To: ecrit@ietf.org=0D=0A=09= Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=20=0D= =0A=0D=0A=09Dear all,=20=0D=0A=09We would like the document to become a BCP= as soon as possible so the group can move on with other documents related = to emergency calling based on location-by-reference and ED's IP-address. =0D= =0A=0D=0A=09[[MCD]] I think you might mean "identity extensions" rather tha= n location-by-reference because LbyR still requires the ED to obtain the re= ference - e.g. by HELD.=0D=0A=09[[LLi]] We use both, the IP-address as UE i= dentity and LbyR. The SIP-proxy uses the IP-address to query the LIS using = HTTP (it's not HELD but SOAP over HTTP, but anyway similar). The LIS respon= ds with a numeric string associated to the caller location, in principle a = LbyR and with the PSAP number. The proxy inserts the LbyR into the SIP-mess= age (as P-Asserted-ID because the PSAPs are in PSTN) and routes the message= to the PSAP. It's a low cost solution.=20=0D=0A=0D=0A=09But we can not HU= M for the current form of the document.=20=0D=0A=0D=0A=09Back to the docume= nt: Some requirements are far form being realistic, at least in Germany, so= me are not realistic at all. Implementing these requirements cost a carrier= a lot of money and there is no ROI for it.=20=0D=0A=0D=0A=09Just a few exa= mples:=20=0D=0A=0D=0A=09=B7 Requiring either geo or civic location do= es not provide carriers with enough flexibility to reuse their existing mec= hanisms and location databases. Routing of emergency calls is currently don= e in Germany based on phone area code not on geo or civic location, at leas= t for the fixed network. For mobile networks the cell-id is used in common.= This is regulated by the german regulator.=20=0D=0A=0D=0A=09[[MCD]] How ma= ny unique PSAP routes are required in Germany=3F The US has lots (6000 plus= ) and Australia has two (and they are redundant so it doesn't matter which = one). Presumably geographic information, for PSAP catchment areas, is the b= asis for determining which area codes are relevant to begin with=3F After a= ll, an area code is not intrinsically geographic; it's a network routing va= lue. If so, then some geographic discriminator is already in play in terms = of constructing the area code based routing data (something like zip codes = perhaps=3F) - and in that case, it should be straightforward to by-pass the= area code step in the construction of routing that goes the correct PSAP U= RI.=20=0D=0A=09[[LLi]] Currently, fixed networks carriers in Germany route = the ECs based only on the caller's area code. Sometime in the past, the car= riers, the regulator and the PSAPs operators (police, the Red Cross) agreed= to do so. This may change in the future, but it will take a quite long tim= e. =20=0D=0A=0D=0A=09 With nomadic VoIP devices (and it's no good being= in denial about this being the norm in the future) area code is no more re= liable than it is for conventional mobile phones. And, presumably, area cod= e is not used for conventional cellular emergency call routing=3F=0D=0A=09[= [LLi]] As far as I know, mobile networks use the Cell-ID, not the area cod= e, and have a different table than the fixed network operators. They are no= t going to change this. As to the nomadic SIP-users...if we like it or not= , very few of our customers use our SIP service nomadic, let alone call EC = from their laptop. =20=0D=0A=0D=0A=091 LOST as a nation= al, let alone as a global directory is not going to be implemented. The reg= ulator will provide in the web a static table which contains the PSAPs and = the area for which they are responsible (one or more area codes). Every car= rier has to implement its own routing database for emergency calls.=20=0D=0A=0D= =0A=09=09[[MCD]] Whatever the carriers implement (and they have to implemen= t something) could just as readily be done using LoST. Then visiting device= s, with no association with any local VoIP proxy server would still be able= to determine a route to the correct PSAP. Alternatively, as long as the re= gulator is maintaining a web service with the routing information, why not = make that directly accessible using LoST and save the operators the cost of= duplicating the service at all=3F=0D=0A=09=09[[LLi]] There is a big diffe= rence between maintaining a web page with a table which operator can print = and implement in their darabases and operating a database which is queried = for every emergency call in Germany, must have an availablity of 99,99...% = , is secure enough...you know. The regulator will not do this.=0D=0A=0D=0A= =09=09=0D=0A=09=092 We have no intention to rely on end devices for l= ocation information because:=20=0D=0A=09=09=B7 ED provided location i= nfo is not trusted=20=0D=0A=0D=0A=09[[MCD]] Location by reference mitigates= this trust issue. The emergency network can (automatically and before huma= n resources are engaged) assess the source of the reference, and the validi= ty of the location by dereference, without having to trust location provide= d directly from the ED. There are more sophisticated approaches to trustabi= lity even using LbyV - based on digital signatures across appropriate attri= butes. This WG and Geopriv haven't really got to grips with that... yet.=0D= =0A=09[[LLi]] We build the SIP-network and EC now. ED-provided location is= needed if EC must work for private and enterprise networks and VPNs. We h= ave no such regulatory requirements. And we don't know of any verdor of DS= L-EDs which provides today SIP with LbyR and is as cheap as the devices wit= hout it. If you do, please let me know.=20=0D=0A=0D=0A=09The regulator ask = us to guarantee that EC works. What if a customer dials 112 and his end dev= ice does not send the location=3F So I have to implement both solutions, wi= th and without ED provided location, anyway. =20=0D=0A=091 There are = already a lot of existing EDs in usage which don't send location. =20=0D=0A=0D= =0A=09[[MCD]] Quite right. ECRIT doesn't overly concern itself with that in= terim situation. The UK and Canadian definitions for an interim solution (l= imiting service to in-country VoIP proxy operators) both assume third-party= query via identity-extension to allow the proxy or the VPC to make the que= ry to the LIS. This isn't extensible to universal emergency service access = by all visiting devices but it does put the necessary LIS functionality in = place as a very good starting point. It would be a pity if Germany were to= cease the evolution there as it would not fulfil the real promise of the I= nternet and the ECRIT model.=20=0D=0A=09[[LLi]] I wonder who will drive an= d pay for upgrading the interim solutions. Unfortunatelly, it's all about = money...=0D=0A=0D=0A=09 Think about it; all the complexity of putting locat= ion determination infrastructure in place for the purposes of dispatch is d= one - and then the next, simpler step, of using that to support the routing= procedure isn't taken... that would be a waste.=0D=0A=09=0D=0A=09[[LLi]] = Do you think this is an argument for a product manager=3F They need a busin= ess case. =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 We don't = intend to require our ED-vendors to provide location because it is useless = to us. =20=0D=0A=0D=0A=09We could agree with the document with following c= hanges:=20=0D=0A=0D=0A=09=09*=09Other location identifiers then geo or civi= l are allowed. It must be possibe that the data foermat is flexible due to = different requirements from regulators over the whole world. (e.G Germany a= rea codes for fixed- and Cell-Id for moile- providers)=20=0D=0A=09=09*=09Th= e MUST for the end devices to support location information, DHCP location o= ptions and HELD shall be removed=20=0D=0A=09=09*=09It must be possible for = the VoIP-provider's proxy to use a LOST (or an ESRP) provided by the AN or = by other local provider on behalf of the AN. =20=0D=0A=0D=0A=09=20=0D=0A=0D= =0A=09 There is no value in Hum-ing documents which one is not going to imp= lement and does not fit into regulated schemes like in Germany. Currently, = neither the IETF- nor the 3GPP-architecture for emergency calling covers ou= r real needs for the next 2 to 5 years and in the end everybody still has i= ts own proprietary implementation. =20=0D=0A=0D=0A=09Best regards=20=0D=0A=0D= =0A=09Roland=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Deutsche Telekom Netzproduk= tion GmbH=0D=0A=09Zentrum Technik Einf=FChrung=0D=0A=09Roland Jesske=0D=0A=09= Gateways, Protokolle, Konvergenz, TE32-1=0D=0A=09Heinrich-Hertz-Str. 3-7, 6= 4295 Darmstadt,=0D=0A=09Postfach, 64307 Darmstadt (Postanschrift)=0D=0A=09+= 496151 628 2766 (Tel)=0D=0A=09+491718618445 (Mobile)=0D=0A=09E-Mail: r.jess= ke@telekom.de =20=0D=0A=09http://www.telekom.d= e =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Registerrech= tliche Unternehmensangaben:=0D=0A=09Deutsche Telekom Netzproduktion (DT NP)= GmbH=0D=0A=09Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=0D=0A=09Gesc= h=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, = Klaus Peren=0D=0A=09Handelsregister: Amtsgericht Bonn HRB 14190=0D=0A=09Sit= z der Gesellschaft: Bonn=0D=0A=09USt-IdNr.: DE 814645262=20=0D=0A=0D=0A=09 =0D= =0A=0D=0A=09=20=0D=0A=0D=0A=0D=0A------------------------------------------= ------------------------------------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information. =20=0D=0AIf you have received it in= error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0A[mf2]=0D=0A=0D=0A=09=20=0D=0A=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA16A4.707F8F85 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ARe: [Ecrit]= HUM on PhoneBCP=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

Hi Laura,

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

=  

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

I regard it as a = goal of ECRIT – as derived=0D=0Afrom the goals of the IETF generally = – to define a structure that will=0D=0Aallow an Internet capable devi= ce to connect to a network anywhere in the world=0D=0Aand be able to make e= mergency calls. Just as FTP, email protocols, SIP and etc.=0D=0Aall work re= gardless of which network the devices attach to. I don’t=0D=0Aunderst= and how the kind of variations that you are requesting be added to the=0D=0A= specification will allow that to occur.

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

 =

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

The position appears to be that the German=0D=0Aregulator doesn&#= 8217;t require anything – and the operators will not be=0D=0Aproactiv= e in following a specification if it doesn’t include what already=0D=0A= exists. In that context, I don’t understand why there is a need for t= he=0D=0ABCP at all. There may be no need to endorse it but, similarly, ther= e should be=0D=0Ano need to object to it – since the operators will o= nly put in place=0D=0Atheir preferred version of the service in any case. T= hat’s OK…=0D=0Ainsofar as it just means German networks aren= 217;t ECRIT compatible – “compatibility”=0D=0Aisn’t= a worthy goal in and of itself; it has to actually mean any device=0D=0Aca= n work anywhere.

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

 

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

Cheers,

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

Martin

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

 =

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

From:=0D=0AL.Liess@telekom.de [mailto:L.Li= ess@telekom.de]
=0D=0ASent:<= /b> Friday, 7 August 2009 12:29=0D=0AAM
=0D=0ATo: Dawson, Martin;=0D=0AR.Jesske@telekom.de; ecrit@ie= tf.org
=0D=0ACc: Reinhard= =2ELauster@t-mobile.at
=0D=0ASubject= : RE: [Ecrit] HUM on=0D=0APhoneBCP

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

 

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

Hi Martin,

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

 

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

See comments inli= ne [[LLi]].

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

 

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

&= nbsp;

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

Laura

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

From:=0D=0A= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawson, Martin
=0D=0ASent: Wednesday, August 05, 2009=0D=0A= 11:00 AM
=0D=0ATo: Jesske= , Roland; ecrit@ietf.org
=0D=0ASubje= ct: Re: [Ecrit] HUM on=0D=0APhoneBCP

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

Hi Roland,

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

 

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

I= think what you’re saying is that=0D=0Ayou don’t think that Germany=0D=0Awill go on to implement full ECRIT support but will = peg development at an=0D=0Ainterim phase.
=0D=0A[[LLi]]  We don't know how the=0D=0A= realtime application networks or EC will look like in 20=0D=0Ayears.&n= bsp;Roland's answer only applies to the next 5 to 10 years. 

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

 <= o:p>

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

 Tha= t would be disappointing – not least because full ECRIT=0D=0Acomplian= ce would ultimately decrease the overhead associated with emergency=0D=0Ase= rvice support for operators as well as providing a more universal service.<= br>=0D=0A
=0D=0A<= span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial;color:blue'>[[LLi]]&= nbsp; This may be true for "green=0D=0Afield" ISPs and VSPs but n= ot for incumbent carriers with existing=0D=0Ainfrastructure. &nbs= p;And universal service is not a requirement for us.=0D=0ANeither the Germa= n regulator requires it nor is it a busines=0D=0Acase.  &nbs= p;

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

 

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

Nevertheless, I don’t= think that=0D=0Adecision invalidates the BCP;
=0D=0A[[LLi]]  We think it=0D=0Adoes, bec= ause some of the requirements are not flexible enough to=0D=0Acover th= e deployments within the next years.  The BCP should be more=0D=0A= flexible:  

=0D=0A=0D=0A
=0D=0A=0D= =0A
    =0D=0A
  • Allow additional=0D=0A location identif= iers 
    • =0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D=0A
    =0D=0A
  • Allow AN operated=0D=0A = LOST
    • =0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A=
=0D=0A=0D=0A
    =0D=0A
  • Provide a way=0D=0A = to enable LOST-query based on national or domain-specific locatio= n=0D=0A identifier. One posiblility is to allow the LIS = to query=0D=0A the LOST , but there are also other alternatives.&n= bsp;
    • =0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A=
=0D=0A=0D=0A
    =0D=0A
  • Allow and describe=0D= =0A also network-centric, not only ED-centric architectures. = If=0D=0A I  remember correctly, John Medland from BT also rec= omended to=0D=0A use a more network- centric architecture, at least for= the next years.
    • =0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

 

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

I think it just means= that the German=0D=0Aregulator and technical advisory committees would poi= nt out the subset aspects=0D=0Aof compliance that would be applicable to th= at jurisdiction.&nbs= p; 
=0D=0A[[LLi]]  Again, the draft is not= flexible=0D=0Aenough for it.  If the BCP contains requirements w= hich are not=0D=0Arealistic, people will just discard the BCP and=  implement proprietary=0D=0Astuff. My expectation from a standard body= is to define protocols and=0D=0Aarchitecture which people are willing= to implement in their network or products=0D=0A, not only in the lab.

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

 

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

[[LLi]] 

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

We are not against the draft in= principle.=0D=0AECRIT provides  us with ve= ry valuable specifications as LbyR, HELD, identity=0D=0Aextensions. Bu= t targeting an architecture which requires everbody to=0D=0Ainvest&nbs= p;without a business case will not help the draft in=0D=0Ath= e end, also if it becomes a BCP.  It would make sense to make it=0D= =0Amore flexible so people are willing to adopt it.   &= nbsp;

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

&nbs= p;

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

 Actually, based on your description=0D=0Abelow, = the NENA i2 architecture would probably be a more straightforward=0D=0Abase= line for analysis – as has been done in the UK and Canada. Of cours= e, it’s=0D=0Agenerally recognized as only an interim step, even in th= ose jurisdictions.

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

Other comments below.

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

 

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

Cheers,

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

Martin=

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

 

=0D=0A=0D=0A
=0D=0A=0D=0A<= div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de=0D=0ASent: Wednesday, 5 A= ugust 2009=0D=0A6:19 PM
=0D=0ATo: ecrit@ietf.org
=0D=0ASubjec= t: Re: [Ecrit] HUM on=0D=0APhoneBCP

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

 

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

 

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

Dear all,
=0D=0AWe would like the=0D=0Adocument t= o become a BCP as soon as possible so the group can move on with=0D=0Aother= documents related to emergency calling based on location-by-reference and=0D= =0AED’s IP-address.

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

[[MCD]] I=0D=0Athink you might mean “identity ex= tensions” rather than=0D=0Alocation-by-reference because LbyR still r= equires the ED to obtain the=0D=0Areference – e.g. by HELD.
=0D=0A= [[LLi]] We use both, the IP-address as UE identi= ty and=0D=0ALbyR. The SIP-proxy uses the IP-address to query the LIS using = HTTP (it's not=0D=0AHELD but SOAP over HTTP, but anyway similar). The = LIS responds with a=0D=0Anumeric string associated to the caller locat= ion, in principle a LbyR and with=0D=0Athe PSAP number. The proxy= inserts the LbyR into the SIP-message=0D=0A(as P-Asserted-ID because = the PSAPs are in PSTN) and routes the message to=0D=0Athe PSAP.  = It's a low cost solution. 

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

But we can not HUM fo= r the current form of=0D=0Athe document.

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

Back to the document: Some = requirements=0D=0Aare far form being realistic, at least in Germany<= /st1:place>, some are not realistic at=0D=0Aall. Implementing these require= ments cost a carrier a lot of money and there is=0D=0Ano ROI for it.

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

Just a few examples:

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

=B7      = ; Requiring either geo or=0D=0Acivic location does not provide c= arriers with enough flexibility to reuse their=0D=0Aexisting mechanisms and= location databases. Routing of emergency calls is=0D=0Acurrently done in <= st1:place w:st=3D"on">Germany=0D=0Abased on phone area code not on geo or civic locat= ion, at least for the fixed=0D=0Anetwork. For mobile networks the cell-id i= s used in common. This is regulated=0D=0Aby the german regulator.

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

[[MCD]] How=0D=0Amany unique PSAP= routes are required in Germany=3F The US has lots (6000 plus) and Australia has two (and they are=0D=0Aredundant so it doesnR= 17;t matter which one). Presumably geographic=0D=0Ainformation, for PSAP ca= tchment areas, is the basis for determining which area=0D=0Acodes are relev= ant to begin with=3F After all, an area code is not intrinsically=0D=0Ageog= raphic; it’s a network routing value. If so, then some geographic=0D=0A= discriminator is already in play in terms of constructing the area code bas= ed=0D=0Arouting data (something like zip codes perhaps=3F) – and in t= hat case, it=0D=0Ashould be straightforward to by-pass the area code step i= n the construction of=0D=0Arouting that goes the correct PSAP URI.
=0D=0A= [[LLi]] Currently, fixed networks carriers&= nbsp;in=0D=0AGermany= =0D=0Aroute the ECs based only on the= caller's area code. Sometime in the=0D=0Apast, the carriers, the= regulator and the PSAPs operators (police, the Red=0D=0ACross) agreed to d= o so. This may change in the future, but it will take a=0D=0Aquite lon= g time.      

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

 With=0D=0Anomadic VoIP devices (and it’s no= good being in denial about this being=0D=0Athe norm in the future) area co= de is no more reliable than it is for=0D=0Aconventional mobile phones. And,= presumably, area code is not used for=0D=0Aconventional cellular emergency= call routing=3F
=0D=0A[[LLi]]  As far as = I know, mobile networks use the=0D=0ACell-ID, not the area code, and have a= different table than the fixed network=0D=0Aoperators. They are not g= oing to change this.  As to the nomadic=0D=0ASIP-users...if we like it= or not, very few of our=0D=0Acustomers use our SIP ser= vice nomadic, let alone call EC from=0D=0Atheir laptop.  &nb= sp;      

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

1 &= nbsp;           =0D=0A= = LOST as a=0D=0Anational, let alone as a global directory is not going to be= implemented. The=0D=0Aregulator will provide in the web a static table whi= ch contains the PSAPs and=0D=0Athe area for which they are responsible (one= or more area codes). Every carrier=0D=0Ahas to implement its own routing d= atabase for emergency calls.

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

[[MCD]]=0D=0AWhatever the carriers implement (and = they have to implement something) could=0D=0Ajust as readily be done using = LoST. Then visiting devices, with no association=0D=0Awith any local VoIP p= roxy server would still be able to determine a route to=0D=0Athe correct PS= AP. Alternatively, as long as the regulator is maintaining a web=0D=0Aservi= ce with the routing information, why not make that directly accessible=0D=0A= using LoST and save the operators the cost of duplicating the service at al= l=3F
=0D=0A[[LLi]]  There is = a big difference between=0D=0Amaintaining a web page with a table whic= h operator can print and implement=0D=0Ain their darabases and operati= ng a database which is queried for=0D=0Aevery emergency call in German= y, must have an availablity of 99,99...% ,  is=0D=0Asec= ure enough...you know. The regulator will not do this.

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


=0D=0A2       We have no intention to = rely on end=0D=0Adevices for location information because:
=0D=0A<= font color=3Dblack>=B7  =      ED provided location=0D=0Ainfo is not tru= sted

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

[[MCD]] Lo= cation=0D=0Aby reference mitigates this trust issue. The emergency network = can=0D=0A(automatically and before human resources are engaged) assess the = source of the=0D=0Areference, and the validity of the location by dereferen= ce, without having to=0D=0Atrust location provided directly from the ED. Th= ere are more sophisticated=0D=0Aapproaches to trustability even using LbyV = – based on digital signatures=0D=0Aacross appropriate attributes. Thi= s WG and Geopriv haven’t really got to=0D=0Agrips with that… ye= t.
=0D=0A[[LLi]]  We build the SIP-= network and EC now.=0D=0AED-provided location is needed if EC mus= t work for private and=0D=0Aenterprise networks and VPNs.  We hav= e no such regulatory=0D=0Arequirements.  And we don't know o= f any verdor of DSL-EDs=0D=0Awhich provides today SIP with LbyR a= nd is as cheap as=0D=0Athe devices without it. If you do, please = let me know. 

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

The reg= ulator=0D=0Aask us to guarantee that EC works. What if a customer= dials 112 and=0D=0Ahis end device does not send the locatio= n=3F So I have to=0D=0Aimplement both solutions, with and without ED provid= ed location,=0D=0Aanyway.  
=0D=0A1   &= nbsp;  =0D=0AThere are already a lot of existing EDs in usage whi= ch don’t send=0D=0Alocation.   

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

[[MCD]] Quite=0D=0Aright. ECR= IT doesn’t overly concern itself with that interim situation.=0D=0ATh= e UK=0D=0Aand Canadian definitions for an interim solution (li= miting service to in-country=0D=0AVoIP proxy operators) both assume third-p= arty query via identity-extension to=0D=0Aallow the proxy or the VPC to mak= e the query to the LIS. This isn’t=0D=0Aextensible to universal emerg= ency service access by all visiting devices but it=0D=0Adoes put the necess= ary LIS functionality in place as a very good starting=0D=0Apoint. &nb= sp;It would be a pity if Germany were to cease the evolu= tion=0D=0Athere as it would not fulfil the real promise of the Internet and= the ECRIT=0D=0Amodel.
=0D=0A[[LLi]]  I= wonder who will drive and pay=0D=0Afor upgrading the interi= m solutions.  Unfortunatelly, it's=0D=0Aall about money...=

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

 Think=0D=0Aabout it; all= the complexity of putting location determination infrastructure=0D=0Ain pl= ace for the purposes of dispatch is done – and then the next,=0D=0Asi= mpler step, of using that to support the routing procedure isn’t=0D=0A= taken… that would be a waste.
=0D=0A
=0D=0A[[LLi]]  Do you think this is an argument for a product=0D=0Ama= nager=3F They need a business case.  <= /o:p>

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

 

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

 = ;

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

<= font size=3D3 color=3Dblack face=3D"Times New Roman">  We don’t intend to=0D= =0Arequire our ED-vendors to provide location because it is useless to=0D=0A= us.  

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

We could agree with the document with=0D=0Afollo= wing changes:

=0D=0A=0D= =0A
    =0D=0A
      =0D=0A
    • Other location identifiers then geo or civil are allowed. It=0D=0A = must be possibe that the data foermat is flexible due to different=0D=0A= requirements from regulators over the whole world. (e.G Germany area codes for fixed-=0D=0A and Cell-Id for moile-= providers)
      • =0D=0A =
    • The MUST for the end devices to support locati= on=0D=0A information, DHCP location options and HELD shall be removed =
      • =0D=0A
    • It must = be possible for the VoIP-provider’s proxy to=0D=0A use a LOST (o= r an ESRP) provided by the AN or by other local provider on=0D=0A beha= lf of the AN. 
      • =0D=0A
    =0D=0A
=0D= =0A=0D=0A

 

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

 There is no value in Hum-ing=0D=0Adocuments which one is not going= to implement and does not fit into regulated=0D=0Aschemes like in Germany= .=0D=0ACurrently, neither the IETF- nor the 3GPP-architecture f= or emergency calling=0D=0Acovers our real needs for the next 2 to 5 years a= nd in the end everybody still=0D=0Ahas its own proprietary implementation.&= nbsp;  

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

Best regards

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

Roland

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

 

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

Deutsche Telekom Netzprodu= ktion GmbH
=0D=0AZentrum Technik Einf=FChrung
=0D=0ARoland Jesske
=0D=0AGateways, Protokolle, Konvergenz= , TE32-1
=0D=0AHeinrich-Hertz-Str. 3-7, 64295 Darmstadt,
=0D=0APostfach, 64307 Darmstadt (Posta= nschrift)
=0D=0A+496151 628 2766 (Tel)
=0D=0A= +491718618445 (Mobile)
=0D= =0AE-Mail: r.jess= ke@telekom.de
=0D=0Ahttp://www.telekom.de=0D=0A

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

 

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

Regis= terrechtliche Unternehmensangaben:
=0D= =0ADeutsche Telekom Netzproduktion (DT NP) GmbH=0D=0AAufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
=0D=0AGesch=E4f= tsf=FChrung: Dr. Bruno=0D=0A= Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren=0D=0AHandelsregister: Amtsgericht Bonn HRB 14190
=0D=0ASitz der Gesell= schaft: Bonn
=0D=0AUSt-IdNr.: DE 814645262=

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

 

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

 

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


=0D=0A= -------------------------------------------------------------------------= -----------------------
=0D=0A This message is for = the designated recipient only and may
=0D=0A c= ontain privileged, proprietary, or otherwise priva= te information.  
=0D=0A If you have rece= ived it in error, please notify the send= er
=0D=0A immediately and delete the original. = ; Any unauthorized use of
=0D=0A this email&nb= sp;is prohibited.
=0D=0A -----------------------------------------= -------------------------------------------------------
=0D=0A [mf2]

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

 

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


---------------------------------------------= ---------------------------------------------------
=0D=0AThis mess= age is for the designated recipient only = ;and may
=0D=0Acontain privileged, proprietary, or&n= bsp;otherwise private information.  
=0D=0AIf y= ou have received it in error, please not= ify the sender
=0D=0Aimmediately and delete the=  original.  Any unauthorized use of
=0D=0A= this email is prohibited.
=0D=0A-------------------------= -----------------------------------------------------------------------
=0D= =0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01CA16A4.707F8F85-- From Martin.Dawson@andrew.com Thu Aug 6 08:21:17 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C49A3A6DF1 for ; Thu, 6 Aug 2009 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ0GzxFBh7dp for ; Thu, 6 Aug 2009 08:20:56 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 57E3C3A6AA3 for ; Thu, 6 Aug 2009 08:20:56 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_06_10_43_41 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 06 Aug 2009 10:43:40 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 10:20:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA16A9.7F0305CD" Date: Thu, 6 Aug 2009 10:20:54 -0500 Message-ID: In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAAOKzRQ References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> From: "Dawson, Martin" To: , , X-OriginalArrivalTime: 06 Aug 2009 15:20:58.0593 (UTC) FILETIME=[7FFB2510:01CA16A9] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 15:21:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA16A9.7F0305CD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I neglected to do a point by point, sorry. So - that follows:=0D=0A=0D=0A =0D= =0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A______________= __________________=0D=0A=0D=0AFrom: L.Liess@telekom.de [mailto:L.Liess@tele= kom.de]=20=0D=0ASent: Friday, 7 August 2009 12:29 AM=0D=0ATo: Dawson, Marti= n; R.Jesske@telekom.de; ecrit@ietf.org=0D=0ACc: Reinhard.Lauster@t-mobile.a= t=0D=0ASubject: RE: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=20=0D=0A=0D=0AHi Ma= rtin,=20=0D=0A=0D=0A=20=0D=0A=0D=0ASee comments inline [[LLi]].=0D=0A=0D=0A= =20=0D=0A=0D=0A=20=0D=0A=0D=0ALaura=0D=0A=0D=0A=09From: ecrit-bounces@ietf.= org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawson, Martin=0D=0A=09Sen= t: Wednesday, August 05, 2009 11:00 AM=0D=0A=09To: Jesske, Roland; ecrit@ie= tf.org=0D=0A=09Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09Hi Roland= ,=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09I think what you're saying is that you do= n't think that Germany will go on to implement full ECRIT support but will = peg development at an interim phase.=20=0D=0A=09[[LLi]] We don't know how = the realtime application networks or EC will look like in 20 years. Roland'= s answer only applies to the next 5 to 10 years.=20=0D=0A=0D=0A=09[[MCD]] T= he implementation of the LIS function is the most significant aspect for op= erators - and that needs to happen in short term scenarios in any case. The= provision of LoST can be a national asset/service. The provision of PSAP U= RIs is an emergency service responsibility. Those are the key requirements = - and that does provide a framework that will work into the next 20 years a= nd beyond.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 That would be disappointing - n= ot least because full ECRIT compliance would ultimately decrease the overhe= ad associated with emergency service support for operators as well as provi= ding a more universal service.=0D=0A=09=0D=0A=09[[LLi]] This may be true f= or "green field" ISPs and VSPs but not for incumbent carriers with existing= infrastructure. And universal service is not a requirement for us. Neithe= r the German regulator requires it nor is it a busines case. =20=0D=0A=0D=0A= =09[[MCD]] I think this is only true to the same extent that a pure Interne= t green field ISP only has to worry about Internet trunk connectivity and d= oesn't have to worry about PSTN circuit trunk connectivity. The latter infr= astructure is legacy and not particularly applicable to the Internet compon= ent of the service. Providing ECRIT emergency calling support requires the = addition of a LIS, access to LoST (whoever hosts it), and a route to the PS= AP URI(s). Both types of operator need to do that. Whatever switched circui= t legacy emergency infrastructure already exists in the established operato= r needs to continue to exist to support the emergency calls on that access.=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09Nevertheless, I don't think that decision inv= alidates the BCP;=20=0D=0A=09[[LLi]] We think it does, because some of the= requirements are not flexible enough to cover the deployments within the n= ext years. The BCP should be more flexible: =20=0D=0A=0D=0A=09*=09Allow ad= ditional location identifiers=20=0D=0A=0D=0A=09[[MCD]] Agreed - although th= at can be done by local-specific use of fields in the PIDF-LO based on juri= sdictional convention and be appropriately parsed by LoST in that jurisdict= ion in a quite transparent fashion. A German technical advisory committee c= ould make this recommendation within that jurisdiction without deference to= the BCP and without impact to ECRIT-compliant devices.=0D=0A=0D=0A=09*=09A= llow AN operated LOST=0D=0A=0D=0A=09[[MCD]] I don't think the BCP excludes = the possibility of the access network hosting LoST. It shouldn't - since th= is is a jurisdictional decision. As long as the LoST service can be discove= red/used when attached to the access, it shouldn't matter where it is hoste= d.=0D=0A=0D=0A=09*=09Provide a way to enable LOST-query based on national o= r domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives.=0D=0A=0D=0A=09[[= MCD]] I was in favour of the LIS proxying the LoST request - since they bot= h share a "locality" it simplifies the whole discovery plot. However, that = didn't take hold in the debate so we have what we have. Given that - a LIS = still need only provide the national level location (i.e. DE) in the PIDF-L= O if that's all that's required to make a successful LoST query. The rest c= an be done using LbyR - with the LIS also providing the reference along wit= h the coarse location. Doesn't that satisfy the requirement=3F=0D=0A=0D=0A=09= *=09Allow and describe also network-centric, not only ED-centric architectu= res. If I remember correctly, John Medland from BT also recomended to use = a more network- centric architecture, at least for the next years.=0D=0A=0D= =0A=09[[MCD]] I don't really understand this "X-centric" argument. Even tra= ditional cellular architectures require a combination of end device and net= work capabilities. Maybe if you are being specific you mean; there should b= e no ECRIT-specific requirements on the end device (though I'm not sure why= ECRIT should have this rule when other architectures don't). You're right = John M did propose such an approach. Not to put words in his mouth, but thi= s was in the context of an interim architecture - per my comments below on = the Canada and UK interim approaches. It works in the limited scope of devi= ces having to proxy calls through "national" VoIP carriers - it doesn't mee= t the long term vision of ECRIT. An interim architecture, by definition, is= not the end-game architecture. ECRIT only seeks to define the end-game; th= ere are already interim architectures to choose from - which was my point a= bout suggesting it might be better to baseline off i2 for the time being ra= ther than trying to shoehorn interim constraints into ECRIT.=0D=0A=0D=0A=09= =20=0D=0A=0D=0A=09I think it just means that the German regulator and techn= ical advisory committees would point out the subset aspects of compliance t= hat would be applicable to that jurisdiction. =20=0D=0A=09[[LLi]] Again, t= he draft is not flexible enough for it. If the BCP contains requirements w= hich are not realistic, people will just discard the BCP and implement prop= rietary stuff. My expectation from a standard body is to define protocols a= nd architecture which people are willing to implement in their network or p= roducts , not only in the lab.=0D=0A=0D=0A=09[[MCD]] What I mean is that co= mpliance isn't compulsory. It's OK to say "we have decided to deviate from = the specification in this way".=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09[[LLi]] =0D= =0A=0D=0A=09We are not against the draft in principle. ECRIT provides us w= ith very valuable specifications as LbyR, HELD, identity extensions. But ta= rgeting an architecture which requires everbody to invest without a busines= s case will not help the draft in the end, also if it becomes a BCP. It wo= uld make sense to make it more flexible so people are willing to adopt it. = =20=0D=0A=0D=0A=09[[MCD]] Lots of the elements you mention exist outside = of the BCP - LbyR, HELD, identity extensions... they aren't defined by the = BCP and can be used in any other context. The BCP has a very specific goal = of defining a way that emergency calls can be made by any Internet connecte= d device/proxy anywhere that follows the specification; it doesn't seek to = be more than that - which I think is what you're looking for. As I say, che= ck out the interim recommendations by the CRTC in Canada and NICC in the UK= =2E=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 Actually, based on your description be= low, the NENA i2 architecture would probably be a more straightforward base= line for analysis - as has been done in the UK and Canada. Of course, it's = generally recognized as only an interim step, even in those jurisdictions.=0D= =0A=0D=0A=09Other comments below.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Cheers,=0D= =0A=0D=0A=09Martin=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=0D=0A__________________= ______________=0D=0A=0D=0A=0D=0A=09From: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de=0D=0A=09Sent: Wednesd= ay, 5 August 2009 6:19 PM=0D=0A=09To: ecrit@ietf.org=0D=0A=09Subject: Re: [= Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09De= ar all,=20=0D=0A=09We would like the document to become a BCP as soon as po= ssible so the group can move on with other documents related to emergency c= alling based on location-by-reference and ED's IP-address.=20=0D=0A=0D=0A=09= [[MCD]] I think you might mean "identity extensions" rather than location-b= y-reference because LbyR still requires the ED to obtain the reference - e.= g. by HELD.=0D=0A=09[[LLi]] We use both, the IP-address as UE identity and = LbyR. The SIP-proxy uses the IP-address to query the LIS using HTTP (it's n= ot HELD but SOAP over HTTP, but anyway similar). The LIS responds with a nu= meric string associated to the caller location, in principle a LbyR and wit= h the PSAP number. The proxy inserts the LbyR into the SIP-message (as P-As= serted-ID because the PSAPs are in PSTN) and routes the message to the PSAP= =2E It's a low cost solution.=20=0D=0A=0D=0A=09But we can not HUM for the = current form of the document.=20=0D=0A=0D=0A=09Back to the document: Some r= equirements are far form being realistic, at least in Germany, some are not= realistic at all. Implementing these requirements cost a carrier a lot of = money and there is no ROI for it.=20=0D=0A=0D=0A=09Just a few examples:=20=0D= =0A=0D=0A=09=B7 Requiring either geo or civic location does not provi= de carriers with enough flexibility to reuse their existing mechanisms and = location databases. Routing of emergency calls is currently done in Germany= based on phone area code not on geo or civic location, at least for the fi= xed network. For mobile networks the cell-id is used in common. This is reg= ulated by the german regulator.=20=0D=0A=0D=0A=09[[MCD]] How many unique PS= AP routes are required in Germany=3F The US has lots (6000 plus) and Austra= lia has two (and they are redundant so it doesn't matter which one). Presum= ably geographic information, for PSAP catchment areas, is the basis for det= ermining which area codes are relevant to begin with=3F After all, an area = code is not intrinsically geographic; it's a network routing value. If so, = then some geographic discriminator is already in play in terms of construct= ing the area code based routing data (something like zip codes perhaps=3F) = - and in that case, it should be straightforward to by-pass the area code s= tep in the construction of routing that goes the correct PSAP URI.=20=0D=0A= =09[[LLi]] Currently, fixed networks carriers in Germany route the ECs base= d only on the caller's area code. Sometime in the past, the carriers, the r= egulator and the PSAPs operators (police, the Red Cross) agreed to do so. T= his may change in the future, but it will take a quite long time. =20=0D= =0A=0D=0A=09 With nomadic VoIP devices (and it's no good being in denial ab= out this being the norm in the future) area code is no more reliable than i= t is for conventional mobile phones. And, presumably, area code is not used= for conventional cellular emergency call routing=3F=0D=0A=09[[LLi]] As fa= r as I know, mobile networks use the Cell-ID, not the area code, and have a= different table than the fixed network operators. They are not going to ch= ange this. As to the nomadic SIP-users...if we like it or not, very few of= our customers use our SIP service nomadic, let alone call EC from their la= ptop. =20=0D=0A=0D=0A=091 LOST as a national, let alone= as a global directory is not going to be implemented. The regulator will p= rovide in the web a static table which contains the PSAPs and the area for = which they are responsible (one or more area codes). Every carrier has to i= mplement its own routing database for emergency calls.=20=0D=0A=0D=0A=09=09= [[MCD]] Whatever the carriers implement (and they have to implement somethi= ng) could just as readily be done using LoST. Then visiting devices, with n= o association with any local VoIP proxy server would still be able to deter= mine a route to the correct PSAP. Alternatively, as long as the regulator i= s maintaining a web service with the routing information, why not make that= directly accessible using LoST and save the operators the cost of duplicat= ing the service at all=3F=0D=0A=09=09[[LLi]] There is a big difference bet= ween maintaining a web page with a table which operator can print and imple= ment in their darabases and operating a database which is queried for every= emergency call in Germany, must have an availablity of 99,99...% , is sec= ure enough...you know. The regulator will not do this.=0D=0A=0D=0A=09=09=0D= =0A=09=092 We have no intention to rely on end devices for location i= nformation because:=20=0D=0A=09=09=B7 ED provided location info is no= t trusted=20=0D=0A=0D=0A=09[[MCD]] Location by reference mitigates this tru= st issue. The emergency network can (automatically and before human resourc= es are engaged) assess the source of the reference, and the validity of the= location by dereference, without having to trust location provided directl= y from the ED. There are more sophisticated approaches to trustability even= using LbyV - based on digital signatures across appropriate attributes. Th= is WG and Geopriv haven't really got to grips with that... yet.=0D=0A=09[[L= Li]] We build the SIP-network and EC now. ED-provided location is needed i= f EC must work for private and enterprise networks and VPNs. We have no su= ch regulatory requirements. And we don't know of any verdor of DSL-EDs whi= ch provides today SIP with LbyR and is as cheap as the devices without it. = If you do, please let me know.=20=0D=0A=0D=0A=09The regulator ask us to gua= rantee that EC works. What if a customer dials 112 and his end device does = not send the location=3F So I have to implement both solutions, with and wi= thout ED provided location, anyway. =20=0D=0A=091 There are already a= lot of existing EDs in usage which don't send location. =20=0D=0A=0D=0A=09= [[MCD]] Quite right. ECRIT doesn't overly concern itself with that interim = situation. The UK and Canadian definitions for an interim solution (limitin= g service to in-country VoIP proxy operators) both assume third-party query= via identity-extension to allow the proxy or the VPC to make the query to = the LIS. This isn't extensible to universal emergency service access by all= visiting devices but it does put the necessary LIS functionality in place = as a very good starting point. It would be a pity if Germany were to cease= the evolution there as it would not fulfil the real promise of the Interne= t and the ECRIT model.=20=0D=0A=09[[LLi]] I wonder who will drive and pay = for upgrading the interim solutions. Unfortunatelly, it's all about money.= =2E.=0D=0A=0D=0A=09 Think about it; all the complexity of putting location = determination infrastructure in place for the purposes of dispatch is done = - and then the next, simpler step, of using that to support the routing pro= cedure isn't taken... that would be a waste.=0D=0A=09=0D=0A=09[[LLi]] Do y= ou think this is an argument for a product manager=3F They need a business = case. =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09 We don't inte= nd to require our ED-vendors to provide location because it is useless to u= s. =20=0D=0A=0D=0A=09We could agree with the document with following chang= es:=20=0D=0A=0D=0A=09=09*=09Other location identifiers then geo or civil ar= e allowed. It must be possibe that the data foermat is flexible due to diff= erent requirements from regulators over the whole world. (e.G Germany area = codes for fixed- and Cell-Id for moile- providers)=20=0D=0A=09=09*=09The MU= ST for the end devices to support location information, DHCP location optio= ns and HELD shall be removed=20=0D=0A=09=09*=09It must be possible for the = VoIP-provider's proxy to use a LOST (or an ESRP) provided by the AN or by o= ther local provider on behalf of the AN. =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09= There is no value in Hum-ing documents which one is not going to implement= and does not fit into regulated schemes like in Germany. Currently, neithe= r the IETF- nor the 3GPP-architecture for emergency calling covers our real= needs for the next 2 to 5 years and in the end everybody still has its own= proprietary implementation. =20=0D=0A=0D=0A=09Best regards=20=0D=0A=0D=0A= =09Roland=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Deutsche Telekom Netzproduktio= n GmbH=0D=0A=09Zentrum Technik Einf=FChrung=0D=0A=09Roland Jesske=0D=0A=09G= ateways, Protokolle, Konvergenz, TE32-1=0D=0A=09Heinrich-Hertz-Str. 3-7, 64= 295 Darmstadt,=0D=0A=09Postfach, 64307 Darmstadt (Postanschrift)=0D=0A=09+4= 96151 628 2766 (Tel)=0D=0A=09+491718618445 (Mobile)=0D=0A=09E-Mail: r.jessk= e@telekom.de =20=0D=0A=09http://www.telekom.de= =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Registerrecht= liche Unternehmensangaben:=0D=0A=09Deutsche Telekom Netzproduktion (DT NP) = GmbH=0D=0A=09Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=0D=0A=09Gesch= =E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, K= laus Peren=0D=0A=09Handelsregister: Amtsgericht Bonn HRB 14190=0D=0A=09Sitz= der Gesellschaft: Bonn=0D=0A=09USt-IdNr.: DE 814645262=20=0D=0A=0D=0A=09 =0D= =0A=0D=0A=09=20=0D=0A=0D=0A=0D=0A------------------------------------------= ------------------------------------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information. =20=0D=0AIf you have received it in= error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0A[mf2]=0D=0A=0D=0A=09=20=0D=0A=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA16A9.7F0305CD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ARe: [Ecrit]= HUM on PhoneBCP=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

I neglected to do a point by point, sorry.=0D=0ASo – that follows= :

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

 

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

Cheers,

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

M= artin

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

 

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

From:=0D=0AL.Liess@telekom.de [mailto:L.Liess@telekom.de] =
=0D=0ASent: Friday, 7 Au= gust 2009 12:29=0D=0AAM
=0D=0ATo: Dawson, Martin;=0D=0AR.Jesske@telekom.de; ecrit@ietf.org
=0D=0A= Cc: Reinhard.Lauster@t-mobil= e.at
=0D=0ASubject: RE: [= Ecrit] HUM on=0D=0APhoneBCP

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

 

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

Hi Martin,

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

 

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

See comments inline [[LLi]].

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

 

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

 

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

Laura

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

From:=0D=0Aecrit-bounces@ietf.o= rg [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawson, Martin
=0D=0ASent: Wednesday, August 05, 2009=0D=0A11:00 AM
=0D=0A= To: Jesske, Roland; ecrit@ie= tf.org
=0D=0ASubject: Re:= [Ecrit] HUM on=0D=0APhoneBCP

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

Hi= Roland,

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

 

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

I think what you̵= 7;re saying is that=0D=0Ayou don’t think that = Germany=0D= =0Awill go on to implement full ECRIT support but will peg development at a= n=0D=0Ainterim phase.
=0D=0A[[LLi]]  We don't know how the=0D=0Arealtime applicatio= n networks or EC will look like in 20=0D=0Ayears. Roland's answer=  only applies to the next 5 to 10 years. 

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

[[MCD]] Th= e implementation of the LIS function is the most=0D=0Asignificant aspect fo= r operators – and that needs to happen in short term=0D=0Ascenarios i= n any case. The provision of LoST can be a national asset/service. The=0D=0A= provision of PSAP URIs is an emergency service responsibility. Those are th= e=0D=0Akey requirements – and that does provide a framework that will= work into=0D=0Athe next 20 years and beyond.

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

 

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

 That would be disappointing – not least because = full ECRIT=0D=0Acompliance would ultimately decrease the overhead associate= d with emergency=0D=0Aservice support for operators as well as providing a = more universal service.
=0D=0A
=0D=0A[[LLi]]  This may be true for "green=0D=0Afield&q= uot; ISPs and VSPs but not for incumbent carriers with existing=0D=0Ai= nfrastructure.  And universal service is not a requirement for us= =2E=0D=0ANeither the German regulator requires it nor is it a busines=0D= =0Acase.   =0D=0A=0D=0A

[[MCD]] I think this is only true to= the same extent that a pure=0D=0AInternet green field ISP only has to worr= y about Internet trunk connectivity=0D=0Aand doesn’t have to worry ab= out PSTN circuit trunk connectivity. The=0D=0Alatter infrastructure is lega= cy and not particularly applicable to the Internet=0D=0Acomponent of the se= rvice. Providing ECRIT emergency calling support requires=0D=0Athe addition= of a LIS, access to LoST (whoever hosts it), and a route to the=0D=0APSAP = URI(s). Both types of operator need to do that. Whatever switched circuit=0D= =0Alegacy emergency infrastructure already exists in the established operat= or=0D=0Aneeds to continue to exist to support the emergency calls on that a= ccess.<= span style=3D'font-size:10.0pt;font-family:Arial;=0D=0Acolor:navy'>

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

 

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

Nevertheless, I don’t think that=0D= =0Adecision invalidates the BCP;
=0D=0A[[LLi]]  We think it=0D=0Adoes, because some= of the requirements are not flexible enough to=0D=0Acover the deployments = within the next years.  The BCP should be more=0D=0Aflexible:&nbs= p; 

=0D=0A=0D=0A
=0D=0A=0D=0A
    =0D=0A
  • Allow additional=0D=0A location identifiers 
    • =0D=0A
=0D=0A=0D=0A

[[MCD]] Agreed= – although that=0D=0Acan be done by local-specific use of fields in = the PIDF-LO based on=0D=0Ajurisdictional convention and be appropriately pa= rsed by LoST in that=0D=0Ajurisdiction in a quite transparent fashion. A Ge= rman technical advisory=0D=0Acommittee could make this recommendation withi= n that jurisdiction without=0D=0Adeference to the BCP and without impact to= ECRIT-compliant devices.

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D= =0A=0D=0A
    =0D=0A
  • = Allow AN operated=0D=0A LOST
    • =0D=0A
=0D=0A=0D=0A

[[MCD]] I don’= ;t think the=0D=0ABCP excludes the possibility of the access network hostin= g LoST. It shouldn’t=0D=0A– since this is a jurisdictional deci= sion. As long as the LoST service=0D=0Acan be discovered/used when attached= to the access, it shouldn’t matter=0D=0Awhere it is hosted.

=0D= =0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
    =0D=0A
  • <= span=0D=0A style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Prov= ide a way=0D=0A to enable LOST-query based on national or=0D=0A= domain-specific location identifier. One posiblility is to a= llow=0D=0A the LIS to query the LOST , but there are als= o other=0D=0A alternatives.
    • =0D=0A
=0D= =0A=0D=0A

[[MCD]] I was in favour of the=0D=0ALIS proxying the L= oST request – since they both share a “locality”=0D=0Ait = simplifies the whole discovery plot. However, that didn’t take hold i= n=0D=0Athe debate so we have what we have. Given that - a LIS still need on= ly provide=0D=0Athe national level location (i.e. DE) in the PIDF-LO if tha= t’s all that’s=0D=0Arequired to make a successful LoST query. T= he rest can be done using LbyR –=0D=0Awith the LIS also providing the= reference along with the coarse location. Doesn’t=0D=0Athat satisfy = the requirement=3F

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A<= ul type=3Ddisc>=0D=0A
  • Allow and describe=0D=0A also&nbs= p;network-centric, not only ED-centric architectures. If=0D=0A I&n= bsp; remember correctly, John Medland from BT also recomended to=0D=0A= use a more network- centric architecture, at least for the next years.=
    • =0D=0A=0D=0A=0D=0A

    [[MCD]] I do= n’t really=0D=0Aunderstand this “X-centric” argument. Eve= n traditional cellular=0D=0Aarchitectures require a combination of end devi= ce and network capabilities. Maybe=0D=0Aif you are being specific you mean;= there should be no ECRIT-specific=0D=0Arequirements on the end device (tho= ugh I’m not sure why ECRIT should have=0D=0Athis rule when other arch= itectures don’t). You’re right John M did=0D=0Apropose such an = approach. Not to put words in his mouth, but this was in the context=0D=0Ao= f an interim architecture – per my comments below on the Canada and UK interim approaches. It works in=0D=0Athe limited scope of devices havin= g to proxy calls through “national”=0D=0AVoIP carriers – = it doesn’t meet the long term vision of ECRIT. An=0D=0Ainterim archit= ecture, by definition, is not the end-game architecture. ECRIT=0D=0Aonly se= eks to define the end-game; there are already interim architectures to=0D=0A= choose from – which was my point about suggesting it might be better = to=0D=0Abaseline off i2 for the time being rather than trying to shoehorn i= nterim=0D=0Aconstraints into ECRIT.

    =0D=0A=0D=0A
    =0D=0A=0D=0A<= div>=0D=0A=0D=0A

    &nbs= p;

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

     

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

     

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

    Dear all,
    =0D=0AWe would like th= e=0D=0Adocument to become a BCP as soon as possible so the group can move o= n with=0D=0Aother documents related to emergency calling based on location-= by-reference and=0D=0AED’s IP-address.

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

    [[MCD]] I=0D=0Athink you might mean= “identity extensions” rather than=0D=0Alocation-by-reference b= ecause LbyR still requires the ED to obtain the=0D=0Areference – e.g.= by HELD.
    =0D=0A    [[LLi]] We use both, the= IP-address as UE identity and=0D=0ALbyR. The SIP-proxy uses the IP-address= to query the LIS using HTTP (it's not=0D=0AHELD but SOAP over HTTP, b= ut anyway similar). The LIS responds with a=0D=0Anumeric string associ= ated to the caller location, in principle a LbyR and with=0D=0Athe PSAP&nbs= p;number. The proxy inserts the LbyR into the SIP-message=0D=0A(a= s P-Asserted-ID because the PSAPs are in PSTN) and routes the message = to=0D=0Athe PSAP.  It's a low cost solution. <= /i>

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

    But we can not HUM for the current form of=0D=0Athe document.

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

    Back to the document: Some requirements=0D=0Aare far form being realistic= , at least in = Germany, some are not realistic at=0D=0Aal= l. Implementing these requirements cost a carrier a lot of money and there = is=0D=0Ano ROI for it.

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

    Just a few examples: <= /o:p>

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

    =B7 =       Requiring either geo or=0D=0Acivi= c location does not provide carriers with enough flexibility to reuse their=0D= =0Aexisting mechanisms and location databases. Routing of emergency calls i= s=0D=0Acurrently done in Germany=0D=0Abased on phone area code= not on geo or civic location, at least for the fixed=0D=0Anetwork. For mob= ile networks the cell-id is used in common. This is regulated=0D=0Aby the g= erman regulator.

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

    <= font size=3D2 color=3Dnavy face=3DArial>[[MCD]]= How=0D=0Amany unique PSAP routes are required in Germany=3F The US has l= ots (6000 plus) and Australia has two (and they are=0D=0A= redundant so it doesn’t matter which one). Presumably geographic=0D=0A= information, for PSAP catchment areas, is the basis for determining which a= rea=0D=0Acodes are relevant to begin with=3F After all, an area code is not= intrinsically=0D=0Ageographic; it’s a network routing value. If so, = then some geographic=0D=0Adiscriminator is already in play in terms of cons= tructing the area code based=0D=0Arouting data (something like zip codes pe= rhaps=3F) – and in that case, it=0D=0Ashould be straightforward to by= -pass the area code step in the construction of=0D=0Arouting that goes the = correct PSAP URI.
    =0D=0A    [[LLi]] Current= ly, fixed networks carriers in=0D=0AGermany=0D=0Arou= te the ECs based only on the caller's area code. Sometime in the=0D= =0Apast, the carriers, the regulator and the PSAPs operators (police, = the Red=0D=0ACross) agreed to do so. This may change in the future, bu= t it will take a=0D=0Aquite long time.      <= /span>

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

     With=0D=0Anomadic = VoIP devices (and it’s no good being in denial about this being=0D=0A= the norm in the future) area code is no more reliable than it is for=0D=0Ac= onventional mobile phones. And, presumably, area code is not used for=0D=0A= conventional cellular emergency call routing=3F
    =0D=0A    =     [[LLi]]  As far as I know, mobile networks use the=0D=0ACell-= ID, not the area code, and have a different table than the fixed network=0D= =0Aoperators. They are not going to change this.  As to the nomad= ic=0D=0ASIP-users...if we like it or not, very few of our=0D=0Acu= stomers use our SIP service nomadic, let alone call EC from=0D= =0Atheir laptop.         

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

    1<= /font>         = ;    =0D=0ALOST as a=0D=0Anational, let alone as a glob= al directory is not going to be implemented. The=0D=0Aregulator will provid= e in the web a static table which contains the PSAPs and=0D=0Athe area for = which they are responsible (one or more area codes). Every carrier=0D=0Ahas= to implement its own routing database for emergency calls. <= font=0D=0Acolor=3Dnavy><= /span>

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

    [[MCD]]=0D=0AWhat= ever the carriers implement (and they have to implement something) could=0D= =0Ajust as readily be done using LoST. Then visiting devices, with no assoc= iation=0D=0Awith any local VoIP proxy server would still be able to determi= ne a route to=0D=0Athe correct PSAP. Alternatively, as long as the regulato= r is maintaining a web=0D=0Aservice with the routing information, why not m= ake that directly accessible=0D=0Ausing LoST and save the operators the cos= t of duplicating the service at all=3F
    =0D=0A    [[LLi]]  There is a big difference between=0D=0Amaintaini= ng a web page with a table which operator can print and implement=0D=0A= in their darabases and operating a database which is queried for=0D=0A= every emergency call in Germany, must have an availablity of=0D=0A= 99,99...% ,  is secure enough...you know. The=0D=0Aregulator=  will not do this.

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

    =
    =0D=0A2   &nbs= p;   We have no intention to rely on end=0D=0Adevices for locatio= n information because:
    =0D=0A    =B7      = ED= provided location=0D=0Ainfo is not trusted

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

    = [[MCD]]=0D=0ALocation by reference mitigates th= is trust issue. The emergency network can=0D=0A(automatically and before hu= man resources are engaged) assess the source of the=0D=0Areference, and the= validity of the location by dereference, without having to=0D=0Atrust loca= tion provided directly from the ED. There are more sophisticated approaches=0D= =0Ato trustability even using LbyV – based on digital signatures acro= ss=0D=0Aappropriate attributes. This WG and Geopriv haven’t really go= t to grips=0D=0Awith that… yet.
    =0D=0A    = [= [LLi]]  We build the SIP-network and EC now.=0D=0AED-provided loc= ation is needed if EC must work for private and=0D=0Aenterpr= ise networks and VPNs.  We have no such regulatory=0D=0Arequirements.&= nbsp; And we don't know of any verdor of DSL-EDs=0D=0Awhich&= nbsp;provides today SIP with LbyR and is as cheap as=0D=0Athe dev= ices without it. If you do, please let me know. =

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

    The regulator=0D=0Aask us to guarantee t= hat EC works. What if a customer dials 112 and=0D=0Ahis end devic= e does not send the location=3F So I have to=0D=0Aimplement both = solutions, with and without ED provided location,=0D=0Aanyway.  <= /span>
    =0D=0A1      =0D=0AThere are alrea= dy a lot of existing EDs in usage which don’t send=0D=0Alocation.&nbs= p;  

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

    [[MCD]] Quite=0D=0Aright. ECRIT doesn’t overly concern itself w= ith that interim situation.=0D=0AThe UK=0D=0Aand Canadian defi= nitions for an interim solution (limiting service to=0D=0Ain-country VoIP p= roxy operators) both assume third-party query via=0D=0Aidentity-extension t= o allow the proxy or the VPC to make the query to the LIS.=0D=0AThis isn= 217;t extensible to universal emergency service access by all=0D=0Avisiting= devices but it does put the necessary LIS functionality in place as a=0D=0A= very good starting point.  It would be a pity if Germany were to cease the evolution=0D=0Athere as it would not fulfil the = real promise of the Internet and the ECRIT=0D=0Amodel.
    =0D=0A    [[LLi]]  I wonder who will drive and pay=0D=0Afo= r upgrading the interim solutions.  Unfortunatelly, it'= s=0D=0Aall about money...

    =0D=0A=0D=0A<= p> Think=0D=0Aabout it; all the complexity of putting location determi= nation infrastructure=0D=0Ain place for the purposes of dispatch is done &#= 8211; and then the next,=0D=0Asimpler step, of using that to support the ro= uting procedure isn’t=0D=0Ataken… that would be a waste.
    =0D= =0A
    =0D=0A    [[LLi]]  Do you think this is a= n argument for a product=0D=0Amanager=3F They need a business case.&nb= sp;

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

     

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

     

    =0D=0A=0D=0A<= p style=3D'margin-left:36.0pt'>&n= bsp; We don’t intend to=0D=0Arequire our ED-vendors to provide locati= on because it is useless to=0D=0Aus.   <= /p>=0D=0A=0D=0A

    We could agree = with the document with following=0D=0Achanges:

    =0D=0A=0D=0A
      =0D=0A
        =0D=0A
      • Other location identifiers then g= eo or civil are allowed. It=0D=0A must be possibe that the data foerma= t is flexible due to different=0D=0A requirements from regulators over= the whole world. (e.G Germany area codes for fixe= d-=0D=0A and Cell-Id for moile- providers)
        • =0D=0A
      • The MUST = for the end devices to support location=0D=0A information, DHCP locati= on options and HELD shall be removed
        • =0D=0A =
      • It must be possible for the VoIP-provider̵= 7;s proxy to=0D=0A use a LOST (or an ESRP) provided by the AN or by ot= her local provider on=0D=0A behalf of the AN. 
        • =0D=0A
      =0D=0A
    =0D=0A=0D=0A

     

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

    <= font size=3D3 color=3Dblack face=3D"Times New Roman"> There is no value in Hum-ing=0D= =0Adocuments which one is not going to implement and does not fit into regu= lated=0D=0Aschemes like in Germany.=0D=0ACurrently, neither the = IETF- nor the 3GPP-architecture for emergency calling=0D=0Acovers our real = needs for the next 2 to 5 years and in the end everybody still=0D=0Ahas its= own proprietary implementation.   

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

    <= span lang=3DEN-GB=0D=0Astyle=3D'font-size:12.0pt;color:black'>Best regards<= /span>

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

    = Roland

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

    &nbs= p;

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

    Deutsche Telekom Netzproduktion GmbH
    =0D=0AZentrum Technik Ein= f=FChrung
    =0D=0A    Roland Jesske
    =0D=0A    Gateways, Protokolle, Konvergenz, TE32-1
    =0D=0AHeinrich-Hertz-Str. 3-7, 64295 D= armstadt,
    =0D=0APostfach, 64307 Darmstadt (Postanschrift)
    =0D=0A+496151 628 2766 (Tel)
    =0D=0A    +491718618445 (Mob= ile)
    =0D=0A    E-Ma= il: r.jesske@telekom.de
    =0D= =0Ahttp://www.telekom= =2Ede=0D=0A

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

     

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

    Registerrechtliche Unternehmensangaben:<= /font>
    =0D=0A    Deutsche Tele= kom Netzproduktion (DT NP) GmbH
    =0D=0AAufsichtsrat: Timotheus H=F6ttges = (Vorsitzender)
    =0D=0AGesch=E4ftsf=FChrung: Dr. Bruno=0D=0AJacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
    =0D=0AHandelsregister: Amtsgericht Bonn HR= B 14190
    =0D=0ASitz der Gesellschaft: Bonn
    =0D=0AUSt-IdNr.: DE 8146452= 62

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

     

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

     =

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


    =0D=0A -----------------------------------------= -------------------------------------------------------
    =0D=0A This&nbs= p;message is for the designated recipient onl= y and may
    =0D=0A contain privileged, proprietary,&n= bsp;or otherwise private information.  
    =0D=0A = If you have received it in error, pleas= e notify the sender
    =0D=0A immediately and del= ete the original.  Any unauthorized use = of
    =0D=0A this email is prohibited.
    =0D=0A ---------= ---------------------------------------------------------------------------= ------------
    =0D=0A [mf2]

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

     <= /span>

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

    -------------= ---------------------------------------------------------------------------= --------
    =0D=0AThis message is for the designat= ed recipient only and may
    =0D=0Acontain privile= ged, proprietary, or otherwise private information= =2E  
    =0D=0AIf you have received it i= n error, please notify the sender
    =0D=0Aimmedia= tely and delete the original.  Any unaut= horized use of
    =0D=0Athis email is prohibited.<= br>=0D=0A------------------------------------------------------------------= ------------------------------
    =0D=0A[mf2]
    =0D=0A=0D= =0A=0D=0A ------_=_NextPart_001_01CA16A9.7F0305CD-- From hannes.tschofenig@nsn.com Thu Aug 6 09:07:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D400128C10F for ; Thu, 6 Aug 2009 09:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfnHFzbHvTdv for ; Thu, 6 Aug 2009 09:07:52 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 32A683A6A63 for ; Thu, 6 Aug 2009 09:07:51 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n76G7oX7020313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 18:07:50 +0200 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 n76G7o0p016665; Thu, 6 Aug 2009 18:07:50 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 18:07:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA16B0.0B4141C1" Date: Thu, 6 Aug 2009 19:10:19 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019411DF@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAAOKzRQAAGMtlA= References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Dawson, Martin" , , , X-OriginalArrivalTime: 06 Aug 2009 16:07:49.0975 (UTC) FILETIME=[0BB1FE70:01CA16B0] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 16:07:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA16B0.0B4141C1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin,=20 =20 you provided a very useful response.=20 =20 A few minor notes below:=20 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of ext Dawson, Martin Sent: 06 August, 2009 18:21 To: L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 I neglected to do a point by point, sorry. So - that follows: =20 Cheers, Martin =20 =09 ________________________________ From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, =20 I think what you're saying is that you don't think that Germany will = go on to implement full ECRIT support but will peg development at an = interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC = will look like in 20 years. Roland's answer only applies to the next 5 = to 10 years.=20 [[MCD]] The implementation of the LIS function is the most significant = aspect for operators - and that needs to happen in short term scenarios = in any case. The provision of LoST can be a national asset/service. The = provision of PSAP URIs is an emergency service responsibility. Those are = the key requirements - and that does provide a framework that will work = into the next 20 years and beyond.=20 =20 [Hannes] This is absolutely correct. Particularly for fixed networks = there is often no LIS available and hence it requires additional cost. = It is also quite unlikely that you will come up with a business model of = selling the fixed location of the subscriber for non-emergency services = purposes. There is, however, no reason for network operator to ask for = financial support from the government (and we see this happening in = various places throughout the world). In the long run it will be quite = difficult to get away without having a LIS provided by the access = provider. Everyone understands that transition time needs some time. = This is what other emergency services organizations, such as NENA and = others, are looking into. =20 So, there is no reason to be so negative towards this work. =20 =20 =20 That would be disappointing - not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service. =09 [[LLi]] This may be true for "green field" ISPs and VSPs but not for = incumbent carriers with existing infrastructure. And universal service = is not a requirement for us. Neither the German regulator requires it = nor is it a busines case. =20 [[MCD]] I think this is only true to the same extent that a pure = Internet green field ISP only has to worry about Internet trunk = connectivity and doesn't have to worry about PSTN circuit trunk = connectivity. The latter infrastructure is legacy and not particularly = applicable to the Internet component of the service. Providing ECRIT = emergency calling support requires the addition of a LIS, access to LoST = (whoever hosts it), and a route to the PSAP URI(s). Both types of = operator need to do that. Whatever switched circuit legacy emergency = infrastructure already exists in the established operator needs to = continue to exist to support the emergency calls on that access.=20 =20 [Hannes] Regarding additional overhead: This is a fairly broad claim = and generic claim that will be hard to justify. Some notes that come to = my mind when it comes to overhead and performance. We have visited the = police PSAP in Vienna/Austria and no location support was provided for = cellular calls. Guess how much delay that causes for the overall = performance of emergency services. I also saw how emergency services = organizations structure change as they move towards Next Generation = emergency services and the consequence was a far less complex structure = and I expect further simplifications that will be incorporated as we = move along.=20 =20 =20 =20 Nevertheless, I don't think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP = should be more flexible: =20 * Allow additional location identifiers =20 [[MCD]] Agreed - although that can be done by local-specific use of = fields in the PIDF-LO based on jurisdictional convention and be = appropriately parsed by LoST in that jurisdiction in a quite transparent = fashion. A German technical advisory committee could make this = recommendation within that jurisdiction without deference to the BCP and = without impact to ECRIT-compliant devices.=20 =20 [Hannes] As part of the efforts currently being done in EENA we hope = to provide a recommendation of how to use civic addresses within each = member state, similar to what has been excercised with = http://www.ietf.org/id/draft-ietf-geopriv-civic-address-recommendations-0= 3.txt and also being done by NENA for the US.=20 =20 If those investigations will lead to the conclusion that new fields = are required then we will ask for more or figure out how to accomplish = the functionality.=20 =20 * Allow AN operated LOST=20 [[MCD]] I don't think the BCP excludes the possibility of the access = network hosting LoST. It shouldn't - since this is a jurisdictional = decision. As long as the LoST service can be discovered/used when = attached to the access, it shouldn't matter where it is hosted.=20 =20 [Hannes] As Martin said it is possible for AN to operator a caching = LoST server (it will most likely not be an authoritative LoST server, I = believe). There are different deployment models and the protocol is = flexible with this regard. Phone BCP cannot mandate a specific = deployment approach as we already know that there will be different = stories in different parts of the world. =20 * Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives.=20 [[MCD]] I was in favour of the LIS proxying the LoST request - since = they both share a "locality" it simplifies the whole discovery plot. = However, that didn't take hold in the debate so we have what we have. = Given that - a LIS still need only provide the national level location = (i.e. DE) in the PIDF-LO if that's all that's required to make a = successful LoST query. The rest can be done using LbyR - with the LIS = also providing the reference along with the coarse location. Doesn't = that satisfy the requirement?=20 =20 [Hannes] We indeed discussed this aspect and the conclusion was to not = proxy LoST in HELD. Reducing the number of options reduces the = implementation complexity and lowers the cost for implementation.=20 =20 The fact that we do not have support for this functionality specified = and not referenced in PhoneBCP does not mean that it will not be = proposed in the future and might find excitement. =20 * Allow and describe also network-centric, not only ED-centric = architectures. If I remember correctly, John Medland from BT also = recomended to use a more network- centric architecture, at least for the = next years.=20 [[MCD]] I don't really understand this "X-centric" argument. Even = traditional cellular architectures require a combination of end device = and network capabilities. Maybe if you are being specific you mean; = there should be no ECRIT-specific requirements on the end device (though = I'm not sure why ECRIT should have this rule when other architectures = don't). You're right John M did propose such an approach. Not to put = words in his mouth, but this was in the context of an interim = architecture - per my comments below on the Canada and UK interim = approaches. It works in the limited scope of devices having to proxy = calls through "national" VoIP carriers - it doesn't meet the long term = vision of ECRIT. An interim architecture, by definition, is not the = end-game architecture. ECRIT only seeks to define the end-game; there = are already interim architectures to choose from - which was my point = about suggesting it might be better to baseline off i2 for the time = being rather than trying to shoehorn interim constraints into ECRIT. =20 [Hannes] Martin captured it quite nicely. I have in meetings also = stated that it would be good for this group to also describe and discuss = intermediate deployment architecture. We got blocked with the completion = of PhoneBCP and Framework but we might still look into some of these = aspects in the future. We also have to consider that NENA has been = working on a transition architecture, namely NENA i2/i2.5 as mentioned = (which also uses many building blocks from ECRIT or at least = semantically similar mechanisms). Since many of these transition = architectures are very much focused on national systems it is likely = that we might find difficulties to generalize them in a way that it = still remains useful. Since there are many legacy components in the game = the IETF might not be the right place todo this type of overall = architecture work.=20 =20 Please also note that while we see countries looking at these = transition architectures, particularly when they have to deal with = legacy PSAPs not supporting IP, we also see a large number of countries = switching to a next generation architecture from an emergency services = network point of view since=20 a) they have to update their PSAPs anyway (because new signaling = protocols are being added) and only the audio part remains unchanged.=20 b) they get many benefits and cost reducts from moving to IP.=20 =20 I think it just means that the German regulator and technical advisory = committees would point out the subset aspects of compliance that would = be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP = contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard = body is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. [[MCD]] What I mean is that compliance isn't compulsory. It's OK to = say "we have decided to deviate from the specification in this way". =20 [Hannes] From what I hear from the regulator is that you are taking = the first steps already to move into a direction that goes into an = architecture that distributes PSAP boundaries to make routing of = emergency calls by VoIP providers possible. With a few minor = enhancements you will quickly end up with an architecture utilized, for = example, in Sweden or as envisioned by Lithuania.=20 =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with = very valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a = business case will not help the draft in the end, also if it becomes a = BCP. It would make sense to make it more flexible so people are willing = to adopt it. =20 [[MCD]] Lots of the elements you mention exist outside of the BCP - = LbyR, HELD, identity extensions... they aren't defined by the BCP and = can be used in any other context. The BCP has a very specific goal of = defining a way that emergency calls can be made by any Internet = connected device/proxy anywhere that follows the specification; it = doesn't seek to be more than that - which I think is what you're looking = for. As I say, check out the interim recommendations by the CRTC in = Canada and NICC in the UK. =20 [Hannes] We understand that the business model, I call it funding = model, for emergency services is complicated. There are places in the = world where interesting funding models are being found. I believe that = Phone BCP does not require a lot of additional investments from access = network providers particularly if they do not provide voice/application = servers. We additionally put the burden for these operators as low as = possible. I believe that sharing of responsibilities in the IETF ECRIT = architecture is much better than it can found in any of the other = architectures I have seen. We could discuss these aspect in more detail = if there is interest.=20 =20 =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis - as has = been done in the UK and Canada. Of course, it's generally recognized as = only an interim step, even in those jurisdictions. Other comments below. =20 [Hannes] The NENA i2 architecture (or better a modified version) would = be more interesting for a comparison. Please note that there is an = ongoing effort to update NENA i2 (to i2.5) by updating some of the work = that is being done elsewhere (such as in the IETF) so that you have = up-to-date protocols. You might find a number of concepts in there that = are familiar. From a network operator point of view the only difference = is the ability to deal with legacy end points that do not have obtained = location. This is, however, also included in the PhoneBCP even though it = is treated as a failure case there. An architecture that has to deal = with legacy end points also has to deal with a number of weaknesses. = Looking forward to have end points that may not have obtained location = but a reference to location to ensure robut location lookup might not = put a too huge burden on the involved parties with a lot of increased = robustness of the overal system. These software updates to obtain these = LbyRs could be judged impossible by some but then I would also like to = know how software bugs are being dealt with without doing any software = updates. =20 =20 Ciao Hannes =20 Cheers, Martin =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling = based on location-by-reference and ED's IP-address.=20 [[MCD]] I think you might mean "identity extensions" rather than = location-by-reference because LbyR still requires the ED to obtain the = reference - e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD = but SOAP over HTTP, but anyway similar). The LIS responds with a numeric = string associated to the caller location, in principle a LbyR and with = the PSAP number. The proxy inserts the LbyR into the SIP-message (as = P-Asserted-ID because the PSAPs are in PSTN) and routes the message to = the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being realistic, = at least in Germany, some are not realistic at all. Implementing these = requirements cost a carrier a lot of money and there is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and = location databases. Routing of emergency calls is currently done in = Germany based on phone area code not on geo or civic location, at least = for the fixed network. For mobile networks the cell-id is used in = common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US = has lots (6000 plus) and Australia has two (and they are redundant so it = doesn't matter which one). Presumably geographic information, for PSAP = catchment areas, is the basis for determining which area codes are = relevant to begin with? After all, an area code is not intrinsically = geographic; it's a network routing value. If so, then some geographic = discriminator is already in play in terms of constructing the area code = based routing data (something like zip codes perhaps?) - and in that = case, it should be straightforward to by-pass the area code step in the = construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the = carriers, the regulator and the PSAPs operators (police, the Red Cross) = agreed to do so. This may change in the future, but it will take a quite = long time. =20 With nomadic VoIP devices (and it's no good being in denial about = this being the norm in the future) area code is no more reliable than it = is for conventional mobile phones. And, presumably, area code is not = used for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the = area code, and have a different table than the fixed network operators. = They are not going to change this. As to the nomadic SIP-users...if we = like it or not, very few of our customers use our SIP service nomadic, = let alone call EC from their laptop. =20 1 LOST as a national, let alone as a global directory is = not going to be implemented. The regulator will provide in the web a = static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its = own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement = something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would = still be able to determine a route to the correct PSAP. Alternatively, = as long as the regulator is maintaining a web service with the routing = information, why not make that directly accessible using LoST and save = the operators the cost of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page = with a table which operator can print and implement in their darabases = and operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you = know. The regulator will not do this. =09 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The = emergency network can (automatically and before human resources are = engaged) assess the source of the reference, and the validity of the = location by dereference, without having to trust location provided = directly from the ED. There are more sophisticated approaches to = trustability even using LbyV - based on digital signatures across = appropriate attributes. This WG and Geopriv haven't really got to grips = with that... yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is = needed if EC must work for private and enterprise networks and VPNs. We = have no such regulatory requirements. And we don't know of any verdor = of DSL-EDs which provides today SIP with LbyR and is as cheap as the = devices without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. = =20 1 There are already a lot of existing EDs in usage which don't = send location. =20 [[MCD]] Quite right. ECRIT doesn't overly concern itself with that = interim situation. The UK and Canadian definitions for an interim = solution (limiting service to in-country VoIP proxy operators) both = assume third-party query via identity-extension to allow the proxy or = the VPC to make the query to the LIS. This isn't extensible to universal = emergency service access by all visiting devices but it does put the = necessary LIS functionality in place as a very good starting point. It = would be a pity if Germany were to cease the evolution there as it would = not fulfil the real promise of the Internet and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim = solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination = infrastructure in place for the purposes of dispatch is done - and then = the next, simpler step, of using that to support the routing procedure = isn't taken... that would be a waste. =09 [[LLi]] Do you think this is an argument for a product manager? They = need a business case. =20 =20 =20 We don't intend to require our ED-vendors to provide location = because it is useless to us. =20 We could agree with the document with following changes:=20 * Other location identifiers then geo or civil are allowed. It must = be possibe that the data foermat is flexible due to different = requirements from regulators over the whole world. (e.G Germany area = codes for fixed- and Cell-Id for moile- providers)=20 * The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed=20 * It must be possible for the VoIP-provider's proxy to use a LOST (or = an ESRP) provided by the AN or by other local provider on behalf of the = AN. =20 =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. = Currently, neither the IETF- nor the 3GPP-architecture for emergency = calling covers our real needs for the next 2 to 5 years and in the end = everybody still has its own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2]=09 ------_=_NextPart_001_01CA16B0.0B4141C1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] = HUM on PhoneBCP
    Hi Martin,
     
    you provided a very useful response. =
     
    A few=20 minor notes below:
     

    From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Dawson,=20 Martin
    Sent: 06 August, 2009 18:21
    To: = L.Liess@telekom.de;=20 R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: Re: [Ecrit] HUM on=20 PhoneBCP

    I neglected = to do a=20 point by point, sorry. So =96 that = follows:

     

    Cheers,

    Martin

     

    From: L.Liess@telekom.de=20 [mailto:L.Liess@telekom.de]
    Sent:     Friday, 7 August 2009 = 12:29=20 AM
    To: Dawson, = Martin;=20 R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

     

    Hi Martin,=20

     

    See = comments inline=20 [[LLi]].

     

     

    Laura

    From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of Dawson, Martin
    Sent:     Wednesday, August 05, = 2009 11:00=20 AM
    To: Jesske, = Roland;=20 ecrit@ietf.org
    Subject: Re:=20 [Ecrit] HUM on PhoneBCP

    Hi=20 Roland,

     

    I think = what you=92re=20 saying is that you don=92t think that Germany will go on to = implement=20 full ECRIT support but will peg development at an interim phase.=20
    [[LLi]]  We=20 don't know how the realtime application networks or EC will = look like=20 in 20 years. Roland's answer only applies to the next = 5 to 10=20 years. 

    [[MCD]]=20 The implementation of the LIS function is the most significant = aspect for=20 operators =96 and that needs to happen in short term scenarios in = any case.=20 The provision of LoST can be a national asset/service. The provision = of PSAP=20 URIs is an emergency service responsibility. Those are the key = requirements=20 =96 and that does provide a framework that will work into the next = 20 years=20 and beyond. 

     

    [Hannes] = This is=20 absolutely correct. Particularly for fixed networks there is = often no=20 LIS available and hence it requires additional cost. It is also = quite=20 unlikely that you will come up with a business model of selling=20 the fixed location of the subscriber for non-emergency services = purposes. There is, however, no reason for network operator to = ask for=20 financial support from the government (and we see this happening in = various=20 places throughout the world). In the long run it will be quite=20 difficult to get away  without having=20 a LIS provided by the access provider. Everyone understands that = transition=20 time needs some time. This is what other emergency services = organizations,=20 such as NENA and others,  are looking=20 into.

     

    So, there = is no reason=20 to be so negative towards this work.=20  

     

     

     That would = be=20 disappointing =96 not least because full ECRIT compliance would = ultimately=20 decrease the overhead associated with emergency service support for=20 operators as well as providing a more universal=20 service.

    [[LLi]]  This=20 may be true for "green field" ISPs and VSPs but not for = incumbent=20 carriers with existing infrastructure.  And universal = service is=20 not a requirement for us. Neither the German regulator = requires it nor=20 is it a busines case.   

    [[MCD]]=20 I think this is only true to the same extent that a pure Internet = green=20 field ISP only has to worry about Internet trunk connectivity and = doesn=92t=20 have to worry about PSTN circuit trunk connectivity. The latter=20 infrastructure is legacy and not particularly applicable to the = Internet=20 component of the service. Providing ECRIT emergency calling support = requires=20 the addition of a LIS, access to LoST (whoever hosts it), and a = route to the=20 PSAP URI(s). Both types of operator need to do that. Whatever = switched=20 circuit legacy emergency infrastructure already exists in the = established=20 operator needs to continue to exist to support the emergency calls = on that=20 access. 

     

    [Hannes] Regarding=20 additional overhead: This is a fairly broad claim and generic claim = that=20 will be hard to justify. Some notes that come to my mind when it = comes to=20 overhead and performance. We have visited the police PSAP=20 in Vienna/Austria and no location support was provided=20 for cellular calls. Guess how much delay that causes for = the=20 overall performance of emergency services. I also saw how = emergency=20 services organizations structure change as = they move towards=20 Next Generation emergency services and the consequence was a far = less=20 complex structure and I expect further = simplifications that will=20 be incorporated as we move = along. 

     

     

     

    Nevertheless, I=20 don=92t think that decision invalidates the BCP; =
    [[LLi]]  We=20 think it does, because some of the requirements are not = flexible=20 enough to cover the deployments within the next = years.  The BCP=20 should be more flexible:  

    • Allow = additional=20 location identifiers 

    [[MCD]]=20 Agreed =96 although that can be done by local-specific use of fields = in the=20 PIDF-LO based on jurisdictional convention and be appropriately = parsed by=20 LoST in that jurisdiction in a quite transparent fashion. A German = technical=20 advisory committee could make this recommendation within that = jurisdiction=20 without deference to the BCP and without impact to ECRIT-compliant=20 devices. 

     

    [Hannes] As part of=20 the efforts currently being done in EENA we hope to = provide a=20 recommendation of how to use civic addresses within each member = state,=20 similar to what has been excercised with http://www.ietf.org/id/draft-ietf-geopriv-civic-address-re= commendations-03.txt and=20 also being done by NENA for the=20 US. 

     

    If those=20 investigations will lead to the conclusion that new fields are = required=20 then we will ask for more or figure out how to accomplish the=20 functionality. 

     

    • Allow = AN operated=20 LOST

    [[MCD]]=20 I don=92t think the BCP excludes the possibility of the access = network hosting=20 LoST. It shouldn=92t =96 since this is a jurisdictional decision. As = long as the=20 LoST service can be discovered/used when attached to the access, it=20 shouldn=92t matter where it is hosted. 

     

    [Hannes] = As Martin said=20 it is possible for AN to operator a caching LoST = server (it=20 will most likely not be an authoritative LoST server, I = believe). There=20 are different deployment models and the protocol is = flexible with=20 this regard. Phone BCP cannot mandate a specific deployment = approach as=20 we already know that there will be different stories=20 in different parts of the world.=20  

    • Provide a=20 way to enable LOST-query based on national or=20 domain-specific location identifier. One posiblility is = to allow=20 the LIS to query the LOST , but there are also = other=20 alternatives.

    [[MCD]]=20 I was in favour of the LIS proxying the LoST request =96 since they = both share=20 a =93locality=94 it simplifies the whole discovery plot. However, = that didn=92t=20 take hold in the debate so we have what we have. Given that - a LIS = still=20 need only provide the national level location (i.e. DE) in the = PIDF-LO if=20 that=92s all that=92s required to make a successful LoST query. The = rest can be=20 done using LbyR =96 with the LIS also providing the reference along = with the=20 coarse location. Doesn=92t that satisfy the requirement? 

     

    [Hannes] = We indeed=20 discussed this aspect and the conclusion was to not proxy = LoST in=20 HELD. Reducing the number of options reduces = the implementation=20 complexity and lowers the cost for=20 implementation. 

     

    The fact = that we do=20 not have support for this functionality specified and=20 not referenced in PhoneBCP does not mean that it will not be = proposed=20 in the future and might find excitement.=20  

    • Allow and describe=20 also network-centric, not only ED-centric = architectures. If=20 I  remember correctly, John Medland from BT also = recomended to=20 use a more network- centric architecture, at least for the next=20 years.

    [[MCD]]=20 I don=92t really understand this =93X-centric=94 argument. Even = traditional=20 cellular architectures require a combination of end device and = network=20 capabilities. Maybe if you are being specific you mean; there should = be no=20 ECRIT-specific requirements on the end device (though I=92m not sure = why ECRIT=20 should have this rule when other architectures don=92t). You=92re = right John M=20 did propose such an approach. Not to put words in his mouth, but = this was in=20 the context of an interim architecture =96 per my comments below on = the=20 Canada and=20 UK interim approaches. = It works=20 in the limited scope of devices having to proxy calls through = =93national=94=20 VoIP carriers =96 it doesn=92t meet the long term vision of ECRIT. = An interim=20 architecture, by definition, is not the end-game architecture. ECRIT = only=20 seeks to define the end-game; there are already interim = architectures to=20 choose from =96 which was my point about suggesting it might be = better to=20 baseline off i2 for the time being rather than trying to shoehorn = interim=20 constraints into ECRIT.

     

    [Hannes]=20 Martin captured it quite nicely. I have in meetings also stated that = it=20 would be good for this group to also describe and discuss = intermediate=20 deployment architecture. We got blocked with the completion of = PhoneBCP and=20 Framework but we might still look into some of these aspects in the = future.=20 We also have to consider that NENA has been working on a transition=20 architecture, namely NENA i2/i2.5 as mentioned (which also uses many = building blocks from ECRIT or at least semantically similar = mechanisms).=20 Since many of these transition architectures are very much focused = on=20 national systems it is likely that we might find difficulties to = generalize=20 them in a way that it still remains useful. Since there are many = legacy=20 components in the game the IETF might not be the right place todo = this type=20 of overall architecture work.

     

    Please also note that while we see = countries looking at=20 these transition architectures, particularly when they have to deal = with=20 legacy PSAPs not supporting IP, we also see a large number of = countries=20 switching to a next generation architecture from an emergency = services=20 network point of view since

    a) they have to update their PSAPs anyway = (because new=20 signaling protocols are being added) and only the audio part remains = unchanged.

    b) they get many benefits and cost reducts = from moving=20 to IP.

     

    I think = it just=20 means that the German regulator and technical advisory committees = would=20 point out the subset aspects of compliance that would be applicable = to that=20 jurisdiction.  
    [[LLi]] =20 Again, the draft is not flexible enough for it.  If the = BCP=20 contains requirements which are not realistic, people will just = discard=20 the BCP and implement proprietary stuff. My expectation = from a=20 standard body is to define protocols and architecture which = people are=20 willing to implement in their network or products , not only in the=20 lab.

    [[MCD]]=20 What I mean is that compliance isn=92t compulsory. It=92s OK to say = =93we have=20 decided to deviate from the specification in this=20 way=94.

     

    [Hannes]=20 From what I hear from the regulator is that you are taking the first = steps=20 already to move into a direction that goes into an architecture that = distributes PSAP boundaries to make routing of emergency calls by = VoIP=20 providers possible. With a few minor enhancements you will quickly = end up=20 with an architecture utilized, for example, in Sweden or as = envisioned=20 by Lithuania. 

     

    [[LLi]] =20

    We are = not against=20 the draft in principle. ECRIT provides  us with = very=20 valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to=20 invest without a business case will not help the=20 draft in the end, also if it becomes a BCP.  It would = make=20 sense to make it more flexible so people are willing to adopt=20 it.    

    [[MCD]]=20 Lots of the elements you mention exist outside of the BCP =96 LbyR, = HELD,=20 identity extensions=85 they aren=92t defined by the BCP and can be = used in any=20 other context. The BCP has a very specific goal of defining a way = that=20 emergency calls can be made by any Internet connected device/proxy = anywhere=20 that follows the specification; it doesn=92t seek to be more than = that =96 which=20 I think is what you=92re looking for. As I say, check out the = interim=20 recommendations by the CRTC in Canada and NICC in the = UK.

     

    [Hannes] We=20 understand that the business model, I call it funding = model, for=20 emergency services is complicated. There are places in the world = where=20 interesting funding models are being found. I believe that Phone BCP = does=20 not require a lot of additional investments from access network = providers=20 particularly if they do not provide voice/application servers. We=20 additionally put the burden for these operators as low as possible. = I=20 believe that sharing of responsibilities in the IETF ECRIT = architecture is=20 much better than it can found in any of the other architectures I = have seen.=20 We could discuss these aspect in more detail if there is interest.=20

     

     

     Actually,=20 based on your description below, the NENA i2 architecture would = probably be=20 a more straightforward baseline for analysis =96 as has been done in = the=20 UK and = Canada. Of course, = it=92s generally=20 recognized as only an interim step, even in those=20 jurisdictions.

    Other = comments=20 below.

     

    [Hannes] The NENA i2 architecture (or = better a=20 modified version) would be more interesting for a comparison. Please = note=20 that there is an ongoing effort to update NENA i2 (to i2.5) by = updating some=20 of the work that is being done elsewhere (such as in the IETF) so = that you=20 have up-to-date protocols. You might find a number of concepts in = there that=20 are familiar. From a network operator point of view the only = difference is=20 the ability to deal with legacy end points that do not have obtained = location. This is, however, also included in the PhoneBCP even = though it is=20 treated as a failure case there. An architecture that has to deal = with=20 legacy end points also has to deal with a number of weaknesses. = Looking=20 forward to have end points that may not have obtained location but a = reference to location to ensure robut location lookup might=20 not put a too huge burden on the involved parties with a = lot=20 of increased robustness of the overal system. These software = updates to=20 obtain these LbyRs could be judged impossible by some but then = I would=20 also like to know how software bugs are being dealt with = without doing=20 any software updates.  

     

    Ciao

    Hannes

     

    Cheers,

    Martin

     

    From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of R.Jesske@telekom.de
    Sent:     Wednesday, 5 August = 2009 6:19=20 PM
    To:=20 ecrit@ietf.org
    Subject: Re:=20 [Ecrit] HUM on PhoneBCP

     

     

    Dear all, =
    We would = like the document=20 to become a BCP as soon as possible so the group can move on with = other=20 documents related to emergency calling based on = location-by-reference and=20 ED=92s IP-address.

    [[MCD]]=20 I think you might mean =93identity extensions=94 rather than=20 location-by-reference because LbyR still requires the ED to obtain = the=20 reference =96 e.g. by HELD.
    [[LLi]] We=20 use both, the IP-address as UE identity and LbyR. The SIP-proxy uses = the=20 IP-address to query the LIS using HTTP (it's not HELD but SOAP = over=20 HTTP, but anyway similar). The LIS responds with a numeric = string=20 associated to the caller location, in principle a LbyR and with the=20 PSAP number. The proxy inserts the LbyR into the = SIP-message=20 (as P-Asserted-ID because the PSAPs are in PSTN) and routes = the message=20 to the PSAP.  It's a low cost=20 solution. 

    But we can not HUM for the = current=20 form of the document.

    Back to the document: Some=20 requirements are far form being realistic, at least in Germany, some are not = realistic=20 at all. Implementing these requirements cost a carrier a lot of = money and=20 there is no ROI for it.

    Just a few examples:=20

    =B7       Requiring either=20 geo or civic location does not provide carriers with enough = flexibility to=20 reuse their existing mechanisms and location databases. Routing of = emergency=20 calls is currently done in Germany based on phone = area code=20 not on geo or civic location, at least for the fixed network. For = mobile=20 networks the cell-id is used in common. This is regulated by the = german=20 regulator.

    [[MCD]]=20 How many unique PSAP routes are required in Germany? The = US has lots (6000 plus) and = Australia has two (and = they are=20 redundant so it doesn=92t matter which one). Presumably geographic=20 information, for PSAP catchment areas, is the basis for determining = which=20 area codes are relevant to begin with? After all, an area code is = not=20 intrinsically geographic; it=92s a network routing value. If so, = then some=20 geographic discriminator is already in play in terms of constructing = the=20 area code based routing data (something like zip codes perhaps?) =96 = and in=20 that case, it should be straightforward to by-pass the area code = step in the=20 construction of routing that goes the correct PSAP URI.=20
    [[LLi]] Currently, fixed=20 networks carriers in Germany route = the ECs based=20 only on the caller's area code. Sometime in the past, the=20 carriers, the regulator and the PSAPs operators (police, the Red = Cross)=20 agreed to do so. This may change in the future, but it will = take a=20 quite long=20 = time.      

     With=20 nomadic VoIP devices (and it=92s no good being in denial about this = being the=20 norm in the future) area code is no more reliable than it is for=20 conventional mobile phones. And, presumably, area code is not used = for=20 conventional cellular emergency call=20 routing?
    [[LLi]] =20 As far as I know, mobile networks use the Cell-ID, not the area = code, and=20 have a different table than the fixed network operators. They = are not=20 going to change this.  As to the nomadic SIP-users...if we like = it or=20 not, very few of our customers use our SIP = service=20 nomadic, let alone call EC from their=20 = laptop.        =  

    1           =   =20 LOST=20 as a national, let alone as a global directory is not going to be=20 implemented. The regulator will provide in the web a static table = which=20 contains the PSAPs and the area for which they are responsible (one = or more=20 area codes). Every carrier has to implement its own routing database = for=20 emergency calls.

    [[MCD]]=20 Whatever the carriers implement (and they have to implement = something)=20 could just as readily be done using LoST. Then visiting devices, = with no=20 association with any local VoIP proxy server would still be able = to=20 determine a route to the correct PSAP. Alternatively, as long as = the=20 regulator is maintaining a web service with the routing = information, why=20 not make that directly accessible using LoST and save the = operators the=20 cost of duplicating the service at=20 all?
    [[LLi]] =20 There is a big difference between maintaining a web page with = a table=20 which operator can print and implement in their darabases=20 and operating a database which is queried for = every emergency=20 call in Germany, must have an availablity of=20 99,99...% ,  is secure enough...you know. The=20 regulator will not do = this.


    2      =20 We have no intention to rely on end devices for location = information=20 because:
    =B7       ED = provided=20 location info is not trusted

    [[MCD]]=20 Location by reference mitigates this trust issue. The emergency = network can=20 (automatically and before human resources are engaged) assess the = source of=20 the reference, and the validity of the location by dereference, = without=20 having to trust location provided directly from the ED. There are = more=20 sophisticated approaches to trustability even using LbyV =96 based = on digital=20 signatures across appropriate attributes. This WG and Geopriv = haven=92t really=20 got to grips with that=85 yet.
    [[LLi]]  We=20 build the SIP-network and EC now. ED-provided location is=20 needed if EC must work for private and enterprise = networks=20 and VPNs.  We have no such regulatory = requirements.  And we=20 don't know of any verdor of DSL-EDs which provides = today SIP=20 with LbyR and is as cheap as the devices without it. If = you do,=20 please let me know. 

    The=20 regulator ask us to guarantee that EC works. What if a = customer=20 dials 112 and his end device does not send = the location? So I=20 have to implement both solutions, with and without ED provided = location,=20 anyway.  
    1       There=20 are already a lot of existing EDs in usage which don=92t send=20 location.   

    [[MCD]]=20 Quite right. ECRIT doesn=92t overly concern itself with that interim = situation. The UK and Canadian = definitions for=20 an interim solution (limiting service to in-country VoIP proxy = operators)=20 both assume third-party query via identity-extension to allow the = proxy or=20 the VPC to make the query to the LIS. This isn=92t extensible to = universal=20 emergency service access by all visiting devices but it does put the = necessary LIS functionality in place as a very good starting=20 point.  It would be a pity if Germany were to cease = the=20 evolution there as it would not fulfil the real promise of the = Internet and=20 the ECRIT model.
    [[LLi]] =20 I wonder who will drive and pay for upgrading the = interim=20 solutions.  Unfortunatelly, it's all about=20 money...

     Think=20 about it; all the complexity of putting location determination=20 infrastructure in place for the purposes of dispatch is done =96 and = then the=20 next, simpler step, of using that to support the routing procedure = isn=92t=20 taken=85 that would be a = waste.

    [[LLi]] =20 Do you think this is an argument for a product manager? = They need a=20 business case. 

     

     

      We=20 don=92t intend to require our ED-vendors to provide location because = it is=20 useless to us.  

    We could agree with the = document with=20 following changes: =

      • Other location = identifiers then=20 geo or civil are allowed. It must be possibe that the data = foermat is=20 flexible due to different requirements from regulators over the = whole=20 world. (e.G Germany area codes = for fixed-=20 and Cell-Id for moile- providers)=20
      • The MUST for the end = devices to=20 support location information, DHCP location options and HELD = shall be=20 removed
      • It must be possible for = the=20 VoIP-provider=92s proxy to use a LOST (or an ESRP) provided by = the AN or=20 by other local provider on behalf of the AN. =20

     

     There is no value in = Hum-ing=20 documents which one is not going to implement and does not fit into=20 regulated schemes like in Germany. Currently, = neither the=20 IETF- nor the 3GPP-architecture for emergency calling covers our = real needs=20 for the next 2 to 5 years and in the end everybody still has its own = proprietary implementation.    =

    Best = regards

    Roland=20

     

    Deutsche = Telekom=20 Netzproduktion GmbH
    Zentrum Technik = Einf=FChrung
    Roland = Jesske
    Gateways, Protokolle,=20 Konvergenz, TE32-1
    Heinrich-Hertz-Str. = 3-7, 64295=20 Darmstadt,
    Postfach,=20 64307 Darmstadt (Postanschrift)
    +496151 628 2766=20 (Tel)
    +491718618445=20 (Mobile)
    E-Mail: = r.jesske@telekom.de=20
    http://www.telekom.de=20

     

    Registerrechtliche=20 Unternehmensangaben:
    Deutsche Telekom = Netzproduktion=20 (DT NP) GmbH
    Aufsichtsrat: Timotheus H=F6ttges=20 (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 Al    bert Matheis, Klaus Peren
    Handelsregister: = Amtsgericht=20 Bonn HRB 14190
    Sitz der Gesellschaft: Bonn
    USt-IdNr.: DE=20 814645262

     

     


    --------------------------------------------------------------= ----------------------------------
    This message is for&= nbsp;the designated recipient only and may
    co= ntain privileged, proprietary, or otherwise priv= ate information.  
    If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
    this email is proh= ibited.
    --------------------------------------------------------------= ----------------------------------
    [mf2]

    <= /TD>

     



    =

    -----------------------------------------------------------------= -------------------------------
    This message is for&nbs= p;the designated recipient only and may
    conta= in privileged, proprietary, or otherwise private=  information.  
    If you have received&nbs= p;it in error, please notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibi= ted.
    -----------------------------------------------------------------= -------------------------------
    [mf2]
    ------_=_NextPart_001_01CA16B0.0B4141C1-- From br@brianrosen.net Thu Aug 6 09:21:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C271C3A69C7 for ; Thu, 6 Aug 2009 09:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDCT8OWDDMcO for ; Thu, 6 Aug 2009 09:21:03 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id DA47E3A6AA3 for ; Thu, 6 Aug 2009 09:21:02 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MZ5hz-0000mT-Rr; Thu, 06 Aug 2009 11:20:53 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , , , References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: Date: Thu, 6 Aug 2009 12:20:55 -0400 Message-ID: <02d601ca16b1$e2464940$a6d2dbc0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D7_01CA1690.5B34A940" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQAANJGZA= 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: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 16:21:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D7_01CA1690.5B34A940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is indeed my problem with this discussion. =20 Current emergency call systems are nation-specific. The goal, of nearly everyone, is to make sure that devices sourced from anywhere, and = visitors with devices from anywhere, are able to make emergency calls anywhere. =20 =20 In order for that to happen, some things likely have to change. =20 I understand the argument for more network centric solutions. The underlying standards permit, and =96phonebcp discusses, for example, = proxy query of the LoST server. Proxy OBO for location is, as you know, on = the IETF agenda for completion in geopriv (HELD Identity). =20 But phone vendors need to have ONE solution that works everywhere. It = seems to me that the way to do that is deploy a simple LoST server everywhere, = and follow phonebcp. That would always work. The cost of a LoST server for Germany would be measured in tens of thousands of euros (you need 5-10 copies of a server with open source code, and a very small database that doesn=92t change very often). That is a very inexpensive way to become globally compliant with emergency call standards. If your networks = don=92t deploy DHCP/HELD, and the regulator is happy to force relationships = between access networks and calling networks, so that OBO becomes viable: fine. Devices that are =96phonebcp compliant will work. And, when those = devices visit North America, they will also work. =20 I think it is extremely short sighted to ignore nomadic use, but if that = is what you want to do, that is your regulator=92s choice. However, the = phone MUST be capable of doing the right thing if it were to be operated in = North America. Even then, if it was, say, a mobile, and the 3GPP guys simply = had the E-CSCF do OBO with SUPL/MLP and the LoST query, then a current 3GPP handset would be okay. It=92s not enough for North America (where I = believe IM from AOL on that handset also has to work), but it=92s a start. =20 That does not change phonebcp. =20 Brian =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Dawson, Martin Sent: Thursday, August 06, 2009 10:45 AM To: L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP =20 Hi Laura, =20 I regard it as a goal of ECRIT =96 as derived from the goals of the IETF generally =96 to define a structure that will allow an Internet capable = device to connect to a network anywhere in the world and be able to make = emergency calls. Just as FTP, email protocols, SIP and etc. all work regardless of which network the devices attach to. I don=92t understand how the kind = of variations that you are requesting be added to the specification will = allow that to occur. =20 The position appears to be that the German regulator doesn=92t require anything =96 and the operators will not be proactive in following a specification if it doesn=92t include what already exists. In that = context, I don=92t understand why there is a need for the BCP at all. There may be = no need to endorse it but, similarly, there should be no need to object to = it =96 since the operators will only put in place their preferred version of = the service in any case. That=92s OK=85 insofar as it just means German = networks aren=92t ECRIT compatible =96 =93compatibility=94 isn=92t a worthy goal = in and of itself; it has to actually mean any device can work anywhere. =20 Cheers, Martin =20 _____ =20 From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, =20 I think what you=92re saying is that you don=92t think that Germany will = go on to implement full ECRIT support but will peg development at an interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC will = look like in 20 years. Roland's answer only applies to the next 5 to 10 = years.=20 =20 That would be disappointing =96 not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service. [[LLi]] This may be true for "green field" ISPs and VSPs but not for incumbent carriers with existing infrastructure. And universal service = is not a requirement for us. Neither the German regulator requires it nor = is it a busines case. =20 =20 Nevertheless, I don=92t think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP should = be more flexible: =20 * Allow additional location identifiers=20 * Allow AN operated LOST * Provide a way to enable LOST-query based on national or domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives.=20 * Allow and describe also network-centric, not only ED-centric architectures. If I remember correctly, John Medland from BT also recomended to use a more network- centric architecture, at least for the next years.=20 =20 I think it just means that the German regulator and technical advisory committees would point out the subset aspects of compliance that would = be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard body = is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with very valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a business case = will not help the draft in the end, also if it becomes a BCP. It would make sense to make it more flexible so people are willing to adopt it. =20 =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis =96 as has been = done in the UK and Canada. Of course, it=92s generally recognized as only an interim step, even in those jurisdictions. Other comments below. =20 Cheers, Martin =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling based on location-by-reference and ED=92s IP-address.=20 [[MCD]] I think you might mean =93identity extensions=94 rather than location-by-reference because LbyR still requires the ED to obtain the reference =96 e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD but SOAP = over HTTP, but anyway similar). The LIS responds with a numeric string = associated to the caller location, in principle a LbyR and with the PSAP number. = The proxy inserts the LbyR into the SIP-message (as P-Asserted-ID because = the PSAPs are in PSTN) and routes the message to the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being realistic, at least in Germany, some are not realistic at all. Implementing these requirements cost a carrier a lot of money and there is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and location databases. Routing of emergency calls is currently done in Germany based = on phone area code not on geo or civic location, at least for the fixed network. For mobile networks the cell-id is used in common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US has = lots (6000 plus) and Australia has two (and they are redundant so it = doesn=92t matter which one). Presumably geographic information, for PSAP catchment areas, is the basis for determining which area codes are relevant to = begin with? After all, an area code is not intrinsically geographic; it=92s a network routing value. If so, then some geographic discriminator is = already in play in terms of constructing the area code based routing data = (something like zip codes perhaps?) =96 and in that case, it should be = straightforward to by-pass the area code step in the construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the carriers, the regulator and the PSAPs operators (police, the Red Cross) agreed to do = so. This may change in the future, but it will take a quite long time. =20 With nomadic VoIP devices (and it=92s no good being in denial about = this being the norm in the future) area code is no more reliable than it is = for conventional mobile phones. And, presumably, area code is not used for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the area code, and have a different table than the fixed network operators. They = are not going to change this. As to the nomadic SIP-users...if we like it = or not, very few of our customers use our SIP service nomadic, let alone = call EC from their laptop. =20 1 LOST as a national, let alone as a global directory is = not going to be implemented. The regulator will provide in the web a static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would still be able = to determine a route to the correct PSAP. Alternatively, as long as the regulator is maintaining a web service with the routing information, why = not make that directly accessible using LoST and save the operators the cost = of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page with a table which operator can print and implement in their darabases and operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you know. = The regulator will not do this. 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The emergency network can (automatically and before human resources are engaged) = assess the source of the reference, and the validity of the location by dereference, without having to trust location provided directly from the = ED. There are more sophisticated approaches to trustability even using LbyV = =96 based on digital signatures across appropriate attributes. This WG and Geopriv haven=92t really got to grips with that=85 yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is = needed if EC must work for private and enterprise networks and VPNs. We have = no such regulatory requirements. And we don't know of any verdor of = DSL-EDs which provides today SIP with LbyR and is as cheap as the devices = without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. =20 1 There are already a lot of existing EDs in usage which don=92t = send location. =20 [[MCD]] Quite right. ECRIT doesn=92t overly concern itself with that = interim situation. The UK and Canadian definitions for an interim solution = (limiting service to in-country VoIP proxy operators) both assume third-party = query via identity-extension to allow the proxy or the VPC to make the query = to the LIS. This isn=92t extensible to universal emergency service access = by all visiting devices but it does put the necessary LIS functionality in = place as a very good starting point. It would be a pity if Germany were to cease = the evolution there as it would not fulfil the real promise of the Internet = and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination infrastructure in place for the purposes of dispatch is done =96 and = then the next, simpler step, of using that to support the routing procedure = isn=92t taken=85 that would be a waste. [[LLi]] Do you think this is an argument for a product manager? They = need a business case. =20 =20 =20 We don=92t intend to require our ED-vendors to provide location = because it is useless to us. =20 We could agree with the document with following changes:=20 * Other location identifiers then geo or civil are allowed. It must be possibe that the data foermat is flexible due to different requirements = from regulators over the whole world. (e.G Germany area codes for fixed- and Cell-Id for moile- providers)=20 * The MUST for the end devices to support location information, DHCP location options and HELD shall be removed=20 * It must be possible for the VoIP-provider=92s proxy to use a LOST (or an ESRP) provided by the AN or by other local provider on behalf of the = AN. =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. Currently, = neither the IETF- nor the 3GPP-architecture for emergency calling covers our = real needs for the next 2 to 5 years and in the end everybody still has its = own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de=20 http://www.telekom.de=20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 =20 -------------------------------------------------------------------------= --- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= --- -------------------- [mf2] =20 =20 -------------------------------------------------------------------------= --- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= --- -------------------- [mf2] =20 ------=_NextPart_000_02D7_01CA1690.5B34A940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP

    This is indeed my problem with this = discussion.

     

    Current emergency call systems are nation-specific.=A0 = The goal, of nearly everyone, is to make sure that devices sourced from anywhere, = and visitors with devices from anywhere, are able to make emergency calls anywhere.=A0

     

    In order for that to happen, some things likely have to = change.

     

    I understand the argument for more network centric = solutions.=A0=A0 The underlying standards permit, and –phonebcp discusses, for = example, proxy query of the LoST server.=A0 Proxy OBO for location is, as you know, on = the IETF agenda for completion in geopriv (HELD Identity).

     

    But phone vendors need to have ONE solution that works everywhere.=A0 It seems to me that the way to do that is deploy a simple = LoST server everywhere, and follow phonebcp.=A0 That would always work.=A0 = The cost of a LoST server for Germany would be measured in tens of thousands of euros = (you need 5-10 copies of a server with open source code, and a very small = database that doesn’t change very often).=A0 That is a very inexpensive way = to become globally compliant with emergency call standards.=A0 If your = networks don’t deploy DHCP/HELD, and the regulator is happy to force relationships = between access networks and calling networks, so that OBO becomes viable: = fine.=A0 Devices that are –phonebcp compliant will work.=A0 And, when those = devices visit North America, they will also work.

     

    I think it is extremely short sighted to ignore nomadic = use, but if that is what you want to do, that is your regulator’s = choice.=A0 However, the phone MUST be capable of=A0 doing the right thing if it = were to be operated in North America.=A0 Even then, if it was, say, a mobile, and = the 3GPP guys simply had the E-CSCF do OBO with SUPL/MLP and the LoST query, then a = current 3GPP handset would be okay.=A0 It’s not enough for North America = (where I believe IM from AOL on that handset also has to work), but it’s a = start.

     

    That does not change phonebcp.

     

    Brian

     

    From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Dawson, Martin
    Sent: Thursday, August 06, 2009 10:45 AM
    To: L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf.org
    Cc: Reinhard.Lauster@t-mobile.at
    Subject: Re: [Ecrit] HUM on PhoneBCP

     

    Hi Laura,

     

    I regard it as a goal of ECRIT – as derived from the = goals of the IETF generally – to define a structure that will allow an = Internet capable device to connect to a network anywhere in the world and be able = to make emergency calls. Just as FTP, email protocols, SIP and etc. all = work regardless of which network the devices attach to. I don’t = understand how the kind of variations that you are requesting be added to the = specification will allow that to occur.

     

    The position appears to be that the German regulator = doesn’t require anything – and the operators will not be proactive in = following a specification if it doesn’t include what already exists. In that = context, I don’t understand why there is a need for the BCP at all. There = may be no need to endorse it but, similarly, there should be no need to object = to it – since the operators will only put in place their preferred = version of the service in any case. That’s OK… insofar as it just means = German networks aren’t ECRIT compatible – = “compatibility” isn’t a worthy goal in and of itself; it has to actually mean any = device can work anywhere.

     

    Cheers,

    Martin

     

    From:= = L.Liess@telekom.de [mailto:L.Liess@telekom.de]
    Sent: Friday, 7 August 2009 12:29 AM
    To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org
    Cc: Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on PhoneBCP

     

    Hi Martin,

     

    See comments inline [[LLi]].

     

     

    Laura

    From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Dawson, Martin
    Sent: Wednesday, August 05, 2009 11:00 AM
    To: Jesske, Roland; ecrit@ietf.org
    Subject: Re: [Ecrit] HUM on PhoneBCP

    Hi Roland,

     

    I think what you’re saying is that you don’t = think that Germany will go on to implement full ECRIT support but will peg = development at an interim phase.
    [[LLi]]  We don't know how the realtime = application networks or EC will look like in 20 years. Roland's = answer only applies to the next 5 to 10 years. 

     

     Tha= t would be disappointing – not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service.

    [[LLi]]  This may be true for "green field" = ISPs and VSPs but not for incumbent carriers with existing infrastructure.  And universal service is not a requirement = for us. Neither the German regulator requires it nor is it a busines case.   

     

    Nevertheless, I don’t think that decision invalidates = the BCP;
    [[LLi]]  We think it does, because some of = the requirements are not flexible enough to cover the deployments within the = next years.  The BCP should be more = flexible:  

    • Allow additional = location identifiers 
    • Allow AN operated = LOST
    • Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS to = query the LOST , but there are also other = alternatives. 
    • Allow and describe= also network-centric, not only ED-centric = architectures. If I  remember correctly, John Medland from BT also = recomended to use a more network- centric architecture, at least for the next = years.

     

    I think it just means that the German regulator and = technical advisory committees would point out the subset aspects of compliance = that would be applicable to that jurisdiction.  <= span lang=3DEN-AU = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'> [[LLi]]  Again, the draft is not flexible enough for it.  If the BCP contains requirements which are not = realistic, people will just discard the BCP and implement proprietary = stuff. My expectation from a standard body is to define protocols and = architecture which people are willing to implement in their network or products , not = only in the lab.

     

    [[LLi]] 

    We are not against the draft in principle. ECRIT = provides&= nbsp; us with very valuable specifications as LbyR, HELD, identity extensions. But targeting an architecture which requires = everbody to invest without a business case will not help the = draft in the end, also if it becomes a BCP.  It would make sense to = make it more flexible so people are willing to adopt = it.    

     

     Actually, based on your description below, the NENA i2 architecture would probably be a more straightforward baseline for = analysis – as has been done in the UK and Canada. Of course, it’s = generally recognized as only an interim step, even in those = jurisdictions.

    Other comments below.

     

    Cheers,

    Martin

     

    From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = R.Jesske@telekom.de
    Sent: Wednesday, 5 August 2009 6:19 PM
    To: ecrit@ietf.org
    Subject: Re: [Ecrit] HUM on PhoneBCP

     

     

    Dear all,
    We would like the = document to become a BCP as soon as possible so the group can move on with other = documents related to emergency calling based on location-by-reference and = ED’s IP-address.

    [[MCD]] I think you might mean “identity = extensions” rather than location-by-reference because LbyR still requires the ED to = obtain the reference – e.g. by HELD.
    [[LLi]] We use both, the IP-address as UE identity and = LbyR. The SIP-proxy uses the IP-address to query the LIS using HTTP (it's not = HELD but SOAP over HTTP, but anyway similar). The LIS responds = with a numeric string associated to the caller location, in principle a LbyR = and with the PSAP number. The proxy inserts the LbyR into the = SIP-message (as P-Asserted-ID because the PSAPs are in PSTN) and routes = the message to the PSAP.  It's a low cost solution. 

    But we can not HUM for the = current form of the document.

    Back to the document: Some = requirements are far form being realistic, at least in Germany, some are not = realistic at all. Implementing these requirements cost a carrier a lot of money and = there is no ROI for it.

    Just a few examples: =

    =B7       Requiring either geo or civic = location does not provide carriers with enough flexibility to reuse their = existing mechanisms and location databases. Routing of emergency calls is = currently done in Germany based on phone area code not on geo or civic location, at = least for the fixed network. For mobile networks the cell-id is used in common. = This is regulated by the german regulator.

    [[MCD]] How many unique PSAP routes are required in Germany? = The US has lots (6000 plus) and Australia has two (and they are redundant so it doesn’t matter which one). Presumably geographic information, for = PSAP catchment areas, is the basis for determining which area codes are = relevant to begin with? After all, an area code is not intrinsically geographic; = it’s a network routing value. If so, then some geographic discriminator is = already in play in terms of constructing the area code based routing data = (something like zip codes perhaps?) – and in that case, it should be = straightforward to by-pass the area code step in the construction of routing that goes the = correct PSAP URI.
    [[LLi]] Currently, fixed networks carriers in Germany route the ECs based only on the caller's area = code. Sometime in the past, the carriers, the regulator and the PSAPs operators = (police, the Red Cross) agreed to do so. This may change in the future, but = it will take a quite long = time.      

     With nomadic VoIP devices (and it’s no good = being in denial about this being the norm in the future) area code is no more = reliable than it is for conventional mobile phones. And, presumably, area code is = not used for conventional cellular emergency call routing?
    [[LLi]]  As far as I know, mobile networks use the = Cell-ID, not the area code, and have a different table than the fixed network operators. They are not going to change this.  As to the = nomadic SIP-users...if we like it or not, very few of our customers use our SIP service nomadic, let alone call EC = from their = laptop.        = &n= bsp;

    1      = ;        LOST as a national, let = alone as a global directory is not going to be implemented. The regulator will = provide in the web a static table which contains the PSAPs and the area for which = they are responsible (one or more area codes). Every carrier has to implement its = own routing database for emergency calls.

    [[MCD]] Whatever the carriers implement (and they have to = implement something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would still be able = to determine a route to the correct PSAP. Alternatively, as long as the = regulator is maintaining a web service with the routing information, why not make = that directly accessible using LoST and save the operators the cost of = duplicating the service at all?
    [[LLi]]  There is a big difference between maintaining = a web page with a table which operator can print and implement in their darabases and operating a database which is queried for every emergency call in Germany, must have an availablity of 99,99...% ,  is secure enough...you know. The regulator will not do this.


    2       We have no intention to rely on = end devices for location information because:     =B7       ED provided location info is = not trusted

    [[MCD]] Location by reference mitigates this trust issue. = The emergency network can (automatically and before human resources are = engaged) assess the source of the reference, and the validity of the location by dereference, without having to trust location provided directly from the = ED. There are more sophisticated approaches to trustability even using LbyV = – based on digital signatures across appropriate attributes. This WG and = Geopriv haven’t really got to grips with that… yet.
    [[LLi]]  We build the SIP-network and EC now. = ED-provided location is needed if EC must work for private and = enterprise networks and VPNs.  We have no such regulatory requirements.  And we don't know of any verdor of = DSL-EDs which provides today SIP with LbyR and is as cheap as the devices without it. If you do, please let me = know. 

    The regulator ask us to guarantee that EC works. What if a customer dials 112 and his end device does not send = the location? So I have to implement both solutions, with and without ED provided = location, anyway.  
    1       There are already a lot of existing EDs in usage which don’t send location.   

    [[MCD]] Quite right. ECRIT doesn’t overly concern = itself with that interim situation. The UK and Canadian definitions for an interim = solution (limiting service to in-country VoIP proxy operators) both assume = third-party query via identity-extension to allow the proxy or the VPC to make the = query to the LIS. This isn’t extensible to universal emergency service = access by all visiting devices but it does put the necessary LIS functionality in = place as a very good starting point.  It would be a pity if Germany = were to cease the evolution there as it would not fulfil the real promise of the Internet and the ECRIT model.
    [[LLi]]  I wonder who will drive and pay for upgrading the interim = solutions.  Unfortunatelly, it's all about money...

     Think about it; all the complexity of putting location determination infrastructure in place for the purposes of dispatch is = done – and then the next, simpler step, of using that to support the = routing procedure isn’t taken… that would be a waste.

    [[LLi]]  Do you think this is an argument for a product manager? They need a business case. 

     

     

      We don’t intend to require our ED-vendors to provide location because = it is useless to us.  

    We could agree with the = document with following changes:

      • Other location identifiers then geo or civil are allowed. It must be = possibe that the data foermat is flexible due to different requirements = from regulators over the whole world. (e.G Germany area codes for = fixed- and Cell-Id for moile- providers) =
      • The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed
      • It must be possible for the VoIP-provider’s proxy to use a LOST = (or an ESRP) provided by the AN or by other local provider on behalf of = the AN. 

     

     There is no value in = Hum-ing documents which one is not going to implement and does not fit into = regulated schemes like in Germany. Currently, neither the IETF- nor the = 3GPP-architecture for emergency calling covers our real needs for the next 2 to 5 years = and in the end everybody still has its own proprietary = implementation.   

    Best regards

    Roland

     

    Deutsche Telekom Netzproduktion GmbH
    Zentrum Technik Einf=FChrung
    Roland Jesske
    Gateways, Protokolle, Konvergenz, TE32-1
    Heinrich-Hert= z-Str. 3-7, 64295 Darmstadt,
    Postfach, 64307 Darmstadt (Postanschrift)
    +496151 628 2766 (Tel)
    +491718618445= (Mobile)
    E-Mail: r= .jesske@telekom.de
    http://www.telekom.de =

     

    Registerrechtl= iche Unternehmensangaben:
    Deutsche Telekom Netzproduktion (DT NP) GmbH
    Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno = Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
    Handelsregister: Amtsgericht Bonn HRB 14190
    Sitz der Gesellschaft: Bonn
    USt-IdNr.: DE 814645262

     

     


    = -------------------------------------------------------------------------= -----------------------
    = This message is for the designated recipien= t only and may
    = contain privileged, proprietary, or otherwise pr= ivate information.  
    = If you have received it in error, plea= se notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibited.
    = -------------------------------------------------------------------------= -----------------------
    [mf2]

     

     


    = -------------------------------------------------------------------------= -----------------------
    = This message is for the designated recipien= t only and may
    = contain privileged, proprietary, or otherwise pr= ivate information.  
    = If you have received it in error, plea= se notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibited.
    = -------------------------------------------------------------------------= -----------------------
    [mf2]

     

    ------=_NextPart_000_02D7_01CA1690.5B34A940-- From root@core3.amsl.com Thu Aug 6 11:45:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DDA233A6C6E; Thu, 6 Aug 2009 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090806184501.DDA233A6C6E@core3.amsl.com> Date: Thu, 6 Aug 2009 11:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-06.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 18:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-06.txt Pages : 24 Date : 2009-08-06 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism can be used for bulk exchange of elements between two entities. As such, this document can also be used without the LoST protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-sync-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-06113317.I-D@ietf.org> --NextPart-- From john@johnlange.ca Thu Aug 6 11:45:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9ACF28C195 for ; Thu, 6 Aug 2009 11:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csELadVLN0g1 for ; Thu, 6 Aug 2009 11:45:01 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 5070228C16D for ; Thu, 6 Aug 2009 11:44:02 -0700 (PDT) Received: (qmail 1047 invoked from network); 6 Aug 2009 13:43:35 -0500 Received: from unknown (HELO ?192.168.4.127?) (192.168.4.127) by lh02.epicnet.ca with SMTP; 6 Aug 2009 13:43:35 -0500 From: John Lange To: ecrit@ietf.org In-Reply-To: References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 Aug 2009 13:42:50 -0500 Message-Id: <1249584170.5335.24.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 18:45:02 -0000 On Wed, 2009-08-05 at 03:59 -0500, Dawson, Martin wrote: > the NENA i2 architecture would probably be a more straightforward > baseline for analysis – as has been done in the UK and Canada. Of > course, it’s generally recognized as only an interim step, even in > those jurisdictions. Lest anyone get the wrong idea, NENAi2 has not been "done in Canada". Only a "Canadian i2" has been suggested (not approved or implemented) and for the most part it resembles NENAi2 only in that they both contain "i2" in the title. Canadian i2 has similar names for the functional elements and interfaces even though many of those elements are missing or operate completely differently than NENA i2. Most importantly, Canadian i2 is not compatible with phone-bcp or ecrit-framework nor would it be an interim stepping-stone to any "next-gen" solution for many reasons but not the least of which is the fact that it does not allow location aware devices. -- John Lange http://www.johnlange.ca From john@johnlange.ca Thu Aug 6 12:16:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BAE3A6E67 for ; Thu, 6 Aug 2009 12:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuA24exlWr1Q for ; Thu, 6 Aug 2009 12:16:43 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 7CAF63A6E66 for ; Thu, 6 Aug 2009 12:16:43 -0700 (PDT) Received: (qmail 9959 invoked from network); 6 Aug 2009 14:16:17 -0500 Received: from unknown (HELO ?192.168.4.127?) (192.168.4.127) by lh02.epicnet.ca with SMTP; 6 Aug 2009 14:16:17 -0500 From: John Lange To: ecrit@ietf.org In-Reply-To: <02d601ca16b1$e2464940$a6d2dbc0$@net> References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <02d601ca16b1$e2464940$a6d2dbc0$@net> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 Aug 2009 14:15:31 -0500 Message-Id: <1249586131.5335.57.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:16:44 -0000 On Thu, 2009-08-06 at 12:20 -0400, Brian Rosen wrote: > I understand the argument for more network centric solutions. The > underlying standards permit, and –phonebcp discusses, for example, > proxy query of the LoST server. Proxy OBO for location is, as you > know, on the IETF agenda for completion in geopriv (HELD Identity). > > > > But phone vendors need to have ONE solution that works everywhere. I was originally quite sceptical about bcp and framework (which you can read in my previous posts to this list) because: - it relies on DHCP to relay location to endpoints - relies on endpoints to be location aware - does not specify any mechanism for OBO All of these things mean it's very unlikely it will be implemented in any regulatory jurisdiction any time soon. However, I'm now in favour of the document(s) for the reason that I've finally seen Brian put into words: > If your networks don’t deploy DHCP/HELD, and the regulator is happy to > force relationships between access networks and calling networks, so > that OBO becomes viable: fine. Devices that are –phonebcp compliant > will work. That is the absolute critical point! Since OBO can not be implemented without forced compliance in each regulatory jurisdiction, it should be left up to each jurisdiction. Hopefully the geopriv group will get something completed for OBO and then the various regulators will have something "standards based" to implement OBO on. So just to reiterate: Step 1: a standard that will work everywhere (someday) Step 2: various standards that bridge the gap between today and someday This is the source of a lot of conflict and confusion because regulators want Step 2 first but you can't build a bridge if you don't know where the other side is. Regards, -- John Lange http://www.johnlange.ca From ted.ietf@gmail.com Thu Aug 6 12:23:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88003A6E7C for ; Thu, 6 Aug 2009 12:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WJgQ-2b6oeb for ; Thu, 6 Aug 2009 12:23:30 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 1DFAB3A6E5C for ; Thu, 6 Aug 2009 12:23:30 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so427861wff.31 for ; Thu, 06 Aug 2009 12:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3WAFFR/fKOythskxckLxtAEhwNlgZJ0fF5Pgn98VN3I=; b=L8tdwk5mt1EQqMFqSb0Pdnw45TpjtgwDxYlHbMqv0FRcNUolz0hX2hxTYrKcWgqrml YmGQu/3J78K7f/q8CzVWbfwyqkayQpjh3RYuRyXP34fxl0pp/8LibwC7EMfssHMfGTev SNu0XmF/+XuRSBZTYpAnXb7l6iIwqQGgXe9d4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tvyag31JcVBmp55mvM/je9b04csa1Ig5Nd2Lw2L7NUmbfr0ONeZNhoHvs6972g8U2/ JCyJ9IK1z0HHfxdIKIA1TlGEIa6Vv7smKbqdPqwJvc6KtAC21zCrkCy5fpAQSQpkDx3z Jzq/MlOeSSP/qoijoQH6eVRJ4s57t9lSyARHA= MIME-Version: 1.0 Received: by 10.142.169.3 with SMTP id r3mr62143wfe.4.1249586611634; Thu, 06 Aug 2009 12:23:31 -0700 (PDT) In-Reply-To: <1249584170.5335.24.camel@vandium.darkcore.net> References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <1249584170.5335.24.camel@vandium.darkcore.net> Date: Thu, 6 Aug 2009 12:23:31 -0700 Message-ID: <6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> From: Ted Hardie To: John Lange Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:23:30 -0000 On Thu, Aug 6, 2009 at 11:42 AM, John Lange wrote: > Most importantly, Canadian i2 is not compatible with phone-bcp or > ecrit-framework nor would it be an interim stepping-stone to any > "next-gen" solution for many reasons but not the least of which is the > fact that it does not allow location aware devices. > Can you unpack what "does not allow location aware devices" means? Do you mean that the location awareness in devices is not presumed, or that location from end stations are not trusted, or something else? regards, Ted From john@johnlange.ca Thu Aug 6 12:30:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5462E3A6E1E for ; Thu, 6 Aug 2009 12:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF9KWvoenITR for ; Thu, 6 Aug 2009 12:30:14 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id D5CB53A6CE6 for ; Thu, 6 Aug 2009 12:30:10 -0700 (PDT) Received: (qmail 13113 invoked from network); 6 Aug 2009 14:29:44 -0500 Received: from unknown (HELO ?192.168.4.127?) (192.168.4.127) by lh02.epicnet.ca with SMTP; 6 Aug 2009 14:29:44 -0500 From: John Lange To: ecrit@ietf.org In-Reply-To: <9B2661AD-4413-49A2-A4E5-D59A43678290@xittel.net> References: <9B2661AD-4413-49A2-A4E5-D59A43678290@xittel.net> Content-Type: text/plain Date: Thu, 06 Aug 2009 14:28:59 -0500 Message-Id: <1249586939.5335.71.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] ECRIT Simplified E-9-1-1 workflow proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:30:15 -0000 On Thu, 2009-08-06 at 07:50 -0400, Francois Menard wrote: > Is anything wrong with the following E-9-1-1 workflow to be possible > with any ATA that can be upgraded to become Phone-BCP compliant. ... > Step 1) In DSL wholesale, PPPoE will assign an IP. The reverse lookup > would be done for this IP by the ATA. > > Step 2) If the ATA is behind nat, it would be provisioned with a STUN > server IP address. The STUN server will return to the ATA, what > public IP address the ATA is behind. > > Step 3) The ATA would then perform an inverse lookup for that IP > address in the DNS server of that domain name, and would expect there > to be a DNS entry for LOCATIONSERVER.DOMAIN-GATHERED-BY-REVERSE- > LOOKUP.DOMAIN-GATHERED-BY-REVERSE-LOOKUP-SUFFIX > > Step 4) The ATA would then use its HELD stack to download the > location object (PIDF-LO). > > Step 5) ATA Memorizes PIDF-LO. > > Step 6) Upon having to dial 9-1-1, ATA sends PIDF-LO via SIPCORE > LOCATION CONVEYANCE (attached) > > Step 7) VoIP server provider will steer the call to the an ILEC SIP > PROXY and send the 9-1-1 RTP media to the ILEC 9-1-1 media gateway > > Step 8) ILEC will inspect the content of the PIDF-LO and will route > the call to the appropriate PSAP I know the focus of your question is regarding the various RADIUS capabilities but I believe the description of steps 5-8 aren't entirely accurate with regard to phonebcp and ecrit-framework. The VOIP endpoint obtains its PIDF-LO and then uses it to obtain the SOS:URI. It caches that information and then uses it to dial the correct ESGW should the need arise. Your description implies that the ESGW URI is obtained in real-time during call routing which I don't believe is what ecrit-framework and phonebcp describe. > All ILEC needs to do is to stop blocking the CIRCUIT-ID's over the > RADIUS accounting interface and accept to implement a SIP-based > gateway + media gateway on the INTERNET which would provide access to > all the PSAPs the ILEC manages (which is the case in Canada where > PSAPs only interconnect directly with the ILEC and no other > competitors). Unfortunately I'm clueless with regard to PPPOE, RADIUS, and DSL so I can't help you with the main point of your question. BTW, the rest of your description is nearly identical to the submission I've been working on. Great minds thing alike even if they think in different languages ;) Regards, -- John Lange http://www.johnlange.ca From john@johnlange.ca Thu Aug 6 12:40:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2283D28C166 for ; Thu, 6 Aug 2009 12:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 8X35yW0Fts5T for ; Thu, 6 Aug 2009 12:40:15 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 54F703A68CC for ; Thu, 6 Aug 2009 12:39:49 -0700 (PDT) Received: (qmail 15653 invoked from network); 6 Aug 2009 14:39:22 -0500 Received: from unknown (HELO ?192.168.4.127?) (192.168.4.127) by lh02.epicnet.ca with SMTP; 6 Aug 2009 14:39:22 -0500 From: John Lange To: Ted Hardie In-Reply-To: <6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <1249584170.5335.24.camel@vandium.darkcore.net> <6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> Content-Type: text/plain Date: Thu, 06 Aug 2009 14:38:37 -0500 Message-Id: <1249587517.5335.80.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:40:16 -0000 On Thu, 2009-08-06 at 12:23 -0700, Ted Hardie wrote: > On Thu, Aug 6, 2009 at 11:42 AM, John Lange wrote: > > > Most importantly, Canadian i2 is not compatible with phone-bcp or > > ecrit-framework nor would it be an interim stepping-stone to any > > "next-gen" solution for many reasons but not the least of which is the > > fact that it does not allow location aware devices. > > > > Can you unpack what "does not allow location aware devices" means? > Do you mean that the location awareness in devices is not presumed, > or that location from end stations are not trusted, or something else? There is no part of Ci2 which allows location to be obtained (v0) or transmitted (v1) from endpoints. In NENAi2 terms, there is no v0 or v1 interface in Ci2. To answer your question, not only is "location awareness in devices ... not presumed", it is presumed that: - devices are not location aware and never will be. - and, VSPs can not do and will never do sip-location-conveyance. Regards, -- John Lange http://www.johnlange.ca From br@brianrosen.net Thu Aug 6 12:51:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222DF3A6C98 for ; Thu, 6 Aug 2009 12:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sbyfaHc2n0L for ; Thu, 6 Aug 2009 12:51:14 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 710433A6A2D for ; Thu, 6 Aug 2009 12:51:14 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MZ8zS-0006Gf-2f; Thu, 06 Aug 2009 14:51:06 -0500 From: "Brian Rosen" To: "'John Lange'" , References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <1249584170.5335.24.camel@vandium.darkcore.net> In-Reply-To: <1249584170.5335.24.camel@vandium.darkcore.net> Date: Thu, 6 Aug 2009 15:51:13 -0400 Message-ID: <031701ca16cf$42ea67a0$c8bf36e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoWxhXilGNkoRICREu/gu4q/2OKvAABvLwg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:51:15 -0000 > Most importantly, Canadian i2 is not compatible with phone-bcp or > ecrit-framework nor would it be an interim stepping-stone to any > "next-gen" solution for many reasons but not the least of which is the > fact that it does not allow location aware devices. In NENA i2, the way we did it is to say that the VPC looks for location = asserted on the call. If it sees it, use that. If it doesn't, use the = database it has. That makes it upwards compatible with i3 location, and = allows -phonebcp compliant phones to be introduced while i2 is still = deployed. Brian From Martin.Dawson@andrew.com Thu Aug 6 16:10:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053193A6D43 for ; Thu, 6 Aug 2009 16:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AAlz5xx9mLC for ; Thu, 6 Aug 2009 16:10:50 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6AB3A3A6C8F for ; Thu, 6 Aug 2009 16:10:50 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_06_18_33_35 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 06 Aug 2009 18:33:35 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 18:10:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 18:10:16 -0500 Message-ID: In-Reply-To: <1249584170.5335.24.camel@vandium.darkcore.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoWxkBS7ffZdpAGQcme0FoFuwCczAAIT4IQ References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <1249584170.5335.24.camel@vandium.darkcore.net> From: "Dawson, Martin" To: "John Lange" , X-OriginalArrivalTime: 06 Aug 2009 23:10:53.0761 (UTC) FILETIME=[259C5B10:01CA16EB] Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 23:10:52 -0000 Hi John,=0D=0A=0D=0AThat is why I chose my words carefully to say "recommen= ded" and=0D=0A"proposed" and to attempt to clarify that each jurisdiction b= aselined=0D=0Aoff i2 - not that they use i2 in toto. In fact i2 prefers=0D=0A= location-capable devices as well - so these jurisdiction-specific=0D=0Areco= mmendations are, by necessity, variants on that architecture.=0D=0AFurther,= i2 incorporates the same dependence on VoIP providers doing the=0D=0Aproxy= ing and a necessary relationship between them and the emergency=0D=0Anetwor= k in the form of the VPC and ESGW network elements. It=0D=0Aincorporates th= e same sorts of national-specific constraints that drive=0D=0Athese interim= variants; that's why it's a useful baseline for these=0D=0Anational interi= m solutions.=0D=0A=0D=0AMost of the variation is in terms of how the access= to application=0D=0Anetwork associations are determined. The mechanics of = ensuring a source=0D=0AIP address is preserved and able to be associated ba= ck to an ISP/LIS for=0D=0Athe OBO step is a cat that can be skinned in many= ways. Advisory=0D=0Acommittees in different places spend a significant amo= unt of their time=0D=0Aworking on that aspect.=0D=0A=0D=0AThe nice thing ab= out ECRIT, once you accept that an ECRIT compliant=0D=0Aterminal (I don't l= ike the term "phone" at all - we're really talking=0D=0Aabout computers the= se days) can have emergency calling embedded at the=0D=0Aoperating system l= evel. There's no need for operators to take=0D=0Aresponsibility for that as= pect any more than they take responsibility=0D=0Afor the implementation of = web browsers. There's no longer a need to=0D=0Ainvest the time and effort i= n "cat skinning" mentioned above. In fact,=0D=0AI'd suggest that jurisdicti= ons (and operators) could save a lot of=0D=0Ainvestment by deciding to go d= irectly to ECRIT/i3. It's tough in, say,=0D=0Athe US where there are thousa= nds of devolved PSAPs that have to be=0D=0AIP-enabled. In jurisdictions wit= h a more centralized call center=0D=0Aarchitecture and management, it shoul= d be possible to get to ECRIT=0D=0Acompliance more quickly than implementin= g interim solutions.=0D=0A=0D=0AHow about we consider the possibility that = a migration to ECRIT-capable=0D=0Adevices (based on a standard reference im= plementation of an emergency=0D=0Acall client) may actually be able to appe= ar quite quickly=3F This is=0D=0Alikely to happen before most regulators ev= en get their head around VoIP.=0D=0A=0D=0AYou say these interim solutions d= on't permit location aware devices. I=0D=0Athink you mean they don't rely o= n them - but location aware devices can=0D=0Astill exist. By the time a LIS= is implemented to support OBO, it already=0D=0Ahas the majority of the fun= ctionality it needs to support target client=0D=0Aqueries. That's a small i= ncremental change to implementation. So I posit=0D=0Athat these interim arc= hitectures do represent a quite sensible stepping=0D=0Astone toward ECRIT c= ompliance.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A=0D=0A=0D=0A-----Origi= nal Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ie= tf.org] On Behalf=0D=0AOf John Lange=0D=0ASent: Friday, 7 August 2009 4:43 = AM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D= =0AOn Wed, 2009-08-05 at 03:59 -0500, Dawson, Martin wrote:=0D=0A> the NEN= A i2 architecture would probably be a more straightforward=0D=0A> baseline = for analysis - as has been done in the UK and Canada. Of=0D=0A> course, it'= s generally recognized as only an interim step, even in=0D=0A> those jurisd= ictions.=0D=0A=0D=0ALest anyone get the wrong idea, NENAi2 has not been "do= ne in Canada".=0D=0A=0D=0AOnly a "Canadian i2" has been suggested (not appr= oved or implemented)=0D=0Aand for the most part it resembles NENAi2 only in= that they both contain=0D=0A"i2" in the title.=0D=0A=0D=0ACanadian i2 has = similar names for the functional elements and interfaces=0D=0Aeven though m= any of those elements are missing or operate completely=0D=0Adifferently th= an NENA i2.=0D=0A=0D=0AMost importantly, Canadian i2 is not compatible with= phone-bcp or=0D=0Aecrit-framework nor would it be an interim stepping-ston= e to any=0D=0A"next-gen" solution for many reasons but not the least of whi= ch is the=0D=0Afact that it does not allow location aware devices.=0D=0A=0D= =0A--=20=0D=0AJohn Lange=0D=0Ahttp://www.johnlange.ca=0D=0A=0D=0A__________= _____________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ie= tf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A From Martin.Dawson@andrew.com Thu Aug 6 16:25:04 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1C33A6E70 for ; Thu, 6 Aug 2009 16:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHnOc11acYxA for ; Thu, 6 Aug 2009 16:25:03 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 98DC028C115 for ; Thu, 6 Aug 2009 16:23:59 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_06_18_46_44 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 06 Aug 2009 18:46:43 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 18:24:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 18:16:05 -0500 Message-ID: In-Reply-To: <1249587517.5335.80.camel@vandium.darkcore.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoWzbx52wSMggZ3SF6i4o0shvhmhgAHXPPg References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><1249584170.5335.24.camel@vandium.darkcore.net><6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> <1249587517.5335.80.camel@vandium.darkcore.net> From: "Dawson, Martin" To: "John Lange" , "Ted Hardie" X-OriginalArrivalTime: 06 Aug 2009 23:24:02.0427 (UTC) FILETIME=[FBB13CB0:01CA16EC] Cc: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 23:25:04 -0000 The "never will" parts seem a bit gratuitous. Personal preference=0D=0Aperh= aps - but, as I say, I think it's a simple step to move from an=0D=0AOBO-on= ly LIS to an ECRIT-compliant LCP LIS. So the "never will" part=0D=0Aseems a= rather dogmatic position.=0D=0A=0D=0AWhat happens when, in fact, devices s= tart incorporating ECRIT clients as=0D=0Aa matter of course...=3F I think C= anada is innovative; it's likely to want=0D=0Ato take advantage of that dev= elopment and enable the benefit of=0D=0Aubiquitous emergency services via a= ll devices/access... I would have=0D=0Athought.=0D=0A=0D=0ACheers,=0D=0AMar= tin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org= [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf John Lange=0D=0ASent: Fr= iday, 7 August 2009 5:39 AM=0D=0ATo: Ted Hardie=0D=0ACc: ecrit@ietf.org=0D=0A= Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0AOn Thu, 2009-08-06 at 12:23= -0700, Ted Hardie wrote:=0D=0A> On Thu, Aug 6, 2009 at 11:42 AM, John Lang= e wrote:=0D=0A>=20=0D=0A> > Most importantly, Canadian i= 2 is not compatible with phone-bcp or=0D=0A> > ecrit-framework nor would it= be an interim stepping-stone to any=0D=0A> > "next-gen" solution for many = reasons but not the least of which is=0D=0Athe=0D=0A> > fact that it does n= ot allow location aware devices.=0D=0A> >=0D=0A>=20=0D=0A> Can you unpack w= hat "does not allow location aware devices" means=3F=0D=0A> Do you mean tha= t the location awareness in devices is not presumed,=0D=0A> or that locatio= n from end stations are not trusted, or something else=3F=0D=0A=0D=0AThere = is no part of Ci2 which allows location to be obtained (v0) or=0D=0Atransmi= tted (v1) from endpoints.=0D=0A=0D=0AIn NENAi2 terms, there is no v0 or v1 = interface in Ci2.=0D=0A=0D=0ATo answer your question, not only is "location= awareness in devices ...=0D=0Anot presumed", it is presumed that:=0D=0A=0D= =0A- devices are not location aware and never will be.=0D=0A- and, VSPs can= not do and will never do sip-location-conveyance.=0D=0A=0D=0ARegards,=0D=0A= --=20=0D=0AJohn Lange=0D=0Ahttp://www.johnlange.ca=0D=0A=0D=0A_____________= __________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.= org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-----------= ---------------------------------------------------------------------------= ----------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A From drage@alcatel-lucent.com Fri Aug 7 00:35:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E753A67FF for ; Fri, 7 Aug 2009 00:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9-12vPLdNjr for ; Fri, 7 Aug 2009 00:35:56 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id BF7933A6BF4 for ; Fri, 7 Aug 2009 00:35:55 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n777ZmaN026725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Aug 2009 09:35:48 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 7 Aug 2009 09:35:48 +0200 From: "DRAGE, Keith (Keith)" To: Marc Linsner , "Gabor.Bajko@nokia.com" , "ecrit@ietf.org" Date: Fri, 7 Aug 2009 09:35:46 +0200 Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42AAJDiUoAAA+bkAAAFk66wAL5PVgA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE208661D03FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 07:35:57 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE208661D03FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Obviously mandates differ between different parts of the world, but certain= ly any wireless operator (2G or 3G) is currently required by the 3GPP stand= ards, reflecting national regulation, to provide ermegency calling where th= ey provide CS voice service on their networks. Where IMS is supported, there is also a requirement to support emergency ca= lling on IMS. For the deployments where an operator is providing LTE in an area not cover= ed by 2G or 3G service, there are indications prior to the network selectio= n to enable determination of whether an emergency call is possible over IMS= or not. What this essentially boils down to is that if you have an contract with a = 3G operator to give you voice service, then emergency calls will work on th= at phone, because the network operator is required to support it. That appl= ies whether there is an internet browser on the phone or not. As far as I know there is currently no mandate on any ISP or indeed interne= t VOIP provider to support emergency calls. That may come in the future, bu= t so far I have seen no evidence of it. So writing a document that claims that some other mechanism is the way to o= ffer emergency calls, and then shouting from the rooftops that this applies= to mobile phones, is more likely to result in deaths than not. regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Wednesday, August 05, 2009 8:30 PM To: Gabor.Bajko@nokia.com; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP h= um Gabor, But reliability and mobility were the main architectural design ch= oices in 3GPP. That is why they ended up with that complex architecture! T= he procedures themselves are a consequence of the architecture. Carriers plan to switch emergency call handling from CS to PS domain, and = they wanted a network controlled ES, they did not want to rely on the hand= set doing the whole procedure because of the liability. Support for emerge= ncy calls is not a revenue generator for carriers, they'd be happy leaving= the tasks up to the client if there were no consequences of emergency cal= ls failing for whatever reason. And just to answer James point, ISPs offering broadband internet service c= an not be paralelled with carriers operating networks using 3GPP standards= . The ISPs do not commit to offer you service with less than a few minutes= outage per year, they provide no mobility and they are not mandated to su= pport emergency services. - gabor [Marc] Are you implying that 3GPP carriers operating a packet voice service= have a different mandate for supporting emergency services than an OTT pro= vider that sells packet voice services? (my understanding, which could be = wrong, is that VoIP is VoIP no matter who is the SP) Or is this a 3GPP self-inflicted mandate that is trying to emulate 2G circu= it-switched services? -Marc- --_000_EDC0A1AE77C57744B664A310A0B23AE208661D03FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: ECRIT/IMS - independent discussion from the PhoneBCP= hum
    Obviously mandates differ between different parts = of the=20 world, but certainly any wireless operator (2G or 3G) is currently required= by=20 the 3GPP standards, reflecting national regulation, to provide ermegency ca= lling=20 where they provide CS voice service on their networks.
     
    Where IMS is supported, there is also a requiremen= t to=20 support emergency calling on IMS.
     
    For the deployments where an operator is providing= LTE in=20 an area not covered by 2G or 3G service, there are indications prior to the= =20 network selection to enable determination of whether an emergency call is=20 possible over IMS or not.
     
    What this essentially boils down to is that if you= have an=20 contract with a 3G operator to give you voice service, then emergency calls= will=20 work on that phone, because the network operator is required to support it.= That=20 applies whether there is an internet browser on the phone or=20 not.
     
    As far as I know there is currently no mandate on = any ISP=20 or indeed internet VOIP provider to support emergency calls. That may come = in=20 the future, but so far I have seen no evidence of=20 it. 
     
    So writing a document that claims that some other = mechanism=20 is the way to offer emergency calls, and then shouting from the rooftops th= at=20 this applies to mobile phones, is more likely to result in deaths than not.= =20
     
     
     
    regards
     
    Keith

    From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc=20 Linsner
    Sent: Wednesday, August 05, 2009 8:30 PM
    To:= =20 Gabor.Bajko@nokia.com; ecrit@ietf.org
    Subject: Re: [Ecrit] ECRI= T/IMS=20 - independent discussion from the PhoneBCP hum

    Gabor,


    <Gabo= r> But=20 reliability and mobility were  the main architectural design=20 choices in 3GPP. That is why they ended up  with that complex= =20 architecture! The procedures themselves are a consequence  of = the=20 architecture.

    Carriers= plan to=20 switch emergency call handling  from CS to PS domain, and they= =20 wanted a network controlled ES, they did not  want to rely on = the=20 handset doing the whole procedure because of the  liability.=20 Support for emergency calls is not a revenue generator  for=20 carriers, they'd be happy leaving the tasks up to the client if=20  there were no consequences of emergency calls failing for wha= tever=20  reason.

    And just= to=20 answer James point, ISPs offering  broadband internet service = can=20 not be paralelled with carriers operating  networks using 3GPP= =20 standards. The ISPs do not commit to offer you service  with l= ess=20 than a few minutes outage per year, they provide no mobility and=20  they are not mandated to support emergency=20  services.



    -=20 gabor


    [Marc] Are you implying that 3GPP= =20 carriers operating a packet voice service have a different mandate = for=20 supporting emergency services than an OTT provider that sells packe= t=20 voice services?  (my understanding, which could be wrong, is t= hat=20 VoIP is VoIP no matter who is the SP)

    Or is this a 3GPP=20 self-inflicted mandate that is trying to emulate 2G circuit-switche= d=20 services?


    -Marc-



    --_000_EDC0A1AE77C57744B664A310A0B23AE208661D03FRMRSSXCHMBSC3d_-- From drage@alcatel-lucent.com Fri Aug 7 00:36:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B42C3A6D6D for ; Fri, 7 Aug 2009 00:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.791 X-Spam-Level: X-Spam-Status: No, score=-4.791 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owm7HuODC+s7 for ; Fri, 7 Aug 2009 00:36:53 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 025113A677D for ; Fri, 7 Aug 2009 00:36:51 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n777apnR020166 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Aug 2009 09:36:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 7 Aug 2009 09:36:51 +0200 From: "DRAGE, Keith (Keith)" To: "Dawson, Martin" , "L.Liess@telekom.de" , "R.Jesske@telekom.de" , "ecrit@ietf.org" Date: Fri, 7 Aug 2009 09:36:50 +0200 Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAAOKzRQAAW1mtA= Message-ID: References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE208661D0BFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Reinhard.Lauster@t-mobile.at" Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 07:36:56 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE208661D0BFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You said: As I say, check out the interim recommendations by the CRTC in Canada and N= ICC in the UK. There is no such thing as interim recommendations from UK NICC. There is a document under development. Whatever it currently says has no st= atus as a UK NICC document. The last I heard the document was under substan= tial reediting. regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= awson, Martin Sent: Thursday, August 06, 2009 4:21 PM To: L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP I neglected to do a point by point, sorry. So =96 that follows: Cheers, Martin ________________________________ From: L.Liess@telekom.de [mailto:L.Liess@telekom.de] Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP Hi Martin, See comments inline [[LLi]]. Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= awson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, I think what you=92re saying is that you don=92t think that Germany will go= on to implement full ECRIT support but will peg development at an interim = phase. [[LLi]] We don't know how the realtime application networks or EC will loo= k like in 20 years. Roland's answer only applies to the next 5 to 10 years. [[MCD]] The implementation of the LIS function is the most significant aspe= ct for operators =96 and that needs to happen in short term scenarios in an= y case. The provision of LoST can be a national asset/service. The provisio= n of PSAP URIs is an emergency service responsibility. Those are the key re= quirements =96 and that does provide a framework that will work into the ne= xt 20 years and beyond. That would be disappointing =96 not least because full ECRIT compliance wo= uld ultimately decrease the overhead associated with emergency service supp= ort for operators as well as providing a more universal service. [[LLi]] This may be true for "green field" ISPs and VSPs but not for incum= bent carriers with existing infrastructure. And universal service is not a= requirement for us. Neither the German regulator requires it nor is it a b= usines case. [[MCD]] I think this is only true to the same extent that a pure Internet g= reen field ISP only has to worry about Internet trunk connectivity and does= n=92t have to worry about PSTN circuit trunk connectivity. The latter infra= structure is legacy and not particularly applicable to the Internet compone= nt of the service. Providing ECRIT emergency calling support requires the a= ddition of a LIS, access to LoST (whoever hosts it), and a route to the PSA= P URI(s). Both types of operator need to do that. Whatever switched circuit= legacy emergency infrastructure already exists in the established operator= needs to continue to exist to support the emergency calls on that access. Nevertheless, I don=92t think that decision invalidates the BCP; [[LLi]] We think it does, because some of the requirements are not flexibl= e enough to cover the deployments within the next years. The BCP should be= more flexible: * Allow additional location identifiers [[MCD]] Agreed =96 although that can be done by local-specific use of field= s in the PIDF-LO based on jurisdictional convention and be appropriately pa= rsed by LoST in that jurisdiction in a quite transparent fashion. A German = technical advisory committee could make this recommendation within that jur= isdiction without deference to the BCP and without impact to ECRIT-complian= t devices. * Allow AN operated LOST [[MCD]] I don=92t think the BCP excludes the possibility of the access netw= ork hosting LoST. It shouldn=92t =96 since this is a jurisdictional decisio= n. As long as the LoST service can be discovered/used when attached to the = access, it shouldn=92t matter where it is hosted. * Provide a way to enable LOST-query based on national or domain-specifi= c location identifier. One posiblility is to allow the LIS to query the LOS= T , but there are also other alternatives. [[MCD]] I was in favour of the LIS proxying the LoST request =96 since they= both share a =93locality=94 it simplifies the whole discovery plot. Howeve= r, that didn=92t take hold in the debate so we have what we have. Given tha= t - a LIS still need only provide the national level location (i.e. DE) in = the PIDF-LO if that=92s all that=92s required to make a successful LoST que= ry. The rest can be done using LbyR =96 with the LIS also providing the ref= erence along with the coarse location. Doesn=92t that satisfy the requireme= nt? * Allow and describe also network-centric, not only ED-centric architect= ures. If I remember correctly, John Medland from BT also recomended to use= a more network- centric architecture, at least for the next years. [[MCD]] I don=92t really understand this =93X-centric=94 argument. Even tra= ditional cellular architectures require a combination of end device and net= work capabilities. Maybe if you are being specific you mean; there should b= e no ECRIT-specific requirements on the end device (though I=92m not sure w= hy ECRIT should have this rule when other architectures don=92t). You=92re = right John M did propose such an approach. Not to put words in his mouth, b= ut this was in the context of an interim architecture =96 per my comments b= elow on the Canada and UK interim approaches. It works in the limited scope= of devices having to proxy calls through =93national=94 VoIP carriers =96 = it doesn=92t meet the long term vision of ECRIT. An interim architecture, b= y definition, is not the end-game architecture. ECRIT only seeks to define = the end-game; there are already interim architectures to choose from =96 wh= ich was my point about suggesting it might be better to baseline off i2 for= the time being rather than trying to shoehorn interim constraints into ECR= IT. I think it just means that the German regulator and technical advisory comm= ittees would point out the subset aspects of compliance that would be appli= cable to that jurisdiction. [[LLi]] Again, the draft is not flexible enough for it. If the BCP contai= ns requirements which are not realistic, people will just discard the BCP a= nd implement proprietary stuff. My expectation from a standard body is to d= efine protocols and architecture which people are willing to implement in t= heir network or products , not only in the lab. [[MCD]] What I mean is that compliance isn=92t compulsory. It=92s OK to say= =93we have decided to deviate from the specification in this way=94. [[LLi]] We are not against the draft in principle. ECRIT provides us with very val= uable specifications as LbyR, HELD, identity extensions. But targeting an a= rchitecture which requires everbody to invest without a business case will = not help the draft in the end, also if it becomes a BCP. It would make sen= se to make it more flexible so people are willing to adopt it. [[MCD]] Lots of the elements you mention exist outside of the BCP =96 LbyR,= HELD, identity extensions=85 they aren=92t defined by the BCP and can be u= sed in any other context. The BCP has a very specific goal of defining a wa= y that emergency calls can be made by any Internet connected device/proxy a= nywhere that follows the specification; it doesn=92t seek to be more than t= hat =96 which I think is what you=92re looking for. As I say, check out the= interim recommendations by the CRTC in Canada and NICC in the UK. Actually, based on your description below, the NENA i2 architecture would = probably be a more straightforward baseline for analysis =96 as has been do= ne in the UK and Canada. Of course, it=92s generally recognized as only an = interim step, even in those jurisdictions. Other comments below. Cheers, Martin ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= .Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Dear all, We would like the document to become a BCP as soon as possible so the group= can move on with other documents related to emergency calling based on loc= ation-by-reference and ED=92s IP-address. [[MCD]] I think you might mean =93identity extensions=94 rather than locati= on-by-reference because LbyR still requires the ED to obtain the reference = =96 e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The SIP-proxy = uses the IP-address to query the LIS using HTTP (it's not HELD but SOAP ove= r HTTP, but anyway similar). The LIS responds with a numeric string associa= ted to the caller location, in principle a LbyR and with the PSAP number. T= he proxy inserts the LbyR into the SIP-message (as P-Asserted-ID because th= e PSAPs are in PSTN) and routes the message to the PSAP. It's a low cost s= olution. But we can not HUM for the current form of the document. Back to the document: Some requirements are far form being realistic, at le= ast in Germany, some are not realistic at all. Implementing these requireme= nts cost a carrier a lot of money and there is no ROI for it. Just a few examples: =B7 Requiring either geo or civic location does not provide carriers = with enough flexibility to reuse their existing mechanisms and location dat= abases. Routing of emergency calls is currently done in Germany based on ph= one area code not on geo or civic location, at least for the fixed network.= For mobile networks the cell-id is used in common. This is regulated by th= e german regulator. [[MCD]] How many unique PSAP routes are required in Germany? The US has lot= s (6000 plus) and Australia has two (and they are redundant so it doesn=92t= matter which one). Presumably geographic information, for PSAP catchment a= reas, is the basis for determining which area codes are relevant to begin w= ith? After all, an area code is not intrinsically geographic; it=92s a netw= ork routing value. If so, then some geographic discriminator is already in = play in terms of constructing the area code based routing data (something l= ike zip codes perhaps?) =96 and in that case, it should be straightforward = to by-pass the area code step in the construction of routing that goes the = correct PSAP URI. [[LLi]] Currently, fixed networks carriers in Germany route the ECs based o= nly on the caller's area code. Sometime in the past, the carriers, the regu= lator and the PSAPs operators (police, the Red Cross) agreed to do so. This= may change in the future, but it will take a quite long time. With nomadic VoIP devices (and it=92s no good being in denial about this b= eing the norm in the future) area code is no more reliable than it is for c= onventional mobile phones. And, presumably, area code is not used for conve= ntional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the area co= de, and have a different table than the fixed network operators. They are n= ot going to change this. As to the nomadic SIP-users...if we like it or no= t, very few of our customers use our SIP service nomadic, let alone call EC= from their laptop. 1 LOST as a national, let alone as a global directory is not g= oing to be implemented. The regulator will provide in the web a static tabl= e which contains the PSAPs and the area for which they are responsible (one= or more area codes). Every carrier has to implement its own routing databa= se for emergency calls. [[MCD]] Whatever the carriers implement (and they have to implement somethi= ng) could just as readily be done using LoST. Then visiting devices, with n= o association with any local VoIP proxy server would still be able to deter= mine a route to the correct PSAP. Alternatively, as long as the regulator i= s maintaining a web service with the routing information, why not make that= directly accessible using LoST and save the operators the cost of duplicat= ing the service at all? [[LLi]] There is a big difference between maintaining a web page with a ta= ble which operator can print and implement in their darabases and operating= a database which is queried for every emergency call in Germany, must have= an availablity of 99,99...% , is secure enough...you know. The regulator = will not do this. 2 We have no intention to rely on end devices for location informatio= n because: =B7 ED provided location info is not trusted [[MCD]] Location by reference mitigates this trust issue. The emergency net= work can (automatically and before human resources are engaged) assess the = source of the reference, and the validity of the location by dereference, w= ithout having to trust location provided directly from the ED. There are mo= re sophisticated approaches to trustability even using LbyV =96 based on di= gital signatures across appropriate attributes. This WG and Geopriv haven= =92t really got to grips with that=85 yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is neede= d if EC must work for private and enterprise networks and VPNs. We have no= such regulatory requirements. And we don't know of any verdor of DSL-EDs = which provides today SIP with LbyR and is as cheap as the devices without i= t. If you do, please let me know. The regulator ask us to guarantee that EC works. What if a customer dials 1= 12 and his end device does not send the location? So I have to implement bo= th solutions, with and without ED provided location, anyway. 1 There are already a lot of existing EDs in usage which don=92t send= location. [[MCD]] Quite right. ECRIT doesn=92t overly concern itself with that interi= m situation. The UK and Canadian definitions for an interim solution (limit= ing service to in-country VoIP proxy operators) both assume third-party que= ry via identity-extension to allow the proxy or the VPC to make the query t= o the LIS. This isn=92t extensible to universal emergency service access by= all visiting devices but it does put the necessary LIS functionality in pl= ace as a very good starting point. It would be a pity if Germany were to c= ease the evolution there as it would not fulfil the real promise of the Int= ernet and the ECRIT model. [[LLi]] I wonder who will drive and pay for upgrading the interim solution= s. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination infra= structure in place for the purposes of dispatch is done =96 and then the ne= xt, simpler step, of using that to support the routing procedure isn=92t ta= ken=85 that would be a waste. [[LLi]] Do you think this is an argument for a product manager? They need = a business case. We don=92t intend to require our ED-vendors to provide location because i= t is useless to us. We could agree with the document with following changes: * Other location identifiers then geo or civil are allowed. It must b= e possibe that the data foermat is flexible due to different requirements f= rom regulators over the whole world. (e.G Germany area codes for fixed- and= Cell-Id for moile- providers) * The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed * It must be possible for the VoIP-provider=92s proxy to use a LOST (= or an ESRP) provided by the AN or by other local provider on behalf of the = AN. There is no value in Hum-ing documents which one is not going to implement= and does not fit into regulated schemes like in Germany. Currently, neithe= r the IETF- nor the 3GPP-architecture for emergency calling covers our real= needs for the next 2 to 5 years and in the end everybody still has its own= proprietary implementation. Best regards Roland Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de http://www.telekom.de Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] --_000_EDC0A1AE77C57744B664A310A0B23AE208661D0BFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM o= n PhoneBCP
    You said:
     
    As I say, check out the i= nterim=20 recommendations by the CRTC in Canada and NICC in the UK.

     

    There is no such thing as = interim=20 recommendations from UK NICC.

     = ;

    There is a document under= =20 development. Whatever it currently says has no status as a UK NICC document= . The=20 last I heard the document was under substantial=20 reediting.

     = ;

    regards

     = ;

    Keith


    From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawson,=20 Martin
    Sent: Thursday, August 06, 2009 4:21 PM
    To:=20 L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: Re: [Ecrit] HUM on=20 PhoneBCP

    I neglected to= do a=20 point by point, sorry. So =96 that follows:

     

    Cheers,

    Martin

     

    From: L.Liess@telekom.de=20 [mailto:L.Liess@telekom.de]
    Sent:     Friday, 7 August 2009 12:29= =20 AM
    To: Dawson, Martin;= =20 R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

     

    Hi Martin,=20

     

    See comments i= nline=20 [[LLi]].

     

     

    Laura

    From:= ecrit-bounces@ietf.org= =20 [mailto:ecrit-bounces@ietf.org] On= Behalf=20 Of Dawson, Martin
    Sent:     Wednesday, August 05, 2009= 11:00=20 AM
    To: Jesske, Rolan= d;=20 ecrit@ietf.org
    Subject:<= /B> Re:=20 [Ecrit] HUM on PhoneBCP    =

    Hi=20 Roland,

     <= /o:p>

    I think what= you=92re=20 saying is that you don=92t think that Germany will go on to impl= ement=20 full ECRIT support but will peg development at an interim phase.=20
    [[LLi]] = ; We=20 don't know how the realtime application networks or EC will look l= ike=20 in 20 years. Roland's answer only applies to the next 5 = to 10=20 years. =

    [[MCD]]=20 The implementation of the LIS function is the most significant aspect f= or=20 operators =96 and that needs to happen in short term scenarios in any c= ase.=20 The provision of LoST can be a national asset/service. The provision of= PSAP=20 URIs is an emergency service responsibility. Those are the key requirem= ents=20 =96 and that does provide a framework that will work into the next 20 y= ears=20 and beyond.<= /SPAN>

     <= /SPAN>

     That would be= =20 disappointing =96 not least because full ECRIT compliance would ultimat= ely=20 decrease the overhead associated with emergency service support for=20 operators as well as providing a more universal=20 service.

    = [[LLi]] = ; This=20 may be true for "green field" ISPs and VSPs but not for incumbent= =20 carriers with existing infrastructure.  And universal service= is=20 not a requirement for us. Neither the German regulator requires it= nor=20 is it a busines case.   =

    [[MCD]]=20 I think this is only true to the same extent that a pure Internet green= =20 field ISP only has to worry about Internet trunk connectivity and doesn= =92t=20 have to worry about PSTN circuit trunk connectivity. The latter=20 infrastructure is legacy and not particularly applicable to the Interne= t=20 component of the service. Providing ECRIT emergency calling support req= uires=20 the addition of a LIS, access to LoST (whoever hosts it), and a route t= o the=20 PSAP URI(s). Both types of operator need to do that. Whatever switched= =20 circuit legacy emergency infrastructure already exists in the establish= ed=20 operator needs to continue to exist to support the emergency calls on t= hat=20 access.<= SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><= /SPAN>

     <= /o:p>

    Nevertheless= , I=20 don=92t think that decision invalidates the BCP;
    [[LLi]] = ; We=20 think it does, because some of the requirements are not flexi= ble=20 enough to cover the deployments within the next years.  The B= CP=20 should be more flexible:  

    • Allow addi= tional=20 location identifiers 

    <= FONT=20 face=3DArial color=3Dnavy size=3D2>[[MCD]]=20 Agreed =96 although that can be done by local-specific use of fields in= the=20 PIDF-LO based on jurisdictional convention and be appropriately parsed = by=20 LoST in that jurisdiction in a quite transparent fashion. A German tech= nical=20 advisory committee could make this recommendation within that jurisdict= ion=20 without deference to the BCP and without impact to ECRIT-compliant=20 devices.= <= /SPAN>

    • Allow AN o= perated=20 LOST

    <= FONT=20 face=3DArial color=3Dnavy size=3D2>[[MCD]]=20 I don=92t think the BCP excludes the possibility of the access network = hosting=20 LoST. It shouldn=92t =96 since this is a jurisdictional decision. As lo= ng as the=20 LoST service can be discovered/used when attached to the access, it=20 shouldn=92t matter where it is hosted.<= /SPAN>

    • Provide&nb= sp;a=20 way to enable LOST-query based on national or=20 domain-specific location identifier. One posiblility is to = allow=20 the LIS to query the LOST , but there are also other=20 alternatives.

    <= FONT=20 face=3DArial color=3Dnavy size=3D2>[[MCD]]=20 I was in favour of the LIS proxying the LoST request =96 since they bot= h share=20 a =93locality=94 it simplifies the whole discovery plot. However, that = didn=92t=20 take hold in the debate so we have what we have. Given that - a LIS sti= ll=20 need only provide the national level location (i.e. DE) in the PIDF-LO = if=20 that=92s all that=92s required to make a successful LoST query. The res= t can be=20 done using LbyR =96 with the LIS also providing the reference along wit= h the=20 coarse location. Doesn=92t that satisfy the=20 requirement?<= /SPAN>

    • Allow = ;and describe=20 also network-centric, not only ED-centric architectures. If= =20 I  remember correctly, John Medland from BT also recomended= to=20 use a more network- centric architecture, at least for the next=20 years.

    <= FONT=20 face=3DArial color=3Dnavy size=3D2>[[MCD]]=20 I don=92t really understand this =93X-centric=94 argument. Even traditi= onal=20 cellular architectures require a combination of end device and network= =20 capabilities. Maybe if you are being specific you mean; there should be= no=20 ECRIT-specific requirements on the end device (though I=92m not sure wh= y ECRIT=20 should have this rule when other architectures don=92t). You=92re right= John M=20 did propose such an approach. Not to put words in his mouth, but this w= as in=20 the context of an interim architecture =96 per my comments below on the= =20 Canada and=20 UK interim approaches. It = works=20 in the limited scope of devices having to proxy calls through =93nation= al=94=20 VoIP carriers =96 it doesn=92t meet the long term vision of ECRIT. An i= nterim=20 architecture, by definition, is not the end-game architecture. ECRIT on= ly=20 seeks to define the end-game; there are already interim architectures t= o=20 choose from =96 which was my point about suggesting it might be better = to=20 baseline off i2 for the time being rather than trying to shoehorn inter= im=20 constraints into ECRIT.<= /SPAN>

     

    I think it j= ust=20 means that the German regulator and technical advisory committees would= =20 point out the subset aspects of compliance that would be applicable to = that=20 jurisdiction.  = ;
    <= /FONT>[[LLi]] = ;=20 Again, the draft is not flexible enough for it.  If the BCP=20 contains requirements which are not realistic, people will just di= scard=20 the BCP and implement proprietary stuff. My expectation from = a=20 standard body is to define protocols and architecture which people= are=20 willing to implement in their network or products , not only in the=20 lab.=

    [[MCD]]=20 What I mean is that compliance isn=92t compulsory. It=92s OK to say =93= we have=20 decided to deviate from the specification in this=20 way=94.<= SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><= /SPAN>

     

    [[LLi]] = ;=20

    We are not a= gainst=20 the draft in principle. ECRIT provides  us with ver= y=20 valuable specifications as LbyR, HELD, identity extensions. But=20 targeting an architecture which requires everbody to=20 invest without a business case will not help the=20 draft in the end, also if it becomes a BCP.  It would ma= ke=20 sense to make it more flexible so people are willing to adopt=20 it.    

    [[MCD]]=20 Lots of the elements you mention exist outside of the BCP =96 LbyR, HEL= D,=20 identity extensions=85 they aren=92t defined by the BCP and can be used= in any=20 other context. The BCP has a very specific goal of defining a way that= =20 emergency calls can be made by any Internet connected device/proxy anyw= here=20 that follows the specification; it doesn=92t seek to be more than that = =96 which=20 I think is what you=92re looking for. As I say, check out the interim=20 recommendations by the CRTC in Canada and NICC in the UK.<= FONT=20 face=3DArial color=3Dnavy size=3D2><= /SPAN>

     

     Actual= ly,=20 based on your description below, the NENA i2 architecture would probabl= y be=20 a more straightforward baseline for analysis =96 as has been done in th= e=20 UK and Canada. Of course, it=92s = generally=20 recognized as only an interim step, even in those=20 jurisdictions.

    Other commen= ts=20 below.

     <= /o:p>

    Cheers,=

    Martin<= /o:p>

     <= /o:p>

    From:= ecrit-bounces@ietf.org= =20 [mailto:ecrit-bounces@ietf.org] On= Behalf=20 Of R.Jesske@telekom.de
    Sent:     Wednesday, 5 August 2009 6= :19=20 PM
    To:=20 ecrit@ietf.org
    Subject:<= /B> Re:=20 [Ecrit] HUM on PhoneBCP

     

     

    Dear all,
    We would like t= he document=20 to become a BCP as soon as possible so the group can move on with other= =20 documents related to emergency calling based on location-by-reference a= nd=20 ED=92s IP-address. <= /P>

    [[MCD]]=20 I think you might mean =93identity extensions=94 rather than=20 location-by-reference because LbyR still requires the ED to obtain the= =20 reference =96 e.g. by HELD.
    [[LLi]] We=20 use both, the IP-address as UE identity and LbyR. The SIP-proxy uses th= e=20 IP-address to query the LIS using HTTP (it's not HELD but SOAP ove= r=20 HTTP, but anyway similar). The LIS responds with a numeric string= =20 associated to the caller location, in principle a LbyR and with the=20 PSAP number. The proxy inserts the LbyR into the SIP-mes= sage=20 (as P-Asserted-ID because the PSAPs are in PSTN) and routes the me= ssage=20 to the PSAP.  It's a low cost=20 solution. 

    But we can not HUM for the curr= ent=20 form of the document.

    Back to the document: Some=20 requirements are far form being realistic, at least in Germany, some are not real= istic=20 at all. Implementing these requirements cost a carrier a lot of money a= nd=20 there is no ROI for it.

    Just a few examples:=20

    =B7    &nbs= p;  Requirin= g either=20 geo or civic location does not provide carriers with enough flexibility= to=20 reuse their existing mechanisms and location databases. Routing of emer= gency=20 calls is currently done in Germany based on phone are= a code=20 not on geo or civic location, at least for the fixed network. For mobil= e=20 networks the cell-id is used in common. This is regulated by the german= =20 regulator.

    [[MCD]]=20 How many unique PSAP routes are required in Germany? The US has lots (6000 plus) and Australia has two (and the= y are=20 redundant so it doesn=92t matter which one). Presumably geographic=20 information, for PSAP catchment areas, is the basis for determining whi= ch=20 area codes are relevant to begin with? After all, an area code is not=20 intrinsically geographic; it=92s a network routing value. If so, then s= ome=20 geographic discriminator is already in play in terms of constructing th= e=20 area code based routing data (something like zip codes perhaps?) =96 an= d in=20 that case, it should be straightforward to by-pass the area code step i= n the=20 construction of routing that goes the correct PSAP URI.=20
    [[LLi]] Currently, fixed=20 networks carriers in Germany route the ECs= based=20 only on the caller's area code. Sometime in the past, the=20 carriers, the regulator and the PSAPs operators (police, the Red Cross)= =20 agreed to do so. This may change in the future, but it will take a= =20 quite long=20 time.      

     With=20 nomadic VoIP devices (and it=92s no good being in denial about this bei= ng the=20 norm in the future) area code is no more reliable than it is for=20 conventional mobile phones. And, presumably, area code is not used for= =20 conventional cellular emergency call=20 routing?
    [[LLi]] =20 As far as I know, mobile networks use the Cell-ID, not the area code, a= nd=20 have a different table than the fixed network operators. They are = not=20 going to change this.  As to the nomadic SIP-users...if we like it= or=20 not, very few of our customers use our SIP service= =20 nomadic, let alone call EC from their=20 laptop.         <= /SPAN>

    1     &n= bsp;       =20 LOST=20 as a national, let alone as a global directory is not going to be=20 implemented. The regulator will provide in the web a static table which= =20 contains the PSAPs and the area for which they are responsible (one or = more=20 area codes). Every carrier has to implement its own routing database fo= r=20 emergency calls.

    <= B>[[MCD]]=20 Whatever the carriers implement (and they have to implement something= )=20 could just as readily be done using LoST. Then visiting devices, with= no=20 association with any local VoIP proxy server would still be able to=20 determine a route to the correct PSAP. Alternatively, as long as the= =20 regulator is maintaining a web service with the routing information, = why=20 not make that directly accessible using LoST and save the operators t= he=20 cost of duplicating the service at=20 all?
    [[LLi]] =20 There is a big difference between maintaining a web page with a = table=20 which operator can print and implement in their darabases=20 and operating a database which is queried for every emergen= cy=20 call in Germany, must have an availablity of=20 99,99...% ,  is secure enough...you know. The=20 regulator will not do this.


    2    =   =20 We have no intention to rely on end devices for location information= =20 because:
    =B7      = ED pro= vided=20 location info is not trusted

    [[MCD]]=20 Location by reference mitigates this trust issue. The emergency network= can=20 (automatically and before human resources are engaged) assess the sourc= e of=20 the reference, and the validity of the location by dereference, without= =20 having to trust location provided directly from the ED. There are more= =20 sophisticated approaches to trustability even using LbyV =96 based on d= igital=20 signatures across appropriate attributes. This WG and Geopriv haven=92t= really=20 got to grips with that=85 yet.
    [[LLi]]  We=20 build the SIP-network and EC now. ED-provided location is=20 needed if EC must work for private and enterprise networ= ks=20 and VPNs.  We have no such regulatory requirements.  And= we=20 don't know of any verdor of DSL-EDs which provides today= SIP=20 with LbyR and is as cheap as the devices without it. If you d= o,=20 please let me know. 

    The=20 regulator ask us to guarantee that EC works. What if a custom= er=20 dials 112 and his end device does not send the location?= So I=20 have to implement both solutions, with and without ED provided location= ,=20 anyway.  
    1     &nbs= p; There=20 are already a lot of existing EDs in usage which don=92t send=20 location.   

    [[MCD]]=20 Quite right. ECRIT doesn=92t overly concern itself with that interim=20 situation. The UK and Canadian definition= s for=20 an interim solution (limiting service to in-country VoIP proxy operator= s)=20 both assume third-party query via identity-extension to allow the proxy= or=20 the VPC to make the query to the LIS. This isn=92t extensible to univer= sal=20 emergency service access by all visiting devices but it does put the=20 necessary LIS functionality in place as a very good starting=20 point.  It would be a pity if Germany were to cease the= =20 evolution there as it would not fulfil the real promise of the Internet= and=20 the ECRIT model.
    [[LLi]] =20 I wonder who will drive and pay for upgrading the interi= m=20 solutions.  Unfortunatelly, it's all about=20 money...

     Think=20 about it; all the complexity of putting location determination=20 infrastructure in place for the purposes of dispatch is done =96 and th= en the=20 next, simpler step, of using that to support the routing procedure isn= =92t=20 taken=85 that would be a waste.

    [[LLi]] =20 Do you think this is an argument for a product manager? They need = a=20 business case. 

     

     

    &nb= sp; We=20 don=92t intend to require our ED-vendors to provide location because it= is=20 useless to us.  

    We could agree with the documen= t with=20 following changes: <= /P>

      • Other location identifiers = then=20 geo or civil are allowed. It must be possibe that the data foermat = is=20 flexible due to different requirements from regulators over the who= le=20 world. (e.G Germany area codes for= fixed-=20 and Cell-Id for moile- providers)= =20
      • The MUST for the end device= s to=20 support location information, DHCP location options and HELD shall = be=20 removed
      • It must be possible for the= =20 VoIP-provider=92s proxy to use a LOST (or an ESRP) provided by the = AN or=20 by other local provider on behalf of the AN. =20

     

     There is no value in Hum-= ing=20 documents which one is not going to implement and does not fit into=20 regulated schemes like in Germany. Currently, neithe= r the=20 IETF- nor the 3GPP-architecture for emergency calling covers our real n= eeds=20 for the next 2 to 5 years and in the end everybody still has its own=20 proprietary implementation.    =

    Best regards

    Roland=20

     

    Deutsche Te= lekom=20 Netzproduktion GmbH
    Zentrum Technik Einf=FChrung
    Roland Jesske
    Gateways, Protokolle,=20 Konvergenz, TE32-1
    Heinrich-Hertz-Str. 3-7, = 64295=20 Darmstadt,
    = Postfach,=20 64307 Darmstadt (Postanschrift)
    +496151 628 2766=20 (Tel)
    +491718618445=20 (Mobile)
    E-Mail: = r.jesske@te= lekom.de=20
    http://www.telekom.de=20

     

    Registerrechtliche=20 Unternehmensangaben:
    Deutsche Telekom Netzpro= duktion=20 (DT NP) GmbH
    Aufsichtsrat: Timotheus H=F6ttges=20 (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 Al    bert Matheis, Klaus Peren
    Handelsregister: Amtsgeric= ht=20 Bonn HRB 14190
    Sitz der Gesellschaft: Bonn
    USt-IdNr.: DE=20 814645262

     

     


    ---------------------= ---------------------------------------------------------------------------=
    This message is for the designated recipi= ent only and may
    contain privileged, proprietar= y, or otherwise private information.  
    If&= nbsp;you have received it in error, please&nb= sp;notify the sender
    immediately and delete the=  original.  Any unauthorized use of
    this&n= bsp;email is prohibited.
    -------------------------------------= -----------------------------------------------------------
    [mf2]

     




    -------------------------------------------------------------= -----------------------------------
    This message is for&n= bsp;the designated recipient only and may
    conta= in privileged, proprietary, or otherwise private&n= bsp;information.  
    If you have received it=  in error, please notify the sender
    immedi= ately and delete the original.  Any unau= thorized use of
    this email is prohibited.
    --= ---------------------------------------------------------------------------= -------------------
    [mf2]
    <= /HTML> --_000_EDC0A1AE77C57744B664A310A0B23AE208661D0BFRMRSSXCHMBSC3d_-- From Hannes.Tschofenig@gmx.net Fri Aug 7 01:00:35 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C8D3A6939 for ; Fri, 7 Aug 2009 01:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=1.161, 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 qtZt9qkAhBeV for ; Fri, 7 Aug 2009 01:00:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B01633A689F for ; Fri, 7 Aug 2009 01:00:33 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2009 08:00:35 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 07 Aug 2009 10:00:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+NLMxMnp+NvC6I7wrp6s3HlC3TZQPxYiBuCGcFC0 AI2umxTGdbnGrY From: "Hannes Tschofenig" To: "'Francois Menard'" , "'ecrit'" References: <9B2661AD-4413-49A2-A4E5-D59A43678290@xittel.net> Date: Fri, 7 Aug 2009 11:03:07 +0300 Message-ID: <051c01ca1735$7ffe53c0$625aa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoWjC0Ecd17xZxUTKeQnzlAoii7BAApwoBg In-Reply-To: <9B2661AD-4413-49A2-A4E5-D59A43678290@xittel.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Subject: Re: [Ecrit] ECRIT Simplified E-9-1-1 workflow proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 08:00:35 -0000 Hi Francois, Quick feedback below. >Is anything wrong with the following E-9-1-1 workflow to be >possible with any ATA that can be upgraded to become Phone-BCP >compliant. > >Step 0) ISP is provided with a copy of the MASTER STREET >ADDRESS GUIDE already pre-formatted in PIDF-LO format. This is not really necessary for the ISP to have. I suspect you want to provide that information to the ISP since then he can do civic address validation locally. The solution would still be OK by not having it locally but rather maintained by someone else, such as the emergency services network, in the spirit of NENA i2/i2.5, via LoST or some other mechanisms. Hence, I don't see this part as crucial for your solution. > ISP >provisions a DHCP server/ HELD server with a PIDF-LO object to >be associated with the IP address to be assigned to an >end-user based on the WIREMAP circut-ID. In DSL wholesale, >the ISP uses the CIRCUT-ID acquired by RADIUS for a given >MSAG-VALID CIVIC PIDF-LO object. The ISP then simply matches >the PPP username and password arriving on a given CIRCUIT-ID >to create a binding between the PUBLIC-IP associated >dynamically to the CIRCUIT-ID and the PIDF-LO object. The ISP >really does not care about the PPP credentials. All it wants >to do is BIND a PIDF-LO to a CIRCUIT-ID to an IP address and >allow for that PIDF-LO to be retrieved EITHER via HELD, or via >DHCP OPTION 99. > >For instance, ILECs for their L2TP LAC's are transitioning to >Juniper E320's - 8.2.3 patch-0.4 which is capable of the >following formats to pass along the unique DSLAM port to be >associated with a CIVIC address over RADIUS to the wholesale >ISP as described in >https://www.juniper.net/techpubs/en_US/junose10.0/information-p >roducts/topic-collections/broadband-access/l2tp-calling-number-avp.html > The details of how the association of an IP address with location is done very much depends on the specific deployment at the ISP. Some operators might, for example, do IP address allocation within the AAA server and do not run a separate DHCP server. Hence, the interaction between the DHCP server and the AAA server becomes a local matter. So, in short you only want to say that the ISP has to provide the capability to associate the IP address with location. >Step 1) In DSL wholesale, PPPoE will assign an IP. The >reverse lookup would be done for this IP by the ATA. > >Step 2) If the ATA is behind nat, it would be provisioned with >a STUN server IP address. The STUN server will return to the >ATA, what public IP address the ATA is behind. > >Step 3) The ATA would then perform an inverse lookup for that >IP address in the DNS server of that domain name, and would >expect there to be a DNS entry for >LOCATIONSERVER.DOMAIN-GATHERED-BY-REVERSE- >LOOKUP.DOMAIN-GATHERED-BY-REVERSE-LOOKUP-SUFFIX > I guess that the previous 3 steps have the purpose of LIS discovery. Right? Maybe it would be good to say that. One could even provide example references to documents, such as http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-lis-discovery/ and http://tools.ietf.org/id/draft-thomson-geopriv-res-gw-lis-discovery-02.txt >Step 4) The ATA would then use its HELD stack to download the >location object (PIDF-LO). OK. > >Step 5) ATA Memorizes PIDF-LO. OK. > >Step 6) Upon having to dial 9-1-1, ATA sends PIDF-LO via >SIPCORE LOCATION CONVEYANCE (attached) OK. > >Step 7) VoIP server provider will steer the call to the an >ILEC SIP PROXY and send the 9-1-1 RTP media to the ILEC 9-1-1 >media gateway You might want to provide some details on how this routing works and why the ILEC runs the SIP proxy. There is no reason why this gatewaying cannot be provided by someone else. For example, how would the VoIP provider figure out what proxy to send it? Would it have some "mapping database" in the style of LoST or the NENA i2 solution? Or: Would it use anycast, like the guys in Sweden want todo? This step is important and requires more description. > >Step 8) ILEC will inspect the content of the PIDF-LO and will >route the call to the appropriate PSAP Depending how you do 7 this step might be omittet. > >All ILEC needs to do is to stop blocking the CIRCUIT-ID's over >the RADIUS accounting interface and accept to implement a >SIP-based gateway + media gateway on the INTERNET which would >provide access to all the PSAPs the ILEC manages (which is the >case in Canada where PSAPs only interconnect directly with the >ILEC and no other competitors). Why would you put this burden on the ILECs? I could imagine that PSAPs would either accept direct VoIP calls from the VSP or would allow the VSPs to pick their provider of choice for doing the VoIP-to-PSTN gatewaying when you have to deal with legacy PSAPs. > >I would appreciate answers by the end of the day on friday as >I am submitting this to the Canadian FCC (CRTC) friday evening. >F. Ciao Hannes > >-- >Francois Menard >fmenard@xittel.net > > > > >Francois Menard >fmenard@xittel.net > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From Martin.Dawson@andrew.com Fri Aug 7 01:10:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD0B3A6E7E for ; Fri, 7 Aug 2009 01:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJzgUMz-XujQ for ; Fri, 7 Aug 2009 01:10:00 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id AB5B13A67F0 for ; Fri, 7 Aug 2009 01:09:40 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_07_03_32_26 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); Fri, 07 Aug 2009 03:32:25 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 03:09:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1736.4E89745F" Date: Fri, 7 Aug 2009 03:08:53 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42AAJDiUoAAA+bkAAAFk66wAL5PVgAAdLrWg References: From: "Dawson, Martin" To: "DRAGE, Keith (Keith)" , "Marc Linsner" , , X-OriginalArrivalTime: 07 Aug 2009 08:09:43.0411 (UTC) FILETIME=[6B957430:01CA1736] Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 08:10:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1736.4E89745F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Keith,=0D=0A=0D=0A=20=0D=0A=0D=0AWRT:=0D=0A=0D=0AWhere IMS is suppor= ted, there is also a requirement to support emergency=0D=0Acalling on IMS.=0D= =0A=0D=0A=20=0D=0A=0D=0ACan you elaborate please=3F Where is this requireme= nt applicable and by=0D=0Awhat legislation/docket=3F I'm assuming you'd agr= ee that IMS is in fact=0D=0AVoIP - but I probably shouldn't.=0D=0A=0D=0A =0D= =0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A_____________________________= ___=0D=0A=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On Behalf=0D=0AOf DRAGE, Keith (Keith)=0D=0ASent: Friday, 7 August 2009 5:= 36 PM=0D=0ATo: Marc Linsner; Gabor.Bajko@nokia.com; ecrit@ietf.org=0D=0ASub= ject: Re: [Ecrit] ECRIT/IMS - independent discussion from the=0D=0APhoneBCP= hum=0D=0A=0D=0A=20=0D=0A=0D=0AObviously mandates differ between different = parts of the world, but=0D=0Acertainly any wireless operator (2G or 3G) is = currently required by the=0D=0A3GPP standards, reflecting national regulati= on, to provide ermegency=0D=0Acalling where they provide CS voice service o= n their networks.=0D=0A=0D=0A=20=0D=0A=0D=0AWhere IMS is supported, there i= s also a requirement to support emergency=0D=0Acalling on IMS.=0D=0A=0D=0A =0D= =0A=0D=0AFor the deployments where an operator is providing LTE in an area = not=0D=0Acovered by 2G or 3G service, there are indications prior to the ne= twork=0D=0Aselection to enable determination of whether an emergency call i= s=0D=0Apossible over IMS or not.=0D=0A=0D=0A=20=0D=0A=0D=0AWhat this essent= ially boils down to is that if you have an contract with=0D=0Aa 3G operator= to give you voice service, then emergency calls will work=0D=0Aon that pho= ne, because the network operator is required to support it.=0D=0AThat appli= es whether there is an internet browser on the phone or not.=0D=0A=0D=0A =0D= =0A=0D=0AAs far as I know there is currently no mandate on any ISP or indee= d=0D=0Ainternet VOIP provider to support emergency calls. That may come in = the=0D=0Afuture, but so far I have seen no evidence of it.=20=0D=0A=0D=0A =0D= =0A=0D=0ASo writing a document that claims that some other mechanism is the= way=0D=0Ato offer emergency calls, and then shouting from the rooftops tha= t this=0D=0Aapplies to mobile phones, is more likely to result in deaths th= an not.=20=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0Aregards=0D= =0A=0D=0A=20=0D=0A=0D=0AKeith=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=0D=0A_______= _________________________=0D=0A=0D=0A=0D=0A=09From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On=0D=0ABehalf Of Marc Linsner=0D=0A=09Sent= : Wednesday, August 05, 2009 8:30 PM=0D=0A=09To: Gabor.Bajko@nokia.com; ecr= it@ietf.org=0D=0A=09Subject: Re: [Ecrit] ECRIT/IMS - independent discussion= from the=0D=0APhoneBCP hum=0D=0A=0D=0A=09Gabor,=0D=0A=0D=0A=09=09=09=0D=0A= =09=09=09=0D=0A=09=09=09 But reliability and mobility were the=0D=0A= main architectural design choices in 3GPP. That is why they ended up=0D=0Aw= ith that complex architecture! The procedures themselves are a=0D=0Aconsequ= ence of the architecture.=0D=0A=09=09=09=0D=0A=09=09=09Carriers plan to sw= itch emergency call handling=0D=0Afrom CS to PS domain, and they wanted a n= etwork controlled ES, they did=0D=0Anot want to rely on the handset doing = the whole procedure because of=0D=0Athe liability. Support for emergency c= alls is not a revenue generator=0D=0Afor carriers, they'd be happy leaving = the tasks up to the client if=0D=0Athere were no consequences of emergency = calls failing for whatever=0D=0Areason.=0D=0A=09=09=09=0D=0A=09=09=09And ju= st to answer James point, ISPs offering=0D=0Abroadband internet service can= not be paralelled with carriers operating=0D=0Anetworks using 3GPP standar= ds. The ISPs do not commit to offer you=0D=0Aservice with less than a few = minutes outage per year, they provide no=0D=0Amobility and they are not ma= ndated to support emergency services.=0D=0A=09=09=09=0D=0A=09=09=09=0D=0A=09= =09=09=0D=0A=09=09=09- gabor=0D=0A=09=09=09=0D=0A=09=09=09=0D=0A=09=09=09[M= arc] Are you implying that 3GPP carriers=0D=0Aoperating a packet voice serv= ice have a different mandate for supporting=0D=0Aemergency services than an= OTT provider that sells packet voice=0D=0Aservices=3F (my understanding, = which could be wrong, is that VoIP is VoIP=0D=0Ano matter who is the SP)=0D= =0A=09=09=09=0D=0A=09=09=09Or is this a 3GPP self-inflicted mandate that is=0D= =0Atrying to emulate 2G circuit-switched services=3F=0D=0A=09=09=09=0D=0A=09= =09=09=0D=0A=09=09=09-Marc-=0D=0A=09=09=09=0D=0A=09=09=09=0D=0A=09=09=09=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA1736.4E89745F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= Re: ECRIT/IMS - independent discussion from the PhoneBCP hum=0D= =0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
    =0D=0A=0D=0A

    Thanks Keith,<= /span>

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

     

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

    WRT:

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

    Where IMS is supp= orted, there is also a=0D=0Arequirement to support emergency calling on IMS= =2E

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

     

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

    Can you elaborate please= =3F Where is this=0D=0Arequirement applicable and by what legislation/docke= t=3F I’m assuming you’d=0D=0Aagree that IMS is in fact VoIP = 211; but I probably shouldn’t.

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

     

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

    Cheers,

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

    = Martin

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

    From:=0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounce= s@ietf.org] On Behalf Of DRAGE, Keith (Keith)
    =0D=0ASent: Friday, 7 August 2009 5:36=0D=0APM
    =0D=0ATo: Marc Linsner;=0D=0AGabor.Bajko@nokia.com; ecr= it@ietf.org
    =0D=0ASubject: Re: [Ecrit] ECRIT/IMS -=0D=0Aindependent discussion from the PhoneBCP hum=

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

     

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

    Obviously mandate= s differ between=0D=0Adifferent parts of the world, but certainly any wirel= ess operator (2G or 3G) is=0D=0Acurrently required by the 3GPP standards, r= eflecting national regulation, to=0D=0Aprovide ermegency calling where they= provide CS voice service on their=0D=0Anetworks.<= /p>=0D=0A=0D=0A

     

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

    Where IMS i= s supported, there is also a=0D=0Arequirement to support emergency calling = on IMS.

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

    &n= bsp;

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

    For the deployments where an operator is=0D=0Aprov= iding LTE in an area not covered by 2G or 3G service, there are indications=0D= =0Aprior to the network selection to enable determination of whether an eme= rgency=0D=0Acall is possible over IMS or not.

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

     

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

    What this essenti= ally boils down to is=0D=0Athat if you have an contract with a 3G operator = to give you voice service, then=0D=0Aemergency calls will work on that phon= e, because the network operator is=0D=0Arequired to support it. That applie= s whether there is an internet browser on=0D=0Athe phone or not.

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

     

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

    As far as I know there is currently no=0D=0Amandate on any ISP or in= deed internet VOIP provider to support emergency calls.=0D=0AThat may come = in the future, but so far I have seen no evidence of=0D=0Ait. 

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

     <= /o:p>

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

    So writing a document that claims that=0D=0Asome other mecha= nism is the way to offer emergency calls, and then shouting=0D=0Afrom the r= ooftops that this applies to mobile phones, is more likely to result=0D=0Ai= n deaths than not.

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

     

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

     

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

     

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

    regards

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

     

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

    Keith

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

     

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

    <= font size=3D2 face=3DTahoma>From:=0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner=
    =0D=0ASent: Wednesday, A= ugust 05, 2009=0D=0A8:30 PM
    =0D=0ATo= : Gabor.Bajko@nokia.com;=0D=0Aecrit@ietf.org
    =0D=0ASubject: Re: [Ecrit] ECRIT/IMS -=0D=0A= independent discussion from the PhoneBCP hum

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

    Gabor,

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


    =0D= =0A
    =0D=0A    <Gabor> But=0D=0Areliability and mobilit= y were  the main architectural design choices in=0D=0A3GPP. That is wh= y they ended up  with that complex architecture! The=0D=0Aprocedures t= hemselves are a consequence  of the architecture.
    =0D=0A
    =0D=0A    Carriers plan to switch=0D=0Aemergency call handling &= nbsp;from CS to PS domain, and they wanted a network=0D=0Acontrolled ES, th= ey did not  want to rely on the handset doing the whole=0D=0Aprocedure= because of the  liability. Support for emergency calls is not a=0D=0A= revenue generator  for carriers, they'd be happy leaving the tasks up = to=0D=0Athe client if  there were no consequences of emergency calls f= ailing for=0D=0Awhatever  reason.
    =0D=0A
    =0D=0A    = And just to answer James=0D=0Apoint, ISPs offering  broadband i= nternet service can not be paralelled=0D=0Awith carriers operating  ne= tworks using 3GPP standards. The ISPs do not=0D=0Acommit to offer you servi= ce  with less than a few minutes outage per year,=0D=0Athey provide no= mobility and  they are not mandated to support emergency=0D=0A s= ervices.
    =0D=0A
    =0D=0A
    =0D=0A
    =0D=0A=     - gabor
    =0D= =0A
    =0D=0A
    =0D=0A[Marc] Are you i= mplying that 3GPP carriers operating a packet voice service=0D=0Ahave a dif= ferent mandate for supporting emergency services than an OTT provider=0D=0A= that sells packet voice services=3F  (my understanding, which could be=0D= =0Awrong, is that VoIP is VoIP no matter who is the SP)
    =0D=0A
    =0D=0A= Or is this a 3GPP self-inflicted mandate that is trying to emulate 2G=0D=0A= circuit-switched services=3F
    =0D=0A
    =0D=0A
    =0D=0A-Marc-
    =0D=0A<= /span>
    =0D=0A
    =0D=0A

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


    ------------------------------------------= ------------------------------------------------------
    =0D=0AThis m= essage is for the designated recipient only&n= bsp;and may
    =0D=0Acontain privileged, proprietary, o= r otherwise private information.  
    =0D=0AIf&nbs= p;you have received it in error, please = notify the sender
    =0D=0Aimmediately and delete = the original.  Any unauthorized use of
    =0D= =0Athis email is prohibited.
    =0D=0A----------------------= --------------------------------------------------------------------------<= br>=0D=0A[mf2]
    =0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01CA1736.4E89745F-- From Martin.Dawson@andrew.com Fri Aug 7 01:11:04 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3AB3A69EB for ; Fri, 7 Aug 2009 01:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.544 X-Spam-Level: X-Spam-Status: No, score=-0.544 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxRKSYavjDUa for ; Fri, 7 Aug 2009 01:10:42 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id A094F3A6E46 for ; Fri, 7 Aug 2009 01:10:41 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_07_03_33_27 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); Fri, 07 Aug 2009 03:33:26 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 03:10:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1736.864BF0B9" Date: Fri, 7 Aug 2009 03:10:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAAOKzRQAAW1mtAAHrEiQA== References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> From: "Dawson, Martin" To: "DRAGE, Keith (Keith)" , , , X-OriginalArrivalTime: 07 Aug 2009 08:10:44.0225 (UTC) FILETIME=[8FD4EF10:01CA1736] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 08:11:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1736.864BF0B9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Last I heard it should be published shortly.=0D=0A=0D=0A=20=0D=0A=0D=0AI'm = not sure what you're getting at. I was referring Laura to the (draft or wha= tever) interim recommendation as a useful piece of work to consider with re= spect to the German situation. Are you suggesting it's not useful and/or wi= ll not actually be published=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0A= Martin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0A= From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20=0D=0ASent: = Friday, 7 August 2009 5:37 PM=0D=0ATo: Dawson, Martin; L.Liess@telekom.de; = R.Jesske@telekom.de; ecrit@ietf.org=0D=0ACc: Reinhard.Lauster@t-mobile.at=0D= =0ASubject: RE: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=20=0D=0A=0D=0AYou said:=0D= =0A=0D=0A=20=0D=0A=0D=0AAs I say, check out the interim recommendations by = the CRTC in Canada and NICC in the UK.=20=0D=0A=0D=0A=20=0D=0A=0D=0AThere i= s no such thing as interim recommendations from UK NICC.=0D=0A=0D=0A=20=0D=0A=0D= =0AThere is a document under development. Whatever it currently says has no= status as a UK NICC document. The last I heard the document was under subs= tantial reediting.=0D=0A=0D=0A=20=0D=0A=0D=0Aregards=0D=0A=0D=0A=20=0D=0A=0D= =0AKeith=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=0D=0A____________________________= ____=0D=0A=0D=0A=0D=0A=09From: ecrit-bounces@ietf.org [mailto:ecrit-bounces= @ietf.org] On Behalf Of Dawson, Martin=0D=0A=09Sent: Thursday, August 06, 2= 009 4:21 PM=0D=0A=09To: L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf= =2Eorg=0D=0A=09Cc: Reinhard.Lauster@t-mobile.at=0D=0A=09Subject: Re: [Ecrit= ] HUM on PhoneBCP=0D=0A=0D=0A=09I neglected to do a point by point, sorry. = So - that follows:=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Cheers,=0D=0A=0D=0A=09Ma= rtin=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=0D=0A________________________________=0D= =0A=0D=0A=0D=0A=09From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20=0D= =0A=09Sent: Friday, 7 August 2009 12:29 AM=0D=0A=09To: Dawson, Martin; R.Je= sske@telekom.de; ecrit@ietf.org=0D=0A=09Cc: Reinhard.Lauster@t-mobile.at=0D= =0A=09Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09= Hi Martin,=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09See comments inline [[LLi]].=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Laura=0D=0A=0D=0A=09=09From= : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawso= n, Martin=0D=0A=09=09Sent: Wednesday, August 05, 2009 11:00 AM=0D=0A=09=09T= o: Jesske, Roland; ecrit@ietf.org=0D=0A=09=09Subject: Re: [Ecrit] HUM on Ph= oneBCP=0D=0A=0D=0A=09=09Hi Roland,=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09I = think what you're saying is that you don't think that Germany will go on to= implement full ECRIT support but will peg development at an interim phase.= =20=0D=0A=09=09[[LLi]] We don't know how the realtime application networks= or EC will look like in 20 years. Roland's answer only applies to the next= 5 to 10 years.=20=0D=0A=0D=0A=09=09[[MCD]] The implementation of the LIS f= unction is the most significant aspect for operators - and that needs to ha= ppen in short term scenarios in any case. The provision of LoST can be a na= tional asset/service. The provision of PSAP URIs is an emergency service re= sponsibility. Those are the key requirements - and that does provide a fram= ework that will work into the next 20 years and beyond.=0D=0A=0D=0A=09=09 =0D= =0A=0D=0A=09=09 That would be disappointing - not least because full ECRIT = compliance would ultimately decrease the overhead associated with emergency= service support for operators as well as providing a more universal servic= e.=0D=0A=09=09=0D=0A=09=09[[LLi]] This may be true for "green field" ISPs = and VSPs but not for incumbent carriers with existing infrastructure. And = universal service is not a requirement for us. Neither the German regulator= requires it nor is it a busines case. =20=0D=0A=0D=0A=09=09[[MCD]] I thin= k this is only true to the same extent that a pure Internet green field ISP= only has to worry about Internet trunk connectivity and doesn't have to wo= rry about PSTN circuit trunk connectivity. The latter infrastructure is leg= acy and not particularly applicable to the Internet component of the servic= e. Providing ECRIT emergency calling support requires the addition of a LIS= , access to LoST (whoever hosts it), and a route to the PSAP URI(s). Both t= ypes of operator need to do that. Whatever switched circuit legacy emergenc= y infrastructure already exists in the established operator needs to contin= ue to exist to support the emergency calls on that access.=0D=0A=0D=0A=09=09= =20=0D=0A=0D=0A=09=09Nevertheless, I don't think that decision invalidates = the BCP;=20=0D=0A=09=09[[LLi]] We think it does, because some of the requi= rements are not flexible enough to cover the deployments within the next ye= ars. The BCP should be more flexible: =20=0D=0A=0D=0A=09=09*=09Allow addit= ional location identifiers =20=0D=0A=0D=0A=09=09[[MCD]] Agreed - although t= hat can be done by local-specific use of fields in the PIDF-LO based on jur= isdictional convention and be appropriately parsed by LoST in that jurisdic= tion in a quite transparent fashion. A German technical advisory committee = could make this recommendation within that jurisdiction without deference t= o the BCP and without impact to ECRIT-compliant devices.=0D=0A=0D=0A=09=09*= =09Allow AN operated LOST=20=0D=0A=0D=0A=09=09[[MCD]] I don't think the BCP= excludes the possibility of the access network hosting LoST. It shouldn't = - since this is a jurisdictional decision. As long as the LoST service can = be discovered/used when attached to the access, it shouldn't matter where i= t is hosted.=0D=0A=0D=0A=09=09*=09Provide a way to enable LOST-query based = on national or domain-specific location identifier. One posiblility is to a= llow the LIS to query the LOST , but there are also other alternatives.=20=0D= =0A=0D=0A=09=09[[MCD]] I was in favour of the LIS proxying the LoST request= - since they both share a "locality" it simplifies the whole discovery plo= t. However, that didn't take hold in the debate so we have what we have. Gi= ven that - a LIS still need only provide the national level location (i.e. = DE) in the PIDF-LO if that's all that's required to make a successful LoST = query. The rest can be done using LbyR - with the LIS also providing the re= ference along with the coarse location. Doesn't that satisfy the requiremen= t=3F=0D=0A=0D=0A=09=09*=09Allow and describe also network-centric, not only= ED-centric architectures. If I remember correctly, John Medland from BT a= lso recomended to use a more network- centric architecture, at least for th= e next years.=20=0D=0A=0D=0A=09=09[[MCD]] I don't really understand this "X= -centric" argument. Even traditional cellular architectures require a combi= nation of end device and network capabilities. Maybe if you are being speci= fic you mean; there should be no ECRIT-specific requirements on the end dev= ice (though I'm not sure why ECRIT should have this rule when other archite= ctures don't). You're right John M did propose such an approach. Not to put= words in his mouth, but this was in the context of an interim architecture= - per my comments below on the Canada and UK interim approaches. It works = in the limited scope of devices having to proxy calls through "national" Vo= IP carriers - it doesn't meet the long term vision of ECRIT. An interim arc= hitecture, by definition, is not the end-game architecture. ECRIT only seek= s to define the end-game; there are already interim architectures to choose= from - which was my point about suggesting it might be better to baseline = off i2 for the time being rather than trying to shoehorn interim constraint= s into ECRIT.=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09I think it just means t= hat the German regulator and technical advisory committees would point out = the subset aspects of compliance that would be applicable to that jurisdict= ion. =20=0D=0A=09=09[[LLi]] Again, the draft is not flexible enough for it= =2E If the BCP contains requirements which are not realistic, people will = just discard the BCP and implement proprietary stuff. My expectation from a= standard body is to define protocols and architecture which people are wil= ling to implement in their network or products , not only in the lab.=0D=0A=0D= =0A=09=09[[MCD]] What I mean is that compliance isn't compulsory. It's OK t= o say "we have decided to deviate from the specification in this way".=0D=0A=0D= =0A=09=09=20=0D=0A=0D=0A=09=09[[LLi]] =20=0D=0A=0D=0A=09=09We are not again= st the draft in principle. ECRIT provides us with very valuable specificat= ions as LbyR, HELD, identity extensions. But targeting an architecture whic= h requires everbody to invest without a business case will not help the dra= ft in the end, also if it becomes a BCP. It would make sense to make it mo= re flexible so people are willing to adopt it. =20=0D=0A=0D=0A=09=09[[MCD= ]] Lots of the elements you mention exist outside of the BCP - LbyR, HELD, = identity extensions... they aren't defined by the BCP and can be used in an= y other context. The BCP has a very specific goal of defining a way that em= ergency calls can be made by any Internet connected device/proxy anywhere t= hat follows the specification; it doesn't seek to be more than that - which= I think is what you're looking for. As I say, check out the interim recomm= endations by the CRTC in Canada and NICC in the UK.=0D=0A=0D=0A=09=09=20=0D= =0A=0D=0A=09=09 Actually, based on your description below, the NENA i2 arch= itecture would probably be a more straightforward baseline for analysis - a= s has been done in the UK and Canada. Of course, it's generally recognized = as only an interim step, even in those jurisdictions.=0D=0A=0D=0A=09=09Othe= r comments below.=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09Cheers,=0D=0A=0D=0A= =09=09Martin=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09=0D=0A__________________= ______________=0D=0A=0D=0A=0D=0A=09=09From: ecrit-bounces@ietf.org [mailto:= ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de=0D=0A=09=09Sent: W= ednesday, 5 August 2009 6:19 PM=0D=0A=09=09To: ecrit@ietf.org=0D=0A=09=09Su= bject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09 =0D= =0A=0D=0A=09=09Dear all,=20=0D=0A=09=09We would like the document to become= a BCP as soon as possible so the group can move on with other documents re= lated to emergency calling based on location-by-reference and ED's IP-addre= ss.=20=0D=0A=0D=0A=09=09[[MCD]] I think you might mean "identity extensions= " rather than location-by-reference because LbyR still requires the ED to o= btain the reference - e.g. by HELD.=0D=0A=09=09[[LLi]] We use both, the IP-= address as UE identity and LbyR. The SIP-proxy uses the IP-address to query= the LIS using HTTP (it's not HELD but SOAP over HTTP, but anyway similar).= The LIS responds with a numeric string associated to the caller location, = in principle a LbyR and with the PSAP number. The proxy inserts the LbyR in= to the SIP-message (as P-Asserted-ID because the PSAPs are in PSTN) and rou= tes the message to the PSAP. It's a low cost solution.=20=0D=0A=0D=0A=09=09= But we can not HUM for the current form of the document.=20=0D=0A=0D=0A=09=09= Back to the document: Some requirements are far form being realistic, at le= ast in Germany, some are not realistic at all. Implementing these requireme= nts cost a carrier a lot of money and there is no ROI for it.=20=0D=0A=0D=0A= =09=09Just a few examples:=20=0D=0A=0D=0A=09=09=B7 Requiring either g= eo or civic location does not provide carriers with enough flexibility to r= euse their existing mechanisms and location databases. Routing of emergency= calls is currently done in Germany based on phone area code not on geo or = civic location, at least for the fixed network. For mobile networks the cel= l-id is used in common. This is regulated by the german regulator.=20=0D=0A=0D= =0A=09=09[[MCD]] How many unique PSAP routes are required in Germany=3F The= US has lots (6000 plus) and Australia has two (and they are redundant so i= t doesn't matter which one). Presumably geographic information, for PSAP ca= tchment areas, is the basis for determining which area codes are relevant t= o begin with=3F After all, an area code is not intrinsically geographic; it= 's a network routing value. If so, then some geographic discriminator is al= ready in play in terms of constructing the area code based routing data (so= mething like zip codes perhaps=3F) - and in that case, it should be straigh= tforward to by-pass the area code step in the construction of routing that = goes the correct PSAP URI.=20=0D=0A=09=09[[LLi]] Currently, fixed networks = carriers in Germany route the ECs based only on the caller's area code. Som= etime in the past, the carriers, the regulator and the PSAPs operators (pol= ice, the Red Cross) agreed to do so. This may change in the future, but it = will take a quite long time. =20=0D=0A=0D=0A=09=09 With nomadic VoIP de= vices (and it's no good being in denial about this being the norm in the fu= ture) area code is no more reliable than it is for conventional mobile phon= es. And, presumably, area code is not used for conventional cellular emerge= ncy call routing=3F=0D=0A=09=09[[LLi]] As far as I know, mobile networks u= se the Cell-ID, not the area code, and have a different table than the fixe= d network operators. They are not going to change this. As to the nomadic = SIP-users...if we like it or not, very few of our customers use our SIP ser= vice nomadic, let alone call EC from their laptop. =20=0D=0A=0D=0A=09= =091 LOST as a national, let alone as a global directory is no= t going to be implemented. The regulator will provide in the web a static t= able which contains the PSAPs and the area for which they are responsible (= one or more area codes). Every carrier has to implement its own routing dat= abase for emergency calls.=20=0D=0A=0D=0A=09=09=09[[MCD]] Whatever the carr= iers implement (and they have to implement something) could just as readily= be done using LoST. Then visiting devices, with no association with any lo= cal VoIP proxy server would still be able to determine a route to the corre= ct PSAP. Alternatively, as long as the regulator is maintaining a web servi= ce with the routing information, why not make that directly accessible usin= g LoST and save the operators the cost of duplicating the service at all=3F=0D= =0A=09=09=09[[LLi]] There is a big difference between maintaining a web pa= ge with a table which operator can print and implement in their darabases a= nd operating a database which is queried for every emergency call in German= y, must have an availablity of 99,99...% , is secure enough...you know. Th= e regulator will not do this.=0D=0A=0D=0A=09=09=09=0D=0A=09=09=092 We= have no intention to rely on end devices for location information because:= =20=0D=0A=09=09=09=B7 ED provided location info is not trusted=20=0D=0A=0D= =0A=09=09[[MCD]] Location by reference mitigates this trust issue. The emer= gency network can (automatically and before human resources are engaged) as= sess the source of the reference, and the validity of the location by deref= erence, without having to trust location provided directly from the ED. The= re are more sophisticated approaches to trustability even using LbyV - base= d on digital signatures across appropriate attributes. This WG and Geopriv = haven't really got to grips with that... yet.=0D=0A=09=09[[LLi]] We build = the SIP-network and EC now. ED-provided location is needed if EC must work = for private and enterprise networks and VPNs. We have no such regulatory r= equirements. And we don't know of any verdor of DSL-EDs which provides tod= ay SIP with LbyR and is as cheap as the devices without it. If you do, plea= se let me know.=20=0D=0A=0D=0A=09=09The regulator ask us to guarantee that = EC works. What if a customer dials 112 and his end device does not send the= location=3F So I have to implement both solutions, with and without ED pro= vided location, anyway. =20=0D=0A=09=091 There are already a lot of e= xisting EDs in usage which don't send location. =20=0D=0A=0D=0A=09=09[[MC= D]] Quite right. ECRIT doesn't overly concern itself with that interim situ= ation. The UK and Canadian definitions for an interim solution (limiting se= rvice to in-country VoIP proxy operators) both assume third-party query via= identity-extension to allow the proxy or the VPC to make the query to the = LIS. This isn't extensible to universal emergency service access by all vis= iting devices but it does put the necessary LIS functionality in place as a= very good starting point. It would be a pity if Germany were to cease the= evolution there as it would not fulfil the real promise of the Internet an= d the ECRIT model.=20=0D=0A=09=09[[LLi]] I wonder who will drive and pay f= or upgrading the interim solutions. Unfortunatelly, it's all about money..= =2E=0D=0A=0D=0A=09=09 Think about it; all the complexity of putting locatio= n determination infrastructure in place for the purposes of dispatch is don= e - and then the next, simpler step, of using that to support the routing p= rocedure isn't taken... that would be a waste.=0D=0A=09=09=0D=0A=09=09[[LLi= ]] Do you think this is an argument for a product manager=3F They need a b= usiness case. =20=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09= We don't intend to require our ED-vendors to provide location because it = is useless to us. =20=0D=0A=0D=0A=09=09We could agree with the document wi= th following changes:=20=0D=0A=0D=0A=09=09=09*=09Other location identifiers= then geo or civil are allowed. It must be possibe that the data foermat is= flexible due to different requirements from regulators over the whole worl= d. (e.G Germany area codes for fixed- and Cell-Id for moile- providers)=20=0D= =0A=09=09=09*=09The MUST for the end devices to support location informatio= n, DHCP location options and HELD shall be removed=20=0D=0A=09=09=09*=09It = must be possible for the VoIP-provider's proxy to use a LOST (or an ESRP) p= rovided by the AN or by other local provider on behalf of the AN. =20=0D=0A=0D= =0A=09=09=20=0D=0A=0D=0A=09=09 There is no value in Hum-ing documents which= one is not going to implement and does not fit into regulated schemes like= in Germany. Currently, neither the IETF- nor the 3GPP-architecture for eme= rgency calling covers our real needs for the next 2 to 5 years and in the e= nd everybody still has its own proprietary implementation. =20=0D=0A=0D=0A= =09=09Best regards=20=0D=0A=0D=0A=09=09Roland=20=0D=0A=0D=0A=09=09=20=0D=0A=0D= =0A=09=09Deutsche Telekom Netzproduktion GmbH=0D=0A=09=09Zentrum Technik Ei= nf=FChrung=0D=0A=09=09Roland Jesske=0D=0A=09=09Gateways, Protokolle, Konver= genz, TE32-1=0D=0A=09=09Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,=0D=0A=09=09= Postfach, 64307 Darmstadt (Postanschrift)=0D=0A=09=09+496151 628 2766 (Tel)=0D= =0A=09=09+491718618445 (Mobile)=0D=0A=09=09E-Mail: r.jesske@telekom.de =20=0D=0A=09=09http://www.telekom.de =20=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09Registerrechtliche Un= ternehmensangaben:=0D=0A=09=09Deutsche Telekom Netzproduktion (DT NP) GmbH=0D= =0A=09=09Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=0D=0A=09=09Gesch=E4= ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klau= s Peren=0D=0A=09=09Handelsregister: Amtsgericht Bonn HRB 14190=0D=0A=09=09S= itz der Gesellschaft: Bonn=0D=0A=09=09USt-IdNr.: DE 814645262=20=0D=0A=0D=0A= =09=09=20=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=20=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A=0D= =0A=09=20=0D=0A=0D=0A------------------------------------------------------= ------------------------------------------=0D=0AThis message is for the des= ignated recipient only and may=0D=0Acontain privileged, proprietary, or oth= erwise private information. =20=0D=0AIf you have received it in error, plea= se notify the sender=0D=0Aimmediately and delete the original. Any unautho= rized use of=0D=0Athis email is prohibited.=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= [mf2]=0D=0A ------_=_NextPart_001_01CA1736.864BF0B9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ARe= : [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D= =0A
    =0D=0A=0D=0A

    Last I heard it should be published=0D=0Ashortly.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    I’m not sure what you’re g= etting at. I was=0D=0Areferring Laura to the (draft or whatever) interim re= commendation as a useful=0D=0Apiece of work to consider with respect to the= German situation. Are you=0D=0Asuggesting it’s not useful and/or wil= l not actually be published=3F

    =0D=0A=0D=0A

     =

    =0D=0A=0D=0A

    Cheers,

    =0D=0A=0D=0A

    Martin

    =0D=0A=0D= =0A

     =

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A    =0D=0A=0D=0A

    From:=0D=0ADRAGE, Keith (Kei= th) [mailto:drage@alcatel-lucent.com]
    =0D=0ASent: Friday, 7 August 2009 5:37=0D=0APM
    =0D=0ATo:     Dawson, Martin;=0D=0AL.Liess@= telekom.de; R.Jesske@telekom.de; ecrit@ietf.org
    =0D=0ACc: Reinhard.Lauster@t-mobile.at
    =0D=0A<= span style=3D'font-weight:bold'>Subject: RE: [Ecrit] HUM on=0D=0A= PhoneBCP

    =0D=0A=0D=0A=
    =0D=0A=0D=0A

     <= /p>=0D=0A=0D=0A

    You s= aid:

    =0D=0A=0D=0A

     = ;

    =0D=0A=0D=0A

    As I=0D=0Asay, check out th= e interim recommendations by the CRTC in Canada and NICC in the UK.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    There is no such thing as inter= im=0D=0Arecommendations from UK NICC.

    =0D=0A=0D= =0A

     

    =0D=0A=0D=0A=

    There is a document u= nder development.=0D=0AWhatever it currently says has no status as a UK NIC= C document. The last I=0D=0Aheard the document was under substantial reedit= ing.

    =0D=0A=0D=0A

     = ;

    =0D=0A=0D=0A

    regards

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Keith<= /p>=0D=0A=0D=0A

    =0D=0A=0D=0A

    &= nbsp;

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D= =0A=0D=0A

    From:=0D= =0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawson, Martin
    =0D=0A= Sent: Thursday, August 06, 2009=0D= =0A4:21 PM
    =0D=0ATo: L.Li= ess@telekom.de;=0D=0AR.Jesske@telekom.de; ecrit@ietf.org
    =0D=0ACc: Reinhard.Lauster@t-mobile.at
    =0D= =0ASubject: Re: [Ecrit] HUM = on=0D=0APhoneBCP

    =0D=0A=0D= =0A

    I neglected to do= a point by point, sorry.=0D=0ASo – that follows:

    =0D=0A=0D=0A

    <= o:p> 

    =0D=0A=0D=0A

    Cheers,

    =0D=0A=0D=0A<= p class=3DMsoNormal>Martin

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D= =0A=0D=0A
    =0D=0A=0D= =0A
    =0D=0A=0D=0A

    From:=0D= =0AL.Liess@telekom.de [mailto:L.Liess@telekom.de]
    =0D=0ASent: Friday, 7 August 2009 12:29=0D=0AAM
    =0D= =0ATo: Dawson, Martin;=0D=0A= R.Jesske@telekom.de; ecrit@ietf.org
    =0D=0ACc: Reinhard.Lauster@t-mobile.at
    =0D=0ASubject: RE: [Ecrit] HUM on=0D=0APhoneBCP

    =0D=0A=0D=0A
    =0D=0A=0D= =0A

     

    =0D=0A=0D=0A=

    Hi Martin,

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    See comments inline [[LLi]].

    =0D=0A=0D=0A=

     

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Laura

    =0D=0A=0D=0A
    =0D=0A=0D=0A

    From:<= font=0D=0Asize=3D2 face=3DTahoma>=0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf= =2Eorg] On Behalf Of Da= wson, Martin
    =0D=0ASent: = Wednesday, August 05, 2009=0D=0A11:00 AM
    =0D=0ATo: Jesske, Roland; ecrit@ietf.org
    =0D=0ASubject: Re: [Ecrit] HUM on=0D=0APhon= eBCP

    =0D=0A=0D=0A

    Hi Roland,

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    I think what you’re saying is that you=0D= =0Adon’t think that Germany=0D=0Awill go on to implement = full ECRIT support but will peg development at an=0D=0Ainterim phase.
    =0D= =0A    [[LLi]]  We do= n't know how the=0D=0Arealtime application networks or EC will look li= ke in 20=0D=0Ayears. Roland's answer only applies to the nex= t 5 to 10 years. 

    =0D= =0A=0D=0A

    [[MCD]] The implementation of the LIS fu= nction is the most=0D=0Asignificant aspect for operators – and that n= eeds to happen in short term=0D=0Ascenarios in any case. The provision of L= oST can be a national asset/service.=0D=0AThe provision of PSAP URIs is an = emergency service responsibility. Those are=0D=0Athe key requirements ̵= 1; and that does provide a framework that will work into=0D=0Athe next 20 y= ears and beyond.

    =0D=0A=0D=0A

     <= o:p>

    =0D=0A=0D=0A

     Tha= t would be disappointing – not least because full ECRIT=0D=0Acomplian= ce would ultimately decrease the overhead associated with emergency=0D=0Ase= rvice support for operators as well as providing a more universal service.<= br>=0D=0A
    =0D=0A    <= span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial;color:blue'>[[LLi]]&= nbsp; This may be true for "green=0D=0Afield" ISPs and VSPs but n= ot for incumbent carriers with existing=0D=0Ainfrastructure. &nbs= p;And universal service is not a requirement for us.=0D=0ANeither the Germa= n regulator requires it nor is it a busines=0D=0Acase.  &nbs= p;

    =0D=0A=0D=0A

    [[MCD]] I think this is only true to the same extent that a=0D= =0Apure Internet green field ISP only has to worry about Internet trunk=0D=0A= connectivity and doesn’t have to worry about PSTN circuit trunk conne= ctivity.=0D=0AThe latter infrastructure is legacy and not particularly appl= icable to the=0D=0AInternet component of the service. Providing ECRIT emerg= ency calling support=0D=0Arequires the addition of a LIS, access to LoST (w= hoever hosts it), and a route=0D=0Ato the PSAP URI(s). Both types of operat= or need to do that. Whatever switched=0D=0Acircuit legacy emergency infrast= ructure already exists in the established operator=0D=0Aneeds to continue t= o exist to support the emergency calls on that access.

    =0D=0A=0D= =0A

     =

    =0D=0A=0D=0A

    Nevertheless, I don’t think that decision=0D=0Ainvalidates = the BCP;
    =0D=0A    <= span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial;color:blue'>[[LLi]]&= nbsp; We think it=0D=0Adoes, because some of the requirements are= not flexible enough to=0D=0Acover the deployments within the next years.&n= bsp; The BCP should be more=0D=0Aflexible:  

    =0D=0A=0D=0A
    =0D=0A=0D=0A
      =0D=0A
    • Allow a= dditional=0D=0A location identifiers  =0D=0A
    =0D=0A=0D=0A

    [[MCD]] Agreed – although that=0D= =0Acan be done by local-specific use of fields in the PIDF-LO based on=0D=0A= jurisdictional convention and be appropriately parsed by LoST in that=0D=0A= jurisdiction in a quite transparent fashion. A German technical advisory=0D= =0Acommittee could make this recommendation within that jurisdiction withou= t=0D=0Adeference to the BCP and without impact to ECRIT-compliant devices.<= /span>

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
      =0D=0A
    • Allow AN operated=0D=0A LOST =0D=0A
    =0D=0A=0D=0A

    [[MCD]] I don’t think the BCP=0D= =0Aexcludes the possibility of the access network hosting LoST. It shouldn&= #8217;t –=0D=0Asince this is a jurisdictional decision. As long as th= e LoST service can be=0D=0Adiscovered/used when attached to the access, it = shouldn’t matter where it is=0D=0Ahosted.

    =0D=0A=0D=0A
    =0D= =0A=0D=0A
    =0D=0A=0D=0A
      =0D=0A
    • Provide a way=0D= =0A to enable LOST-query based on national or=0D=0A domain-spe= cific location identifier. One posiblility is to allow=0D=0A = the LIS to query the LOST , but there are also other=0D=0A = alternatives.
      • =0D=0A
    =0D=0A=0D=0A

    [[MCD]] I was in favour of the=0D=0ALIS proxying the LoST request &#= 8211; since they both share a “locality” it=0D=0Asimplifies the= whole discovery plot. However, that didn’t take hold in the=0D=0Adeb= ate so we have what we have. Given that - a LIS still need only provide the=0D= =0Anational level location (i.e. DE) in the PIDF-LO if that’s all tha= t’s required=0D=0Ato make a successful LoST query. The rest can be do= ne using LbyR – with the LIS=0D=0Aalso providing the reference along = with the coarse location. Doesn’t that=0D=0Asatisfy the requirement=3F=

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
      =0D= =0A
    • Allow and describe=0D=0A also network-centric,= not only ED-centric architectures. If=0D=0A I  remember corr= ectly, John Medland from BT also recomended to=0D=0A use a more ne= twork- centric architecture, at least for the next years.=0D=0A=
      • =0D=0A
    =0D=0A=0D=0A

    [[MCD]] I don’= ;t really=0D=0Aunderstand this “X-centric” argument. Even tradi= tional cellular architectures=0D=0Arequire a combination of end device and = network capabilities. Maybe if you are=0D=0Abeing specific you mean; there = should be no ECRIT-specific requirements on the=0D=0Aend device (though I&#= 8217;m not sure why ECRIT should have this rule when other=0D=0Aarchitectur= es don’t). You’re right John M did propose such an approach. No= t to=0D=0Aput words in his mouth, but this was in the context of an interim= architecture=0D=0A– per my comments below on the Canada=0D=0Aand UK=0D=0Ainte= rim approaches. It works in the limited scope of devices having to proxy=0D= =0Acalls through “national” VoIP carriers – it doesn̵= 7;t meet the long term vision=0D=0Aof ECRIT. An interim architecture, by de= finition, is not the end-game=0D=0Aarchitecture. ECRIT only seeks to define= the end-game; there are already=0D=0Ainterim architectures to choose from = – which was my point about suggesting it=0D=0Amight be better to base= line off i2 for the time being rather than trying to=0D=0Ashoehorn interim = constraints into ECRIT.

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D= =0A=0D=0A

     

    =0D=0A=0D=0A
    =0D=0A=0D=0A

    = I think it just means that the German=0D=0A= regulator and technical advisory committees would point out the subset aspe= cts=0D=0Aof compliance that would be applicable to that jurisdiction.  =
    =0D=0A    [[LLi]]  Again, the draft is not flexible=0D=0Aenough = for it.  If the BCP contains requirements which are not=0D=0A= realistic, people will just discard the BCP and implement proprie= tary=0D=0Astuff. My expectation from a standard body is to define prot= ocols and=0D=0Aarchitecture which people are willing to implement in their = network or products=0D=0A, not only in the lab.=

    =0D=0A=0D=0A

    [[MCD]] What I= mean is that compliance isn’t compulsory.=0D=0AIt’s OK to say = “we have decided to deviate from the specification in this way”= =2E=

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    [[LLi]] 

    =0D=0A=0D=0A

    We are not against the draft in pri= nciple.=0D=0AECRIT provides&= nbsp; us with very val= uable specifications as LbyR, HELD, identity=0D=0Aextensions. But targ= eting an architecture which requires everbody to=0D=0Ainvest with= out a business case will not help the draft in=0D=0Athe end,= also if it becomes a BCP.  It would make sense to make it=0D=0Am= ore flexible so people are willing to adopt it.    = ;

    =0D=0A=0D=0A

    [[MCD]]= Lots of the elements you mention exist outside of=0D=0Athe BCP – Lby= R, HELD, identity extensions… they aren’t defined by the BCP an= d=0D=0Acan be used in any other context. The BCP has a very specific goal o= f defining=0D=0Aa way that emergency calls can be made by any Internet conn= ected device/proxy=0D=0Aanywhere that follows the specification; it doesn&#= 8217;t seek to be more than that –=0D=0Awhich I think is what youR= 17;re looking for. As I say, check out the interim=0D=0Arecommendations by = the CRTC in Canada=0D=0A= and NICC in the UK.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

     Actually, based on your descript= ion=0D=0Abelow, the NENA i2 architecture would probably be a more straightf= orward=0D=0Abaseline for analysis – as has been done in the UK=0D=0Aand Canada= =2E=0D=0AOf course, it’s generally recognized as only an interim step= , even in those=0D=0Ajurisdictions.

    =0D=0A=0D=0A=

    Other comments below.=

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Cheers,

    =0D=0A=0D=0A

    M= artin

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A=0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A

    From:=0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@ie= tf.org] On Behalf Of R.= Jesske@telekom.de
    =0D=0ASent:= Wednesday, 5 August 2009=0D=0A6:19 PM
    =0D=0ATo: ecrit@ietf.org
    =0D=0ASubject: Re: [Ecrit] HUM on=0D=0APhoneBCP

    =0D=0A=0D=0A
    =0D=0A=0D=0A=

     

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Dear all,
    =0D=0AWe would like th= e=0D=0Adocument to become a BCP as soon as possible so the group can move o= n with=0D=0Aother documents related to emergency calling based on location-= by-reference and=0D=0AED’s IP-address.

    =0D=0A=0D=0A

    [[MCD]] I=0D=0Athink you might mean= “identity extensions” rather than location-by-reference=0D=0Ab= ecause LbyR still requires the ED to obtain the reference – e.g. by H= ELD.
    =0D=0A    [[LLi]] We use both, the IP-add= ress as UE identity and=0D=0ALbyR. The SIP-proxy uses the IP-address to que= ry the LIS using HTTP (it's not=0D=0AHELD but SOAP over HTTP, but anyw= ay similar). The LIS responds with a=0D=0Anumeric string associated to= the caller location, in principle a LbyR and with=0D=0Athe PSAP numbe= r. The proxy inserts the LbyR into the SIP-message=0D=0A(as P-Ass= erted-ID because the PSAPs are in PSTN) and routes the message to=0D=0A= the PSAP.  It's a low cost solution. <= o:p>

    =0D=0A=0D=0A

    But = we can not HUM for the current form of=0D=0Athe document.

    =0D=0A=0D=0A

    Back t= o the document: Some requirements=0D=0Aare far form being realistic, at lea= st in Germany<= /st1:country-region>, some are not realistic at=0D=0Aall. Imple= menting these requirements cost a carrier a lot of money and there is=0D=0A= no ROI for it.

    =0D=0A=0D=0A

    Just a few examples: =0D=0A=0D=0A

    =B7  &n= bsp;    Requiring either geo or=0D=0Acivic locati= on does not provide carriers with enough flexibility to reuse their=0D=0Aex= isting mechanisms and location databases. Routing of emergency calls is=0D=0A= currently done in Ge= rmany=0D=0Abased on phone area code not on= geo or civic location, at least for the fixed=0D=0Anetwork. For mobile net= works the cell-id is used in common. This is regulated=0D=0Aby the german r= egulator.

    =0D=0A=0D=0A

    [[MCD]] How=0D= =0Amany unique PSAP routes are required in Germany=3F Th= e US has lots (60= 00 plus) and A= ustralia has two (and they are=0D=0Aredund= ant so it doesn’t matter which one). Presumably geographic informatio= n,=0D=0Afor PSAP catchment areas, is the basis for determining which area c= odes are=0D=0Arelevant to begin with=3F After all, an area code is not intr= insically=0D=0Ageographic; it’s a network routing value. If so, then = some geographic=0D=0Adiscriminator is already in play in terms of construct= ing the area code based=0D=0Arouting data (something like zip codes perhaps= =3F) – and in that case, it should be=0D=0Astraightforward to by-pass= the area code step in the construction of routing=0D=0Athat goes the corre= ct PSAP URI.
    =0D=0A    [[LLi]] Currently,&n= bsp;fixed networks carriers in=0D=0AGermany=0D=0Aroute th= e ECs based only on the caller's area code. Sometime in the=0D=0A= past, the carriers, the regulator and the PSAPs operators (police, the= Red=0D=0ACross) agreed to do so. This may change in the future, but i= t will take a=0D=0Aquite long time.      

    =0D=0A=0D=0A

     With=0D=0Anomadic VoIP = devices (and it’s no good being in denial about this being the=0D=0An= orm in the future) area code is no more reliable than it is for conventiona= l=0D=0Amobile phones. And, presumably, area code is not used for convention= al cellular=0D=0Aemergency call routing=3F
    =0D=0A    <= b>[[LLi]]  As far as I know, mobile networks use the=0D=0ACell-ID, n= ot the area code, and have a different table than the fixed network=0D=0Aop= erators. They are not going to change this.  As to the nomadic=0D= =0ASIP-users...if we like it or not, very few of our=0D=0Acustome= rs use our SIP service nomadic, let alone call EC from=0D=0A= their laptop.        =      

    =0D=0A=0D=0A

    1         =     =0D=0ALOST as a=0D=0Anational, let alone as a global = directory is not going to be implemented. The=0D=0Aregulator will provide i= n the web a static table which contains the PSAPs and=0D=0Athe area for whi= ch they are responsible (one or more area codes). Every carrier=0D=0Ahas to= implement its own routing database for emergency calls.

    =0D=0A=0D=0A
    =0D=0A=0D=0A

    [[MCD]]=0D=0AWhateve= r the carriers implement (and they have to implement something) could=0D=0A= just as readily be done using LoST. Then visiting devices, with no associat= ion=0D=0Awith any local VoIP proxy server would still be able to determine = a route to=0D=0Athe correct PSAP. Alternatively, as long as the regulator i= s maintaining a web=0D=0Aservice with the routing information, why not make= that directly accessible=0D=0Ausing LoST and save the operators the cost o= f duplicating the service at all=3F
    =0D=0A    [[LLi]]  There is a big difference between=0D=0Amaintaining = a web page with a table which operator can print and implement=0D=0Ain= their darabases and operating a database which is queried for=0D=0Aev= ery emergency call in Germany, must have an availablity of 99,99.= =2E.% ,  is=0D=0Asecure enough...you know. The regulator&nbs= p;will not do this.

    =0D=0A=0D=0A


    =0D=0A2    &n= bsp;  We have no intention to rely on end=0D=0Adevices for location in= formation because:
    =0D=0A    =B7       ED p= rovided location=0D=0Ainfo is not trusted =

    =0D=0A=0D=0A=
    =0D=0A=0D=0A

    = [[MCD]] Location=0D=0Aby reference mitigates th= is trust issue. The emergency network can=0D=0A(automatically and before hu= man resources are engaged) assess the source of the=0D=0Areference, and the= validity of the location by dereference, without having to=0D=0Atrust loca= tion provided directly from the ED. There are more sophisticated=0D=0Aappro= aches to trustability even using LbyV – based on digital signatures a= cross=0D=0Aappropriate attributes. This WG and Geopriv haven’t really= got to grips with=0D=0Athat… yet.
    =0D=0A    = [[LLi]]  We build the SIP-network and EC now.=0D=0AED-provided = location is needed if EC must work for private and=0D=0Aente= rprise networks and VPNs.  We have no such regulatory=0D=0Arequirement= s.  And we don't know of any verdor of DSL-EDs=0D=0Awhi= ch provides today SIP with LbyR and is as cheap as=0D=0Athe = devices without it. If you do, please let me know. <= /b>

    =0D=0A=0D=0A

    The regulator=0D=0Aask us to guarante= e that EC works. What if a customer dials 112 and=0D=0Ahis end de= vice does not send the location=3F So I have to=0D=0Aimplement bo= th solutions, with and without ED provided location,=0D=0Aanyway. &nbs= p;
    =0D=0A1      =0D=0AThere are al= ready a lot of existing EDs in usage which don’t send=0D=0Alocation.&= nbsp;  

    =0D= =0A=0D=0A

    [[MCD]] Quite=0D=0Aright. ECRIT doesn’t overly concern it= self with that interim situation. The UK and=0D=0ACanadia= n definitions for an interim solution (limiting service to in-country=0D=0A= VoIP proxy operators) both assume third-party query via identity-extension = to=0D=0Aallow the proxy or the VPC to make the query to the LIS. This isn&#= 8217;t extensible=0D=0Ato universal emergency service access by all visitin= g devices but it does put=0D=0Athe necessary LIS functionality in place as = a very good starting=0D=0Apoint.  It would be a pity if Germany were to cease the evolution=0D=0Athere as it would not fu= lfil the real promise of the Internet and the ECRIT=0D=0Amodel.
    =0D=0A<= /span>    [[LLi]]  I wonder who will drive and pay=0D= =0Afor upgrading the interim solutions.  Unfortunatelly= , it's=0D=0Aall about money...

    =0D=0A=0D= =0A

     Think=0D=0Aabout it; all the complexity of putting location det= ermination infrastructure=0D=0Ain place for the purposes of dispatch is don= e – and then the next, simpler=0D=0Astep, of using that to support th= e routing procedure isn’t taken… that would be=0D=0Aa waste.=0D=0A
    =0D=0A    [[LLi]]  Do you think this= is an argument for a product=0D=0Amanager=3F They need a business cas= e. 

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    <= span style=3D'font-size:12.0pt'> 

    =0D=0A=0D= =0A

      We don’t intend to=0D=0Arequire our ED-vendors to provide lo= cation because it is useless to=0D=0Aus.  

    =0D=0A=0D=0A

    We could ag= ree with the document with=0D=0Afollowing changes:

    =0D=0A=0D=0A
      =0D=0A
        =0D=0A
      • Other location identifiers then = geo or civil are allowed. It=0D=0A must be possibe that the data foerm= at is flexible due to different=0D=0A requirements from regulators ove= r the whole world. (e.G Germany area codes for fix= ed-=0D=0A and Cell-Id for moile- providers)
        • =0D=0A
      • The MUST= for the end devices to support location=0D=0A information, DHCP locat= ion options and HELD shall be removed
        • =0D=0A =
      • It must be possible for the VoIP-provider̵= 7;s proxy to use a=0D=0A LOST (or an ESRP) provided by the AN or by ot= her local provider on behalf=0D=0A of the AN. 
        • =0D=0A
      =0D=0A
    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    <= font size=3D3 color=3Dblack face=3D"Times New Roman"> There is no value in Hum-ing=0D= =0Adocuments which one is not going to implement and does not fit into regu= lated=0D=0Aschemes like in Germany.=0D=0ACurrently, neither the = IETF- nor the 3GPP-architecture for emergency calling=0D=0Acovers our real = needs for the next 2 to 5 years and in the end everybody still=0D=0Ahas its= own proprietary implementation.   

    =0D=0A=0D=0A

    <= span lang=3DEN-GB=0D=0Astyle=3D'font-size:12.0pt;color:black'>Best regards<= /span>

    =0D=0A=0D=0A

    = Roland

    =0D=0A=0D=0A

    &nbs= p;

    =0D=0A=0D=0A

    Deutsche Telekom Netzproduktion GmbH
    =0D=0AZentrum Technik Ein= f=FChrung
    =0D=0A    Roland Jesske
    =0D=0A    Gateways, Protokolle, Konvergenz, TE32-1
    =0D=0AHeinrich-Hertz-Str. 3-7, 64295 D= armstadt,
    =0D=0APostfach, 64307 Darmstadt (Postanschrift)
    =0D=0A+496151 628 2766 (Tel)
    =0D=0A    +491718618445 (Mob= ile)
    =0D=0A    E-Ma= il: r.jesske@telekom.de
    =0D= =0Ahttp://www.telekom= =2Ede=0D=0A

    =0D=0A=0D=0A

     

    =0D=0A=0D= =0A

    Registerrechtliche Unternehmensangaben:<= /font>
    =0D=0A    Deutsche Tele= kom Netzproduktion (DT NP) GmbH
    =0D=0AAufsichtsrat: Timotheus H=F6ttges = (Vorsitzender)
    =0D=0AGesch=E4ftsf=FChrung: Dr. Bruno=0D=0AJacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
    =0D=0AHandelsregister: Amtsgericht Bonn HR= B 14190
    =0D=0ASitz der Gesellschaft: Bonn
    =0D=0AUSt-IdNr.: DE 8146452= 62

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

     =

    =0D=0A=0D=0A=0D=0A =0D=0A =0D=0A= =0D=0A
    =0D=0A


    =0D=0A -----------------------------------------= -------------------------------------------------------
    =0D=0A This&nbs= p;message is for the designated recipient onl= y and may
    =0D=0A contain privileged, proprietary,&n= bsp;or otherwise private information.  
    =0D=0A = If you have received it in error, pleas= e notify the sender
    =0D=0A immediately and del= ete the original.  Any unauthorized use = of
    =0D=0A this email is prohibited.
    =0D=0A ---------= ---------------------------------------------------------------------------= ------------
    =0D=0A [mf2]

    =0D=0A
    =0D=0A=0D=0A

     <= /span>

    =0D=0A=0D=0A=0D=0A=0D=0A

     

    =0D=0A=0D= =0A=0D=0A =0D=0A =0D=0A =0D=0A=0D=0A=0D=0A

     

    =0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A

    =0D=0A


    =0D=0A ---------------------------------------------------------= ---------------------------------------
    =0D=0A This message i= s for the designated recipient only and = may
    =0D=0A contain privileged, proprietary, or othe= rwise private information.  
    =0D=0A If you&nbs= p;have received it in error, please notify&nb= sp;the sender
    =0D=0A immediately and delete the&nbs= p;original.  Any unauthorized use of
    =0D=0A th= is email is prohibited.
    =0D=0A -------------------------= -----------------------------------------------------------------------
    =0D= =0A [mf2]

    =0D=0A

    -----------------------------------= -------------------------------------------------------------
    =0D=0AThis=  message is for the designated recipient = ;only and may
    =0D=0Acontain privileged, proprietary,=  or otherwise private information.  
    =0D=0A= If you have received it in error, please=  notify the sender
    =0D=0Aimmediately and delete=  the original.  Any unauthorized use of<= br>=0D=0Athis email is prohibited.
    =0D=0A----------------= ---------------------------------------------------------------------------= -----
    =0D=0A[mf2]
    =0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01CA1736.864BF0B9-- From Ray.Bellis@nominet.org.uk Fri Aug 7 01:16:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4733A6E3E for ; Fri, 7 Aug 2009 01:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FeldE-0cnFU for ; Fri, 7 Aug 2009 01:16:58 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id ED4AF3A6E6E for ; Fri, 7 Aug 2009 01:16:57 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=OeuGpN7mRtVHFTbnOrFdIj9K4RbGiaoqVAhTw19wpbXwZbI++TupKqDL 1SVpY03vEsoAa7jV3kRhZb6bIHh6+9a74mG3BYiUfTk229lw4fMPjVJ4J BLIkVrGP65bsXc5; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1249633021; x=1281169021; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20HUM=20on=20PhoneBCP|Date:=20Fri,=207=20Aug=202009=20 09:16:57=20+0100|Message-ID:=20|To:=20"D awson,=20Martin"=20|Cc:=20"DRAG E,=20Keith=20(Keith)"=20,=0D=0A =09ecrit@ietf.org|MIME-Version:=201.0|In-Reply-To:=20 |References:=20<9886E5FCA6D76549A3011068483A4BD404BFF773@ S4DE8PSAAQB.mitte.t-com.de><40FB0FFB97588246A1BEFB0575 9DC8A00343138F@S4DE9JSAANI.ost.t-com.de>=0D=0A=09=09=20; bh=6krnxI/axpqprxw0bCt1KQdwo4iIAdo1XnJSig0cdw0=; b=BjhsgAVV7IavkImeAVaUpBakJUpb65tMVSVbtnRhiEJ0dDZUsKkG86iS mR1HnLOnO/4wdyWPKoDmNbOq5xzBRjRDTMs26JjBDNbXpG7YWDMtAyZzd 899KXGk4ynEZCiV; X-IronPort-AV: E=Sophos;i="4.43,340,1246834800"; d="scan'208";a="16503121" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 07 Aug 2009 09:16:58 +0100 In-Reply-To: References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> To: "Dawson, Martin" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 7 Aug 2009 09:16:57 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 07/08/2009 09:16:59 AM, Serialize complete at 07/08/2009 09:16:59 AM Content-Type: multipart/alternative; boundary="=_alternative 002D7F728025760B_=" Cc: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 08:16:59 -0000 This is a multipart message in MIME format. --=_alternative 002D7F728025760B_= Content-Type: text/plain; charset="US-ASCII" > Last I heard it should be published shortly. Indeed - the NICC document has been through some major re-editing but is due to be re-submitted to the working group's parent committee for approval very shortly. Ray --=_alternative 002D7F728025760B_= Content-Type: text/html; charset="US-ASCII"
    > Last I heard it should be published shortly.

    Indeed - the NICC document has been through some major re-editing but is due to be re-submitted to the working group's parent committee for approval very shortly.  

    Ray


    --=_alternative 002D7F728025760B_=-- From fmenard@xittel.net Fri Aug 7 03:41:19 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B693A6804 for ; Fri, 7 Aug 2009 03:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txhKQ4Y6daUf for ; Fri, 7 Aug 2009 03:41:16 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 9AD483A6B04 for ; Fri, 7 Aug 2009 03:41:15 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MZMsv-0000jD-It; Fri, 07 Aug 2009 06:41:17 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MZMsv-000838-02; Fri, 07 Aug 2009 06:41:17 -0400 Message-Id: <567CAB20-F546-4408-BF04-BCFEFCFF2F03@xittel.net> From: Francois Menard To: "Hannes Tschofenig" In-Reply-To: <051c01ca1735$7ffe53c0$625aa20a@nsnintra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 06:41:16 -0400 References: <9B2661AD-4413-49A2-A4E5-D59A43678290@xittel.net> <051c01ca1735$7ffe53c0$625aa20a@nsnintra.net> X-Mailer: Apple Mail (2.935.3) Cc: 'ecrit' Subject: Re: [Ecrit] ECRIT Simplified E-9-1-1 workflow proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 10:41:19 -0000 On 7-Aug-09, at 4:03 AM, Hannes Tschofenig wrote: > Hi Francois, > > Quick feedback below. > >> Is anything wrong with the following E-9-1-1 workflow to be >> possible with any ATA that can be upgraded to become Phone-BCP >> compliant. >> >> Step 0) ISP is provided with a copy of the MASTER STREET >> ADDRESS GUIDE already pre-formatted in PIDF-LO format. > > This is not really necessary for the ISP to have. I suspect you want > to > provide that information to the ISP since then he can do civic address > validation locally. The solution would still be OK by not having it > locally > but rather maintained by someone else, such as the emergency services > network, in the spirit of NENA i2/i2.5, via LoST or some other > mechanisms. > The ILECs here have committed to provide access to the MSAG, but they did not detail how the access would be provided. What's important, is this be not the source of improv. If CIVIC's are already pre-formatted in XML, them the ISP only has to cut and paste and send stuff to the ILEC SIP PROXY in the manner the proxy will dispatch for it being MSAG valid to begin with. > Hence, I don't see this part as crucial for your solution. > >> ISP >> provisions a DHCP server/ HELD server with a PIDF-LO object to >> be associated with the IP address to be assigned to an >> end-user based on the WIREMAP circut-ID. In DSL wholesale, >> the ISP uses the CIRCUT-ID acquired by RADIUS for a given >> MSAG-VALID CIVIC PIDF-LO object. The ISP then simply matches >> the PPP username and password arriving on a given CIRCUIT-ID >> to create a binding between the PUBLIC-IP associated >> dynamically to the CIRCUIT-ID and the PIDF-LO object. The ISP >> really does not care about the PPP credentials. All it wants >> to do is BIND a PIDF-LO to a CIRCUIT-ID to an IP address and >> allow for that PIDF-LO to be retrieved EITHER via HELD, or via >> DHCP OPTION 99. >> >> For instance, ILECs for their L2TP LAC's are transitioning to >> Juniper E320's - 8.2.3 patch-0.4 which is capable of the >> following formats to pass along the unique DSLAM port to be >> associated with a CIVIC address over RADIUS to the wholesale >> ISP as described in >> https://www.juniper.net/techpubs/en_US/junose10.0/information-p >> roducts/topic-collections/broadband-access/l2tp-calling-number- >> avp.html >> > > The details of how the association of an IP address with location is > done > very much depends on the specific deployment at the ISP. Some > operators > might, for example, do IP address allocation within the AAA server > and do > not run a separate DHCP server. Hence, the interaction between the > DHCP > server and the AAA server becomes a local matter. The interface of interest is not that of the ISP to AAA server, but rather that of the ILEC to ISP. In the ILEC to ISP interface, there is no IP addresses travelling back and forth, just PPP session ID's and CIRCUIT-ID's and PPP user credentials with domain. > > So, in short you only want to say that the ISP has to provide the > capability > to associate the IP address with location. I actually want to say that the Access Network provider has to EMPOWER the ISP to do that. > >> Step 1) In DSL wholesale, PPPoE will assign an IP. The >> reverse lookup would be done for this IP by the ATA. >> >> Step 2) If the ATA is behind nat, it would be provisioned with >> a STUN server IP address. The STUN server will return to the >> ATA, what public IP address the ATA is behind. >> >> Step 3) The ATA would then perform an inverse lookup for that >> IP address in the DNS server of that domain name, and would >> expect there to be a DNS entry for >> LOCATIONSERVER.DOMAIN-GATHERED-BY-REVERSE- >> LOOKUP.DOMAIN-GATHERED-BY-REVERSE-LOOKUP-SUFFIX >> > > I guess that the previous 3 steps have the purpose of LIS discovery. > Right? > Maybe it would be good to say that. One could even provide example > references to documents, such as > http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-lis-discovery/ and > http://tools.ietf.org/id/draft-thomson-geopriv-res-gw-lis-discovery-02.txt > Absolutely. > > > >> Step 4) The ATA would then use its HELD stack to download the >> location object (PIDF-LO). > > OK. > >> >> Step 5) ATA Memorizes PIDF-LO. > > OK. > >> >> Step 6) Upon having to dial 9-1-1, ATA sends PIDF-LO via >> SIPCORE LOCATION CONVEYANCE (attached) > > OK. > >> >> Step 7) VoIP server provider will steer the call to the an >> ILEC SIP PROXY and send the 9-1-1 RTP media to the ILEC 9-1-1 >> media gateway > > You might want to provide some details on how this routing works and > why the > ILEC runs the SIP proxy. There is no reason why this gatewaying > cannot be > provided by someone else. That's all stuff described here: http://www.crtc.gc.ca/public/cisc/es/ESCO283.doc In those jurisdictions where the ILECs want to step up to the plate and take that much insofar as responsibility, this ENABLEs the simplified workflow as described here. > > For example, how would the VoIP provider figure out what proxy to > send it? > Would it have some "mapping database" in the style of LoST or the > NENA i2 > solution? No need. There is only ONE destination to choose for the ISP under the Canadian i2 proposal. > Or: Would it use anycast, like the guys in Sweden want todo? > > This step is important and requires more description. > >> >> Step 8) ILEC will inspect the content of the PIDF-LO and will >> route the call to the appropriate PSAP > > Depending how you do 7 this step might be omittet. Under http://www.crtc.gc.ca/public/cisc/es/ESCO283.doc This is what the ILECs propose in Canada > >> >> All ILEC needs to do is to stop blocking the CIRCUIT-ID's over >> the RADIUS accounting interface and accept to implement a >> SIP-based gateway + media gateway on the INTERNET which would >> provide access to all the PSAPs the ILEC manages (which is the >> case in Canada where PSAPs only interconnect directly with the >> ILEC and no other competitors). > > Why would you put this burden on the ILECs? I could imagine that > PSAPs would > either accept direct VoIP calls from the VSP or would allow the VSPs > to pick > their provider of choice for doing the VoIP-to-PSTN gatewaying when > you have > to deal with legacy PSAPs. > The PSAPs in Canada do not accept interconnection from providers directly. You need to send them to the ILEC here... F. >> >> I would appreciate answers by the end of the day on friday as >> I am submitting this to the Canadian FCC (CRTC) friday evening. >> F. > > Ciao > Hannes > Merci beaucoup! f. >> >> -- >> Francois Menard >> fmenard@xittel.net >> >> >> >> >> Francois Menard >> fmenard@xittel.net >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > Francois Menard fmenard@xittel.net From L.Liess@telekom.de Fri Aug 7 05:00:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DBC3A6F15 for ; Fri, 7 Aug 2009 05:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c8hEMFh7CGG for ; Fri, 7 Aug 2009 05:00:06 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 0E9433A6F33 for ; Fri, 7 Aug 2009 04:59:02 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 07 Aug 2009 13:58:59 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 13:58:57 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1756.718434F6" Date: Fri, 7 Aug 2009 13:58:56 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rA= References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> From: To: , , X-OriginalArrivalTime: 07 Aug 2009 11:58:57.0900 (UTC) FILETIME=[71E5EAC0:01CA1756] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:00:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1756.718434F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Martin, =20 Hi Laura, =20 I regard it as a goal of ECRIT - as derived from the goals of the IETF = generally - to define a structure that will allow an Internet capable = device to connect to a network anywhere in the world and be able to make = emergency calls. Just as FTP, email protocols, SIP and etc. all work = regardless of which network the devices attach to. I don't understand = how the kind of variations that you are requesting be added to the = specification will allow that to occur. =09 [[LLi]] This is fine and usefull. Just that every country uses today = different formats for the location used for emergency calls. Changing = this will take time and costs money.=20 What is the harm in allowing ECs to work with local location formats = which are understood only by the LIS and the PSAP ?. I dont see why a = common location format must be implemented by everybody.=20 Maybe the EC could work like this :=20 * The proxy discovers the LIS based on EDs IP-address using reverse-DNS = and SRV record (this is possible with "identity extenssions") * It retrieves the location ( e.g. using HELD) in a local format = understood only by the LIS and the PSAP, which are in the same country. = The location is just a string which is passed transparently through the = network to the PSAP. In my opinion, it would be in principle posible to = use LbyR to transport local location identidfiers, e. g. = area-code@lis.telekom.de , but this is currently my personal opinion, I = didn' found any statemant or example in the drafts. =20 =09 * The LIS delivers, together with the LbyR above, the PSAP URI. As far = as I know there is currently no way to do this in HELD (or did I miss = something?). =20 =20 It would be an alternative which is interoperable and quite easy to = implement, without the need for the operators to change their location = databases. I think by allowing this scenario, interoperable EC could be = achieved earlier. And this does not exclude the scenario described in = the framework and phone-bcp, where the EDs retrieve deo or civic = location, which is needed for EC to work in private/enterprise networks. = =20 =20 =20 =20 The position appears to be that the German regulator doesn't require = anything - and the operators will not be proactive in following a = specification if it doesn't include what already exists. In that = context, I don't understand why there is a need for the BCP at all. = There may be no need to endorse it but, similarly, there should be no = need to object to it - since the operators will only put in place their = preferred version of the service in any case.=20 [[LLi]] This is not quite true. We have to ensure that EC works for = different AN- and VoIP-provider and for nomadic users in Germany by = 2013. Our current solution does not allow this and there is the same for = other carriers. We definitively need to define in Germany an = architecture which fullfills this requirements. It would be very usefull = if we can use standard protocols. But nobody will be willing to change = everything at once. Having a standard based architecture which is low = cost would be a great advantage.=20 =20 Kind regards Laura =20 =20 That's OK... insofar as it just means German networks aren't ECRIT = compatible - "compatibility" isn't a worthy goal in and of itself; it = has to actually mean any device can work anywhere. =20 Cheers, Martin =20 =09 ________________________________ From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, =20 I think what you're saying is that you don't think that Germany will = go on to implement full ECRIT support but will peg development at an = interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC = will look like in 20 years. Roland's answer only applies to the next 5 = to 10 years.=20 =20 That would be disappointing - not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service. =09 [[LLi]] This may be true for "green field" ISPs and VSPs but not for = incumbent carriers with existing infrastructure. And universal service = is not a requirement for us. Neither the German regulator requires it = nor is it a busines case. =20 =20 Nevertheless, I don't think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP = should be more flexible: =20 * Allow additional location identifiers =20 * Allow AN operated LOST=20 * Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives. =20 * Allow and describe also network-centric, not only ED-centric = architectures. If I remember correctly, John Medland from BT also = recomended to use a more network- centric architecture, at least for the = next years.=20 =20 I think it just means that the German regulator and technical advisory = committees would point out the subset aspects of compliance that would = be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP = contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard = body is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with = very valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a = business case will not help the draft in the end, also if it becomes a = BCP. It would make sense to make it more flexible so people are willing = to adopt it. =20 =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis - as has = been done in the UK and Canada. Of course, it's generally recognized as = only an interim step, even in those jurisdictions. Other comments below. =20 Cheers, Martin =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling = based on location-by-reference and ED's IP-address.=20 [[MCD]] I think you might mean "identity extensions" rather than = location-by-reference because LbyR still requires the ED to obtain the = reference - e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD = but SOAP over HTTP, but anyway similar). The LIS responds with a numeric = string associated to the caller location, in principle a LbyR and with = the PSAP number. The proxy inserts the LbyR into the SIP-message (as = P-Asserted-ID because the PSAPs are in PSTN) and routes the message to = the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being realistic, = at least in Germany, some are not realistic at all. Implementing these = requirements cost a carrier a lot of money and there is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and = location databases. Routing of emergency calls is currently done in = Germany based on phone area code not on geo or civic location, at least = for the fixed network. For mobile networks the cell-id is used in = common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US = has lots (6000 plus) and Australia has two (and they are redundant so it = doesn't matter which one). Presumably geographic information, for PSAP = catchment areas, is the basis for determining which area codes are = relevant to begin with? After all, an area code is not intrinsically = geographic; it's a network routing value. If so, then some geographic = discriminator is already in play in terms of constructing the area code = based routing data (something like zip codes perhaps?) - and in that = case, it should be straightforward to by-pass the area code step in the = construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the = carriers, the regulator and the PSAPs operators (police, the Red Cross) = agreed to do so. This may change in the future, but it will take a quite = long time. =20 With nomadic VoIP devices (and it's no good being in denial about = this being the norm in the future) area code is no more reliable than it = is for conventional mobile phones. And, presumably, area code is not = used for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the = area code, and have a different table than the fixed network operators. = They are not going to change this. As to the nomadic SIP-users...if we = like it or not, very few of our customers use our SIP service nomadic, = let alone call EC from their laptop. =20 1 LOST as a national, let alone as a global directory is = not going to be implemented. The regulator will provide in the web a = static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its = own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement = something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would = still be able to determine a route to the correct PSAP. Alternatively, = as long as the regulator is maintaining a web service with the routing = information, why not make that directly accessible using LoST and save = the operators the cost of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page = with a table which operator can print and implement in their darabases = and operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you = know. The regulator will not do this. =09 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The = emergency network can (automatically and before human resources are = engaged) assess the source of the reference, and the validity of the = location by dereference, without having to trust location provided = directly from the ED. There are more sophisticated approaches to = trustability even using LbyV - based on digital signatures across = appropriate attributes. This WG and Geopriv haven't really got to grips = with that... yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is = needed if EC must work for private and enterprise networks and VPNs. We = have no such regulatory requirements. And we don't know of any verdor = of DSL-EDs which provides today SIP with LbyR and is as cheap as the = devices without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. = =20 1 There are already a lot of existing EDs in usage which don't = send location. =20 [[MCD]] Quite right. ECRIT doesn't overly concern itself with that = interim situation. The UK and Canadian definitions for an interim = solution (limiting service to in-country VoIP proxy operators) both = assume third-party query via identity-extension to allow the proxy or = the VPC to make the query to the LIS. This isn't extensible to universal = emergency service access by all visiting devices but it does put the = necessary LIS functionality in place as a very good starting point. It = would be a pity if Germany were to cease the evolution there as it would = not fulfil the real promise of the Internet and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim = solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination = infrastructure in place for the purposes of dispatch is done - and then = the next, simpler step, of using that to support the routing procedure = isn't taken... that would be a waste. =09 [[LLi]] Do you think this is an argument for a product manager? They = need a business case. =20 =20 =20 We don't intend to require our ED-vendors to provide location = because it is useless to us. =20 We could agree with the document with following changes:=20 * Other location identifiers then geo or civil are allowed. It must = be possibe that the data foermat is flexible due to different = requirements from regulators over the whole world. (e.G Germany area = codes for fixed- and Cell-Id for moile- providers)=20 * The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed=20 * It must be possible for the VoIP-provider's proxy to use a LOST (or = an ESRP) provided by the AN or by other local provider on behalf of the = AN. =20 =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. = Currently, neither the IETF- nor the 3GPP-architecture for emergency = calling covers our real needs for the next 2 to 5 years and in the end = everybody still has its own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2]=09 ------_=_NextPart_001_01CA1756.718434F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] = HUM on PhoneBCP
     
    Hi=20 Martin,  

    Hi=20 Laura,

     

    I regard it = as a goal=20 of ECRIT =96 as derived from the goals of the IETF generally =96 to = define a=20 structure that will allow an Internet capable device to connect to a = network=20 anywhere in the world and be able to make emergency calls. Just as = FTP, email=20 protocols, SIP and etc. all work regardless of which network the = devices=20 attach to. I don=92t understand how the kind of variations that you = are=20 requesting be added to the specification will allow that to = occur.

    [[LLi]] This is fine and = usefull. Just=20 that every country uses today different formats for the location used = for=20 emergency calls. Changing this will take time and costs money. =

    What is the harm in allowing = ECs to work=20 with local location formats which are understood only by the LIS and = the=20 PSAP ?. I dont see why a common location = format must be=20 implemented by everybody.

    Maybe the EC could work like = this :=20

    • The proxy discovers the LIS based on = EDs=20 IP-address using reverse-DNS and SRV record (this is possible with = "identity=20 extenssions")
    • It retrieves the location ( e.g. using = HELD) in a=20 local format understood only by the LIS and the PSAP, which are in = the same=20 country. The location is just a string which is passed transparently = through=20 the network to the PSAP. In my opinion, it would be in principle  posible to use = LbyR to=20 transport local location identidfiers, e. g.  area-code@lis.telekom.de , but this is currently my personal = opinion,=20 I didn' found any statemant or example in the = drafts.   
    • The LIS = delivers,=20 together with the LbyR above, the PSAP URI.  As far as I know = there is=20 currently no way to do this in HELD (or did I miss=20 = something?).        
       
    It would = be an=20 alternative which is interoperable and quite easy to implement,=20 without the need for the operators to change their location=20 databases. I think by allowing = this=20 scenario, interoperable EC could be achieved earlier. And this = does not=20 exclude the scenario described in the framework and phone-bcp, = where the=20 EDs retrieve deo or civic location, which is needed for = EC to=20 work in private/enterprise networks.  
      

        

     

    The = position appears=20 to be that the German regulator doesn=92t require anything =96 and the = operators=20 will not be proactive in following a specification if it doesn=92t = include what=20 already exists. In that context, I don=92t understand why there is a = need for=20 the BCP at all. There may be no need to endorse it but, similarly, = there=20 should be no need to object to it =96 since the operators will only = put in place=20 their preferred version of the service in any case.
    [[LLi]]  This is = not quite=20 true. We have to ensure that EC works for different AN- and = VoIP-provider and=20 for nomadic users in Germany by 2013. Our current solution does = not allow=20 this and there is the same for other carriers. We definitively = need to=20 define in Germany an architecture which fullfills this = requirements. It=20 would be very usefull if we can use standard protocols. But = nobody will=20 be willing to change everything at once.  Having a standard based = architecture which is low cost would be a great advantage.=20

     

    Kind=20 regards

    Laura     <= /FONT>

     

     That=92s OK=85 insofar as it = just means=20 German networks aren=92t ECRIT compatible =96 =93compatibility=94 = isn=92t a worthy goal=20 in and of itself; it has to actually mean any device can work=20 anywhere.

     

    Cheers,

    Martin

     

    From: L.Liess@telekom.de=20 [mailto:L.Liess@telekom.de]
    Sent:     Friday, 7 August 2009 = 12:29=20 AM
    To: Dawson, = Martin;=20 R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

     

    Hi Martin,=20

     

    See = comments inline=20 [[LLi]].

     

     

    Laura

    From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of Dawson, Martin
    Sent:     Wednesday, August 05, = 2009 11:00=20 AM
    To: Jesske, = Roland;=20 ecrit@ietf.org
    Subject: Re:=20 [Ecrit] HUM on PhoneBCP

    Hi=20 Roland,

     

    I think = what you=92re=20 saying is that you don=92t think that Germany will go on to = implement=20 full ECRIT support but will peg development at an interim phase.=20
    [[LLi]]  We=20 don't know how the realtime application networks or EC will = look like=20 in 20 years. Roland's answer only applies to the next = 5 to 10=20 years. 

     

     That would = be=20 disappointing =96 not least because full ECRIT compliance would = ultimately=20 decrease the overhead associated with emergency service support for=20 operators as well as providing a more universal=20 service.

    [[LLi]]  This=20 may be true for "green field" ISPs and VSPs but not for = incumbent=20 carriers with existing infrastructure.  And universal = service is=20 not a requirement for us. Neither the German regulator = requires it nor=20 is it a busines case.   

     

    Nevertheless, I=20 don=92t think that decision invalidates the BCP; =
    [[LLi]]  We=20 think it does, because some of the requirements are not = flexible=20 enough to cover the deployments within the next = years.  The BCP=20 should be more flexible:  

    • Allow = additional=20 location identifiers  =
    • Allow = AN operated=20 LOST
    • Provide a=20 way to enable LOST-query based on national or=20 domain-specific location identifier. One posiblility is = to allow=20 the LIS to query the LOST , but there are also = other=20 alternatives. 
    • Allow and describe=20 also network-centric, not only ED-centric = architectures. If=20 I  remember correctly, John Medland from BT also = recomended to=20 use a more network- centric architecture, at least for the next = years.=20

     

    I think = it just=20 means that the German regulator and technical advisory committees = would=20 point out the subset aspects of compliance that would be applicable = to that=20 jurisdiction.  
    [[LLi]] =20 Again, the draft is not flexible enough for it.  If the = BCP=20 contains requirements which are not realistic, people will just = discard=20 the BCP and implement proprietary stuff. My expectation = from a=20 standard body is to define protocols and architecture which = people are=20 willing to implement in their network or products , not only in the=20 lab.

     

    [[LLi]] =20

    We are = not against=20 the draft in principle. ECRIT provides  us with = very=20 valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to=20 invest without a business case will not help the=20 draft in the end, also if it becomes a BCP.  It would = make=20 sense to make it more flexible so people are willing to adopt=20 it.    

     

     Actually,=20 based on your description below, the NENA i2 architecture would = probably be=20 a more straightforward baseline for analysis =96 as has been done in = the=20 UK and = Canada. Of course, = it=92s generally=20 recognized as only an interim step, even in those=20 jurisdictions.

    Other = comments=20 below.

     

    Cheers,

    Martin

     

    From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of R.Jesske@telekom.de
    Sent:     Wednesday, 5 August = 2009 6:19=20 PM
    To:=20 ecrit@ietf.org
    Subject: Re:=20 [Ecrit] HUM on PhoneBCP

     

     

    Dear all, =
    We would = like the document=20 to become a BCP as soon as possible so the group can move on with = other=20 documents related to emergency calling based on = location-by-reference and=20 ED=92s IP-address.

    [[MCD]]=20 I think you might mean =93identity extensions=94 rather than=20 location-by-reference because LbyR still requires the ED to obtain = the=20 reference =96 e.g. by HELD.
    [[LLi]] We=20 use both, the IP-address as UE identity and LbyR. The SIP-proxy uses = the=20 IP-address to query the LIS using HTTP (it's not HELD but SOAP = over=20 HTTP, but anyway similar). The LIS responds with a numeric = string=20 associated to the caller location, in principle a LbyR and with the=20 PSAP number. The proxy inserts the LbyR into the = SIP-message=20 (as P-Asserted-ID because the PSAPs are in PSTN) and routes = the message=20 to the PSAP.  It's a low cost=20 solution. 

    But we can not HUM for the = current=20 form of the document.

    Back to the document: Some=20 requirements are far form being realistic, at least in Germany, some are not = realistic=20 at all. Implementing these requirements cost a carrier a lot of = money and=20 there is no ROI for it.

    Just a few examples:=20

    =B7       Requiring either=20 geo or civic location does not provide carriers with enough = flexibility to=20 reuse their existing mechanisms and location databases. Routing of = emergency=20 calls is currently done in Germany based on phone = area code=20 not on geo or civic location, at least for the fixed network. For = mobile=20 networks the cell-id is used in common. This is regulated by the = german=20 regulator.

    [[MCD]]=20 How many unique PSAP routes are required in Germany? The = US has lots (6000 plus) and = Australia has two (and = they are=20 redundant so it doesn=92t matter which one). Presumably geographic=20 information, for PSAP catchment areas, is the basis for determining = which=20 area codes are relevant to begin with? After all, an area code is = not=20 intrinsically geographic; it=92s a network routing value. If so, = then some=20 geographic discriminator is already in play in terms of constructing = the=20 area code based routing data (something like zip codes perhaps?) =96 = and in=20 that case, it should be straightforward to by-pass the area code = step in the=20 construction of routing that goes the correct PSAP URI.=20
    [[LLi]] Currently, fixed=20 networks carriers in Germany route = the ECs based=20 only on the caller's area code. Sometime in the past, the=20 carriers, the regulator and the PSAPs operators (police, the Red = Cross)=20 agreed to do so. This may change in the future, but it will = take a=20 quite long=20 = time.      

     With=20 nomadic VoIP devices (and it=92s no good being in denial about this = being the=20 norm in the future) area code is no more reliable than it is for=20 conventional mobile phones. And, presumably, area code is not used = for=20 conventional cellular emergency call=20 routing?
    [[LLi]] =20 As far as I know, mobile networks use the Cell-ID, not the area = code, and=20 have a different table than the fixed network operators. They = are not=20 going to change this.  As to the nomadic SIP-users...if we like = it or=20 not, very few of our customers use our SIP = service=20 nomadic, let alone call EC from their=20 = laptop.        =  

    1           =   =20 LOST=20 as a national, let alone as a global directory is not going to be=20 implemented. The regulator will provide in the web a static table = which=20 contains the PSAPs and the area for which they are responsible (one = or more=20 area codes). Every carrier has to implement its own routing database = for=20 emergency calls.

    [[MCD]]=20 Whatever the carriers implement (and they have to implement = something)=20 could just as readily be done using LoST. Then visiting devices, = with no=20 association with any local VoIP proxy server would still be able = to=20 determine a route to the correct PSAP. Alternatively, as long as = the=20 regulator is maintaining a web service with the routing = information, why=20 not make that directly accessible using LoST and save the = operators the=20 cost of duplicating the service at=20 all?
    [[LLi]] =20 There is a big difference between maintaining a web page with = a table=20 which operator can print and implement in their darabases=20 and operating a database which is queried for = every emergency=20 call in Germany, must have an availablity of=20 99,99...% ,  is secure enough...you know. The=20 regulator will not do = this.


    2      =20 We have no intention to rely on end devices for location = information=20 because:
    =B7       ED = provided=20 location info is not trusted

    [[MCD]]=20 Location by reference mitigates this trust issue. The emergency = network can=20 (automatically and before human resources are engaged) assess the = source of=20 the reference, and the validity of the location by dereference, = without=20 having to trust location provided directly from the ED. There are = more=20 sophisticated approaches to trustability even using LbyV =96 based = on digital=20 signatures across appropriate attributes. This WG and Geopriv = haven=92t really=20 got to grips with that=85 yet.
    [[LLi]]  We=20 build the SIP-network and EC now. ED-provided location is=20 needed if EC must work for private and enterprise = networks=20 and VPNs.  We have no such regulatory = requirements.  And we=20 don't know of any verdor of DSL-EDs which provides = today SIP=20 with LbyR and is as cheap as the devices without it. If = you do,=20 please let me know. 

    The=20 regulator ask us to guarantee that EC works. What if a = customer=20 dials 112 and his end device does not send = the location? So I=20 have to implement both solutions, with and without ED provided = location,=20 anyway.  
    1       There=20 are already a lot of existing EDs in usage which don=92t send=20 location.   

    [[MCD]]=20 Quite right. ECRIT doesn=92t overly concern itself with that interim = situation. The UK and Canadian = definitions for=20 an interim solution (limiting service to in-country VoIP proxy = operators)=20 both assume third-party query via identity-extension to allow the = proxy or=20 the VPC to make the query to the LIS. This isn=92t extensible to = universal=20 emergency service access by all visiting devices but it does put the = necessary LIS functionality in place as a very good starting=20 point.  It would be a pity if Germany were to cease = the=20 evolution there as it would not fulfil the real promise of the = Internet and=20 the ECRIT model.
    [[LLi]] =20 I wonder who will drive and pay for upgrading the = interim=20 solutions.  Unfortunatelly, it's all about=20 money...

     Think=20 about it; all the complexity of putting location determination=20 infrastructure in place for the purposes of dispatch is done =96 and = then the=20 next, simpler step, of using that to support the routing procedure = isn=92t=20 taken=85 that would be a = waste.

    [[LLi]] =20 Do you think this is an argument for a product manager? = They need a=20 business case. 

     

     

      We=20 don=92t intend to require our ED-vendors to provide location because = it is=20 useless to us.  

    We could agree with the = document with=20 following changes: =

      • Other location = identifiers then=20 geo or civil are allowed. It must be possibe that the data = foermat is=20 flexible due to different requirements from regulators over the = whole=20 world. (e.G Germany area codes = for fixed-=20 and Cell-Id for moile- providers)=20
      • The MUST for the end = devices to=20 support location information, DHCP location options and HELD = shall be=20 removed
      • It must be possible for = the=20 VoIP-provider=92s proxy to use a LOST (or an ESRP) provided by = the AN or=20 by other local provider on behalf of the AN. =20

     

     There is no value in = Hum-ing=20 documents which one is not going to implement and does not fit into=20 regulated schemes like in Germany. Currently, = neither the=20 IETF- nor the 3GPP-architecture for emergency calling covers our = real needs=20 for the next 2 to 5 years and in the end everybody still has its own = proprietary implementation.    =

    Best = regards

    Roland=20

     

    Deutsche = Telekom=20 Netzproduktion GmbH
    Zentrum Technik = Einf=FChrung
    Roland = Jesske
    Gateways, Protokolle,=20 Konvergenz, TE32-1
    Heinrich-Hertz-Str. = 3-7, 64295=20 Darmstadt,
    Postfach,=20 64307 Darmstadt (Postanschrift)
    +496151 628 2766=20 (Tel)
    +491718618445=20 (Mobile)
    E-Mail: = r.jesske@telekom.de=20
    http://www.telekom.de=20

     

    Registerrechtliche=20 Unternehmensangaben:
    Deutsche Telekom = Netzproduktion=20 (DT NP) GmbH
    Aufsichtsrat: Timotheus H=F6ttges=20 (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 Al    bert Matheis, Klaus Peren
    Handelsregister: = Amtsgericht=20 Bonn HRB 14190
    Sitz der Gesellschaft: Bonn
    USt-IdNr.: DE=20 814645262

     

     


    --------------------------------------------------------------= ----------------------------------
    This message is for&= nbsp;the designated recipient only and may
    co= ntain privileged, proprietary, or otherwise priv= ate information.  
    If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
    this email is proh= ibited.
    --------------------------------------------------------------= ----------------------------------
    [mf2]

    <= /TD>

     



    =

    -----------------------------------------------------------------= -------------------------------
    This message is for&nbs= p;the designated recipient only and may
    conta= in privileged, proprietary, or otherwise private=  information.  
    If you have received&nbs= p;it in error, please notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibi= ted.
    -----------------------------------------------------------------= -------------------------------
    [mf2]
    ------_=_NextPart_001_01CA1756.718434F6-- From L.Liess@telekom.de Fri Aug 7 05:13:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3993A68C6 for ; Fri, 7 Aug 2009 05:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqGZ8ayc4pH5 for ; Fri, 7 Aug 2009 05:13:10 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 2559F28C191 for ; Fri, 7 Aug 2009 05:13:07 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 07 Aug 2009 14:12:58 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 14:12:29 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1758.5578D0E6" Date: Fri, 7 Aug 2009 14:12:28 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003431674@S4DE9JSAANI.ost.t-com.de> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAAOKzRQAAW1mtAAHrEiQAAIEX2A References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> From: To: , , , X-OriginalArrivalTime: 07 Aug 2009 12:12:29.0809 (UTC) FILETIME=[55D56610:01CA1758] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:13:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1758.5578D0E6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin,=20 =20 NENA i2 is not an international standard. We can not use it as a = reference. Also, in Germany, there is no dedicated for the emergency = service infrastructure (or money for building one) like you have in the = US or a central PSAP like in UK. This is quite important. =20 =20 People here will not agree to use NENA as a reference.=20 =20 Kind Regards Laura ________________________________ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Friday, August 07, 2009 10:10 AM To: DRAGE, Keith (Keith); Liess, Laura; Jesske, Roland; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =09 =09 Last I heard it should be published shortly. =20 I'm not sure what you're getting at. I was referring Laura to the = (draft or whatever) interim recommendation as a useful piece of work to = consider with respect to the German situation. Are you suggesting it's = not useful and/or will not actually be published? =20 Cheers, Martin =20 =09 ________________________________ From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Friday, 7 August 2009 5:37 PM To: Dawson, Martin; L.Liess@telekom.de; R.Jesske@telekom.de; = ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 You said: =20 As I say, check out the interim recommendations by the CRTC in Canada = and NICC in the UK.=20 =20 There is no such thing as interim recommendations from UK NICC. =20 There is a document under development. Whatever it currently says has = no status as a UK NICC document. The last I heard the document was under = substantial reediting. =20 regards =20 Keith =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Dawson, Martin Sent: Thursday, August 06, 2009 4:21 PM To: L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP I neglected to do a point by point, sorry. So - that follows: =20 Cheers, Martin =20 =09 ________________________________ From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, =20 I think what you're saying is that you don't think that Germany will = go on to implement full ECRIT support but will peg development at an = interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC = will look like in 20 years. Roland's answer only applies to the next 5 = to 10 years.=20 [[MCD]] The implementation of the LIS function is the most = significant aspect for operators - and that needs to happen in short = term scenarios in any case. The provision of LoST can be a national = asset/service. The provision of PSAP URIs is an emergency service = responsibility. Those are the key requirements - and that does provide a = framework that will work into the next 20 years and beyond. =20 That would be disappointing - not least because full ECRIT = compliance would ultimately decrease the overhead associated with = emergency service support for operators as well as providing a more = universal service. =09 [[LLi]] This may be true for "green field" ISPs and VSPs but not for = incumbent carriers with existing infrastructure. And universal service = is not a requirement for us. Neither the German regulator requires it = nor is it a busines case. =20 [[MCD]] I think this is only true to the same extent that a pure = Internet green field ISP only has to worry about Internet trunk = connectivity and doesn't have to worry about PSTN circuit trunk = connectivity. The latter infrastructure is legacy and not particularly = applicable to the Internet component of the service. Providing ECRIT = emergency calling support requires the addition of a LIS, access to LoST = (whoever hosts it), and a route to the PSAP URI(s). Both types of = operator need to do that. Whatever switched circuit legacy emergency = infrastructure already exists in the established operator needs to = continue to exist to support the emergency calls on that access. =20 Nevertheless, I don't think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP = should be more flexible: =20 * Allow additional location identifiers =20 [[MCD]] Agreed - although that can be done by local-specific use of = fields in the PIDF-LO based on jurisdictional convention and be = appropriately parsed by LoST in that jurisdiction in a quite transparent = fashion. A German technical advisory committee could make this = recommendation within that jurisdiction without deference to the BCP and = without impact to ECRIT-compliant devices. * Allow AN operated LOST=20 [[MCD]] I don't think the BCP excludes the possibility of the access = network hosting LoST. It shouldn't - since this is a jurisdictional = decision. As long as the LoST service can be discovered/used when = attached to the access, it shouldn't matter where it is hosted. * Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives.=20 [[MCD]] I was in favour of the LIS proxying the LoST request - since = they both share a "locality" it simplifies the whole discovery plot. = However, that didn't take hold in the debate so we have what we have. = Given that - a LIS still need only provide the national level location = (i.e. DE) in the PIDF-LO if that's all that's required to make a = successful LoST query. The rest can be done using LbyR - with the LIS = also providing the reference along with the coarse location. Doesn't = that satisfy the requirement? * Allow and describe also network-centric, not only ED-centric = architectures. If I remember correctly, John Medland from BT also = recomended to use a more network- centric architecture, at least for the = next years.=20 [[MCD]] I don't really understand this "X-centric" argument. Even = traditional cellular architectures require a combination of end device = and network capabilities. Maybe if you are being specific you mean; = there should be no ECRIT-specific requirements on the end device (though = I'm not sure why ECRIT should have this rule when other architectures = don't). You're right John M did propose such an approach. Not to put = words in his mouth, but this was in the context of an interim = architecture - per my comments below on the Canada and UK interim = approaches. It works in the limited scope of devices having to proxy = calls through "national" VoIP carriers - it doesn't meet the long term = vision of ECRIT. An interim architecture, by definition, is not the = end-game architecture. ECRIT only seeks to define the end-game; there = are already interim architectures to choose from - which was my point = about suggesting it might be better to baseline off i2 for the time = being rather than trying to shoehorn interim constraints into ECRIT. =20 I think it just means that the German regulator and technical = advisory committees would point out the subset aspects of compliance = that would be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP = contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard = body is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. [[MCD]] What I mean is that compliance isn't compulsory. It's OK to = say "we have decided to deviate from the specification in this way". =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with = very valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a = business case will not help the draft in the end, also if it becomes a = BCP. It would make sense to make it more flexible so people are willing = to adopt it. =20 [[MCD]] Lots of the elements you mention exist outside of the BCP - = LbyR, HELD, identity extensions... they aren't defined by the BCP and = can be used in any other context. The BCP has a very specific goal of = defining a way that emergency calls can be made by any Internet = connected device/proxy anywhere that follows the specification; it = doesn't seek to be more than that - which I think is what you're looking = for. As I say, check out the interim recommendations by the CRTC in = Canada and NICC in the UK. =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis - as has = been done in the UK and Canada. Of course, it's generally recognized as = only an interim step, even in those jurisdictions. Other comments below. =20 Cheers, Martin =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling = based on location-by-reference and ED's IP-address.=20 [[MCD]] I think you might mean "identity extensions" rather than = location-by-reference because LbyR still requires the ED to obtain the = reference - e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD = but SOAP over HTTP, but anyway similar). The LIS responds with a numeric = string associated to the caller location, in principle a LbyR and with = the PSAP number. The proxy inserts the LbyR into the SIP-message (as = P-Asserted-ID because the PSAPs are in PSTN) and routes the message to = the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being realistic, = at least in Germany, some are not realistic at all. Implementing these = requirements cost a carrier a lot of money and there is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and = location databases. Routing of emergency calls is currently done in = Germany based on phone area code not on geo or civic location, at least = for the fixed network. For mobile networks the cell-id is used in = common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US = has lots (6000 plus) and Australia has two (and they are redundant so it = doesn't matter which one). Presumably geographic information, for PSAP = catchment areas, is the basis for determining which area codes are = relevant to begin with? After all, an area code is not intrinsically = geographic; it's a network routing value. If so, then some geographic = discriminator is already in play in terms of constructing the area code = based routing data (something like zip codes perhaps?) - and in that = case, it should be straightforward to by-pass the area code step in the = construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the = carriers, the regulator and the PSAPs operators (police, the Red Cross) = agreed to do so. This may change in the future, but it will take a quite = long time. =20 With nomadic VoIP devices (and it's no good being in denial about = this being the norm in the future) area code is no more reliable than it = is for conventional mobile phones. And, presumably, area code is not = used for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the = area code, and have a different table than the fixed network operators. = They are not going to change this. As to the nomadic SIP-users...if we = like it or not, very few of our customers use our SIP service nomadic, = let alone call EC from their laptop. =20 1 LOST as a national, let alone as a global directory is = not going to be implemented. The regulator will provide in the web a = static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its = own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement = something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would = still be able to determine a route to the correct PSAP. Alternatively, = as long as the regulator is maintaining a web service with the routing = information, why not make that directly accessible using LoST and save = the operators the cost of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page = with a table which operator can print and implement in their darabases = and operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you = know. The regulator will not do this. =09 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The = emergency network can (automatically and before human resources are = engaged) assess the source of the reference, and the validity of the = location by dereference, without having to trust location provided = directly from the ED. There are more sophisticated approaches to = trustability even using LbyV - based on digital signatures across = appropriate attributes. This WG and Geopriv haven't really got to grips = with that... yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is = needed if EC must work for private and enterprise networks and VPNs. We = have no such regulatory requirements. And we don't know of any verdor = of DSL-EDs which provides today SIP with LbyR and is as cheap as the = devices without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. = =20 1 There are already a lot of existing EDs in usage which don't = send location. =20 [[MCD]] Quite right. ECRIT doesn't overly concern itself with that = interim situation. The UK and Canadian definitions for an interim = solution (limiting service to in-country VoIP proxy operators) both = assume third-party query via identity-extension to allow the proxy or = the VPC to make the query to the LIS. This isn't extensible to universal = emergency service access by all visiting devices but it does put the = necessary LIS functionality in place as a very good starting point. It = would be a pity if Germany were to cease the evolution there as it would = not fulfil the real promise of the Internet and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim = solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination = infrastructure in place for the purposes of dispatch is done - and then = the next, simpler step, of using that to support the routing procedure = isn't taken... that would be a waste. =09 [[LLi]] Do you think this is an argument for a product manager? They = need a business case. =20 =20 =20 We don't intend to require our ED-vendors to provide location = because it is useless to us. =20 We could agree with the document with following changes:=20 * Other location identifiers then geo or civil are allowed. It must = be possibe that the data foermat is flexible due to different = requirements from regulators over the whole world. (e.G Germany area = codes for fixed- and Cell-Id for moile- providers)=20 * The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed=20 * It must be possible for the VoIP-provider's proxy to use a LOST = (or an ESRP) provided by the AN or by other local provider on behalf of = the AN. =20 =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. = Currently, neither the IETF- nor the 3GPP-architecture for emergency = calling covers our real needs for the next 2 to 5 years and in the end = everybody still has its own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] =20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2]=09 ------_=_NextPart_001_01CA1758.5578D0E6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] = HUM on PhoneBCP
    Hi Martin,
     
    NENA i2 is not an international = standard.  We=20 can not use it as a reference. Also, in Germany, there is no=20 dedicated for the emergency service infrastructure (or money for = building=20 one) like you have in the US or a central PSAP like in UK. This is = quite=20 important.  
     
    People here will not agree to use NENA = as a=20 reference.
     

    Kind=20 Regards

    Laura


    From: Dawson, Martin=20 [mailto:Martin.Dawson@andrew.com]
    Sent: Friday, August 07, = 2009=20 10:10 AM
    To: DRAGE, Keith (Keith); Liess, Laura; Jesske, = Roland;=20 ecrit@ietf.org
    Cc: = Reinhard.Lauster@t-mobile.at
    Subject:=20 RE: [Ecrit] HUM on PhoneBCP

    Last I = heard it=20 should be published shortly.

     

    I=92m not = sure what=20 you=92re getting at. I was referring Laura to the (draft or whatever) = interim=20 recommendation as a useful piece of work to consider with respect to = the=20 German situation. Are you suggesting it=92s not useful and/or will not = actually=20 be published?

     

    Cheers,

    Martin

     

    From: DRAGE, Keith (Keith)=20 [mailto:drage@alcatel-lucent.com]
    Sent:     Friday, 7 August 2009 = 5:37=20 PM
    To: Dawson, = Martin;=20 L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

     

    You=20 said:

     

    As=20 I say, check out the interim recommendations by the CRTC in=20 Canada and NICC = in the=20 UK.=20

     

    There is no = such=20 thing as interim recommendations from UK = NICC.

     

    There is a = document=20 under development. Whatever it currently says has no status as a UK = NICC=20 document. The last I heard the document was under substantial=20 reediting.

     

    regards

     

    Keith

     

    From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of Dawson, Martin
    Sent:     Thursday, August 06, = 2009 4:21=20 PM
    To: = L.Liess@telekom.de;=20 R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: Re: [Ecrit] HUM on=20 PhoneBCP

    I = neglected to do a=20 point by point, sorry. So =96 that = follows:

     

    Cheers,

    Martin

     

    From: L.Liess@telekom.de=20 [mailto:L.Liess@telekom.de]
    Sent:     Friday, 7 August 2009 = 12:29=20 AM
    To: Dawson, = Martin;=20 R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

     

    Hi = Martin,=20

     

    See = comments inline=20 [[LLi]].

     

     

    Laura

    From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On=20 Behalf Of Dawson, Martin
    Sent:     Wednesday, August 05, = 2009=20 11:00 AM
    To: = Jesske,=20 Roland; ecrit@ietf.org
    Subject: Re: [Ecrit] HUM on = PhoneBCP

    Hi=20 Roland,

     

    I think = what=20 you=92re saying is that you don=92t think that Germany will go on to = implement=20 full ECRIT support but will peg development at an interim phase.=20
    [[LLi]]  We=20 don't know how the realtime application networks or EC will = look like=20 in 20 years. Roland's answer only applies to the = next 5 to=20 10 years. 

    [[MCD]]=20 The implementation of the LIS function is the most significant = aspect for=20 operators =96 and that needs to happen in short term scenarios in = any case.=20 The provision of LoST can be a national asset/service. The = provision of=20 PSAP URIs is an emergency service responsibility. Those are the = key=20 requirements =96 and that does provide a framework that will work = into the=20 next 20 years and beyond.

     

     That = would be=20 disappointing =96 not least because full ECRIT compliance would = ultimately=20 decrease the overhead associated with emergency service support = for=20 operators as well as providing a more universal=20 service.

    [[LLi]] =20 This may be true for "green field" ISPs and VSPs but not for=20 incumbent carriers with existing infrastructure.  And = universal=20 service is not a requirement for us. Neither the German regulator=20 requires it nor is it a busines=20 case.   

    [[MCD]]=20 I think this is only true to the same extent that a pure Internet = green=20 field ISP only has to worry about Internet trunk connectivity and = doesn=92t=20 have to worry about PSTN circuit trunk connectivity. The latter=20 infrastructure is legacy and not particularly applicable to the = Internet=20 component of the service. Providing ECRIT emergency calling = support=20 requires the addition of a LIS, access to LoST (whoever hosts it), = and a=20 route to the PSAP URI(s). Both types of operator need to do that. = Whatever=20 switched circuit legacy emergency infrastructure already exists in = the=20 established operator needs to continue to exist to support the = emergency=20 calls on that access.

     

    Nevertheless, I=20 don=92t think that decision invalidates the BCP; =
    [[LLi]]  We=20 think it does, because some of the requirements are not = flexible=20 enough to cover the deployments within the next = years.  The BCP=20 should be more flexible:  

    • Allow = additional location identifiers  =

    [[MCD]]=20 Agreed =96 although that can be done by local-specific use of = fields in the=20 PIDF-LO based on jurisdictional convention and be appropriately = parsed by=20 LoST in that jurisdiction in a quite transparent fashion. A German = technical advisory committee could make this recommendation within = that=20 jurisdiction without deference to the BCP and without impact to=20 ECRIT-compliant devices.

    • Allow = AN=20 operated LOST

    [[MCD]]=20 I don=92t think the BCP excludes the possibility of the access = network=20 hosting LoST. It shouldn=92t =96 since this is a jurisdictional = decision. As=20 long as the LoST service can be discovered/used when attached to = the=20 access, it shouldn=92t matter where it is = hosted.

    • Provide a=20 way to enable LOST-query based on national or=20 domain-specific location identifier. One posiblility is=20 to allow the LIS to query the LOST , but = there are=20 also other alternatives.

    [[MCD]]=20 I was in favour of the LIS proxying the LoST request =96 since = they both=20 share a =93locality=94 it simplifies the whole discovery plot. = However, that=20 didn=92t take hold in the debate so we have what we have. Given = that - a LIS=20 still need only provide the national level location (i.e. DE) in = the=20 PIDF-LO if that=92s all that=92s required to make a successful = LoST query. The=20 rest can be done using LbyR =96 with the LIS also providing the = reference=20 along with the coarse location. Doesn=92t that satisfy the=20 requirement?

    • Allow and describe=20 also network-centric, not only ED-centric = architectures. If=20 I  remember correctly, John Medland from BT also = recomended to=20 use a more network- centric architecture, at least for the next=20 years.

    [[MCD]]=20 I don=92t really understand this =93X-centric=94 argument. Even = traditional=20 cellular architectures require a combination of end device and = network=20 capabilities. Maybe if you are being specific you mean; there = should be no=20 ECRIT-specific requirements on the end device (though I=92m not = sure why=20 ECRIT should have this rule when other architectures don=92t). = You=92re right=20 John M did propose such an approach. Not to put words in his = mouth, but=20 this was in the context of an interim architecture =96 per my = comments below=20 on the Canada = and=20 UK interim = approaches. It works=20 in the limited scope of devices having to proxy calls through = =93national=94=20 VoIP carriers =96 it doesn=92t meet the long term vision of ECRIT. = An interim=20 architecture, by definition, is not the end-game architecture. = ECRIT only=20 seeks to define the end-game; there are already interim = architectures to=20 choose from =96 which was my point about suggesting it might be = better to=20 baseline off i2 for the time being rather than trying to shoehorn = interim=20 constraints into ECRIT.

     

    I think = it just=20 means that the German regulator and technical advisory committees = would=20 point out the subset aspects of compliance that would be = applicable to=20 that jurisdiction.  
    [[LLi]] =20 Again, the draft is not flexible enough for it.  If the = BCP=20 contains requirements which are not realistic, people will = just=20 discard the BCP and implement proprietary stuff. My = expectation=20 from a standard body is to define protocols and architecture = which=20 people are willing to implement in their network or products , not = only in=20 the lab.

    [[MCD]]=20 What I mean is that compliance isn=92t compulsory. It=92s OK to = say =93we have=20 decided to deviate from the specification in this=20 way=94.

     

    [[LLi]] =20

    We are = not=20 against the draft in principle. ECRIT provides  us = with very=20 valuable specifications as LbyR, HELD, identity = extensions. But=20 targeting an architecture which requires everbody to=20 invest without a business case will not help the=20 draft in the end, also if it becomes a BCP.  It = would make=20 sense to make it more flexible so people are willing to adopt = it.    

    [[MCD]]=20 Lots of the elements you mention exist outside of the BCP =96 = LbyR, HELD,=20 identity extensions=85 they aren=92t defined by the BCP and can be = used in any=20 other context. The BCP has a very specific goal of defining a way = that=20 emergency calls can be made by any Internet connected device/proxy = anywhere that follows the specification; it doesn=92t seek to be = more than=20 that =96 which I think is what you=92re looking for. As I say, = check out the=20 interim recommendations by the CRTC in Canada and NICC in the UK.

     

     Actually,=20 based on your description below, the NENA i2 architecture would = probably=20 be a more straightforward baseline for analysis =96 as has been = done in the=20 UK and = Canada. Of course, = it=92s=20 generally recognized as only an interim step, even in those=20 jurisdictions.

    Other = comments=20 below.

     

    Cheers,

    Martin

     

    From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On=20 Behalf Of R.Jesske@telekom.de
    Sent:     Wednesday, 5 August = 2009 6:19=20 PM
    To:=20 ecrit@ietf.org
    Subject:=20 Re: [Ecrit] HUM on PhoneBCP

     

     

    Dear all, =
    We would = like the=20 document to become a BCP as soon as possible so the group can move = on with=20 other documents related to emergency calling based on=20 location-by-reference and ED=92s IP-address.

    [[MCD]]=20 I think you might mean =93identity extensions=94 rather than=20 location-by-reference because LbyR still requires the ED to obtain = the=20 reference =96 e.g. by HELD.
    [[LLi]] We=20 use both, the IP-address as UE identity and LbyR. The SIP-proxy = uses the=20 IP-address to query the LIS using HTTP (it's not HELD = but SOAP over=20 HTTP, but anyway similar). The LIS responds with a numeric = string=20 associated to the caller location, in principle a LbyR and with = the=20 PSAP number. The proxy inserts the LbyR into the=20 SIP-message (as P-Asserted-ID because the PSAPs are in PSTN) and = routes=20 the message to the PSAP.  It's a low cost=20 solution. 

    But we can not HUM for the = current=20 form of the document.

    Back to the document: Some = requirements are far form being realistic, at least in Germany, some are not = realistic=20 at all. Implementing these requirements cost a carrier a lot of = money and=20 there is no ROI for it.

    Just a few examples:=20

    =B7       Requiring either=20 geo or civic location does not provide carriers with enough = flexibility to=20 reuse their existing mechanisms and location databases. Routing of = emergency calls is currently done in Germany based on = phone area=20 code not on geo or civic location, at least for the fixed network. = For=20 mobile networks the cell-id is used in common. This is regulated = by the=20 german regulator.

    [[MCD]]=20 How many unique PSAP routes are required in Germany? The=20 US has lots = (6000 plus)=20 and Australia has two = (and they are=20 redundant so it doesn=92t matter which one). Presumably geographic = information, for PSAP catchment areas, is the basis for = determining which=20 area codes are relevant to begin with? After all, an area code is = not=20 intrinsically geographic; it=92s a network routing value. If so, = then some=20 geographic discriminator is already in play in terms of = constructing the=20 area code based routing data (something like zip codes perhaps?) = =96 and in=20 that case, it should be straightforward to by-pass the area code = step in=20 the construction of routing that goes the correct PSAP URI.=20
    [[LLi]] Currently, fixed=20 networks carriers in Germany route = the ECs=20 based only on the caller's area code. Sometime in the = past, the=20 carriers, the regulator and the PSAPs operators (police, the Red = Cross)=20 agreed to do so. This may change in the future, but it will = take a=20 quite long=20 = time.      

     With=20 nomadic VoIP devices (and it=92s no good being in denial about = this being=20 the norm in the future) area code is no more reliable than it is = for=20 conventional mobile phones. And, presumably, area code is not used = for=20 conventional cellular emergency call=20 routing?
    [[LLi]] =20 As far as I know, mobile networks use the Cell-ID, not the area = code, and=20 have a different table than the fixed network operators. They = are not=20 going to change this.  As to the nomadic SIP-users...if we = like it or=20 not, very few of our customers use our SIP = service=20 nomadic, let alone call EC from their=20 = laptop.        =  

    1           =   =20 LOST=20 as a national, let alone as a global directory is not going to be=20 implemented. The regulator will provide in the web a static table = which=20 contains the PSAPs and the area for which they are responsible = (one or=20 more area codes). Every carrier has to implement its own routing = database=20 for emergency calls.

    [[MCD]]=20 Whatever the carriers implement (and they have to implement = something)=20 could just as readily be done using LoST. Then visiting devices, = with no=20 association with any local VoIP proxy server would still be able = to=20 determine a route to the correct PSAP. Alternatively, as long as = the=20 regulator is maintaining a web service with the routing = information, why=20 not make that directly accessible using LoST and save the = operators the=20 cost of duplicating the service at=20 all?
    [[LLi]] =20 There is a big difference between maintaining a web page with=20 a table which operator can print and implement in their = darabases=20 and operating a database which is queried for = every emergency=20 call in Germany, must have an availablity of=20 99,99...% ,  is secure enough...you know. The=20 regulator will not do = this.


    2      =20 We have no intention to rely on end devices for location = information=20 because:
    =B7       ED provided=20 location info is not trusted

    [[MCD]]=20 Location by reference mitigates this trust issue. The emergency = network=20 can (automatically and before human resources are engaged) assess = the=20 source of the reference, and the validity of the location by = dereference,=20 without having to trust location provided directly from the ED. = There are=20 more sophisticated approaches to trustability even using LbyV =96 = based on=20 digital signatures across appropriate attributes. This WG and = Geopriv=20 haven=92t really got to grips with that=85=20 yet.
    [[LLi]]  We=20 build the SIP-network and EC now. ED-provided location is=20 needed if EC must work for private and enterprise = networks=20 and VPNs.  We have no such regulatory = requirements.  And we=20 don't know of any verdor of DSL-EDs which provides = today=20 SIP with LbyR and is as cheap as the devices without it. = If you=20 do, please let me know. 

    The=20 regulator ask us to guarantee that EC works. What if a = customer=20 dials 112 and his end device does not send = the location? So=20 I have to implement both solutions, with and without ED provided = location,=20 anyway.  
    1      =20 There are already a lot of existing EDs in usage which don=92t = send=20 location.   

    [[MCD]]=20 Quite right. ECRIT doesn=92t overly concern itself with that = interim=20 situation. The UK and Canadian = definitions for=20 an interim solution (limiting service to in-country VoIP proxy = operators)=20 both assume third-party query via identity-extension to allow the = proxy or=20 the VPC to make the query to the LIS. This isn=92t extensible to = universal=20 emergency service access by all visiting devices but it does put = the=20 necessary LIS functionality in place as a very good starting=20 point.  It would be a pity if Germany were to cease = the=20 evolution there as it would not fulfil the real promise of the = Internet=20 and the ECRIT model.
    [[LLi]] =20 I wonder who will drive and pay for upgrading the = interim=20 solutions.  Unfortunatelly, it's all about=20 money...

     Think=20 about it; all the complexity of putting location determination=20 infrastructure in place for the purposes of dispatch is done =96 = and then=20 the next, simpler step, of using that to support the routing = procedure=20 isn=92t taken=85 that would be a=20 waste.

    [[LLi]] =20 Do you think this is an argument for a product manager? = They need a=20 business case. 

     

     

      We=20 don=92t intend to require our ED-vendors to provide location = because it is=20 useless to us.  

    We could agree with the = document=20 with following changes:=20

      • Other location = identifiers then=20 geo or civil are allowed. It must be possibe that the data = foermat is=20 flexible due to different requirements from regulators over = the whole=20 world. (e.G Germany area = codes for=20 fixed- and Cell-Id for moile- providers)
      • The MUST for the end = devices to=20 support location information, DHCP location options and HELD = shall be=20 removed
      • It must be possible = for the=20 VoIP-provider=92s proxy to use a LOST (or an ESRP) provided by = the AN or=20 by other local provider on behalf of the AN. =20

     

     There is no value in = Hum-ing=20 documents which one is not going to implement and does not fit = into=20 regulated schemes like in Germany. Currently, = neither the=20 IETF- nor the 3GPP-architecture for emergency calling covers our = real=20 needs for the next 2 to 5 years and in the end everybody still has = its own=20 proprietary implementation.   =20

    Best = regards

    Roland

     

    Deutsche Telekom=20 Netzproduktion GmbH
    Zentrum Technik = Einf=FChrung
    Roland=20 Jesske
    Gateways, = Protokolle,=20 Konvergenz, TE32-1
    Heinrich-Hertz-Str. = 3-7, 64295=20 Darmstadt,
    Postfach,=20 64307 Darmstadt (Postanschrift)
    +496151 628 2766=20 (Tel)
    +491718618445=20 (Mobile)
    E-Mail:=20 r.jesske@telekom.de=20
    http://www.telekom.de=20

     

    Registerrechtliche=20 Unternehmensangaben:
    Deutsche Telekom=20 Netzproduktion (DT NP) GmbH
    Aufsichtsrat: Timotheus H=F6ttges=20 (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), = Al    bert Matheis, Klaus Peren
    Handelsregister: = Amtsgericht=20 Bonn HRB 14190
    Sitz der Gesellschaft: Bonn
    USt-IdNr.: DE=20 814645262

     

     


    --------------------------------------------------------------= ----------------------------------
    This message is for&= nbsp;the designated recipient only and may
    co= ntain privileged, proprietary, or otherwise priv= ate information.  
    If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
    this email is proh= ibited.
    --------------------------------------------------------------= ----------------------------------
    [mf2]

    <= /TD>

     

     


    --------------------------------------------------------------= ----------------------------------
    This message is for&= nbsp;the designated recipient only and may
    co= ntain privileged, proprietary, or otherwise priv= ate information.  
    If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
    this email is proh= ibited.
    --------------------------------------------------------------= ----------------------------------
    [mf2]

    <= /TD>

     



    =

    -----------------------------------------------------------------= -------------------------------
    This message is for&nbs= p;the designated recipient only and may
    conta= in privileged, proprietary, or otherwise private=  information.  
    If you have received&nbs= p;it in error, please notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibi= ted.
    -----------------------------------------------------------------= -------------------------------
    [mf2]
    ------_=_NextPart_001_01CA1758.5578D0E6-- From Ray.Bellis@nominet.org.uk Fri Aug 7 05:18:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF2F3A6F14; Fri, 7 Aug 2009 05:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng0Pqysx9e2d; Fri, 7 Aug 2009 05:18:29 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id CF92B3A6977; Fri, 7 Aug 2009 05:18:28 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=RqxKTiVqJUVDerH2CUPkoC4sSJwKwU3WpEGauxAxtH8lBNAb9qxpa2kv uJv0tXCYqIE27d85wgs6eq9Okk0UZC0bd9CeXS6uqhykH0qpDVEspGd+A uGQ4yuSwbu/SzlS; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1249647512; x=1281183512; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20HUM=20on=20PhoneBCP|Date:=20Fri,=207=20Aug=202009=20 13:18:23=20+0100|Message-ID:=20|To:=20|Cc:=20ecrit@ietf.org,=0D=0A=09ecrit-bo unces@ietf.org,=0D=0A=09Martin.Dawson@andrew.com,=0D=0A =09Reinhard.Lauster@t-mobile.at,=0D=0A=09R.Jesske@telekom .de|MIME-Version:=201.0|In-Reply-To:=20<40FB0FFB97588246A 1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> |References:=20<9886E5FCA6D76549A3011068483A4BD404BFF773@ S4DE8PSAAQB.mitte.t-com.de>=09=0D=0A=09<40FB0FFB975882 46A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de>=09=20<40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI .ost.t-com.de>; bh=IPVxwtNwcqvj7EscNIIXfjuBh6gsbQdIWxScIM/stnI=; b=gQzuEUSVDcAPXTG3KY9fbfBiOsaTrjHkX8aiwtr/cmfCmNFcHI5XNl4G zxIVvxHbNodGOP4ySCwXKEVeG/LoM2Vm192LAUU4CGg38SM2y5KKB4u1r 3SOfKQbbpGRL77F; X-IronPort-AV: E=Sophos;i="4.43,341,1246834800"; d="scan'208";a="16507897" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 07 Aug 2009 13:18:25 +0100 In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 7 Aug 2009 13:18:23 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 07/08/2009 01:18:30 PM, Serialize complete at 07/08/2009 01:18:30 PM Content-Type: multipart/alternative; boundary="=_alternative 004399D78025760B_=" Cc: Martin.Dawson@andrew.com, R.Jesske@telekom.de, ecrit@ietf.org, Reinhard.Lauster@t-mobile.at, ecrit-bounces@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:18:30 -0000 This is a multipart message in MIME format. --=_alternative 004399D78025760B_= Content-Type: text/plain; charset="US-ASCII" > Maybe the EC could work like this : > The proxy discovers the LIS based on EDs IP-address using reverse- > DNS and SRV record (this is possible with "identity extenssions") Laura, Please see draft-thomson-geopriv-res-gw-lis-discovery-02 The main LIS Discovery draft from Geopriv previously did almost exactly what you've just described, but it was changed because of complaints from the DNS folk (myself included) that it assumed a mapping between domain names and network access that simply often doesn't exist. The current proposal instead simply stores the LIS Discovery U-NAPTR records directly in the reverse DNS tree, where there's a much stronger (almost 100%) mapping between the DNS and the network access provider. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 004399D78025760B_= Content-Type: text/html; charset="US-ASCII" > Maybe the EC could work like this :
    > The proxy discovers the LIS based on EDs IP-address using reverse-
    > DNS and SRV record (this is possible with "identity extenssions")

    Laura,

    Please see draft-thomson-geopriv-res-gw-lis-discovery-02

    The main LIS Discovery draft from Geopriv previously did almost exactly what you've just described, but it was changed because of complaints from the DNS folk (myself included) that it assumed a mapping between domain names and network access that simply often doesn't exist.

    The current proposal instead simply stores the LIS Discovery U-NAPTR records directly in the reverse DNS tree, where there's a much stronger (almost 100%) mapping between the DNS and the network access provider.

    kind regards,

    Ray

    --
    Ray Bellis, MA(Oxon) MIET
    Senior Researcher in Advanced Projects, Nominet
    e: ray@nominet.org.uk, t: +44 1865 332211     --=_alternative 004399D78025760B_=-- From Martin.Dawson@andrew.com Fri Aug 7 05:39:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859563A6E60 for ; Fri, 7 Aug 2009 05:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vmE3hEH7BqQ for ; Fri, 7 Aug 2009 05:39:37 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 1F2BF3A6B8E for ; Fri, 7 Aug 2009 05:39:24 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_07_08_02_09 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 07 Aug 2009 08:02:09 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 07:39:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Aug 2009 07:38:41 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAAOKzRQAAW1mtAAHrEiQAAIEX2AAADtgOU= References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431674@S4DE9JSAANI.ost.t-com.de> From: "Dawson, Martin" To: , , , X-OriginalArrivalTime: 07 Aug 2009 12:39:26.0547 (UTC) FILETIME=[197C0A30:01CA175C] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:39:39 -0000 Hi Laura,=0D=0A=0D=0AIt's not necessary to normatively reference i2 in term= s of adherence to it. Neither the CRTC or the NICC documents do that. The j= urisdictions are different but the technical challenges are common. They ca= n be summed up as call-routing and dispatch location delivery. For example,= the NICC document does not specify i2; NICC just used i2 as a starting poi= nt since it deals with the same set of technical challenges. Beyond that it= only references individuals specs (like HELD) as part of their own nationa= l specification. Again - I think this is a very valuable step for jurisdict= ions to take. It addresses the short term concerns that some operators may = have about actual or self-imposed obligations. At the same time it lays dow= n the fundamental LIS infrastructure that will ultimately allow VoIP-provid= er independent emergency calling to happen in an ECRIT-compliant manner. Th= at next step is about as minimal in cost as it could be.=0D=0A=0D=0AAs anot= her touch stone - all that was required for POTS emergency calling was PSTN= access (some jurisdictions, e.g. USA, even dedicated trunks to the emergen= cy service fromt the very edge of the network). All that should be needed t= o make emergency calls in the 21st century is a connection to the Internet.=0D= =0A=0D=0AHave a great weekend.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: L.Liess@telekom.de [mailto:L.Liess= @telekom.de]=0D=0ASent: Fri 8/7/2009 10:12 PM=0D=0ATo: Dawson, Martin; drag= e@alcatel-lucent.com; R.Jesske@telekom.de; ecrit@ietf.org=0D=0ACc: Reinhard= =2ELauster@t-mobile.at=0D=0ASubject: RE: [Ecrit] HUM on PhoneBCP=0D=0A=20=0D= =0AHi Martin,=20=0D=0A=20=0D=0ANENA i2 is not an international standard. W= e can not use it as a reference. Also, in Germany, there is no dedicated fo= r the emergency service infrastructure (or money for building one) like you= have in the US or a central PSAP like in UK. This is quite important. =20=0D= =0A=20=0D=0APeople here will not agree to use NENA as a reference.=20=0D=0A= =20=0D=0A=0D=0AKind Regards=0D=0A=0D=0ALaura=0D=0A=0D=0A=0D=0A_____________= ___________________=0D=0A=0D=0A=09From: Dawson, Martin [mailto:Martin.Dawso= n@andrew.com]=20=0D=0A=09Sent: Friday, August 07, 2009 10:10 AM=0D=0A=09To:= DRAGE, Keith (Keith); Liess, Laura; Jesske, Roland; ecrit@ietf.org=0D=0A=09= Cc: Reinhard.Lauster@t-mobile.at=0D=0A=09Subject: RE: [Ecrit] HUM on PhoneB= CP=0D=0A=09=0D=0A=09=0D=0A=0D=0A=09Last I heard it should be published shor= tly.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09I'm not sure what you're getting at. I= was referring Laura to the (draft or whatever) interim recommendation as a= useful piece of work to consider with respect to the German situation. Are= you suggesting it's not useful and/or will not actually be published=3F=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09Cheers,=0D=0A=0D=0A=09Martin=0D=0A=0D=0A=09 =0D= =0A=0D=0A=09=0D=0A________________________________=0D=0A=0D=0A=0D=0A=09From= : DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20=0D=0A=09Sent: F= riday, 7 August 2009 5:37 PM=0D=0A=09To: Dawson, Martin; L.Liess@telekom.de= ; R.Jesske@telekom.de; ecrit@ietf.org=0D=0A=09Cc: Reinhard.Lauster@t-mobile= =2Eat=0D=0A=09Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09=20=0D=0A=0D= =0A=09You said:=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09As I say, check out the int= erim recommendations by the CRTC in Canada and NICC in the UK.=20=0D=0A=0D=0A= =09=20=0D=0A=0D=0A=09There is no such thing as interim recommendations from= UK NICC.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09There is a document under develop= ment. Whatever it currently says has no status as a UK NICC document. The l= ast I heard the document was under substantial reediting.=0D=0A=0D=0A=09 =0D= =0A=0D=0A=09regards=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Keith=0D=0A=0D=0A=09=09= =20=0D=0A=0D=0A=09=09=0D=0A________________________________=0D=0A=0D=0A=0D=0A= =09=09From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f Of Dawson, Martin=0D=0A=09=09Sent: Thursday, August 06, 2009 4:21 PM=0D=0A= =09=09To: L.Liess@telekom.de; R.Jesske@telekom.de; ecrit@ietf.org=0D=0A=09=09= Cc: Reinhard.Lauster@t-mobile.at=0D=0A=09=09Subject: Re: [Ecrit] HUM on Pho= neBCP=0D=0A=0D=0A=09=09I neglected to do a point by point, sorry. So - that= follows:=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09Cheers,=0D=0A=0D=0A=09=09Ma= rtin=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09=0D=0A__________________________= ______=0D=0A=0D=0A=0D=0A=09=09From: L.Liess@telekom.de [mailto:L.Liess@tele= kom.de]=20=0D=0A=09=09Sent: Friday, 7 August 2009 12:29 AM=0D=0A=09=09To: D= awson, Martin; R.Jesske@telekom.de; ecrit@ietf.org=0D=0A=09=09Cc: Reinhard.= Lauster@t-mobile.at=0D=0A=09=09Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A=0D= =0A=09=09=20=0D=0A=0D=0A=09=09Hi Martin,=20=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A= =09=09See comments inline [[LLi]].=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09 =0D= =0A=0D=0A=09=09Laura=0D=0A=0D=0A=09=09=09From: ecrit-bounces@ietf.org [mail= to:ecrit-bounces@ietf.org] On Behalf Of Dawson, Martin=0D=0A=09=09=09Sent: = Wednesday, August 05, 2009 11:00 AM=0D=0A=09=09=09To: Jesske, Roland; ecrit= @ietf.org=0D=0A=09=09=09Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09= =09=09Hi Roland,=0D=0A=0D=0A=09=09=09=20=0D=0A=0D=0A=09=09=09I think what y= ou're saying is that you don't think that Germany will go on to implement f= ull ECRIT support but will peg development at an interim phase.=20=0D=0A=09= =09=09[[LLi]] We don't know how the realtime application networks or EC wi= ll look like in 20 years. Roland's answer only applies to the next 5 to 10 = years.=20=0D=0A=0D=0A=09=09=09[[MCD]] The implementation of the LIS functio= n is the most significant aspect for operators - and that needs to happen i= n short term scenarios in any case. The provision of LoST can be a national= asset/service. The provision of PSAP URIs is an emergency service responsi= bility. Those are the key requirements - and that does provide a framework = that will work into the next 20 years and beyond.=0D=0A=0D=0A=09=09=09=20=0D= =0A=0D=0A=09=09=09 That would be disappointing - not least because full ECR= IT compliance would ultimately decrease the overhead associated with emerge= ncy service support for operators as well as providing a more universal ser= vice.=0D=0A=09=09=09=0D=0A=09=09=09[[LLi]] This may be true for "green fie= ld" ISPs and VSPs but not for incumbent carriers with existing infrastructu= re. And universal service is not a requirement for us. Neither the German = regulator requires it nor is it a busines case. =20=0D=0A=0D=0A=09=09=09[[= MCD]] I think this is only true to the same extent that a pure Internet gre= en field ISP only has to worry about Internet trunk connectivity and doesn'= t have to worry about PSTN circuit trunk connectivity. The latter infrastru= cture is legacy and not particularly applicable to the Internet component o= f the service. Providing ECRIT emergency calling support requires the addit= ion of a LIS, access to LoST (whoever hosts it), and a route to the PSAP UR= I(s). Both types of operator need to do that. Whatever switched circuit leg= acy emergency infrastructure already exists in the established operator nee= ds to continue to exist to support the emergency calls on that access.=0D=0A=0D= =0A=09=09=09=20=0D=0A=0D=0A=09=09=09Nevertheless, I don't think that decisi= on invalidates the BCP;=20=0D=0A=09=09=09[[LLi]] We think it does, because= some of the requirements are not flexible enough to cover the deployments = within the next years. The BCP should be more flexible: =20=0D=0A=0D=0A=09= =09=09*=09Allow additional location identifiers =20=0D=0A=0D=0A=09=09=09[[M= CD]] Agreed - although that can be done by local-specific use of fields in = the PIDF-LO based on jurisdictional convention and be appropriately parsed = by LoST in that jurisdiction in a quite transparent fashion. A German techn= ical advisory committee could make this recommendation within that jurisdic= tion without deference to the BCP and without impact to ECRIT-compliant dev= ices.=0D=0A=0D=0A=09=09=09*=09Allow AN operated LOST=20=0D=0A=0D=0A=09=09=09= [[MCD]] I don't think the BCP excludes the possibility of the access networ= k hosting LoST. It shouldn't - since this is a jurisdictional decision. As = long as the LoST service can be discovered/used when attached to the access= , it shouldn't matter where it is hosted.=0D=0A=0D=0A=09=09=09*=09Provide a= way to enable LOST-query based on national or domain-specific location ide= ntifier. One posiblility is to allow the LIS to query the LOST , but there = are also other alternatives.=20=0D=0A=0D=0A=09=09=09[[MCD]] I was in favour= of the LIS proxying the LoST request - since they both share a "locality" = it simplifies the whole discovery plot. However, that didn't take hold in t= he debate so we have what we have. Given that - a LIS still need only provi= de the national level location (i.e. DE) in the PIDF-LO if that's all that'= s required to make a successful LoST query. The rest can be done using LbyR= - with the LIS also providing the reference along with the coarse location= =2E Doesn't that satisfy the requirement=3F=0D=0A=0D=0A=09=09=09*=09Allow a= nd describe also network-centric, not only ED-centric architectures. If I = remember correctly, John Medland from BT also recomended to use a more netw= ork- centric architecture, at least for the next years.=20=0D=0A=0D=0A=09=09= =09[[MCD]] I don't really understand this "X-centric" argument. Even tradit= ional cellular architectures require a combination of end device and networ= k capabilities. Maybe if you are being specific you mean; there should be n= o ECRIT-specific requirements on the end device (though I'm not sure why EC= RIT should have this rule when other architectures don't). You're right Joh= n M did propose such an approach. Not to put words in his mouth, but this w= as in the context of an interim architecture - per my comments below on the= Canada and UK interim approaches. It works in the limited scope of devices= having to proxy calls through "national" VoIP carriers - it doesn't meet t= he long term vision of ECRIT. An interim architecture, by definition, is no= t the end-game architecture. ECRIT only seeks to define the end-game; there= are already interim architectures to choose from - which was my point abou= t suggesting it might be better to baseline off i2 for the time being rathe= r than trying to shoehorn interim constraints into ECRIT.=0D=0A=0D=0A=09=09= =09=20=0D=0A=0D=0A=09=09=09I think it just means that the German regulator = and technical advisory committees would point out the subset aspects of com= pliance that would be applicable to that jurisdiction. =20=0D=0A=09=09=09[[= LLi]] Again, the draft is not flexible enough for it. If the BCP contains= requirements which are not realistic, people will just discard the BCP and= implement proprietary stuff. My expectation from a standard body is to def= ine protocols and architecture which people are willing to implement in the= ir network or products , not only in the lab.=0D=0A=0D=0A=09=09=09[[MCD]] W= hat I mean is that compliance isn't compulsory. It's OK to say "we have dec= ided to deviate from the specification in this way".=0D=0A=0D=0A=09=09=09 =0D= =0A=0D=0A=09=09=09[[LLi]] =20=0D=0A=0D=0A=09=09=09We are not against the dr= aft in principle. ECRIT provides us with very valuable specifications as L= byR, HELD, identity extensions. But targeting an architecture which require= s everbody to invest without a business case will not help the draft in the= end, also if it becomes a BCP. It would make sense to make it more flexib= le so people are willing to adopt it. =20=0D=0A=0D=0A=09=09=09[[MCD]] Lot= s of the elements you mention exist outside of the BCP - LbyR, HELD, identi= ty extensions... they aren't defined by the BCP and can be used in any othe= r context. The BCP has a very specific goal of defining a way that emergenc= y calls can be made by any Internet connected device/proxy anywhere that fo= llows the specification; it doesn't seek to be more than that - which I thi= nk is what you're looking for. As I say, check out the interim recommendati= ons by the CRTC in Canada and NICC in the UK.=0D=0A=0D=0A=09=09=09=20=0D=0A=0D= =0A=09=09=09 Actually, based on your description below, the NENA i2 archite= cture would probably be a more straightforward baseline for analysis - as h= as been done in the UK and Canada. Of course, it's generally recognized as = only an interim step, even in those jurisdictions.=0D=0A=0D=0A=09=09=09Othe= r comments below.=0D=0A=0D=0A=09=09=09=20=0D=0A=0D=0A=09=09=09Cheers,=0D=0A=0D= =0A=09=09=09Martin=0D=0A=0D=0A=09=09=09=20=0D=0A=0D=0A=09=09=09=0D=0A______= __________________________=0D=0A=0D=0A=0D=0A=09=09=09From: ecrit-bounces@ie= tf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de=0D=0A= =09=09=09Sent: Wednesday, 5 August 2009 6:19 PM=0D=0A=09=09=09To: ecrit@iet= f.org=0D=0A=09=09=09Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A=09=09=09= =20=0D=0A=0D=0A=09=09=09=20=0D=0A=0D=0A=09=09=09Dear all,=20=0D=0A=09=09=09= We would like the document to become a BCP as soon as possible so the group= can move on with other documents related to emergency calling based on loc= ation-by-reference and ED's IP-address.=20=0D=0A=0D=0A=09=09=09[[MCD]] I th= ink you might mean "identity extensions" rather than location-by-reference = because LbyR still requires the ED to obtain the reference - e.g. by HELD.=0D= =0A=09=09=09[[LLi]] We use both, the IP-address as UE identity and LbyR. Th= e SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD = but SOAP over HTTP, but anyway similar). The LIS responds with a numeric st= ring associated to the caller location, in principle a LbyR and with the PS= AP number. The proxy inserts the LbyR into the SIP-message (as P-Asserted-I= D because the PSAPs are in PSTN) and routes the message to the PSAP. It's = a low cost solution.=20=0D=0A=0D=0A=09=09=09But we can not HUM for the curr= ent form of the document.=20=0D=0A=0D=0A=09=09=09Back to the document: Some= requirements are far form being realistic, at least in Germany, some are n= ot realistic at all. Implementing these requirements cost a carrier a lot o= f money and there is no ROI for it.=20=0D=0A=0D=0A=09=09=09Just a few examp= les:=20=0D=0A=0D=0A=09=09=09=B7 Requiring either geo or civic locatio= n does not provide carriers with enough flexibility to reuse their existing= mechanisms and location databases. Routing of emergency calls is currently= done in Germany based on phone area code not on geo or civic location, at = least for the fixed network. For mobile networks the cell-id is used in com= mon. This is regulated by the german regulator.=20=0D=0A=0D=0A=09=09=09[[MC= D]] How many unique PSAP routes are required in Germany=3F The US has lots = (6000 plus) and Australia has two (and they are redundant so it doesn't mat= ter which one). Presumably geographic information, for PSAP catchment areas= , is the basis for determining which area codes are relevant to begin with=3F= After all, an area code is not intrinsically geographic; it's a network ro= uting value. If so, then some geographic discriminator is already in play i= n terms of constructing the area code based routing data (something like zi= p codes perhaps=3F) - and in that case, it should be straightforward to by-= pass the area code step in the construction of routing that goes the correc= t PSAP URI.=20=0D=0A=09=09=09[[LLi]] Currently, fixed networks carriers in = Germany route the ECs based only on the caller's area code. Sometime in the= past, the carriers, the regulator and the PSAPs operators (police, the Red= Cross) agreed to do so. This may change in the future, but it will take a = quite long time. =20=0D=0A=0D=0A=09=09=09 With nomadic VoIP devices (an= d it's no good being in denial about this being the norm in the future) are= a code is no more reliable than it is for conventional mobile phones. And, = presumably, area code is not used for conventional cellular emergency call = routing=3F=0D=0A=09=09=09[[LLi]] As far as I know, mobile networks use the= Cell-ID, not the area code, and have a different table than the fixed netw= ork operators. They are not going to change this. As to the nomadic SIP-us= ers...if we like it or not, very few of our customers use our SIP service n= omadic, let alone call EC from their laptop. =20=0D=0A=0D=0A=09=09=09= 1 LOST as a national, let alone as a global directory is not g= oing to be implemented. The regulator will provide in the web a static tabl= e which contains the PSAPs and the area for which they are responsible (one= or more area codes). Every carrier has to implement its own routing databa= se for emergency calls.=20=0D=0A=0D=0A=09=09=09=09[[MCD]] Whatever the carr= iers implement (and they have to implement something) could just as readily= be done using LoST. Then visiting devices, with no association with any lo= cal VoIP proxy server would still be able to determine a route to the corre= ct PSAP. Alternatively, as long as the regulator is maintaining a web servi= ce with the routing information, why not make that directly accessible usin= g LoST and save the operators the cost of duplicating the service at all=3F=0D= =0A=09=09=09=09[[LLi]] There is a big difference between maintaining a web= page with a table which operator can print and implement in their darabase= s and operating a database which is queried for every emergency call in Ger= many, must have an availablity of 99,99...% , is secure enough...you know.= The regulator will not do this.=0D=0A=0D=0A=09=09=09=09=0D=0A=09=09=09=092= We have no intention to rely on end devices for location information= because:=20=0D=0A=09=09=09=09=B7 ED provided location info is not tr= usted=20=0D=0A=0D=0A=09=09=09[[MCD]] Location by reference mitigates this t= rust issue. The emergency network can (automatically and before human resou= rces are engaged) assess the source of the reference, and the validity of t= he location by dereference, without having to trust location provided direc= tly from the ED. There are more sophisticated approaches to trustability ev= en using LbyV - based on digital signatures across appropriate attributes. = This WG and Geopriv haven't really got to grips with that... yet.=0D=0A=09=09= =09[[LLi]] We build the SIP-network and EC now. ED-provided location is ne= eded if EC must work for private and enterprise networks and VPNs. We have= no such regulatory requirements. And we don't know of any verdor of DSL-E= Ds which provides today SIP with LbyR and is as cheap as the devices withou= t it. If you do, please let me know.=20=0D=0A=0D=0A=09=09=09The regulator a= sk us to guarantee that EC works. What if a customer dials 112 and his end = device does not send the location=3F So I have to implement both solutions,= with and without ED provided location, anyway. =20=0D=0A=09=09=091 T= here are already a lot of existing EDs in usage which don't send location. = =20=0D=0A=0D=0A=09=09=09[[MCD]] Quite right. ECRIT doesn't overly concern= itself with that interim situation. The UK and Canadian definitions for an= interim solution (limiting service to in-country VoIP proxy operators) bot= h assume third-party query via identity-extension to allow the proxy or the= VPC to make the query to the LIS. This isn't extensible to universal emerg= ency service access by all visiting devices but it does put the necessary L= IS functionality in place as a very good starting point. It would be a pit= y if Germany were to cease the evolution there as it would not fulfil the r= eal promise of the Internet and the ECRIT model.=20=0D=0A=09=09=09[[LLi]] = I wonder who will drive and pay for upgrading the interim solutions. Unfor= tunatelly, it's all about money...=0D=0A=0D=0A=09=09=09 Think about it; all= the complexity of putting location determination infrastructure in place f= or the purposes of dispatch is done - and then the next, simpler step, of u= sing that to support the routing procedure isn't taken... that would be a w= aste.=0D=0A=09=09=09=0D=0A=09=09=09[[LLi]] Do you think this is an argumen= t for a product manager=3F They need a business case. =20=0D=0A=0D=0A=09=09= =09=20=0D=0A=0D=0A=09=09=09=20=0D=0A=0D=0A=09=09=09 We don't intend to req= uire our ED-vendors to provide location because it is useless to us. =20=0D= =0A=0D=0A=09=09=09We could agree with the document with following changes: =0D= =0A=0D=0A=09=09=09=09*=09Other location identifiers then geo or civil are a= llowed. It must be possibe that the data foermat is flexible due to differe= nt requirements from regulators over the whole world. (e.G Germany area cod= es for fixed- and Cell-Id for moile- providers)=20=0D=0A=09=09=09=09*=09The= MUST for the end devices to support location information, DHCP location op= tions and HELD shall be removed=20=0D=0A=09=09=09=09*=09It must be possible= for the VoIP-provider's proxy to use a LOST (or an ESRP) provided by the A= N or by other local provider on behalf of the AN. =20=0D=0A=0D=0A=09=09=09 =0D= =0A=0D=0A=09=09=09 There is no value in Hum-ing documents which one is not = going to implement and does not fit into regulated schemes like in Germany.= Currently, neither the IETF- nor the 3GPP-architecture for emergency calli= ng covers our real needs for the next 2 to 5 years and in the end everybody= still has its own proprietary implementation. =20=0D=0A=0D=0A=09=09=09Be= st regards=20=0D=0A=0D=0A=09=09=09Roland=20=0D=0A=0D=0A=09=09=09=20=0D=0A=0D= =0A=09=09=09Deutsche Telekom Netzproduktion GmbH=0D=0A=09=09=09Zentrum Tech= nik Einf=FChrung=0D=0A=09=09=09Roland Jesske=0D=0A=09=09=09Gateways, Protok= olle, Konvergenz, TE32-1=0D=0A=09=09=09Heinrich-Hertz-Str. 3-7, 64295 Darms= tadt,=0D=0A=09=09=09Postfach, 64307 Darmstadt (Postanschrift)=0D=0A=09=09=09= +496151 628 2766 (Tel)=0D=0A=09=09=09+491718618445 (Mobile)=0D=0A=09=09=09E= -Mail: r.jesske@telekom.de =20=0D=0A=09=09=09h= ttp://www.telekom.de =20=0D=0A=0D=0A=09=09=09=20=0D= =0A=0D=0A=09=09=09Registerrechtliche Unternehmensangaben:=0D=0A=09=09=09Deu= tsche Telekom Netzproduktion (DT NP) GmbH=0D=0A=09=09=09Aufsichtsrat: Timot= heus H=F6ttges (Vorsitzender)=0D=0A=09=09=09Gesch=E4ftsf=FChrung: Dr. Bruno= Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren=0D=0A=09=09=09H= andelsregister: Amtsgericht Bonn HRB 14190=0D=0A=09=09=09Sitz der Gesellsch= aft: Bonn=0D=0A=09=09=09USt-IdNr.: DE 814645262=20=0D=0A=0D=0A=09=09=09=20=0D= =0A=0D=0A=09=09=09=20=0D=0A=0D=0A=0D=0A------------------------------------= ------------------------------------------------------------=0D=0AThis mess= age is for the designated recipient only and may=0D=0Acontain privileged, p= roprietary, or otherwise private information. =20=0D=0AIf you have received= it in error, please notify the sender=0D=0Aimmediately and delete the orig= inal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0A[mf2]=0D=0A=0D=0A=09=09=09=20=0D=0A=0D=0A=09=09=20=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A=0D= =0A=09=09=20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0AThis m= essage is for the designated recipient only and may=0D=0Acontain privileged= , proprietary, or otherwise private information. =20=0D=0AIf you have recei= ved it in error, please notify the sender=0D=0Aimmediately and delete the o= riginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0A[mf2]=09=0D=0A=0D=0A=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A From Hannes.Tschofenig@gmx.net Fri Aug 7 05:42:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3543728C1B7 for ; Fri, 7 Aug 2009 05:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=1.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 ZbKLwadSEv7O for ; Fri, 7 Aug 2009 05:42:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4F7953A6EF8 for ; Fri, 7 Aug 2009 05:42:40 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2009 12:42:42 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 07 Aug 2009 14:42:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19uLoJAiSNuts8iIQgxTJAd7Me4vK7RmSsKPQeleS yaBBcDGZvaXucE From: "Hannes Tschofenig" To: , References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> Date: Fri, 7 Aug 2009 15:45:13 +0300 Message-ID: <056301ca175c$e9373560$625aa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoXWTAZL1ukZTDiSgCKViYdIB1KfAAA1H9w In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 Cc: ecrit-bounces@ietf.org, Martin.Dawson@andrew.com, ecrit@ietf.org, R.Jesske@telekom.de, Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:42:45 -0000 Ray, Laura wants to use the reverse DNS lookup by the proxy rather than the end host. draft-thomson-geopriv-res-gw-lis-discovery talks about the end host usage instead. Ciao Hannes ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ray.Bellis@nominet.org.uk Sent: 07 August, 2009 15:18 To: L.Liess@telekom.de Cc: Martin.Dawson@andrew.com; R.Jesske@telekom.de; ecrit@ietf.org; Reinhard.Lauster@t-mobile.at; ecrit-bounces@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP > Maybe the EC could work like this : > The proxy discovers the LIS based on EDs IP-address using reverse- > DNS and SRV record (this is possible with "identity extenssions") Laura, Please see draft-thomson-geopriv-res-gw-lis-discovery-02 The main LIS Discovery draft from Geopriv previously did almost exactly what you've just described, but it was changed because of complaints from the DNS folk (myself included) that it assumed a mapping between domain names and network access that simply often doesn't exist. The current proposal instead simply stores the LIS Discovery U-NAPTR records directly in the reverse DNS tree, where there's a much stronger (almost 100%) mapping between the DNS and the network access provider. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From Ray.Bellis@nominet.org.uk Fri Aug 7 05:46:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C86F3A6F09; Fri, 7 Aug 2009 05:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB3p61SXUiJT; Fri, 7 Aug 2009 05:46:44 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 28C8E3A6F10; Fri, 7 Aug 2009 05:46:43 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=sCsgVMzKbl4b1jC8wxaEuAoD0htnyh3M1oMLkYpVQoKdboBzXMvhv689 /YMWMyXJeZ08XCT9yRK+3RVEYElE+dwRsB7KYdHx1ye+HN9MTOe9i+lRA QFJGM554kF/Vncm; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1249649208; x=1281185208; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20RE:=20[Ecri t]=20HUM=20on=20PhoneBCP|Date:=20Fri,=207=20Aug=202009=20 13:46:39=20+0100|Message-ID:=20|To:=20"H annes=20Tschofenig"=20|Cc:=20e crit@ietf.org,=0D=0A=09ecrit-bounces@ietf.org,=0D=0A=09L. Liess@telekom.de,=0D=0A=09Martin.Dawson@andrew.com,=0D=0A =09Reinhard.Lauster@t-mobile.at,=0D=0A=09R.Jesske@telekom .de|MIME-Version:=201.0|In-Reply-To:=20<056301ca175c$e937 3560$625aa20a@nsnintra.net>|References:=20<9886E5FCA6D765 49A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de>=09 <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI. ost.t-com.de>=0D=0A=09<40FB0FFB97588246A1BEFB05759DC8A 003431659@S4DE9JSAANI.ost.t-com.de>=20 =20<056301ca175c$e9373560$625aa20a@nsnintra.net>; bh=eX+Yjp8lx/ew5EenOhv42J18vVVlRSxrDCjxJsfagwI=; b=WbyKqxCroA7IM/sb5ZqguYoRkGBbckh3dw/cI3sWWz4QeXKaK/AA1+H3 jv1UWfv8ksZNvWFMibDscgGxtqvZ1KOphFT/MSukkS05lDPD5p8ke9aku 7+1wBBMaKx4p1xQ; X-IronPort-AV: E=Sophos;i="4.43,341,1246834800"; d="scan'208";a="12041079" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 07 Aug 2009 13:46:42 +0100 In-Reply-To: <056301ca175c$e9373560$625aa20a@nsnintra.net> References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <056301ca175c$e9373560$625aa20a@nsnintra.net> To: "Hannes Tschofenig" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 7 Aug 2009 13:46:39 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 07/08/2009 01:46:45 PM, Serialize complete at 07/08/2009 01:46:45 PM Content-Type: multipart/alternative; boundary="=_alternative 004630668025760B_=" Cc: Martin.Dawson@andrew.com, ecrit@ietf.org, ecrit-bounces@ietf.org, R.Jesske@telekom.de, L.Liess@telekom.de, Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:46:45 -0000 This is a multipart message in MIME format. --=_alternative 004630668025760B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > Laura wants to use the reverse DNS lookup by the proxy rather than the=20 end > host.=20 > draft-thomson-geopriv-res-gw-lis-discovery talks about the end host=20 usage > instead.=20 Yes, it primarily talks about queries by the end-host, but also mentions=20 that the exact same mechanism is also perfect for 3rd party LIS discovery=20 requests. See =A73.2 and =A74.3, although possibly this text about third party (proxy= )=20 queries could do with some beefing up. Ray --=_alternative 004630668025760B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
    > Laura wants to use the reverse DNS lookup by the proxy rather than the end
    > host.
    > draft-thomson-geopriv-res-gw-lis-discovery talks about the end host usage
    > instead.

    Yes, it primarily talks about queries by the end-hos= t, but also mentions that the exact same mechanism is also perfect for 3rd party LIS discovery requests.

    See =A73.2 and =A74.3, although possibly this text a= bout third party (proxy) queries could do with some beefing up.

    Ray
    --=_alternative 004630668025760B_=-- From Hannes.Tschofenig@gmx.net Fri Aug 7 05:50:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFCF3A6F22 for ; Fri, 7 Aug 2009 05:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3rAZNd0hR-k for ; Fri, 7 Aug 2009 05:50:00 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 54DEF3A6CFD for ; Fri, 7 Aug 2009 05:49:56 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2009 12:49:58 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp006) with SMTP; 07 Aug 2009 14:49:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+T6GUczYeTjCdqe427OpsHlJBvq11MTtidI9bj17 EhLB7D6+TN6YcD From: "Hannes Tschofenig" To: References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de><40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <056301ca175c$e9373560$625aa20a@nsnintra.net> Date: Fri, 7 Aug 2009 15:52:29 +0300 Message-ID: <056d01ca175d$ed2d0b30$625aa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_056E_01CA1777.127A4330" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoXXR9rvI6HzazQQNGvmtc1+NWKRwAAMQzQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6,0.6 Cc: Martin.Dawson@andrew.com, ecrit@ietf.org, ecrit-bounces@ietf.org, R.Jesske@telekom.de, L.Liess@telekom.de, Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:50:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_056E_01CA1777.127A4330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for pointing me to these sections. I will have a look at it.=20 =20 _____ =20 From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]=20 Sent: 07 August, 2009 15:47 To: Hannes Tschofenig Cc: ecrit@ietf.org; ecrit-bounces@ietf.org; L.Liess@telekom.de; Martin.Dawson@andrew.com; Reinhard.Lauster@t-mobile.at; = R.Jesske@telekom.de Subject: RE: [Ecrit] HUM on PhoneBCP > Laura wants to use the reverse DNS lookup by the proxy rather than the = end > host.=20 > draft-thomson-geopriv-res-gw-lis-discovery talks about the end host = usage > instead.=20 Yes, it primarily talks about queries by the end-host, but also mentions that the exact same mechanism is also perfect for 3rd party LIS = discovery requests.=20 See =A73.2 and =A74.3, although possibly this text about third party = (proxy) queries could do with some beefing up.=20 Ray=20 ------=_NextPart_000_056E_01CA1777.127A4330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Thanks for pointing me to these sections. I = will have a=20 look at it.
     

    From: Ray.Bellis@nominet.org.uk=20 [mailto:Ray.Bellis@nominet.org.uk]
    Sent: 07 August, 2009=20 15:47
    To: Hannes Tschofenig
    Cc: ecrit@ietf.org;=20 ecrit-bounces@ietf.org; L.Liess@telekom.de; Martin.Dawson@andrew.com;=20 Reinhard.Lauster@t-mobile.at; R.Jesske@telekom.de
    Subject: = RE:=20 [Ecrit] HUM on PhoneBCP


    > Laura wants to use the reverse = DNS lookup=20 by the proxy rather than the end
    > host.
    >=20 draft-thomson-geopriv-res-gw-lis-discovery talks about the end host=20 usage
    > instead.

    Yes, it = primarily=20 talks about queries by the end-host, but also mentions that the exact = same=20 mechanism is also perfect for 3rd party LIS discovery = requests.=20

    See =A73.2 and =A74.3, although possibly = this text about=20 third party (proxy) queries could do with some beefing up. =

    Ray =
    ------=_NextPart_000_056E_01CA1777.127A4330-- From mlinsner@cisco.com Fri Aug 7 06:01:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA0B3A6B09 for ; Fri, 7 Aug 2009 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.256 X-Spam-Level: X-Spam-Status: No, score=-5.256 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A05-sKvi4LIk for ; Fri, 7 Aug 2009 06:01:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 633853A68A2 for ; Fri, 7 Aug 2009 06:01:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4FADDCe0qrR7PD/2dsb2JhbACCJi+WUJ1jiCuQFgWEFg X-IronPort-AV: E=Sophos;i="4.43,341,1246838400"; d="scan'208,217";a="224915076" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 07 Aug 2009 13:01:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n77D1hXw015490; Fri, 7 Aug 2009 06:01:43 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n77D1eB2001371; Fri, 7 Aug 2009 13:01:43 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 09:01:42 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 09:01:41 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 07 Aug 2009 09:01:40 -0400 From: Marc Linsner To: "DRAGE, Keith (Keith)" , "ecrit@ietf.org" Message-ID: Thread-Topic: ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42AAJDiUoAAA+bkAAAFk66wAL5PVgAAncuW2 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3332480501_145556" X-OriginalArrivalTime: 07 Aug 2009 13:01:41.0898 (UTC) FILETIME=[356A6EA0:01CA175F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7483; t=1249650103; x=1250514103; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20ECRIT/IMS=20-=20independent=20discussio n=20from=20the=20PhoneBCP=20hum |Sender:=20; bh=xD8B7J0/olPXUImIJtAwCaJxDp+N99g2ZfKS83+2hmY=; b=vVZ4EHT3kP99OWAm/S/hewHgVcTP7ogcawOTGowgRH7t1Kga6qGk5HO6hv /xwSK6jQvaWLzsOqxxh6F99F7BPgFMvVAVsZgO/F60jTQE3jcGKp2QPnMRla A/1ZEubkcz; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:01:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3332480501_145556 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Keith, On 8/7/09 3:35 AM, "DRAGE, Keith (Keith)" wrote: > Obviously mandates differ between different parts of the world, but certa= inly > any wireless operator (2G or 3G) is currently required by the 3GPP standa= rds, > reflecting national regulation, to provide ermegency calling where they > provide CS voice service on their networks. > =20 > Where IMS is supported, there is also a requirement to support emergency > calling on IMS. > =20 > For the deployments where an operator is providing LTE in an area not cov= ered > by 2G or 3G service, there are indications prior to the network selection= to > enable determination of whether an emergency call is possible over IMS or= not. > =20 > What this essentially boils down to is that if you have an contract with = a 3G > operator to give you voice service, then emergency calls will work on tha= t > phone, because the network operator is required to support it. That appli= es > whether there is an internet browser on the phone or not. >=20 > [Marc] I agree if the voice service is circuit-switched. > =20 > As far as I know there is currently no mandate on any ISP or indeed inter= net > VOIP provider to support emergency calls. That may come in the future, bu= t so > far I have seen no evidence of it. >=20 > [Marc] In 2005 in the US, the FCC imposed 911 obligations on VoIP provide= rs > that interconnect with the PSTN. > (http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-258818A1.pdf) >=20 > What is not clear to me is whether the owner of the RF license that sells > VoIP-only (IMS =AD no CS) has more regulatory obligation wrt 911 than an OT= T > VoIP provider. Hence, my questioning whether these mandates are > self-inflicted. > =20 > So writing a document that claims that some other mechanism is the way to > offer emergency calls, and then shouting from the rooftops that this appl= ies > to mobile phones, is more likely to result in deaths than not. >=20 > [Marc] I don=B9t believe anyone claims that the ECRIT architecture is a bet= ter > technical solution for emergency calling than any of the legacy (CS) > solutions. But it is certain that legacy solutions for emergency calling > CANNOT work on the Internet (which, btw, is where the IETF is focused). = The > ECRIT solution is targeted at the Internet and CAN work on private IP > networks. If the owner/operator of a private IP network doesn=B9t care abo= ut > global universal support, then they can utilize whatever solution they wi= sh. > The market will decide in the end. >=20 > -Marc- > =20 > =20 > =20 > regards > =20 > Keith >=20 --B_3332480501_145556 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: ECRIT/IMS - independent discussion from the PhoneBCP hum Keith,


    On 8/7/09 3:35 AM, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> wrote:

    Obviously mandates differ between different parts of th= e world, but certainly any wireless operator (2G or 3G) is currently require= d by the 3GPP standards, reflecting national regulation, to provide ermegenc= y calling where they provide CS voice service on their networks.
    Where IMS is supported, the= re is also a requirement to support emergency calling on IMS.
    For the deployments where a= n operator is providing LTE in an area not covered by 2G or 3G service, ther= e are indications prior to the network selection to enable determination of = whether an emergency call is possible over IMS or not.
    What this essentially boils= down to is that if you have an contract with a 3G operator to give you voic= e service, then emergency calls will work on that phone, because the network= operator is required to support it. That applies whether there is an intern= et browser on the phone or not.

    [Marc] I agree if th= e voice service is circuit-switched.
    As far as I know there is c= urrently no mandate on any ISP or indeed internet VOIP provider to support e= mergency calls. That may come in the future, but so far I have seen no evide= nce of it.

    [Marc] In 2005 in th= e US, the FCC imposed 911 obligations on VoIP providers that interconnect wi= th the PSTN. (http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-258818A= 1.pdf)

    What is not clear to me is whether the owner of the RF license that sells V= oIP-only (IMS – no CS) has more regulatory obligation wrt 911 than an = OTT VoIP provider.  Hence, my questioning whether these mandates are se= lf-inflicted.
    So writing a document that = claims that some other mechanism is the way to offer emergency calls, and th= en shouting from the rooftops that this applies to mobile phones, is more li= kely to result in deaths than not.

    [Marc] I don’t= believe anyone claims that the ECRIT architecture is a better technical sol= ution for emergency calling than any of the legacy (CS) solutions.  But= it is certain that legacy solutions for emergency calling CANNOT work on th= e Internet (which, btw, is where the IETF is focused).  The ECRIT solut= ion is targeted at the Internet and CAN work on private IP networks.  I= f the owner/operator of a private IP network doesn’t care about global= universal support, then they can utilize whatever solution they wish.  = ;The market will decide in the end.

    -Marc-
     
     
    regards
    Keith

    --B_3332480501_145556-- From br@brianrosen.net Fri Aug 7 06:05:20 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2E23A6C82 for ; Fri, 7 Aug 2009 06:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+kQwFoOhjLV for ; Fri, 7 Aug 2009 06:04:58 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 36AB23A6B53 for ; Fri, 7 Aug 2009 06:04:58 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MZP7j-0005ev-42; Fri, 07 Aug 2009 08:04:51 -0500 From: "Brian Rosen" To: , , , References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> Date: Fri, 7 Aug 2009 09:04:46 -0400 Message-ID: <042001ca175f$a92e0d60$fb8a2820$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0421_01CA173E.221C6D60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rAAA0M6gA== 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: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:05:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0421_01CA173E.221C6D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually, the PIDF-LO is designed to cater for all the variations in addressing. You don=92t mean =93location used for emergency calls=94, = you mean =93key for location used for emergency calls=94. The area code is not = the location, it is a key that is mapped to PSAP URI. The telephone number (with its area code) is the identifier you would use with HELD to get = the location, from which LoST would get you a PSAP URI. =20 This seems trivial for you to implement: you deploy a HELD server that = takes telephone number and returns a polygon representing the area code = boundary, and you deploy a LoST server that takes that polygon and returns the = PSAP URI associated with it. This would be no more expensive than what you = are proposing. Proxies could use this or phonebcp compatible endpoints = could use it. =20 =20 NENA is planning on doing pretty much this same thing to handle legacy wireline networks where telephone number is currently the key to the location database (ALI). The LIS will store location as the key (using held-identity), and a gateway will construct an LbyR from the phone = number. All the rest of the ecrit compatible infrastructure can then use the Location URI to get location, route, etc. =20 Making what you now see as a one step mapping (area code to PSAP URI) = into a two step (telephone number to polygon, polygon to PSAP URI) is a bit = more complex, but not any significant difference in deployment. It also = works for wireless (cell sector/ID to polygon, polygon to PSAP URI), and of course, would be upwardly compatible with real location based routing, should your systems evolve as we expect they evolve, or something like = EU regulations compel more accurate location services. =20 Brian =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of L.Liess@telekom.de Sent: Friday, August 07, 2009 7:59 AM To: Martin.Dawson@andrew.com; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Hi Martin, =20 Hi Laura, =20 I regard it as a goal of ECRIT =96 as derived from the goals of the IETF generally =96 to define a structure that will allow an Internet capable = device to connect to a network anywhere in the world and be able to make = emergency calls. Just as FTP, email protocols, SIP and etc. all work regardless of which network the devices attach to. I don=92t understand how the kind = of variations that you are requesting be added to the specification will = allow that to occur. [[LLi]] This is fine and usefull. Just that every country uses today different formats for the location used for emergency calls. Changing = this will take time and costs money.=20 What is the harm in allowing ECs to work with local location formats = which are understood only by the LIS and the PSAP ?. I dont see why a common location format must be implemented by everybody.=20 Maybe the EC could work like this :=20 * The proxy discovers the LIS based on EDs IP-address using reverse-DNS and SRV record (this is possible with "identity = extenssions") * It retrieves the location ( e.g. using HELD) in a local format understood only by the LIS and the PSAP, which are in the same country. = The location is just a string which is passed transparently through the = network to the PSAP. In my opinion, it would be in principle posible to use = LbyR to transport local location identidfiers, e. g. area-code@lis.telekom.de , = but this is currently my personal opinion, I didn' found any statemant or example in the drafts. =20 * The LIS delivers, together with the LbyR above, the PSAP URI. As far as I know there is currently no way to do this in HELD (or did I = miss something?). =20 =20 It would be an alternative which is interoperable and quite easy to implement, without the need for the operators to change their location databases. I think by allowing this scenario, interoperable EC could be achieved earlier. And this does not exclude the scenario described in = the framework and phone-bcp, where the EDs retrieve deo or civic location, = which is needed for EC to work in private/enterprise networks. =20 =20 =20 =20 The position appears to be that the German regulator doesn=92t require anything =96 and the operators will not be proactive in following a specification if it doesn=92t include what already exists. In that = context, I don=92t understand why there is a need for the BCP at all. There may be = no need to endorse it but, similarly, there should be no need to object to = it =96 since the operators will only put in place their preferred version of = the service in any case.=20 [[LLi]] This is not quite true. We have to ensure that EC works for different AN- and VoIP-provider and for nomadic users in Germany by = 2013. Our current solution does not allow this and there is the same for other carriers. We definitively need to define in Germany an architecture = which fullfills this requirements. It would be very usefull if we can use = standard protocols. But nobody will be willing to change everything at once. = Having a standard based architecture which is low cost would be a great = advantage.=20 =20 Kind regards Laura =20 =20 That=92s OK=85 insofar as it just means German networks aren=92t ECRIT = compatible =96 =93compatibility=94 isn=92t a worthy goal in and of itself; it has = to actually mean any device can work anywhere. =20 Cheers, Martin =20 _____ =20 From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, =20 I think what you=92re saying is that you don=92t think that Germany will = go on to implement full ECRIT support but will peg development at an interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC will = look like in 20 years. Roland's answer only applies to the next 5 to 10 = years.=20 =20 That would be disappointing =96 not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service. [[LLi]] This may be true for "green field" ISPs and VSPs but not for incumbent carriers with existing infrastructure. And universal service = is not a requirement for us. Neither the German regulator requires it nor = is it a busines case. =20 =20 Nevertheless, I don=92t think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP should = be more flexible: =20 * Allow additional location identifiers =20 * Allow AN operated LOST=20 * Provide a way to enable LOST-query based on national or domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives. =20 * Allow and describe also network-centric, not only ED-centric architectures. If I remember correctly, John Medland from BT also recomended to use a more network- centric architecture, at least for the next years.=20 =20 I think it just means that the German regulator and technical advisory committees would point out the subset aspects of compliance that would = be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard body = is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with very valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a business case = will not help the draft in the end, also if it becomes a BCP. It would make sense to make it more flexible so people are willing to adopt it. =20 =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis =96 as has been = done in the UK and Canada. Of course, it=92s generally recognized as only an interim step, even in those jurisdictions. Other comments below. =20 Cheers, Martin =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling based on location-by-reference and ED=92s IP-address.=20 [[MCD]] I think you might mean =93identity extensions=94 rather than location-by-reference because LbyR still requires the ED to obtain the reference =96 e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD but SOAP = over HTTP, but anyway similar). The LIS responds with a numeric string = associated to the caller location, in principle a LbyR and with the PSAP number. = The proxy inserts the LbyR into the SIP-message (as P-Asserted-ID because = the PSAPs are in PSTN) and routes the message to the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being realistic, at least in Germany, some are not realistic at all. Implementing these requirements cost a carrier a lot of money and there is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and location databases. Routing of emergency calls is currently done in Germany based = on phone area code not on geo or civic location, at least for the fixed network. For mobile networks the cell-id is used in common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US has = lots (6000 plus) and Australia has two (and they are redundant so it = doesn=92t matter which one). Presumably geographic information, for PSAP catchment areas, is the basis for determining which area codes are relevant to = begin with? After all, an area code is not intrinsically geographic; it=92s a network routing value. If so, then some geographic discriminator is = already in play in terms of constructing the area code based routing data = (something like zip codes perhaps?) =96 and in that case, it should be = straightforward to by-pass the area code step in the construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the carriers, the regulator and the PSAPs operators (police, the Red Cross) agreed to do = so. This may change in the future, but it will take a quite long time. =20 With nomadic VoIP devices (and it=92s no good being in denial about = this being the norm in the future) area code is no more reliable than it is = for conventional mobile phones. And, presumably, area code is not used for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the area code, and have a different table than the fixed network operators. They = are not going to change this. As to the nomadic SIP-users...if we like it = or not, very few of our customers use our SIP service nomadic, let alone = call EC from their laptop. =20 1 LOST as a national, let alone as a global directory is = not going to be implemented. The regulator will provide in the web a static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would still be able = to determine a route to the correct PSAP. Alternatively, as long as the regulator is maintaining a web service with the routing information, why = not make that directly accessible using LoST and save the operators the cost = of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page with a table which operator can print and implement in their darabases and operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you know. = The regulator will not do this. 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The emergency network can (automatically and before human resources are engaged) = assess the source of the reference, and the validity of the location by dereference, without having to trust location provided directly from the = ED. There are more sophisticated approaches to trustability even using LbyV = =96 based on digital signatures across appropriate attributes. This WG and Geopriv haven=92t really got to grips with that=85 yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is = needed if EC must work for private and enterprise networks and VPNs. We have = no such regulatory requirements. And we don't know of any verdor of = DSL-EDs which provides today SIP with LbyR and is as cheap as the devices = without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. =20 1 There are already a lot of existing EDs in usage which don=92t = send location. =20 [[MCD]] Quite right. ECRIT doesn=92t overly concern itself with that = interim situation. The UK and Canadian definitions for an interim solution = (limiting service to in-country VoIP proxy operators) both assume third-party = query via identity-extension to allow the proxy or the VPC to make the query = to the LIS. This isn=92t extensible to universal emergency service access = by all visiting devices but it does put the necessary LIS functionality in = place as a very good starting point. It would be a pity if Germany were to cease = the evolution there as it would not fulfil the real promise of the Internet = and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination infrastructure in place for the purposes of dispatch is done =96 and = then the next, simpler step, of using that to support the routing procedure = isn=92t taken=85 that would be a waste. [[LLi]] Do you think this is an argument for a product manager? They = need a business case. =20 =20 =20 We don=92t intend to require our ED-vendors to provide location = because it is useless to us. =20 We could agree with the document with following changes:=20 * Other location identifiers then geo or civil are allowed. It must be possibe that the data foermat is flexible due to different requirements = from regulators over the whole world. (e.G Germany area codes for fixed- and Cell-Id for moile- providers)=20 * The MUST for the end devices to support location information, DHCP location options and HELD shall be removed=20 * It must be possible for the VoIP-provider=92s proxy to use a LOST (or an ESRP) provided by the AN or by other local provider on behalf of the = AN. =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. Currently, = neither the IETF- nor the 3GPP-architecture for emergency calling covers our = real needs for the next 2 to 5 years and in the end everybody still has its = own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de=20 http://www.telekom.de=20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 =20 -------------------------------------------------------------------------= --- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= --- -------------------- [mf2] =20 =20 -------------------------------------------------------------------------= --- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= --- -------------------- [mf2] =20 ------=_NextPart_000_0421_01CA173E.221C6D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP

    Actually, the PIDF-LO is designed to cater for all the variations in addressing.=A0 You don’t mean “location used = for emergency calls”, you mean “key for location used for = emergency calls”.=A0 The area code is not the location, it is a key that is = mapped to PSAP URI.=A0 The telephone number (with its area code) is the identifier = you would use with HELD to get the location, from which LoST would get you a = PSAP URI.

     

    This seems trivial for you to implement: you deploy a = HELD server that takes telephone number and returns a polygon representing = the area code boundary, and you deploy a LoST server that takes that polygon and = returns the PSAP URI associated with it.=A0=A0=A0 This would be no more = expensive than what you are proposing.=A0 Proxies could use this or phonebcp compatible = endpoints could use it.=A0

     

    NENA is planning on doing pretty much this same thing to = handle legacy wireline networks where telephone number is currently the key to = the location database (ALI).=A0 The LIS will store location as the key = (using held-identity), and a gateway will construct an LbyR from the phone = number.=A0 All the rest of the ecrit compatible infrastructure can then use the = Location URI to get location, route, etc.

     

    Making what you now see as a one step mapping (area code = to PSAP URI) into a two step (telephone number to polygon, polygon to PSAP URI) = is a bit more complex, but not any significant difference in deployment.=A0 = It also works for wireless (cell sector/ID to polygon, polygon to PSAP URI), and = of course, would be upwardly compatible with real location based routing, = should your systems evolve as we expect they evolve, or something like EU = regulations compel more accurate location services.

     

    Brian

     

    From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = L.Liess@telekom.de
    Sent: Friday, August 07, 2009 7:59 AM
    To: Martin.Dawson@andrew.com; R.Jesske@telekom.de; = ecrit@ietf.org
    Cc: Reinhard.Lauster@t-mobile.at
    Subject: Re: [Ecrit] HUM on PhoneBCP

     

     

    Hi Martin,  

    Hi Laura,

     

    I regard it as a goal of ECRIT – as derived from the = goals of the IETF generally – to define a structure that will allow an = Internet capable device to connect to a network anywhere in the world and be able to make emergency calls. Just as FTP, email protocols, SIP and etc. all work = regardless of which network the devices attach to. I don’t understand how the = kind of variations that you are requesting be added to the specification will = allow that to occur.

    [[LLi]] This is = fine and usefull. Just that every country uses today different formats for the = location used for emergency calls. Changing this will take time and costs money. =

    What is the = harm in allowing ECs to work with local location formats which are understood only by the = LIS and the PSAP ?. I dont = see why a common location format must be implemented by everybody.

    Maybe the = EC could work like this : =

    • The proxy = discovers the LIS based on EDs IP-address using reverse-DNS and SRV record (this = is possible with "identity extenssions")
    • It retrieves the = location ( e.g. using HELD) in a local format understood only by the LIS and = the PSAP, which are in the same country. The location is just a string = which is passed transparently through the network to the PSAP. In my = opinion, it would be in principle  posible to use LbyR to transport = local location identidfiers, e. = g.  area-code@lis.telekom.de , but this is currently my personal opinion, I didn' found any statemant or example in the = drafts.   
    • The LIS delivers, = together with the LbyR above, the PSAP URI.  As far as I know there is currently no way to do this in HELD (or did I miss something?).        
       

    It would be an alternative which is interoperable and = quite easy to implement, without the need for the operators to change = their location databases. I think by allowing this scenario, = interoperable EC could be achieved earlier. And this does not exclude the scenario described in the framework and phone-bcp, where the EDs = retrieve deo or civic location, which is needed for EC to work in = private/enterprise networks.  
      

     &n= bsp;  

     

    The position appears to be that the German regulator = doesn’t require anything – and the operators will not be proactive in = following a specification if it doesn’t include what already exists. In that = context, I don’t understand why there is a need for the BCP at all. There = may be no need to endorse it but, similarly, there should be no need to object = to it – since the operators will only put in place their preferred = version of the service in any case.
    [[LLi]]  This is not quite true. We have to ensure that = EC works for different AN- and VoIP-provider and for nomadic users in = Germany by 2013. Our current solution does not allow this and there is the = same for other carriers. We definitively need to define in Germany an architecture which fullfills this requirements. It would be very usefull if we can use standard protocols. But nobody will be = willing to change everything at once.  Having a standard based architecture = which is low cost would be a great advantage.

     

    Kind regards

    Laura     

     

     That’s OK… insofar as it just means German networks aren’t ECRIT compatible – = “compatibility” isn’t a worthy goal in and of itself; it has to actually mean any = device can work anywhere.

     

    Cheers,

    Martin

     

    From:= = L.Liess@telekom.de [mailto:L.Liess@telekom.de]
    Sent: Friday, 7 August 2009 12:29 AM
    To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org
    Cc: Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on PhoneBCP

     

    Hi Martin,

     

    See comments inline [[LLi]].

     

     

    Laura

    From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Dawson, Martin
    Sent: Wednesday, August 05, 2009 11:00 AM
    To: Jesske, Roland; ecrit@ietf.org
    Subject: Re: [Ecrit] HUM on PhoneBCP

    Hi Roland,

     

    I think what you’re saying is that you don’t = think that Germany will go on to implement full ECRIT support but will peg = development at an interim phase.
    [[LLi]]  We don't know how the realtime = application networks or EC will look like in 20 years. Roland's = answer only applies to the next 5 to 10 years. 

     

     Tha= t would be disappointing – not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service.

    [[LLi]]  This may be true for "green field" = ISPs and VSPs but not for incumbent carriers with existing infrastructure.  And universal service is not a requirement = for us. Neither the German regulator requires it nor is it a busines case.   

     

    Nevertheless, I don’t think that decision invalidates = the BCP;
    [[LLi]]  We think it does, because some of = the requirements are not flexible enough to cover the deployments within the = next years.  The BCP should be more = flexible:  

    • Allow additional = location identifiers 
    • Allow AN operated = LOST
    • Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS to = query the LOST , but there are also other = alternatives. 
    • Allow and describe= also network-centric, not only ED-centric = architectures. If I  remember correctly, John Medland from BT also = recomended to use a more network- centric architecture, at least for the next = years.

     

    I think it just means that the German regulator and = technical advisory committees would point out the subset aspects of compliance = that would be applicable to that jurisdiction.  <= span lang=3DEN-AU = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'> [[LLi]]  Again, the draft is not flexible enough for it.  If the BCP contains requirements which are not = realistic, people will just discard the BCP and implement proprietary = stuff. My expectation from a standard body is to define protocols and = architecture which people are willing to implement in their network or products , not = only in the lab.

     

    [[LLi]] 

    We are not against the draft in principle. ECRIT = provides&= nbsp; us with very valuable specifications as LbyR, HELD, identity extensions. But targeting an architecture which requires = everbody to invest without a business case will not help the = draft in the end, also if it becomes a BCP.  It would make sense to = make it more flexible so people are willing to adopt = it.    

     

     Actually, based on your description below, the NENA i2 architecture would probably be a more straightforward baseline for = analysis – as has been done in the UK and Canada. Of course, it’s = generally recognized as only an interim step, even in those = jurisdictions.

    Other comments below.

     

    Cheers,

    Martin

     

    From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = R.Jesske@telekom.de
    Sent: Wednesday, 5 August 2009 6:19 PM
    To: ecrit@ietf.org
    Subject: Re: [Ecrit] HUM on PhoneBCP

     

     

    Dear all,
    We would like the = document to become a BCP as soon as possible so the group can move on with other = documents related to emergency calling based on location-by-reference and = ED’s IP-address.

    [[MCD]] I think you might mean “identity = extensions” rather than location-by-reference because LbyR still requires the ED to = obtain the reference – e.g. by HELD.
    [[LLi]] We use both, the IP-address as UE identity and = LbyR. The SIP-proxy uses the IP-address to query the LIS using HTTP (it's not = HELD but SOAP over HTTP, but anyway similar). The LIS responds = with a numeric string associated to the caller location, in principle a LbyR = and with the PSAP number. The proxy inserts the LbyR into the = SIP-message (as P-Asserted-ID because the PSAPs are in PSTN) and routes = the message to the PSAP.  It's a low cost solution. 

    But we can not HUM for the = current form of the document.

    Back to the document: Some = requirements are far form being realistic, at least in Germany, some are not = realistic at all. Implementing these requirements cost a carrier a lot of money and = there is no ROI for it.

    Just a few examples: =

    =B7       Requiring either geo or civic = location does not provide carriers with enough flexibility to reuse their = existing mechanisms and location databases. Routing of emergency calls is = currently done in Germany based on phone area code not on geo or civic location, at = least for the fixed network. For mobile networks the cell-id is used in common. = This is regulated by the german regulator.

    [[MCD]] How many unique PSAP routes are required in Germany? = The US has lots (6000 plus) and Australia has two (and they are redundant so it doesn’t matter which one). Presumably geographic information, for = PSAP catchment areas, is the basis for determining which area codes are = relevant to begin with? After all, an area code is not intrinsically geographic; = it’s a network routing value. If so, then some geographic discriminator is = already in play in terms of constructing the area code based routing data = (something like zip codes perhaps?) – and in that case, it should be = straightforward to by-pass the area code step in the construction of routing that goes = the correct PSAP URI.
    [[LLi]] Currently, fixed networks carriers in Germany route the ECs based only on the caller's area = code. Sometime in the past, the carriers, the regulator and the PSAPs operators = (police, the Red Cross) agreed to do so. This may change in the future, but = it will take a quite long = time.      

     With nomadic VoIP devices (and it’s no good = being in denial about this being the norm in the future) area code is no more = reliable than it is for conventional mobile phones. And, presumably, area code is = not used for conventional cellular emergency call routing?
    [[LLi]]  As far as I know, mobile networks use the = Cell-ID, not the area code, and have a different table than the fixed network operators. They are not going to change this.  As to the = nomadic SIP-users...if we like it or not, very few of our = customers use our SIP service nomadic, let alone call EC from their laptop.        = &n= bsp;

    1      = ;        LOST as a national, let = alone as a global directory is not going to be implemented. The regulator will = provide in the web a static table which contains the PSAPs and the area for which = they are responsible (one or more area codes). Every carrier has to implement its = own routing database for emergency calls.

    [[MCD]] Whatever the carriers implement (and they have to = implement something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would still be able = to determine a route to the correct PSAP. Alternatively, as long as the = regulator is maintaining a web service with the routing information, why not make = that directly accessible using LoST and save the operators the cost of = duplicating the service at all?
    [[LLi]]  There is a big difference between maintaining = a web page with a table which operator can print and implement in their darabases and operating a database which is queried for every emergency call in Germany, must have an availablity of 99,99...% ,  is secure enough...you know. The regulator will not do this.


    2       We have no intention to rely on = end devices for location information because:     =B7       ED provided location info is = not trusted

    [[MCD]] Location by reference mitigates this trust issue. = The emergency network can (automatically and before human resources are = engaged) assess the source of the reference, and the validity of the location by dereference, without having to trust location provided directly from the = ED. There are more sophisticated approaches to trustability even using LbyV = – based on digital signatures across appropriate attributes. This WG and = Geopriv haven’t really got to grips with that… yet.
    [[LLi]]  We build the SIP-network and EC now. = ED-provided location is needed if EC must work for private and = enterprise networks and VPNs.  We have no such regulatory requirements.  And we don't know of any verdor of = DSL-EDs which provides today SIP with LbyR and is as cheap as the devices without it. If you do, please let me = know. 

    The regulator ask us to guarantee that EC works. What if a customer dials 112 and his end device does not send the location? So I have to implement both solutions, with and = without ED provided location, anyway.  
    1       There are already a lot of existing EDs in usage which don’t send location.   

    [[MCD]] Quite right. ECRIT doesn’t overly concern = itself with that interim situation. The UK and Canadian definitions for an interim = solution (limiting service to in-country VoIP proxy operators) both assume = third-party query via identity-extension to allow the proxy or the VPC to make the = query to the LIS. This isn’t extensible to universal emergency service = access by all visiting devices but it does put the necessary LIS functionality in = place as a very good starting point.  It would be a pity if Germany = were to cease the evolution there as it would not fulfil the real promise of the Internet and the ECRIT model.
    [[LLi]]  I wonder who will drive and pay for upgrading the interim = solutions.  Unfortunatelly, it's all about money...

     Think about it; all the complexity of putting location determination infrastructure in place for the purposes of dispatch is = done – and then the next, simpler step, of using that to support the = routing procedure isn’t taken… that would be a waste.

    [[LLi]]  Do you think this is an argument for a product manager? They need a business case. 

     

     

      We don’t intend to require our ED-vendors to provide location because = it is useless to us.  

    We could agree with the = document with following changes:

      • Other location identifiers then geo or civil are allowed. It must be = possibe that the data foermat is flexible due to different requirements = from regulators over the whole world. (e.G Germany area codes for = fixed- and Cell-Id for moile- providers) =
      • The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed
      • It must be possible for the VoIP-provider’s proxy to use a LOST = (or an ESRP) provided by the AN or by other local provider on behalf of = the AN. 

     

     There is no value in = Hum-ing documents which one is not going to implement and does not fit into = regulated schemes like in Germany. Currently, neither the IETF- nor the = 3GPP-architecture for emergency calling covers our real needs for the next 2 to 5 years = and in the end everybody still has its own proprietary implementation.   

    Best regards

    Roland

     

    Deutsche Telekom Netzproduktion GmbH
    Zentrum Technik Einf=FChrung
    Roland Jesske
    Gateways, Protokolle, Konvergenz, TE32-1
    Heinrich-Hert= z-Str. 3-7, 64295 Darmstadt,
    Postfach, 64307 Darmstadt (Postanschrift)
    +496151 628 2766 (Tel)
    +491718618445= (Mobile)
    E-Mail: r= .jesske@telekom.de
    http://www.telekom.de =

     

    Registerrechtl= iche Unternehmensangaben:
    Deutsche Telekom Netzproduktion (DT NP) GmbH
    Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno = Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
    Handelsregister: Amtsgericht Bonn HRB 14190
    Sitz der Gesellschaft: Bonn
    USt-IdNr.: DE 814645262

     

     


    = -------------------------------------------------------------------------= -----------------------
    = This message is for the designated recipien= t only and may
    = contain privileged, proprietary, or otherwise pr= ivate information.  
    = If you have received it in error, plea= se notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibited.
    = -------------------------------------------------------------------------= -----------------------
    [mf2]

     

     


    = -------------------------------------------------------------------------= -----------------------
    = This message is for the designated recipien= t only and may
    = contain privileged, proprietary, or otherwise pr= ivate information.  
    = If you have received it in error, plea= se notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibited.
    = -------------------------------------------------------------------------= -----------------------
    [mf2]

     

    ------=_NextPart_000_0421_01CA173E.221C6D60-- From mlinsner@cisco.com Fri Aug 7 06:26:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95283A6EB3 for ; Fri, 7 Aug 2009 06:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.649, 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 H5DFawUXZVut for ; Fri, 7 Aug 2009 06:26:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F0A653A6CFD for ; Fri, 7 Aug 2009 06:26:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAvIe0qrR7MV/2dsb2JhbAC3JIgrkBoFhBaBUQ X-IronPort-AV: E=Sophos;i="4.43,341,1246838400"; d="scan'208";a="224925827" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Aug 2009 13:26:08 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n77DQ8Pv011359; Fri, 7 Aug 2009 06:26:08 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n77DQ7mv014781; Fri, 7 Aug 2009 13:26:08 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 09:26:07 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 09:26:07 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 07 Aug 2009 09:26:04 -0400 From: Marc Linsner To: John Lange Message-ID: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoXYpzl5OveLP3SsUONjUR4JKrMtQ== In-Reply-To: <1249587517.5335.80.camel@vandium.darkcore.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Aug 2009 13:26:07.0187 (UTC) FILETIME=[9ECBCA30:01CA1762] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=795; t=1249651568; x=1250515568; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20HUM=20on=20PhoneBCP |Sender:=20; bh=xRKUseY21hRxPgcKlH4GXOfLSs9W0uv0Ye2+j3I5Vz8=; b=AoiyGgL375g8MBOcuCfxjmWd4hTTKpEgD9108CQM+28nBdqu/a84FIH73g hJ6+ZmszaFJi6d1DHUwOkF6C7/55k9DIMKyKUnxv85Q7yUqoSz9jqeR5vj34 VqdpnT9/QNHe3eRjX1S0bTjTYoDBSsaByjyy+bYq0ecF9antT9u6Y=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:26:07 -0000 > > There is no part of Ci2 which allows location to be obtained (v0) or > transmitted (v1) from endpoints. > > In NENAi2 terms, there is no v0 or v1 interface in Ci2. > > To answer your question, not only is "location awareness in devices ... > not presumed", it is presumed that: > > - devices are not location aware and never will be. > - and, VSPs can not do and will never do sip-location-conveyance. > This smells like regulators being manipulated by special interest to protect business models. Not surprising though, some business models can only survive by stifling competition via regulation. The only hope is that the Internet is mature enough in the marketplace that the consumer will be able to tell the difference and make the final decision. -Marc- From L.Liess@telekom.de Fri Aug 7 06:35:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF56428C1CA; Fri, 7 Aug 2009 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glLg-skbV-AI; Fri, 7 Aug 2009 06:35:15 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 2EE8428C1D7; Fri, 7 Aug 2009 06:33:55 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 07 Aug 2009 15:33:53 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 15:33:53 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Aug 2009 15:33:52 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0034316F8@S4DE9JSAANI.ost.t-com.de> In-reply-to: <056301ca175c$e9373560$625aa20a@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoXWTAZL1ukZTDiSgCKViYdIB1KfAAA1H9wAAHDaSA= References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <056301ca175c$e9373560$625aa20a@nsnintra.net> From: To: , X-OriginalArrivalTime: 07 Aug 2009 13:33:53.0523 (UTC) FILETIME=[B4C10430:01CA1763] Cc: ecrit-bounces@ietf.org, Martin.Dawson@andrew.com, ecrit@ietf.org, R.Jesske@telekom.de, Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:35:15 -0000 This is correct.=20 Thank you, Hannes.=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, August 07, 2009 2:45 PM To: Ray.Bellis@nominet.org.uk; Liess, Laura Cc: Martin.Dawson@andrew.com; Jesske, Roland; ecrit@ietf.org; Reinhard.Lauster@t-mobile.at; ecrit-bounces@ietf.org Subject: RE: [Ecrit] HUM on PhoneBCP Ray,=20 =20 Laura wants to use the reverse DNS lookup by the proxy rather than the end host.=20 draft-thomson-geopriv-res-gw-lis-discovery talks about the end host usage instead.=20 =20 Ciao Hannes =20 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ray.Bellis@nominet.org.uk Sent: 07 August, 2009 15:18 To: L.Liess@telekom.de Cc: Martin.Dawson@andrew.com; R.Jesske@telekom.de; ecrit@ietf.org; Reinhard.Lauster@t-mobile.at; ecrit-bounces@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =09 =09 > Maybe the EC could work like this :=20 > The proxy discovers the LIS based on EDs IP-address using reverse- > DNS and SRV record (this is possible with "identity extenssions")=20 =09 Laura,=20 =09 Please see draft-thomson-geopriv-res-gw-lis-discovery-02=20 =09 The main LIS Discovery draft from Geopriv previously did almost exactly what you've just described, but it was changed because of complaints from the DNS folk (myself included) that it assumed a mapping between domain names and network access that simply often doesn't exist.=20 =09 The current proposal instead simply stores the LIS Discovery U-NAPTR records directly in the reverse DNS tree, where there's a much stronger (almost 100%) mapping between the DNS and the network access provider.=20 =09 kind regards,=20 =09 Ray=20 =09 --=20 Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From mlinsner@cisco.com Fri Aug 7 07:06:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C2C3A6F10 for ; Fri, 7 Aug 2009 07:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.295 X-Spam-Level: X-Spam-Status: No, score=-5.295 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXSThfJydodv for ; Fri, 7 Aug 2009 07:06:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6AEB73A6A87 for ; Fri, 7 Aug 2009 07:06:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAOPRe0pAZnme/2dsb2JhbACCJDGWUJ4LiCuQHgWCKoFs X-IronPort-AV: E=Sophos;i="4.43,341,1246838400"; d="scan'208,217";a="53273932" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Aug 2009 14:06:06 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n77E66X9008882 for ; Fri, 7 Aug 2009 10:06:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n77E66oL020617 for ; Fri, 7 Aug 2009 14:06:06 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 10:06:05 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 10:06:05 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 07 Aug 2009 10:06:04 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: PhoneBCP Publication Request HUM Thread-Index: AcoXaDNoEx+gYth04EaM7J4f5A4RqA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3332484365_377450" X-OriginalArrivalTime: 07 Aug 2009 14:06:05.0627 (UTC) FILETIME=[3460B0B0:01CA1768] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1711; t=1249653966; x=1250517966; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20PhoneBCP=20Publication=20Request=20HUM |Sender:=20 |To:=20=22ecrit@ietf.org=22=20; bh=BMEiwV1OW8YHGTcEztAgilkgizTpcDguLWuQK5s0EtU=; b=exgz01zqvakY6OFqqngg5Rz/Ann1xuTyHt2xOOjcN/f84nlHJZR3tp7GyL 2SgbJnim59HA9UFuMfN6DU6bZEEbAjeawtaMoQgN+lOpv2VpsM8CYul7SyKJ ru6Vcj4nG0; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Ecrit] PhoneBCP Publication Request HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 14:06:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3332484365_377450 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable We called for a hum during the Stockholm meeting asking if PhoneBCP is read= y for Publication Request. There was rough consensus in the room agreeing that PhoneBCP is ready to move forward. We took the question to the list asking, =B3Do you agree or disagree that PhoneBCP -13 is ready to Publication Request?=B2, and gave 1 week for responses. The vote on the list is now closed and we are calling rough consensus that PhoneBCP is ready for Publication Request, hence it=B9s status will not change. Marc & Hannes --B_3332484365_377450 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable PhoneBCP Publication Request HUM We called for a hum during the Stockholm meeting ask= ing if PhoneBCP is ready for Publication Request.  There was rough cons= ensus in the room agreeing that PhoneBCP is ready to move forward.  We = took the question to the list asking, “Do you agree or disagree that P= honeBCP -13 is ready to Publication Request?”, and gave 1 week for res= ponses.  The vote on the list is now closed and we are calling rough co= nsensus that PhoneBCP is ready for Publication Request, hence it’s sta= tus will not change.


    Marc & Hannes     --B_3332484365_377450-- From L.Liess@telekom.de Fri Aug 7 07:45:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B64228C169 for ; Fri, 7 Aug 2009 07:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k72hjDlsnWoS for ; Fri, 7 Aug 2009 07:45:02 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 840F128C1C9 for ; Fri, 7 Aug 2009 07:44:43 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 07 Aug 2009 16:44:41 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 16:44:41 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA176D.982DDA32" Date: Fri, 7 Aug 2009 16:44:39 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00348055D@S4DE9JSAANI.ost.t-com.de> In-reply-to: <042001ca175f$a92e0d60$fb8a2820$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rAAA0M6gAACNUgw References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <042001ca175f$a92e0d60$fb8a2820$@net> From: To: , , , X-OriginalArrivalTime: 07 Aug 2009 14:44:41.0279 (UTC) FILETIME=[989D24F0:01CA176D] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 14:45:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA176D.982DDA32 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brian, =20 Please see comments inline. =20 =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, August 07, 2009 3:05 PM To: Liess, Laura; Martin.Dawson@andrew.com; Jesske, Roland; = ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =09 =09 Actually, the PIDF-LO is designed to cater for all the variations in = addressing. You don't mean "location used for emergency calls", you = mean "key for location used for emergency calls". The area code is not = the location, it is a key that is mapped to PSAP URI.=20 [[LLi]] This is correct. =20 The telephone number (with its area code) is the identifier you would = use with HELD to get the location, from which LoST would get you a PSAP = URI. [[LLi]] Here we don't use the phone number. The proxy sends the = IP-address to the LIS. The LIS finds out the access hardware (DSLAM = port) corresponding to the IP-address and assigns a temporary string to = it (kind of LbyR). It also finds out the phone area code for this = hardware. With the phone area code, the LIS queries a table which = contains the phone area codes and the corresponding PSAP URI, then = delivers the the string (LbyR) and the PSAP-URI to the SIP proxy. The = SIP proxy routes the call and sends the LbyR to the PSAP. In very few = cases, PSAPs dereference the the LyBR to a civic address.=20 We do not have any kind of geo data or poligons in our database. In = principle we have the the civic address, but the access to this data is = quite slow. I think other fixed networks carriers here have more or = less the same.=20 =20 This seems trivial for you to implement: you deploy a HELD server that = takes telephone number and returns a polygon representing the area code = boundary, and you deploy a LoST server that takes that polygon and = returns the PSAP URI associated with it. =20 =09 This would be no more expensive than what you are proposing. Proxies = could use this or phonebcp compatible endpoints could use it. =20 =20 NENA is planning on doing pretty much this same thing to handle legacy = wireline networks where telephone number is currently the key to the = location database (ALI). The LIS will store location as the key (using = held-identity), and a gateway will construct an LbyR from the phone = number. All the rest of the ecrit compatible infrastructure can then = use the Location URI to get location, route, etc. =20 Making what you now see as a one step mapping (area code to PSAP URI) = into a two step (telephone number to polygon, polygon to PSAP URI) is a = bit more complex, but not any significant difference in deployment. It = also works for wireless (cell sector/ID to polygon, polygon to PSAP = URI), and of course, would be upwardly compatible with real location = based routing, should your systems evolve as we expect they evolve, or = something like EU regulations compel more accurate location services. =09 [[LLi]] Nobody here is willing to putting geodata or poligons into the = access databases. And we could avoid doing this just by allowing the = LIS to query the local LOST with the LbyR and to deliver the PSAP URI to = the SIP proxy. =20 =20 Kind regards Laura =20 Brian =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of L.Liess@telekom.de Sent: Friday, August 07, 2009 7:59 AM To: Martin.Dawson@andrew.com; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Hi Martin, =20 Hi Laura, =20 I regard it as a goal of ECRIT - as derived from the goals of the IETF = generally - to define a structure that will allow an Internet capable = device to connect to a network anywhere in the world and be able to make = emergency calls. Just as FTP, email protocols, SIP and etc. all work = regardless of which network the devices attach to. I don't understand = how the kind of variations that you are requesting be added to the = specification will allow that to occur. [[LLi]] This is fine and usefull. Just that every country uses today = different formats for the location used for emergency calls. Changing = this will take time and costs money.=20 What is the harm in allowing ECs to work with local location formats = which are understood only by the LIS and the PSAP ?. I dont see why a = common location format must be implemented by everybody.=20 Maybe the EC could work like this :=20 * The proxy discovers the LIS based on EDs IP-address using = reverse-DNS and SRV record (this is possible with "identity = extenssions")=20 * It retrieves the location ( e.g. using HELD) in a local format = understood only by the LIS and the PSAP, which are in the same country. = The location is just a string which is passed transparently through the = network to the PSAP. In my opinion, it would be in principle posible to = use LbyR to transport local location identidfiers, e. g. = area-code@lis.telekom.de , but this is currently my personal opinion, I = didn' found any statemant or example in the drafts. =20 * The LIS delivers, together with the LbyR above, the PSAP URI. As = far as I know there is currently no way to do this in HELD (or did I = miss something?). =20 =20 It would be an alternative which is interoperable and quite easy to = implement, without the need for the operators to change their location = databases. I think by allowing this scenario, interoperable EC could be = achieved earlier. And this does not exclude the scenario described in = the framework and phone-bcp, where the EDs retrieve deo or civic = location, which is needed for EC to work in private/enterprise networks. = =20 =20 =20 =20 The position appears to be that the German regulator doesn't require = anything - and the operators will not be proactive in following a = specification if it doesn't include what already exists. In that = context, I don't understand why there is a need for the BCP at all. = There may be no need to endorse it but, similarly, there should be no = need to object to it - since the operators will only put in place their = preferred version of the service in any case.=20 [[LLi]] This is not quite true. We have to ensure that EC works for = different AN- and VoIP-provider and for nomadic users in Germany by = 2013. Our current solution does not allow this and there is the same for = other carriers. We definitively need to define in Germany an = architecture which fullfills this requirements. It would be very usefull = if we can use standard protocols. But nobody will be willing to change = everything at once. Having a standard based architecture which is low = cost would be a great advantage.=20 =20 Kind regards Laura =20 =20 That's OK... insofar as it just means German networks aren't ECRIT = compatible - "compatibility" isn't a worthy goal in and of itself; it = has to actually mean any device can work anywhere. =20 Cheers, Martin =20 ________________________________ From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, =20 I think what you're saying is that you don't think that Germany will = go on to implement full ECRIT support but will peg development at an = interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC = will look like in 20 years. Roland's answer only applies to the next 5 = to 10 years.=20 =20 That would be disappointing - not least because full ECRIT = compliance would ultimately decrease the overhead associated with = emergency service support for operators as well as providing a more = universal service. =09 [[LLi]] This may be true for "green field" ISPs and VSPs but not for = incumbent carriers with existing infrastructure. And universal service = is not a requirement for us. Neither the German regulator requires it = nor is it a busines case. =20 =20 Nevertheless, I don't think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP = should be more flexible: =20 * Allow additional location identifiers =20 * Allow AN operated LOST=20 * Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives. =20 * Allow and describe also network-centric, not only ED-centric = architectures. If I remember correctly, John Medland from BT also = recomended to use a more network- centric architecture, at least for the = next years.=20 =20 I think it just means that the German regulator and technical = advisory committees would point out the subset aspects of compliance = that would be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP = contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard = body is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with = very valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a = business case will not help the draft in the end, also if it becomes a = BCP. It would make sense to make it more flexible so people are willing = to adopt it. =20 =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis - as has = been done in the UK and Canada. Of course, it's generally recognized as = only an interim step, even in those jurisdictions. Other comments below. =20 Cheers, Martin =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling = based on location-by-reference and ED's IP-address.=20 [[MCD]] I think you might mean "identity extensions" rather than = location-by-reference because LbyR still requires the ED to obtain the = reference - e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD = but SOAP over HTTP, but anyway similar). The LIS responds with a numeric = string associated to the caller location, in principle a LbyR and with = the PSAP number. The proxy inserts the LbyR into the SIP-message (as = P-Asserted-ID because the PSAPs are in PSTN) and routes the message to = the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being realistic, = at least in Germany, some are not realistic at all. Implementing these = requirements cost a carrier a lot of money and there is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and = location databases. Routing of emergency calls is currently done in = Germany based on phone area code not on geo or civic location, at least = for the fixed network. For mobile networks the cell-id is used in = common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US = has lots (6000 plus) and Australia has two (and they are redundant so it = doesn't matter which one). Presumably geographic information, for PSAP = catchment areas, is the basis for determining which area codes are = relevant to begin with? After all, an area code is not intrinsically = geographic; it's a network routing value. If so, then some geographic = discriminator is already in play in terms of constructing the area code = based routing data (something like zip codes perhaps?) - and in that = case, it should be straightforward to by-pass the area code step in the = construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the = carriers, the regulator and the PSAPs operators (police, the Red Cross) = agreed to do so. This may change in the future, but it will take a quite = long time. =20 With nomadic VoIP devices (and it's no good being in denial about = this being the norm in the future) area code is no more reliable than it = is for conventional mobile phones. And, presumably, area code is not = used for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the = area code, and have a different table than the fixed network operators. = They are not going to change this. As to the nomadic SIP-users...if we = like it or not, very few of our customers use our SIP service nomadic, = let alone call EC from their laptop. =20 1 LOST as a national, let alone as a global directory is = not going to be implemented. The regulator will provide in the web a = static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its = own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement = something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would = still be able to determine a route to the correct PSAP. Alternatively, = as long as the regulator is maintaining a web service with the routing = information, why not make that directly accessible using LoST and save = the operators the cost of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page = with a table which operator can print and implement in their darabases = and operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you = know. The regulator will not do this. =09 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The = emergency network can (automatically and before human resources are = engaged) assess the source of the reference, and the validity of the = location by dereference, without having to trust location provided = directly from the ED. There are more sophisticated approaches to = trustability even using LbyV - based on digital signatures across = appropriate attributes. This WG and Geopriv haven't really got to grips = with that... yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is = needed if EC must work for private and enterprise networks and VPNs. We = have no such regulatory requirements. And we don't know of any verdor = of DSL-EDs which provides today SIP with LbyR and is as cheap as the = devices without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. = =20 1 There are already a lot of existing EDs in usage which don't = send location. =20 [[MCD]] Quite right. ECRIT doesn't overly concern itself with that = interim situation. The UK and Canadian definitions for an interim = solution (limiting service to in-country VoIP proxy operators) both = assume third-party query via identity-extension to allow the proxy or = the VPC to make the query to the LIS. This isn't extensible to universal = emergency service access by all visiting devices but it does put the = necessary LIS functionality in place as a very good starting point. It = would be a pity if Germany were to cease the evolution there as it would = not fulfil the real promise of the Internet and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim = solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination = infrastructure in place for the purposes of dispatch is done - and then = the next, simpler step, of using that to support the routing procedure = isn't taken... that would be a waste. =09 [[LLi]] Do you think this is an argument for a product manager? They = need a business case. =20 =20 =20 We don't intend to require our ED-vendors to provide location = because it is useless to us. =20 We could agree with the document with following changes:=20 * Other location identifiers then geo or civil are allowed. It must = be possibe that the data foermat is flexible due to different = requirements from regulators over the whole world. (e.G Germany area = codes for fixed- and Cell-Id for moile- providers)=20 * The MUST for the end devices to support location information, DHCP = location options and HELD shall be removed=20 * It must be possible for the VoIP-provider's proxy to use a LOST = (or an ESRP) provided by the AN or by other local provider on behalf of = the AN. =20 =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. = Currently, neither the IETF- nor the 3GPP-architecture for emergency = calling covers our real needs for the next 2 to 5 years and in the end = everybody still has its own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] =20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] =20 ------_=_NextPart_001_01CA176D.982DDA32 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP
    Hi Brian,
     
    Please see comments inline. =  
     

    From: Brian Rosen = [mailto:br@brianrosen.net]=20
    Sent: Friday, August 07, 2009 3:05 PM
    To: Liess, = Laura;=20 Martin.Dawson@andrew.com; Jesske, Roland; ecrit@ietf.org
    Cc: = Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

    Actually,=20 the PIDF-LO is designed to cater for all the variations in = addressing. =20 You don=92t mean =93location used for emergency calls=94, you mean = =93key for location=20 used for emergency calls=94.  The area code is not the location, = it is a=20 key that is mapped to PSAP URI. 
    [[LLi]]  This is=20 correct.

     

      The telephone number (with = its area=20 code) is the identifier you would use with HELD to get the=20 location,  from which LoST would get you = a PSAP=20 URI.
    [[LLi]] Here we don't use the = phone number. The=20 proxy sends the IP-address to the LIS. The LIS finds out = the access=20 hardware (DSLAM port)  corresponding to the IP-address and = assigns a=20 temporary string to it (kind of LbyR). It also finds out the = phone area=20 code for this hardware. With the phone area code, the LIS queries = a table=20 which contains the phone area codes and the corresponding PSAP = URI, =20 then delivers the the string (LbyR) and the PSAP-URI to the SIP=20 proxy. The SIP proxy routes the call and sends the LbyR to the = PSAP. In=20 very few cases, PSAPs dereference  the the LyBR to a civic = address.=20

    We do not have=20 any kind of geo data or poligons in our database. In principle we = have=20 the the civic address, but the access to this data is quite=20 slow.  I think other fixed networks carriers here = have more or=20 less the same. 

     

    This=20 seems trivial for you to implement: you deploy a HELD server that = takes=20 telephone number and returns a polygon representing the area code = boundary,=20 and you deploy a LoST server that takes that polygon and returns the = PSAP URI=20 associated with it.   

      This would be no more = expensive than=20 what you are proposing.  Proxies could use this or phonebcp = compatible=20 endpoints could use it. 

     

    NENA=20 is planning on doing pretty much this same thing to handle legacy = wireline=20 networks where telephone number is currently the key to the location = database=20 (ALI).  The LIS will store location as the key (using = held-identity), and=20 a gateway will construct an LbyR from the phone number.  All the = rest of=20 the ecrit compatible infrastructure can then use the Location URI to = get=20 location, route, etc.

     

    Making=20 what you now see as a one step mapping (area code to PSAP URI) into a = two step=20 (telephone number to polygon, polygon to PSAP URI) is a bit more = complex, but=20 not any significant difference in deployment.  It also works for = wireless=20 (cell sector/ID to polygon, polygon to PSAP URI), and of course, would = be=20 upwardly compatible with real location based routing, should your = systems=20 evolve as we expect they evolve, or something like EU regulations = compel more=20 accurate location services.

    [[LLi]] Nobody here is willing to putting geodata or=20 poligons into the access databases.  And = we could=20 avoid doing this just by allowing the LIS to query the local LOST with = the=20 LbyR and to deliver the PSAP URI to the SIP=20 proxy.  

     

    Kind=20 regards

    Laura

     

    Brian

     

    From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = L.Liess@telekom.de
    Sent: Friday, August 07, 2009 7:59=20 AM
    To: Martin.Dawson@andrew.com; R.Jesske@telekom.de;=20 ecrit@ietf.org
    Cc: = Reinhard.Lauster@t-mobile.at
    Subject:=20 Re: [Ecrit] HUM on PhoneBCP

     

     

    Hi=20 Martin,  

    Hi=20 Laura,

     

    I=20 regard it as a goal of ECRIT =96 as derived from the goals of the = IETF=20 generally =96 to define a structure that will allow an Internet = capable device=20 to connect to a network anywhere in the world and be able to make = emergency=20 calls. Just as FTP, email protocols, SIP and etc. all work = regardless of=20 which network the devices attach to. I don=92t understand how the = kind of=20 variations that you are requesting be added to the specification = will allow=20 that to occur.

    [[LLi]] = This is fine and=20 usefull. Just that every country uses today different formats for = the=20 location used for emergency calls. Changing this will take time and = costs=20 money.

    What is = the harm in=20 allowing ECs to work with local location formats which are = understood only=20 by the LIS and the PSAP ?. I dont see why a common location = format must=20 be implemented by everybody.

    Maybe the EC could work like = this :

    • The proxy=20 discovers the LIS based on EDs IP-address using reverse-DNS and = SRV record=20 (this is possible with "identity extenssions")=20
    • It=20 retrieves the location ( e.g. using HELD) in a local format = understood=20 only by the LIS and the PSAP, which are in the same country. The = location=20 is just a string which is passed transparently through the network = to the=20 PSAP. In my opinion, it would be in principle  posible = to use=20 LbyR to transport local location identidfiers, e.=20 g.  area-code@lis.telekom.de , but this is = currently my=20 personal opinion, I didn' found any statemant or example in = the=20 drafts.   =20
    • The=20 LIS delivers, together with the LbyR above, the PSAP URI.  As = far as=20 I know there is currently no way to do this in HELD (or did I = miss=20 = something?).        
       =20

    It=20 would be an alternative which is interoperable and quite easy = to=20 implement, without the need for the operators to change their = location=20 databases. I think by allowing this scenario, interoperable EC = could be=20 achieved earlier. And this does not exclude the scenario = described in=20 the framework and phone-bcp, where the EDs retrieve deo or = civic=20 location, which is needed for EC to work in = private/enterprise=20 networks.  
      

        

     

    The=20 position appears to be that the German regulator doesn=92t require = anything =96=20 and the operators will not be proactive in following a specification = if it=20 doesn=92t include what already exists. In that context, I don=92t = understand why=20 there is a need for the BCP at all. There may be no need to endorse = it but,=20 similarly, there should be no need to object to it =96 since the = operators=20 will only put in place their preferred version of the service in any = case.=20
    [[LLi]] =20 This is not quite true. We have to ensure that EC works for = different AN-=20 and VoIP-provider and for nomadic users in Germany by 2013. Our = current=20 solution does not allow this and there is the same for other=20 carriers. We definitively need to define in Germany=20 an architecture which fullfills this requirements. It would be = very=20 usefull if we can use standard protocols. But nobody will be = willing to=20 change everything at once.  Having a standard based = architecture which=20 is low cost would be a great advantage.

     

    Kind=20 regards

    Laura     

     

     That=92s=20 OK=85 insofar as it just means German networks aren=92t ECRIT = compatible =96=20 =93compatibility=94 isn=92t a worthy goal in and of itself; it has = to actually=20 mean any device can work anywhere.

     

    Cheers,

    Martin

     

    From:=20 L.Liess@telekom.de [mailto:L.Liess@telekom.de]
    Sent: = Friday, 7=20 August 2009 12:29 AM
    To: Dawson, Martin; = R.Jesske@telekom.de;=20 ecrit@ietf.org
    Cc: = Reinhard.Lauster@t-mobile.at
    Subject:=20 RE: [Ecrit] HUM on PhoneBCP

     

    Hi=20 Martin,

     

    See=20 comments inline [[LLi]].

     

     

    Laura

    From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of=20 Dawson, Martin
    Sent: Wednesday, August 05, 2009 = 11:00=20 AM
    To: Jesske, Roland; ecrit@ietf.org
    Subject: = Re:=20 [Ecrit] HUM on PhoneBCP

    Hi=20 Roland,

     

    I=20 think what you=92re saying is that you don=92t think that Germany = will go on=20 to implement full ECRIT support but will peg development at an = interim=20 phase.
    [[LLi]]  We=20 don't know how the realtime application networks or EC will = look like=20 in 20 years. Roland's answer only applies to the = next 5 to=20 10 years. 

     

     That=20 would be disappointing =96 not least because full ECRIT compliance = would=20 ultimately decrease the overhead associated with emergency service = support=20 for operators as well as providing a more universal=20 service.

    [[LLi]] =20 This may be true for "green field" ISPs and VSPs but not for=20 incumbent carriers with existing infrastructure.  And = universal=20 service is not a requirement for us. Neither the German regulator=20 requires it nor is it a busines = case.   

     

    Nevertheless,=20 I don=92t think that decision invalidates the BCP; =
    [[LLi]] =20 We think it does, because some of the requirements are = not=20 flexible enough to cover the deployments within the next=20 years.  The BCP should be more = flexible:  

    • Allow=20 additional location identifiers =20
    • Allow=20 AN operated LOST=20
    • Provide a=20 way to enable LOST-query based on national or=20 domain-specific location identifier. One posiblility is=20 to allow the LIS to query the LOST , but = there are=20 also other alternatives. =20
    • Allow and describe=20 also network-centric, not only ED-centric = architectures. If=20 I  remember correctly, John Medland from BT also = recomended to=20 use a more network- centric architecture, at least for the next = years.=20

     

    I=20 think it just means that the German regulator and technical = advisory=20 committees would point out the subset aspects of compliance that = would be=20 applicable to that jurisdiction.  
    [[LLi]] =20 Again, the draft is not flexible enough for it.  If the = BCP=20 contains requirements which are not realistic, people will = just=20 discard the BCP and implement proprietary stuff. My = expectation=20 from a standard body is to define protocols and architecture = which=20 people are willing to implement in their network or products , not = only in=20 the lab.

     

    [[LLi]] =20

    We=20 are not against the draft in principle. ECRIT provides =20 us with very valuable specifications as LbyR, HELD, identity=20 extensions. But targeting an architecture which requires = everbody to invest without a business case will not = help=20 the draft in the end, also if it becomes a BCP.  It = would=20 make sense to make it more flexible so people are willing to = adopt=20 it.    

     

     Actually,=20 based on your description below, the NENA i2 architecture would = probably=20 be a more straightforward baseline for analysis =96 as has been = done in the=20 UK and Canada. Of course, it=92s generally recognized as only an = interim=20 step, even in those jurisdictions.

    Other=20 comments below.

     

    Cheers,

    Martin

     

    From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of=20 R.Jesske@telekom.de
    Sent: Wednesday, 5 August 2009 = 6:19=20 PM
    To: ecrit@ietf.org
    Subject: Re: [Ecrit] HUM = on=20 PhoneBCP

     

     

    Dear all,=20
    We would like = the=20 document to become a BCP as soon as possible so the group can move = on with=20 other documents related to emergency calling based on=20 location-by-reference and ED=92s IP-address.

    [[MCD]]=20 I think you might mean =93identity extensions=94 rather than=20 location-by-reference because LbyR still requires the ED to obtain = the=20 reference =96 e.g. by HELD.
    [[LLi]] We=20 use both, the IP-address as UE identity and LbyR. The SIP-proxy = uses the=20 IP-address to query the LIS using HTTP (it's not HELD = but SOAP over=20 HTTP, but anyway similar). The LIS responds with a numeric = string=20 associated to the caller location, in principle a LbyR and with = the=20 PSAP number. The proxy inserts the LbyR into the=20 SIP-message (as P-Asserted-ID because the PSAPs are in PSTN) and = routes=20 the message to the PSAP.  It's a low cost=20 solution. 

    But we can not HUM = for the=20 current form of the document.

    Back to the document: = Some=20 requirements are far form being realistic, at least in Germany, = some are=20 not realistic at all. Implementing these requirements cost a = carrier a lot=20 of money and there is no ROI for it.

    Just a few examples: =

    =B7       Requiring either geo or = civic=20 location does not provide carriers with enough flexibility to = reuse their=20 existing mechanisms and location databases. Routing of emergency = calls is=20 currently done in Germany based on phone area code not on geo or = civic=20 location, at least for the fixed network. For mobile networks the = cell-id=20 is used in common. This is regulated by the german regulator.=20

    [[MCD]]=20 How many unique PSAP routes are required in Germany? The US has = lots (6000=20 plus) and Australia has two (and they are redundant so it = doesn=92t matter=20 which one). Presumably geographic information, for PSAP catchment = areas,=20 is the basis for determining which area codes are relevant to = begin with?=20 After all, an area code is not intrinsically geographic; it=92s a = network=20 routing value. If so, then some geographic discriminator is = already in=20 play in terms of constructing the area code based routing data = (something=20 like zip codes perhaps?) =96 and in that case, it should be = straightforward=20 to by-pass the area code step in the construction of routing that = goes the=20 correct PSAP URI.
    [[LLi]] Currently, fixed=20 networks carriers in Germany route the ECs based only on = the=20 caller's area code. Sometime in the past, the carriers, = the=20 regulator and the PSAPs operators (police, the Red Cross) agreed = to do=20 so. This may change in the future, but it will take a quite = long=20 time.      

     With=20 nomadic VoIP devices (and it=92s no good being in denial about = this being=20 the norm in the future) area code is no more reliable than it is = for=20 conventional mobile phones. And, presumably, area code is not used = for=20 conventional cellular emergency call=20 routing?
    [[LLi]] =20 As far as I know, mobile networks use the Cell-ID, not the area = code, and=20 have a different table than the fixed network operators. They = are not=20 going to change this.  As to the nomadic SIP-users...if we = like it or=20 not, very few of our customers use our SIP = service=20 nomadic, let alone call EC from their=20 = laptop.        =  

    1           =   =20 LOST as a = national, let alone=20 as a global directory is not going to be implemented. The = regulator will=20 provide in the web a static table which contains the PSAPs and the = area=20 for which they are responsible (one or more area codes). Every = carrier has=20 to implement its own routing database for emergency calls. =

    [[MCD]]=20 Whatever the carriers implement (and they have to implement = something)=20 could just as readily be done using LoST. Then visiting devices, = with no=20 association with any local VoIP proxy server would still be able = to=20 determine a route to the correct PSAP. Alternatively, as long as = the=20 regulator is maintaining a web service with the routing = information, why=20 not make that directly accessible using LoST and save the = operators the=20 cost of duplicating the service at = all?
    [[LLi]] =20 There is a big difference between maintaining a web page with=20 a table which operator can print and implement in their = darabases=20 and operating a database which is queried for = every emergency=20 call in Germany, must have an availablity of=20 99,99...% ,  is secure enough...you know. The=20 regulator will not do this.


    2       = We have=20 no intention to rely on end devices for location information = because:=20
    =B7       ED provided location = info is not=20 trusted

    [[MCD]]=20 Location by reference mitigates this trust issue. The emergency = network=20 can (automatically and before human resources are engaged) assess = the=20 source of the reference, and the validity of the location by = dereference,=20 without having to trust location provided directly from the ED. = There are=20 more sophisticated approaches to trustability even using LbyV =96 = based on=20 digital signatures across appropriate attributes. This WG and = Geopriv=20 haven=92t really got to grips with that=85 = yet.
    [[LLi]]  We=20 build the SIP-network and EC now. ED-provided location is=20 needed if EC must work for private and enterprise = networks=20 and VPNs.  We have no such regulatory = requirements.  And we=20 don't know of any verdor of DSL-EDs which provides = today=20 SIP with LbyR and is as cheap as the devices without it. = If you=20 do, please let me know. 

    The=20 regulator ask us to guarantee that EC works. What if a = customer=20 dials 112 and his end device does not send = the location? So=20 I have to implement both solutions, with and without ED provided = location,=20 anyway.  
    1      =20 There are already a lot of existing EDs in usage which don=92t = send=20 location.   

    [[MCD]]=20 Quite right. ECRIT doesn=92t overly concern itself with that = interim=20 situation. The UK and Canadian definitions for an interim solution = (limiting service to in-country VoIP proxy operators) both assume=20 third-party query via identity-extension to allow the proxy or the = VPC to=20 make the query to the LIS. This isn=92t extensible to universal = emergency=20 service access by all visiting devices but it does put the = necessary LIS=20 functionality in place as a very good starting = point.  It would=20 be a pity if Germany were to cease the evolution there as it would = not=20 fulfil the real promise of the Internet and the ECRIT model.=20
    [[LLi]] =20 I wonder who will drive and pay for upgrading the = interim=20 solutions.  Unfortunatelly, it's all about=20 money...

     Think=20 about it; all the complexity of putting location determination=20 infrastructure in place for the purposes of dispatch is done =96 = and then=20 the next, simpler step, of using that to support the routing = procedure=20 isn=92t taken=85 that would be a = waste.

    [[LLi]] =20 Do you think this is an argument for a product manager? = They need a=20 business case. 

     

     

     =20 We don=92t intend to require our ED-vendors to provide location = because it=20 is useless to us.  

    We could agree with = the document=20 with following changes:

      • Other location identifiers = then geo or=20 civil are allowed. It must be possibe that the data foermat is = flexible due to different requirements from regulators over = the whole=20 world. (e.G Germany area codes for fixed- and Cell-Id for = moile-=20 providers)
      • The MUST for the end = devices to=20 support location information, DHCP location options and HELD = shall be=20 removed
      • It must be possible for = the=20 VoIP-provider=92s proxy to use a LOST (or an ESRP) provided by = the AN or=20 by other local provider on behalf of the AN.  =

     

     There is no = value in=20 Hum-ing documents which one is not going to implement and does not = fit=20 into regulated schemes like in Germany. Currently, neither the = IETF- nor=20 the 3GPP-architecture for emergency calling covers our real needs = for the=20 next 2 to 5 years and in the end everybody still has its own = proprietary=20 implementation.   

    Best = regards

    Roland=20

     

    Deutsche=20 Telekom Netzproduktion GmbH
    Zentrum Technik = Einf=FChrung
    Roland=20 Jesske
    Gateways,=20 Protokolle, Konvergenz, TE32-1
    Heinrich-Hertz-Str.=20 3-7, 64295 Darmstadt,
    Postfach, 64307=20 Darmstadt (Postanschrift)
    +496151 628=20 2766 (Tel)
    +491718618445=20 (Mobile)
    E-Mail:=20 r.jesske@telekom.de=20
    http://www.telekom.de=20

     

    Registerrechtliche=20 Unternehmensangaben:
    Deutsche=20 Telekom Netzproduktion (DT NP) GmbH
    Aufsichtsrat: Timotheus = H=F6ttges=20 (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno=20 Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus=20 Peren
    Handelsregister: Amtsgericht Bonn HRB 14190
    Sitz der=20 Gesellschaft: Bonn
    USt-IdNr.: DE 814645262    =20

     

     


    --------------------------------------------------------------= ----------------------------------
    This message is for&= nbsp;the designated recipient only and may
    co= ntain privileged, proprietary, or otherwise priv= ate information.  
    If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
    this email is proh= ibited.
    --------------------------------------------------------------= ----------------------------------
    [mf2]

     

     


    --------------------------------------------------------------= ----------------------------------
    This message is for&= nbsp;the designated recipient only and may
    co= ntain privileged, proprietary, or otherwise priv= ate information.  
    If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
    this email is proh= ibited.
    --------------------------------------------------------------= ----------------------------------
    [mf2]

     

    ------_=_NextPart_001_01CA176D.982DDA32-- From john@johnlange.ca Fri Aug 7 07:55:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D785B3A6910 for ; Fri, 7 Aug 2009 07:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBFr-N-6c1Cn for ; Fri, 7 Aug 2009 07:55:11 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 3AE873A6892 for ; Fri, 7 Aug 2009 07:55:11 -0700 (PDT) Received: (qmail 12267 invoked from network); 7 Aug 2009 09:55:13 -0500 Received: from unknown (HELO ?10.179.179.201?) (74.198.148.45) by lh02.epicnet.ca with SMTP; 7 Aug 2009 09:55:12 -0500 From: John Lange To: "Dawson, Martin" In-Reply-To: References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <1249584170.5335.24.camel@vandium.darkcore.net> <6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> <1249587517.5335.80.camel@vandium.darkcore.net> Content-Type: text/plain Date: Fri, 07 Aug 2009 09:53:55 -0500 Message-Id: <1249656835.5053.35.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: ecrit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 14:55:12 -0000 On Thu, 2009-08-06 at 18:16 -0500, Dawson, Martin wrote: > The "never will" parts seem a bit gratuitous. Personal preference > perhaps - but, as I say, I think it's a simple step to move from an > OBO-only LIS to an ECRIT-compliant LCP LIS. So the "never will" part > seems a rather dogmatic position. > > What happens when, in fact, devices start incorporating ECRIT clients as > a matter of course...? I think Canada is innovative; it's likely to want > to take advantage of that development and enable the benefit of > ubiquitous emergency services via all devices/access... I would have > thought. Ci2 has no allowance for SIP-location conveyance, period. You can deploy location aware devices all you want but they will just be treated as "dumb" voip endpoints in Ci2. There is nothing that allows devices to discover their own location and even if they did (say through local DHCP), that information it will be ignored. That is why I say "devices are not location aware and never will be"; because Ci2 has no method for them to find their location _and_ even if they have location it will be ignored. Also, "VSPs can not do and will never do sip-location-conveyance"; because, Ci2 does not have sip-location-conveyance. If a VSP were to send location to the ESGW, it would be ignored. So the use of "never" is accurate. Some future version of Ci2 (Ci2.5 ?) might allow these things but that is extremely unlikely given that the entire location discovery mechanism is on an ILEC private network. Under the proposed Ci2, the VSP has only one single ESGW. All the VSP does is hand the emergency call to the ILEC's ESGW and the ILEC does all the location discovery and call routing on a private network. People naturally confuse NENAi2 with Ci2 but they have almost nothing in common. Some ideas and terminology were borrowed from NENAi2 but it is otherwise a completely different animal. Fundamentally the difference is, NENAi2 "happens" on the internet. Ci2 "happens" on a private network accessible only to the ILEC(s). Ci2 will never evolve into ECRIT because the network architecture prevents it. -- John Lange http://www.johnlange.ca > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of John Lange > Sent: Friday, 7 August 2009 5:39 AM > To: Ted Hardie > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] HUM on PhoneBCP > > On Thu, 2009-08-06 at 12:23 -0700, Ted Hardie wrote: > > On Thu, Aug 6, 2009 at 11:42 AM, John Lange wrote: > > > > > Most importantly, Canadian i2 is not compatible with phone-bcp or > > > ecrit-framework nor would it be an interim stepping-stone to any > > > "next-gen" solution for many reasons but not the least of which is > the > > > fact that it does not allow location aware devices. > > > > > > > Can you unpack what "does not allow location aware devices" means? > > Do you mean that the location awareness in devices is not presumed, > > or that location from end stations are not trusted, or something else? > > There is no part of Ci2 which allows location to be obtained (v0) or > transmitted (v1) from endpoints. > > In NENAi2 terms, there is no v0 or v1 interface in Ci2. > > To answer your question, not only is "location awareness in devices ... > not presumed", it is presumed that: > > - devices are not location aware and never will be. > - and, VSPs can not do and will never do sip-location-conveyance. > > Regards, From mlinsner@cisco.com Fri Aug 7 08:32:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B535A28C1E8 for ; Fri, 7 Aug 2009 08:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.611, 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 pdhPz98wtQe7 for ; Fri, 7 Aug 2009 08:32:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E8E6828C1E4 for ; Fri, 7 Aug 2009 08:32:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFble0qrR7PE/2dsb2JhbAC3bIgrkCAFgjWBYYFR X-IronPort-AV: E=Sophos;i="4.43,342,1246838400"; d="scan'208";a="224988806" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 07 Aug 2009 15:32:32 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n77FWW4m029007; Fri, 7 Aug 2009 08:32:32 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n77FWVMm016554; Fri, 7 Aug 2009 15:32:32 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 11:32:29 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 11:32:28 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 07 Aug 2009 11:32:25 -0400 From: Marc Linsner To: John Lange Message-ID: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoXdEOGDDAQOgu29Eu9LueMEVAiJg== In-Reply-To: <1249656835.5053.35.camel@vandium.darkcore.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Aug 2009 15:32:29.0048 (UTC) FILETIME=[45EFF780:01CA1774] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2698; t=1249659152; x=1250523152; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20HUM=20on=20PhoneBCP |Sender:=20; bh=9WRWnJfRB/1s9yiRY5d/hH421UrXkc4oAk17YzXbtSA=; b=W6r3nMuNy0fQ/KvRBgstP1Te2p4SKRntEOSu3QnM7y/dHNfHRB5jyxLc23 BX1+yj5DfkS+XNgZfk60Pu/WrVptRvgnkUTrK32bKpDlV4FYcUo1CMZPvoOD WwRpfBBGOe; Authentication-Results: sj-dkim-4; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ecrit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 15:32:32 -0000 Hmm, the PSTN will be an awful expense venture when the only thing on it are PSAPs. In the US, PSAPs have shown an interest to keep up with the advances in their customer's modes of communication and take advantage of features afforded by the new technologies. So far, special interest hasn't been able to sway regulators into thinking this is a bad idea. Which is a good thing, IMO. -Marc- On 8/7/09 10:53 AM, "John Lange" wrote: > On Thu, 2009-08-06 at 18:16 -0500, Dawson, Martin wrote: >> The "never will" parts seem a bit gratuitous. Personal preference >> perhaps - but, as I say, I think it's a simple step to move from an >> OBO-only LIS to an ECRIT-compliant LCP LIS. So the "never will" part >> seems a rather dogmatic position. >> >> What happens when, in fact, devices start incorporating ECRIT clients as >> a matter of course...? I think Canada is innovative; it's likely to want >> to take advantage of that development and enable the benefit of >> ubiquitous emergency services via all devices/access... I would have >> thought. > > Ci2 has no allowance for SIP-location conveyance, period. You can deploy > location aware devices all you want but they will just be treated as > "dumb" voip endpoints in Ci2. There is nothing that allows devices to > discover their own location and even if they did (say through local > DHCP), that information it will be ignored. > > That is why I say "devices are not location aware and never will be"; > because Ci2 has no method for them to find their location _and_ even if > they have location it will be ignored. > > Also, "VSPs can not do and will never do sip-location-conveyance"; > because, Ci2 does not have sip-location-conveyance. If a VSP were to > send location to the ESGW, it would be ignored. > > So the use of "never" is accurate. Some future version of Ci2 (Ci2.5 ?) > might allow these things but that is extremely unlikely given that the > entire location discovery mechanism is on an ILEC private network. > > Under the proposed Ci2, the VSP has only one single ESGW. All the VSP > does is hand the emergency call to the ILEC's ESGW and the ILEC does all > the location discovery and call routing on a private network. > > People naturally confuse NENAi2 with Ci2 but they have almost nothing in > common. Some ideas and terminology were borrowed from NENAi2 but it is > otherwise a completely different animal. > > Fundamentally the difference is, NENAi2 "happens" on the internet. Ci2 > "happens" on a private network accessible only to the ILEC(s). Ci2 will > never evolve into ECRIT because the network architecture prevents it. From Martin.Dawson@andrew.com Fri Aug 7 08:40:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840C63A6F50 for ; Fri, 7 Aug 2009 08:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMRtZAiIfrnb for ; Fri, 7 Aug 2009 08:40:34 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 0A4C33A6F4A for ; Fri, 7 Aug 2009 08:40:33 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_07_11_03_19 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); Fri, 07 Aug 2009 11:03:19 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 10:40:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Aug 2009 10:40:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoXbxIfvdELuapgSkuTa1TNT7l1oAAAVFHA References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><1249584170.5335.24.camel@vandium.darkcore.net><6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com><1249587517.5335.80.camel@vandium.darkcore.net> <1249656835.5053.35.camel@vandium.darkcore.net> From: "Dawson, Martin" To: "John Lange" X-OriginalArrivalTime: 07 Aug 2009 15:40:37.0031 (UTC) FILETIME=[68CC4370:01CA1775] Cc: ecrit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 15:40:36 -0000 ECRIT still works if everything - the LIS, LoST, and the route to the PSAP = occur in the access network and via a VPN or direct physical IP trunk to th= e PSAP. The ESGW is a PSAP URI.=0D=0A=0D=0ASo - assuming ILECS (and ISPs an= d broadband wireless providers and municipal WiFi networks...) who are putt= ing in the location-determination infrastructure for Ci2 take the minimal s= tep of allowing end device access to that location service, then the step t= o ECRIT can be made.=0D=0A=0D=0AI'm saying that the investment in dynamic l= ocation determination capabilities in the network is the most significant s= tep an operator needs to make toward ECRIT capability. So any architecture = that does this does represent a significant step toward ECRIT... whether th= at's the intention or not.=0D=0A=0D=0A> So the use of "never" is accurate. = Some future version of Ci2 (Ci2.5 =3F)=0D=0A> might allow these things but = that is extremely unlikely given that the=0D=0A> entire location discovery = mechanism is on an ILEC private network.=0D=0A=0D=0AI think that pretty muc= h establishes that the extent of our disagreement is only a matter of degre= e. Never doesn't have to mean never; it boils down to what one thinks most = likely. I'm happy to say that I think that Canada will support a more compr= ehensive access to emergency calling than Ci2 offers at the outset.=0D=0A=0D= =0AOn a side-note, there's a common view that emergency calling is all abou= t VoIP services - and I think this view only arises because people tend to = "talk" to PSAPs. The service that LECs provided subscribers in POTS days wa= s the ability to establish a circuit from their point of subscription to an= y other address (aka phone number) on the global PSTN. The most common use = people made of that circuit was to talk to each other... but voice is just = an application of the service and not the service itself; the circuits also= got used for sending fax, monitoring security systems, and even point to p= oint IP data. That is, LECs don't have some sort of natural right or owners= hip of the voice application.=0D=0A=0D=0ANow we're in ISP times; the fundam= ental service the "LECs" provide their subscribers is the ability to send a= n IP packet to any other point (aka IP address) on the global Internet. In = POTS days, calling emergency services got the subscriber a circuit to the P= SAP. In Internet times, calling emergency services means getting an IP pack= et session established with the PSAP (SIP with the option of audio or text= media as a starting point having emerged as the dominant assumption). Lett= ing the users of the end devices do this should not be predicated on them h= aving to have a VoIP service on that network, in that country, or at all fo= r that matter. As with voice in a PSTN context, VoIP is an application (jus= t an Internet presence service actually). I liken the insistence on the use= of a VoIP provider to make emergency calls in the Internet era to insistin= g on the use of long distance providers to make emergency calls in the POTS= era.=0D=0A=0D=0ACheers,=0D=0AMartin=20=0D=0A=0D=0A=0D=0A-----Original Mess= age-----=0D=0AFrom: John Lange [mailto:john@johnlange.ca]=0D=0ASent: Sat 8/= 8/2009 12:53 AM=0D=0ATo: Dawson, Martin=0D=0ACc: ecrit=0D=0ASubject: RE: [E= crit] HUM on PhoneBCP=0D=0A=20=0D=0AOn Thu, 2009-08-06 at 18:16 -0500, Daws= on, Martin wrote:=0D=0A> The "never will" parts seem a bit gratuitous. Pers= onal preference=0D=0A> perhaps - but, as I say, I think it's a simple step = to move from an=0D=0A> OBO-only LIS to an ECRIT-compliant LCP LIS. So the "= never will" part=0D=0A> seems a rather dogmatic position.=0D=0A>=20=0D=0A> = What happens when, in fact, devices start incorporating ECRIT clients as=0D= =0A> a matter of course...=3F I think Canada is innovative; it's likely to = want=0D=0A> to take advantage of that development and enable the benefit of=0D= =0A> ubiquitous emergency services via all devices/access... I would have=0D= =0A> thought.=0D=0A=0D=0ACi2 has no allowance for SIP-location conveyance, = period. You can deploy=0D=0Alocation aware devices all you want but they wi= ll just be treated as=0D=0A"dumb" voip endpoints in Ci2. There is nothing t= hat allows devices to=0D=0Adiscover their own location and even if they did= (say through local=0D=0ADHCP), that information it will be ignored.=0D=0A=0D= =0AThat is why I say "devices are not location aware and never will be";=0D= =0Abecause Ci2 has no method for them to find their location _and_ even if=0D= =0Athey have location it will be ignored.=0D=0A=0D=0AAlso, "VSPs can not do= and will never do sip-location-conveyance";=0D=0Abecause, Ci2 does not hav= e sip-location-conveyance. If a VSP were to=0D=0Asend location to the ESGW,= it would be ignored.=0D=0A=0D=0ASo the use of "never" is accurate. Some fu= ture version of Ci2 (Ci2.5 =3F)=0D=0Amight allow these things but that is e= xtremely unlikely given that the=0D=0Aentire location discovery mechanism i= s on an ILEC private network.=0D=0A=0D=0AUnder the proposed Ci2, the VSP ha= s only one single ESGW. All the VSP=0D=0Adoes is hand the emergency call to= the ILEC's ESGW and the ILEC does all=0D=0Athe location discovery and call= routing on a private network.=0D=0A=0D=0APeople naturally confuse NENAi2 w= ith Ci2 but they have almost nothing in=0D=0Acommon. Some ideas and termino= logy were borrowed from NENAi2 but it is=0D=0Aotherwise a completely differ= ent animal.=0D=0A=0D=0AFundamentally the difference is, NENAi2 "happens" on= the internet. Ci2=0D=0A"happens" on a private network accessible only to t= he ILEC(s). Ci2 will=0D=0Anever evolve into ECRIT because the network archi= tecture prevents it.=0D=0A=0D=0A--=20=0D=0AJohn Lange=0D=0Ahttp://www.johnl= ange.ca=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0A> Of John Lan= ge=0D=0A> Sent: Friday, 7 August 2009 5:39 AM=0D=0A> To: Ted Hardie=0D=0A> = Cc: ecrit@ietf.org=0D=0A> Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A>=20=0D= =0A> On Thu, 2009-08-06 at 12:23 -0700, Ted Hardie wrote:=0D=0A> > On Thu, = Aug 6, 2009 at 11:42 AM, John Lange wrote:=0D=0A> >=20=0D= =0A> > > Most importantly, Canadian i2 is not compatible with phone-bcp or=0D= =0A> > > ecrit-framework nor would it be an interim stepping-stone to any=0D= =0A> > > "next-gen" solution for many reasons but not the least of which is=0D= =0A> the=0D=0A> > > fact that it does not allow location aware devices.=0D=0A= > > >=0D=0A> >=20=0D=0A> > Can you unpack what "does not allow location awa= re devices" means=3F=0D=0A> > Do you mean that the location awareness in de= vices is not presumed,=0D=0A> > or that location from end stations are not = trusted, or something else=3F=0D=0A>=20=0D=0A> There is no part of Ci2 whic= h allows location to be obtained (v0) or=0D=0A> transmitted (v1) from endpo= ints.=0D=0A>=20=0D=0A> In NENAi2 terms, there is no v0 or v1 interface in C= i2.=0D=0A>=20=0D=0A> To answer your question, not only is "location awarene= ss in devices ...=0D=0A> not presumed", it is presumed that:=0D=0A>=20=0D=0A= > - devices are not location aware and never will be.=0D=0A> - and, VSPs ca= n not do and will never do sip-location-conveyance.=0D=0A>=20=0D=0A> Regard= s,=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A-------------------------------------------= -----------------------------------------------------=0D=0AThis message is = for the designated recipient only and may=0D=0Acontain privileged, propriet= ary, or otherwise private information. =20=0D=0AIf you have received it in = error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A---------------= ---------------------------------------------------------------------------= ------=0D=0A[mf2]=0D=0A From br@brianrosen.net Fri Aug 7 08:46:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265EB3A699E for ; Fri, 7 Aug 2009 08:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1EoxJbjvCDZ for ; Fri, 7 Aug 2009 08:45:39 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5E05B3A6DCB for ; Fri, 7 Aug 2009 08:45:39 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MZRdH-0005q5-F6; Fri, 07 Aug 2009 10:45:30 -0500 From: "Brian Rosen" To: , , , References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <042001ca175f$a92e0d60$fb8a2820$@net> <40FB0FFB97588246A1BEFB05759DC8A00348055D@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A00348055D@S4DE9JSAANI.ost.t-com.de> Date: Fri, 7 Aug 2009 11:45:31 -0400 Message-ID: <046201ca1776$1a2bfa70$4e83ef50$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0463_01CA1754.931A5A70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rAAA0M6gAACNUgwAAM0rIA= 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: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 15:46:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0463_01CA1754.931A5A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Laura =20 I don=92t think we=92re going to get to the point where the IETF rolls = back =96framework and =96phonebcp far enough to suit you. The approach that = Hannes described, which is to finish the current work as is, and then go back = and see if we can standardize a way for VoIP services to connect to older systems with more limited capabilities using OBO and other tricks, makes some sense to me. =20 =20 However, device vendors have to build devices that work in countries = that are more aggressively upgrading their emergency systems, without unduly burdening you. What I=92m attempting to do is to figure out a way that = you can work with a =96phonebcp compliant device, without incurring a lot of = cost. =20 We=92re not going to make it zero. =20 If you don=92t like a poly, return any street address in the area code. = In most cases, it could be a PIDF with a couple of A levels that works for = the town. =20 All that matters is that if a =96phonebcp client queries an LCP, it = should get a location that, when passed to LoST, gets the right URI. If the = location is coarse, that is okay; it works. I=92d like you to deploy HELD and = LoST servers in your networks that return the right thing to the endpoint and = not just to the OBO proxy, but even if you don=92t, phonebcp compliant end = devices will =93work=94 in your network: their attempts to reach LIS and LoST = servers will fail, and they will send emergency calls without location and PSAP = URI, and your proxy can fill in the right stuff. =20 You don=92t need =96phonebcp compliant endpoints. Good for you. = However, vendors ought to make phonebcp compliant endpoints so that they work everywhere. =20 If you want less that that, then I=92m not sure IETF can oblige, since = we don=92t do nation specific solutions and some nations need the full = =96phonebcp spec. =20 One complication you should consider: devices need to know the local = dial string(s) for emergency calls. In the IETF architecture, LoST provides that. What were you planning on doing? =20 Brian =20 =20 From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, August 07, 2009 10:45 AM To: br@brianrosen.net; Martin.Dawson@andrew.com; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Brian, =20 Please see comments inline. =20 =20 =20 _____ =20 From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, August 07, 2009 3:05 PM To: Liess, Laura; Martin.Dawson@andrew.com; Jesske, Roland; = ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP Actually, the PIDF-LO is designed to cater for all the variations in addressing. You don=92t mean =93location used for emergency calls=94, = you mean =93key for location used for emergency calls=94. The area code is not = the location, it is a key that is mapped to PSAP URI.=20 [[LLi]] This is correct. =20 The telephone number (with its area code) is the identifier you would = use with HELD to get the location, from which LoST would get you a PSAP = URI. [[LLi]] Here we don't use the phone number. The proxy sends the = IP-address to the LIS. The LIS finds out the access hardware (DSLAM port) corresponding to the IP-address and assigns a temporary string to it = (kind of LbyR). It also finds out the phone area code for this hardware. With = the phone area code, the LIS queries a table which contains the phone area = codes and the corresponding PSAP URI, then delivers the the string (LbyR) and = the PSAP-URI to the SIP proxy. The SIP proxy routes the call and sends the = LbyR to the PSAP. In very few cases, PSAPs dereference the the LyBR to a = civic address.=20 We do not have any kind of geo data or poligons in our database. In principle we have the the civic address, but the access to this data is quite slow. I think other fixed networks carriers here have more or = less the same.=20 =20 This seems trivial for you to implement: you deploy a HELD server that = takes telephone number and returns a polygon representing the area code = boundary, and you deploy a LoST server that takes that polygon and returns the = PSAP URI associated with it. =20 This would be no more expensive than what you are proposing. Proxies could use this or phonebcp compatible endpoints could use it. =20 =20 NENA is planning on doing pretty much this same thing to handle legacy wireline networks where telephone number is currently the key to the location database (ALI). The LIS will store location as the key (using held-identity), and a gateway will construct an LbyR from the phone = number. All the rest of the ecrit compatible infrastructure can then use the Location URI to get location, route, etc. =20 Making what you now see as a one step mapping (area code to PSAP URI) = into a two step (telephone number to polygon, polygon to PSAP URI) is a bit = more complex, but not any significant difference in deployment. It also = works for wireless (cell sector/ID to polygon, polygon to PSAP URI), and of course, would be upwardly compatible with real location based routing, should your systems evolve as we expect they evolve, or something like = EU regulations compel more accurate location services. [[LLi]] Nobody here is willing to putting geodata or poligons into the access databases. And we could avoid doing this just by allowing the = LIS to query the local LOST with the LbyR and to deliver the PSAP URI to the = SIP proxy. =20 =20 Kind regards Laura =20 Brian =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of L.Liess@telekom.de Sent: Friday, August 07, 2009 7:59 AM To: Martin.Dawson@andrew.com; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Hi Martin, =20 Hi Laura, =20 I regard it as a goal of ECRIT =96 as derived from the goals of the IETF generally =96 to define a structure that will allow an Internet capable = device to connect to a network anywhere in the world and be able to make = emergency calls. Just as FTP, email protocols, SIP and etc. all work regardless of which network the devices attach to. I don=92t understand how the kind = of variations that you are requesting be added to the specification will = allow that to occur. [[LLi]] This is fine and usefull. Just that every country uses today different formats for the location used for emergency calls. Changing = this will take time and costs money.=20 What is the harm in allowing ECs to work with local location formats = which are understood only by the LIS and the PSAP ?. I dont see why a common location format must be implemented by everybody.=20 Maybe the EC could work like this :=20 =B7 The proxy discovers the LIS based on EDs IP-address using reverse-DNS and SRV record (this is possible with "identity = extenssions")=20 =B7 It retrieves the location ( e.g. using HELD) in a local = format understood only by the LIS and the PSAP, which are in the same country. = The location is just a string which is passed transparently through the = network to the PSAP. In my opinion, it would be in principle posible to use = LbyR to transport local location identidfiers, e. g. area-code@lis.telekom.de , = but this is currently my personal opinion, I didn' found any statemant or example in the drafts. =20 =B7 The LIS delivers, together with the LbyR above, the PSAP = URI. As far as I know there is currently no way to do this in HELD (or did I = miss something?). =20 =20 It would be an alternative which is interoperable and quite easy to implement, without the need for the operators to change their location databases. I think by allowing this scenario, interoperable EC could be achieved earlier. And this does not exclude the scenario described in = the framework and phone-bcp, where the EDs retrieve deo or civic location, = which is needed for EC to work in private/enterprise networks. =20 =20 =20 =20 The position appears to be that the German regulator doesn=92t require anything =96 and the operators will not be proactive in following a specification if it doesn=92t include what already exists. In that = context, I don=92t understand why there is a need for the BCP at all. There may be = no need to endorse it but, similarly, there should be no need to object to = it =96 since the operators will only put in place their preferred version of = the service in any case.=20 [[LLi]] This is not quite true. We have to ensure that EC works for different AN- and VoIP-provider and for nomadic users in Germany by = 2013. Our current solution does not allow this and there is the same for other carriers. We definitively need to define in Germany an architecture = which fullfills this requirements. It would be very usefull if we can use = standard protocols. But nobody will be willing to change everything at once. = Having a standard based architecture which is low cost would be a great = advantage.=20 =20 Kind regards Laura =20 =20 That=92s OK=85 insofar as it just means German networks aren=92t ECRIT = compatible =96 =93compatibility=94 isn=92t a worthy goal in and of itself; it has = to actually mean any device can work anywhere. =20 Cheers, Martin =20 _____ =20 From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, =20 I think what you=92re saying is that you don=92t think that Germany will = go on to implement full ECRIT support but will peg development at an interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC will = look like in 20 years. Roland's answer only applies to the next 5 to 10 = years.=20 =20 That would be disappointing =96 not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service. [[LLi]] This may be true for "green field" ISPs and VSPs but not for incumbent carriers with existing infrastructure. And universal service = is not a requirement for us. Neither the German regulator requires it nor = is it a busines case. =20 =20 Nevertheless, I don=92t think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP should = be more flexible: =20 =B7 Allow additional location identifiers =20 =B7 Allow AN operated LOST=20 =B7 Provide a way to enable LOST-query based on national or domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives. =20 =B7 Allow and describe also network-centric, not only ED-centric architectures. If I remember correctly, John Medland from BT also recomended to use a more network- centric architecture, at least for the next years.=20 =20 I think it just means that the German regulator and technical advisory committees would point out the subset aspects of compliance that would = be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard body = is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with very valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a business case = will not help the draft in the end, also if it becomes a BCP. It would make sense to make it more flexible so people are willing to adopt it. =20 =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis =96 as has been = done in the UK and Canada. Of course, it=92s generally recognized as only an interim step, even in those jurisdictions. Other comments below. =20 Cheers, Martin =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so the = group can move on with other documents related to emergency calling based on location-by-reference and ED=92s IP-address.=20 [[MCD]] I think you might mean =93identity extensions=94 rather than location-by-reference because LbyR still requires the ED to obtain the reference =96 e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD but SOAP = over HTTP, but anyway similar). The LIS responds with a numeric string = associated to the caller location, in principle a LbyR and with the PSAP number. = The proxy inserts the LbyR into the SIP-message (as P-Asserted-ID because = the PSAPs are in PSTN) and routes the message to the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being realistic, at least in Germany, some are not realistic at all. Implementing these requirements cost a carrier a lot of money and there is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and location databases. Routing of emergency calls is currently done in Germany based = on phone area code not on geo or civic location, at least for the fixed network. For mobile networks the cell-id is used in common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US has = lots (6000 plus) and Australia has two (and they are redundant so it = doesn=92t matter which one). Presumably geographic information, for PSAP catchment areas, is the basis for determining which area codes are relevant to = begin with? After all, an area code is not intrinsically geographic; it=92s a network routing value. If so, then some geographic discriminator is = already in play in terms of constructing the area code based routing data = (something like zip codes perhaps?) =96 and in that case, it should be = straightforward to by-pass the area code step in the construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the carriers, the regulator and the PSAPs operators (police, the Red Cross) agreed to do = so. This may change in the future, but it will take a quite long time. =20 With nomadic VoIP devices (and it=92s no good being in denial about = this being the norm in the future) area code is no more reliable than it is = for conventional mobile phones. And, presumably, area code is not used for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the area code, and have a different table than the fixed network operators. They = are not going to change this. As to the nomadic SIP-users...if we like it = or not, very few of our customers use our SIP service nomadic, let alone = call EC from their laptop. =20 1 LOST as a national, let alone as a global directory is = not going to be implemented. The regulator will provide in the web a static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would still be able = to determine a route to the correct PSAP. Alternatively, as long as the regulator is maintaining a web service with the routing information, why = not make that directly accessible using LoST and save the operators the cost = of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page with a table which operator can print and implement in their darabases and operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you know. = The regulator will not do this. 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The emergency network can (automatically and before human resources are engaged) = assess the source of the reference, and the validity of the location by dereference, without having to trust location provided directly from the = ED. There are more sophisticated approaches to trustability even using LbyV = =96 based on digital signatures across appropriate attributes. This WG and Geopriv haven=92t really got to grips with that=85 yet. [[LLi]] We build the SIP-network and EC now. ED-provided location is = needed if EC must work for private and enterprise networks and VPNs. We have = no such regulatory requirements. And we don't know of any verdor of = DSL-EDs which provides today SIP with LbyR and is as cheap as the devices = without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. =20 1 There are already a lot of existing EDs in usage which don=92t = send location. =20 [[MCD]] Quite right. ECRIT doesn=92t overly concern itself with that = interim situation. The UK and Canadian definitions for an interim solution = (limiting service to in-country VoIP proxy operators) both assume third-party = query via identity-extension to allow the proxy or the VPC to make the query = to the LIS. This isn=92t extensible to universal emergency service access = by all visiting devices but it does put the necessary LIS functionality in = place as a very good starting point. It would be a pity if Germany were to cease = the evolution there as it would not fulfil the real promise of the Internet = and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location determination infrastructure in place for the purposes of dispatch is done =96 and = then the next, simpler step, of using that to support the routing procedure = isn=92t taken=85 that would be a waste. [[LLi]] Do you think this is an argument for a product manager? They = need a business case. =20 =20 =20 We don=92t intend to require our ED-vendors to provide location = because it is useless to us. =20 We could agree with the document with following changes:=20 o Other location identifiers then geo or civil are allowed. It must = be possibe that the data foermat is flexible due to different requirements = from regulators over the whole world. (e.G Germany area codes for fixed- and Cell-Id for moile- providers)=20 o The MUST for the end devices to support location information, DHCP location options and HELD shall be removed=20 o It must be possible for the VoIP-provider=92s proxy to use a LOST = (or an ESRP) provided by the AN or by other local provider on behalf of the AN. = =20 =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. Currently, = neither the IETF- nor the 3GPP-architecture for emergency calling covers our = real needs for the next 2 to 5 years and in the end everybody still has its = own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de=20 http://www.telekom.de=20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 =20 -------------------------------------------------------------------------= --- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= --- -------------------- [mf2] =20 =20 -------------------------------------------------------------------------= --- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= --- -------------------- [mf2] =20 ------=_NextPart_000_0463_01CA1754.931A5A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM on PhoneBCP

    Laura

     

    I don’t think we’re going to get to the point = where the IETF rolls back –framework and –phonebcp far enough to = suit you.=A0 The approach that Hannes described, which is to finish the = current work as is, and then go back and see if we can standardize a way for VoIP = services to connect to older systems with more limited capabilities using OBO and = other tricks, makes some sense to me.=A0

     

    However, device vendors have to build devices that work = in countries that are more aggressively upgrading their emergency systems, without = unduly burdening you.=A0 What I’m attempting to do is to figure out a way that you = can work with a –phonebcp compliant device, without incurring a lot of = cost.

     

    We’re not going to make it = zero.

     

    If you don’t like a poly, return any street address = in the area code.=A0 In most cases, it could be a PIDF with a couple of A = levels that works for the town.

     

    All that matters is that if a –phonebcp client = queries an LCP, it should get a location that, when passed to LoST, gets the right = URI.=A0 If the location is coarse, that is okay; it works.=A0 I’d like you = to deploy HELD and LoST servers in your networks that return the right = thing to the endpoint and not just to the OBO proxy, but even if you don’t, = phonebcp compliant end devices will “work” in your network: their = attempts to reach LIS and LoST servers will fail, and they will send emergency = calls without location and PSAP URI, and your proxy can fill in the right = stuff.

     

    You don’t need –phonebcp compliant = endpoints.=A0 Good for you.=A0 However, vendors ought to make phonebcp compliant endpoints = so that they work everywhere.

     

    If you want less that that, then I’m not sure IETF = can oblige, since we don’t do nation specific solutions and some nations need = the full –phonebcp spec.

     

    One complication you should consider: devices need to = know the local dial string(s) for emergency calls.=A0 In the IETF architecture, = LoST provides that.=A0 What were you planning on doing?

     

    Brian

     

     

    From:= = L.Liess@telekom.de [mailto:L.Liess@telekom.de]
    Sent: Friday, August 07, 2009 10:45 AM
    To: br@brianrosen.net; Martin.Dawson@andrew.com; = R.Jesske@telekom.de; ecrit@ietf.org
    Cc: Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on PhoneBCP

     

    Hi Brian,

     

    Please see comments inline.  

     

     

    From:= = Brian Rosen [mailto:br@brianrosen.net]
    Sent: Friday, August 07, 2009 3:05 PM
    To: Liess, Laura; Martin.Dawson@andrew.com; Jesske, Roland; ecrit@ietf.org
    Cc: Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on PhoneBCP

    Actually, = the PIDF-LO is designed to cater for all the variations in addressing.  = You don’t mean “location used for emergency calls”, you = mean “key for location used for emergency calls”.  The area = code is not the location, it is a key that is mapped to PSAP URI. 
    [[= LLi]]  This is correct.

     

      = The telephone number (with its area code) is the identifier you would use with HELD to = get the location,  from which LoST would get you a PSAP URI.
    [[= LLi]] Here we don't use the phone number. The proxy sends the IP-address to = the LIS. The LIS finds out the access hardware (DSLAM port)  corresponding = to the IP-address and assigns a temporary string to it (kind of LbyR). It also finds out the phone area code for this hardware. With the = phone area code, the LIS queries a table which contains the phone area codes and the corresponding PSAP URI,  then delivers the the string = (LbyR) and the PSAP-URI to the SIP proxy. The SIP proxy routes the call = and sends the LbyR to the PSAP. In very few cases, PSAPs dereference  the the = LyBR to a civic address.

    We do not = have any kind of geo data or poligons in our database. In principle we have = the the civic address, but the access to this data is quite = slow.  I think other fixed networks carriers here have more or less the = same. 

     

    This = seems trivial for you to implement: you deploy a HELD server that takes telephone = number and returns a polygon representing the area code boundary, and you deploy a = LoST server that takes that polygon and returns the PSAP URI associated with it.   

      = This would be no more expensive than what you are proposing.  Proxies could use = this or phonebcp compatible endpoints could use it. 

     

    NENA is = planning on doing pretty much this same thing to handle legacy wireline networks = where telephone number is currently the key to the location database = (ALI).  The LIS will store location as the key (using held-identity), and a gateway = will construct an LbyR from the phone number.  All the rest of the ecrit compatible infrastructure can then use the Location URI to get location, = route, etc.

     

    Making = what you now see as a one step mapping (area code to PSAP URI) into a two step = (telephone number to polygon, polygon to PSAP URI) is a bit more complex, but not = any significant difference in deployment.  It also works for wireless = (cell sector/ID to polygon, polygon to PSAP URI), and of course, would be = upwardly compatible with real location based routing, should your systems evolve = as we expect they evolve, or something like EU regulations compel more = accurate location services.

    [[LLi]] Nobody here is willing to putting geodata or poligons into the access databases.  And we could avoid doing this just by allowing the = LIS to query the local LOST with the LbyR and to deliver the PSAP URI to the = SIP proxy.  

     

    Kind = regards

    Laura

     

    Brian

     

    From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = L.Liess@telekom.de
    Sent: Friday, August 07, 2009 7:59 AM
    To: Martin.Dawson@andrew.com; R.Jesske@telekom.de; = ecrit@ietf.org
    Cc: Reinhard.Lauster@t-mobile.at
    Subject: Re: [Ecrit] HUM on PhoneBCP

     

     

    Hi Martin,  

    Hi Laura,

     

    I regard it as a goal of ECRIT – as derived from the goals of the = IETF generally – to define a structure that will allow an Internet = capable device to connect to a network anywhere in the world and be able to make emergency calls. Just as FTP, email protocols, SIP and etc. all work = regardless of which network the devices attach to. I don’t understand how the = kind of variations that you are requesting be added to the specification will = allow that to occur.

    [[LLi]] This is = fine and usefull. Just that every country uses today different formats for the = location used for emergency calls. Changing this will take time and costs money. =

    What is the = harm in allowing ECs to work with local location formats which are understood only by the = LIS and the PSAP ?. I dont = see why a common location format must be implemented by everybody.

    Maybe the = EC could work like this : =

    =B7         The proxy discovers = the LIS based on EDs IP-address using reverse-DNS and SRV record (this is = possible with "identity extenssions")

    =B7         It retrieves the location ( = e.g. using HELD) in a local format understood only by the LIS and the PSAP, = which are in the same country. The location is just a string which is passed transparently through the network to the PSAP. In my opinion, it would be in principle  posible to use LbyR to transport local = location identidfiers, e. g.  area-code@lis.telekom.de , but this = is currently my personal opinion, I didn' found any statemant or = example in the drafts.   

    =B7         The LIS delivers, together = with the LbyR above, the PSAP URI.  As far as I know there is currently = no way to do this in HELD (or did I miss something?).        
     

    It would be an alternative which is interoperable and quite easy to implement, without the need for the operators to change their = location databases. I think by allowing this scenario, interoperable EC = could be achieved earlier. And this does not exclude the scenario described = in the framework and phone-bcp, where the EDs retrieve deo or civic = location, which is needed for EC to work in private/enterprise networks.  
      

        

     

    The position appears to be that the German regulator doesn’t require = anything – and the operators will not be proactive in following a = specification if it doesn’t include what already exists. In that context, I = don’t understand why there is a need for the BCP at all. There may be no need = to endorse it but, similarly, there should be no need to object to it = – since the operators will only put in place their preferred version of = the service in any case.
    [[LLi]]  This is not quite true. We have = to ensure that EC works for different AN- and VoIP-provider and for nomadic = users in Germany by 2013. Our current solution does not allow this and = there is the same for other carriers. We definitively need to define in = Germany an architecture which fullfills this requirements. It would be very usefull if we can use standard protocols. But nobody will be = willing to change everything at once.  Having a standard based architecture = which is low cost would be a great advantage.

     

    Kind regards

    Laura     

     

     That’s OK… insofar as it just means German networks aren’t ECRIT compatible – “compatibility” isn’t a worthy goal = in and of itself; it has to actually mean any device can work = anywhere.

     

    Cheers,

    Martin

     

    From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]
    Sent: Friday, 7 August 2009 12:29 AM
    To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org
    Cc: Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on PhoneBCP

     

    Hi Martin,

     

    See comments inline [[LLi]].

     

     

    Laura

    From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Dawson, Martin
    Sent: Wednesday, August 05, 2009 11:00 AM
    To: Jesske, Roland; ecrit@ietf.org
    Subject: Re: [Ecrit] HUM on PhoneBCP

    Hi Roland,

     

    I think what you’re saying is that you don’t think that Germany will = go on to implement full ECRIT support but will peg development at an interim = phase.
    [[LLi]]  We don't know how the = realtime application networks or EC will look like in 20 = years. Roland's answer only applies to the next 5 to 10 years. 

     

     That would be disappointing – not least because full ECRIT compliance = would ultimately decrease the overhead associated with emergency service = support for operators as well as providing a more universal service.

    [[LLi]]  This may be true for = "green field" ISPs and VSPs but not for incumbent carriers with = existing infrastructure.  And universal service is not a requirement = for us. Neither the German regulator requires it nor is it a busines case.   

     

    Nevertheless, I don’t think that decision = invalidates the BCP;
    [[LLi]]  We think it = does, because some of the requirements are not flexible enough to cover the deployments = within the next years.  The BCP should be more = flexible:  

    =B7         Allow additional = location identifiers 

    =B7         Allow AN operated = LOST

    =B7         Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS to query the LOST , but there are also other alternatives. 

    =B7         Allow and describe= also network-centric, not only ED-centric architectures. If = I  remember correctly, John Medland from BT also recomended to use a = more network- centric architecture, at least for the next years.

     

    I think it just means that the German regulator and technical advisory = committees would point out the subset aspects of compliance that would be = applicable to that jurisdiction.  
    [[LLi]]  Again, the draft is not = flexible enough for it.  If the BCP contains requirements which are not realistic, people will just discard the BCP and implement = proprietary stuff. My expectation from a standard body is to define protocols = and architecture which people are willing to implement in their network or = products , not only in the lab.

     

    [[LLi]] 

    We are not against the draft in principle. ECRIT provides  us with very valuable specifications as LbyR, HELD, identity extensions. But targeting an architecture which requires = everbody to invest without a business case will not help the = draft in the end, also if it becomes a BCP.  It would make sense to = make it more flexible so people are willing to adopt = it.    

     

     Actually, based on your description below, the NENA i2 architecture would probably = be a more straightforward baseline for analysis – as has been done in = the UK and Canada. Of course, it’s generally recognized as only an = interim step, even in those jurisdictions.

    Other comments below.

     

    Cheers,

    Martin

     

    From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = R.Jesske@telekom.de
    Sent: Wednesday, 5 August 2009 6:19 PM
    To: ecrit@ietf.org
    Subject: Re: [Ecrit] HUM on PhoneBCP

     

     

    Dear all,
    We would like the document to become a BCP as = soon as possible so the group can move on with other documents related to = emergency calling based on location-by-reference and ED’s IP-address. =

    [[MCD]] I think you might mean “identity extensions” rather than location-by-reference = because LbyR still requires the ED to obtain the reference – e.g. by = HELD.
    [[LLi]] We use both, the IP-address as = UE identity and LbyR. The SIP-proxy uses the IP-address to query the LIS = using HTTP (it's not HELD but SOAP over HTTP, but anyway similar). The = LIS responds with a numeric string associated to the caller location, = in principle a LbyR and with the PSAP number. The proxy inserts = the LbyR into the SIP-message (as P-Asserted-ID because the PSAPs are = in PSTN) and routes the message to the PSAP.  It's a low cost solution. 

    But we can not HUM for the = current form of the document.

    Back to the document: Some = requirements are far form being realistic, at least in Germany, some are not realistic at = all. Implementing these requirements cost a carrier a lot of money and there = is no ROI for it.

    Just a few examples:

    =B7       Requiring either geo or civic location does not provide carriers with enough = flexibility to reuse their existing mechanisms and location databases. Routing of = emergency calls is currently done in Germany based on phone area code not on geo = or civic location, at least for the fixed network. For mobile networks the = cell-id is used in common. This is regulated by the german regulator. =

    [[MCD]] How many unique PSAP = routes are required in Germany? The US has lots (6000 plus) and Australia has two = (and they are redundant so it doesn’t matter which one). Presumably = geographic information, for PSAP catchment areas, is the basis for determining = which area codes are relevant to begin with? After all, an area code is not = intrinsically geographic; it’s a network routing value. If so, then some = geographic discriminator is already in play in terms of constructing the area code = based routing data (something like zip codes perhaps?) – and in that = case, it should be straightforward to by-pass the area code step in the = construction of routing that goes the correct PSAP URI.
    [[LLi]] Currently, fixed networks carriers in Germany route the ECs based only on the caller's = area code. Sometime in the past, the carriers, the regulator and = the PSAPs operators (police, the Red Cross) agreed to do so. This may change = in the future, but it will take a quite long = time.      

     With nomadic VoIP devices = (and it’s no good being in denial about this being the norm in the = future) area code is no more reliable than it is for conventional mobile phones. = And, presumably, area code is not used for conventional cellular emergency = call routing?
    [[LLi]]  As far as I know, mobile = networks use the Cell-ID, not the area code, and have a different table than the = fixed network operators. They are not going to change this.  As to = the nomadic SIP-users...if we like it or not, very few of our customers use our SIP service nomadic, let alone call EC = from their = laptop.         

    1        = ;      LOST as a national, let alone as a global = directory is not going to be implemented. The regulator will provide in the web a = static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its own routing = database for emergency calls.

    [[MCD]] Whatever the carriers = implement (and they have to implement something) could just as readily be done using = LoST. Then visiting devices, with no association with any local VoIP proxy = server would still be able to determine a route to the correct PSAP. = Alternatively, as long as the regulator is maintaining a web service with the routing information, why not make that directly accessible using LoST and save = the operators the cost of duplicating the service at all?
    [[LLi]]  There is a big difference = between maintaining a web page with a table which operator can print and = implement in their darabases and operating a database which is queried for every emergency call in Germany, must have an availablity of 99,99...% ,  is secure enough...you know. The regulator will not do this.


    2       We have no intention to rely on = end devices for location information because:     =B7       ED = provided location info is not trusted

    [[MCD]] Location by reference = mitigates this trust issue. The emergency network can (automatically and before human resources are engaged) assess the source of the reference, and the = validity of the location by dereference, without having to trust location provided = directly from the ED. There are more sophisticated approaches to trustability = even using LbyV – based on digital signatures across appropriate attributes. = This WG and Geopriv haven’t really got to grips with that… yet.
    [[LLi]]  We build the SIP-network = and EC now. ED-provided location is needed if EC must work = for private and enterprise networks and VPNs.  We have no such regulatory requirements.  And we don't know of any verdor of = DSL-EDs which provides today SIP with LbyR and is as cheap as the devices without it. If you do, please let me = know. 

    The regulator ask us to = guarantee that EC works. What if a customer dials 112 and his end device does not send the location? So I have to implement both solutions, = with and without ED provided location, anyway.  
    1       There are already a lot of existing EDs in usage which don’t send location.   

    [[MCD]] Quite right. ECRIT = doesn’t overly concern itself with that interim situation. The UK and Canadian definitions for an interim solution (limiting service to in-country VoIP = proxy operators) both assume third-party query via identity-extension to allow = the proxy or the VPC to make the query to the LIS. This isn’t = extensible to universal emergency service access by all visiting devices but it does = put the necessary LIS functionality in place as a very good starting point.  It would be a pity if Germany were to cease the = evolution there as it would not fulfil the real promise of the Internet and the = ECRIT model.
    [[LLi]]  I wonder who will = drive and pay for upgrading the interim = solutions.  Unfortunatelly, it's all about money...

     Think about it; all the = complexity of putting location determination infrastructure in place for the purposes = of dispatch is done – and then the next, simpler step, of using that = to support the routing procedure isn’t taken… that would be a = waste.

    [[LLi]]  Do you think this is an = argument for a product manager? They need a business case.  =

     

     

      = We don’t intend to require our ED-vendors to provide location because = it is useless to us.  

    We could agree with the document = with following changes:

    o    Other location = identifiers then geo or civil are allowed. It must be possibe that the data foermat is = flexible due to different requirements from regulators over the whole world. (e.G = Germany area codes for fixed- and Cell-Id for moile- providers)

    o    The MUST for the end devices to support location information, DHCP location = options and HELD shall be removed

    o    It must be possible for the VoIP-provider’s proxy to use a LOST (or an ESRP) = provided by the AN or by other local provider on behalf of the AN.  =

     

     There is no value in = Hum-ing documents which one is not going to implement and does not fit into regulated = schemes like in Germany. Currently, neither the IETF- nor the 3GPP-architecture = for emergency calling covers our real needs for the next 2 to 5 years and in = the end everybody still has its own proprietary = implementation.   

    Best regards

    Roland

     

    Deutsche = Telekom Netzproduktion GmbH
    Zentrum Technik Einf=FChrung
    Roland Jesske
    Gateways, Protokolle, Konvergenz, TE32-1
    Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,
    Postfach, 64307 Darmstadt (Postanschrift)
    +496151 628 2766 (Tel)
    +491718618445 (Mobile)
    E-Mail:     r= .jesske@telekom.de
    http://www.telekom.de =

     

    Registerrechtliche = Unternehmensangaben:
    Deutsche Telekom Netzproduktion (DT NP) GmbH
    Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno = Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
    Handelsregister: Amtsgericht Bonn HRB 14190
    Sitz der Gesellschaft: Bonn
    USt-IdNr.: DE 814645262

     

     


    = -------------------------------------------------------------------------= -----------------------
    = This message is for the designated recipien= t only and may
    = contain privileged, proprietary, or otherwise pr= ivate information.  
    = If you have received it in error, plea= se notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibited.
    = -------------------------------------------------------------------------= -----------------------
    [mf2]

     

     


    = -------------------------------------------------------------------------= -----------------------
    = This message is for the designated recipien= t only and may
    = contain privileged, proprietary, or otherwise pr= ivate information.  
    = If you have received it in error, plea= se notify the sender
    = immediately and delete the original.  Any&n= bsp;unauthorized use of
    this email is prohibited.
    = -------------------------------------------------------------------------= -----------------------
    [mf2]

     

    ------=_NextPart_000_0463_01CA1754.931A5A70-- From mlinsner@cisco.com Fri Aug 7 10:06:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB37128C1DF for ; Fri, 7 Aug 2009 10:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.582, 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 qIL9UYAxujwZ for ; Fri, 7 Aug 2009 10:06:54 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C6EC228C1E5 for ; Fri, 7 Aug 2009 10:06:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJv7e0pAZnmf/2dsb2JhbAC4MYgrkBwFhBY X-IronPort-AV: E=Sophos;i="4.43,343,1246838400"; d="scan'208";a="53340570" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Aug 2009 17:06:56 +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 n77H6uFa024372; Fri, 7 Aug 2009 13:06:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n77H6uM9002192; Fri, 7 Aug 2009 17:06:56 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 13:06:56 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 13:06:55 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 07 Aug 2009 13:06:54 -0400 From: Marc Linsner To: Ted Hardie , "'ecrit'" Message-ID: Thread-Topic: [Ecrit] Proto for PhoneBCP Thread-Index: AcoXgXaDV2B6SOelhU+3mRqr0SpP1w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Aug 2009 17:06:55.0768 (UTC) FILETIME=[7790D180:01CA1781] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1696; t=1249664816; x=1250528816; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Proto=20for=20PhoneBCP |Sender:=20 |To:=20Ted=20Hardie=20,=20=22'ecrit'=2 2=20; bh=a8TRbrKato9PS837mMXSaqcaU33AKO8dwPLq5cTncqU=; b=PQmCCm43yJG7w3NjMehq+wwuuRdY2TAdY+390BZO0omR9ecVPYvr6/RvTB 7ya3EsoMJWKo0cnhmuwxUqW2BBE9DjjsIWN1+w5bm/UwTzRqrIr6GV+rZsMg H5xERLUxtZ; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] Proto for PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 17:06:55 -0000 I updated the proto section (1e) to reflect that we have received this liaison. -Marc- On 7/28/09 4:43 PM, "Ted Hardie" wrote: > At 6:26 AM -0700 7/28/09, Marc Linsner wrote: >> >> (1.e) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole understand and >> agree with it? >> >> While there has been some past controversy around some of the exact wording >> in this document, there is overall wg consensus that this document - in its >> present form - should be published. The WG as a whole has been working on the >> document. >> The last remaining issue was a discussion titled 'Applicability Statement'. >> Text was submitted and rejected by the WG. See: >> http://www. >> ietf.org/mail-archive/web/ecrit/current/msg06434.html > >> (1.f) Has anyone threatened an appeal or otherwise indicated extreme >> discontent? If so, please summarize the areas of conflict in >> separate email messages to the Responsible Area Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >> >> No known threats for an appeal. > > I think it would be valuable to add the history of requests for > liaison and the liaisons from 3gpp here. I understand that the > current liaison is not very useful, since it simply promises and > eventual technical comment, but I think the history here > needs to be said. > > thanks, > Ted From mlinsner@cisco.com Fri Aug 7 10:47:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91043A6E7D for ; Fri, 7 Aug 2009 10:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPKwJphNfvxo for ; Fri, 7 Aug 2009 10:47:06 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EBF7F28C1D0 for ; Fri, 7 Aug 2009 10:47:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAPsEfEpAZnmf/2dsb2JhbACCVZZPnmGIK5AfBYQW X-IronPort-AV: E=Sophos;i="4.43,343,1246838400"; d="scan'208,217";a="53346248" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Aug 2009 17:47: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 n77Hl8Cr016929 for ; Fri, 7 Aug 2009 13:47:08 -0400 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.14.3) with ESMTP id n77Hl82h001153 for ; Fri, 7 Aug 2009 17:47:08 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 13:47:08 -0400 Received: from [10.116.195.114] ([10.116.195.114]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 13:47:07 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 07 Aug 2009 13:47:06 -0400 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: Premature Disconnect Thread-Index: AcoXhxQtX8f3gqAXCEqhXCTtM2totQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3332497627_1173189" X-OriginalArrivalTime: 07 Aug 2009 17:47:08.0016 (UTC) FILETIME=[1560A700:01CA1787] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2934; t=1249667228; x=1250531228; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Premature=20Disconnect |Sender:=20 |To:=20=22'ecrit'=22=20; bh=tfio7TcOx3rjICzGPzEnL2b3ed+JYXUd0gmzkfIQ8L0=; b=h3Oclz02DdJQokPurp5clB2tJei2viJGKgBc2d2aC93m2Rd0lFggK5rK6P joPYkey6GrX9ysHkbCBdUZUyEnlMVDRpOYEplga8Zemr0K2V/iOtRLEl5xCd NmAuEcKE8w; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Ecrit] Premature Disconnect X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 17:47:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3332497627_1173189 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable At the Stockholm meeting Brian Rosen presented Premature Disconnect (http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02= ) . After some amount of discussion, we told Brian to =8Cgo away=B9 and bring back a problem statement vs. a set of requirements so we could evaluate whether this is something we wanted to work on. I had hoped we would have time during the meeting for Brian to present the problem statement, but we ran out of time. Brian sent it to the list on 7/29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html). Now for the obvious questions. Do you have feedback regarding the problem statement? Do you think that this is a problem worth solving in ECRIT? Your feedback will determine whether we ask for AD approval to add this wor= k to our charter. Please respond by COB Friday August 14, 2009. Thanks, Marc & Hannes --B_3332497627_1173189 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Premature Disconnect At the Stockholm meeting Brian Rosen presented Premature Disconnect (http://www.ietf.o= rg/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-prematu= re-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecri= t-premature-disconnect-rqmts-02).  After some amount of discussion,= we told Brian to ‘go away’ and bring back a problem statement v= s. a set of requirements so we could evaluate whether this is something we w= anted to work on.  I had hoped we would have time during the meeting fo= r Brian to present the problem statement, but we ran out of time. Brian sent= it to the list on 7/29/09 (http://www.ietf.org/mail-archive/web/ecrit/curren= t/msg06500.html).

    Now for the obvious questions.

    Do you have feedback regarding the problem statement?

    Do you think that this is a problem worth solving in ECRIT?

    Your feedback will determine whether we ask for AD approval to add this wor= k to our charter.  Please respond by COB Friday August 14, 2009.

    Thanks,

    Marc & Hannes     --B_3332497627_1173189-- From bernard_aboba@hotmail.com Fri Aug 7 12:15:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1745E3A6943 for ; Fri, 7 Aug 2009 12:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.148 X-Spam-Level: X-Spam-Status: No, score=0.148 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsYdUjOJl9xY for ; Fri, 7 Aug 2009 12:15:17 -0700 (PDT) Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by core3.amsl.com (Postfix) with ESMTP id 620643A6F97 for ; Fri, 7 Aug 2009 12:15:11 -0700 (PDT) Received: from BLU137-DS7 ([65.55.111.73]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:15:14 -0700 X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Marc Linsner'" , "'ecrit'" References: In-Reply-To: Date: Fri, 7 Aug 2009 12:15:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CA1758.B8521B30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoXhxQtX8f3gqAXCEqhXCTtM2totQACEdlw Content-Language: en-us X-OriginalArrivalTime: 07 Aug 2009 19:15:14.0319 (UTC) FILETIME=[644279F0:01CA1793] Subject: Re: [Ecrit] Premature Disconnect X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 19:15:23 -0000 ------=_NextPart_000_00A0_01CA1758.B8521B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The essence of the problem is described in Section 1.1 draft-rosen-ecrit-premature-disconnect-rqmts: Occasionally, when on an emergency call, a caller hangs up the call before the call taker is finished acquiring enough information. Emergency calls are stressful, and mistakes are inevitably made. A mechanism is needed to re-establish communication between the caller and the call taker when this happens. As was pointed out during the meeting, the question is exactly what it means to "re-establish communication", and in particular, the role of the caller vs. the PSAP. For me, Section 1.1 of the original document did not provide the justification for the requirements that subsequently followed in Sections 2 and 3. The problem statement posted to the list on July 29 is a step in the right direction, in that it goes into more detail on the types of behavior that might be desirable in different circumstances (e.g. answering of the emergency call by IVR versus a dispatcher). However, it still seems to me that the problem statement (not requirements) deserves an expanded treatment which in particular goes into the issues that can be encountered in "re-establishing communication" with existing implementations, as well as those conforming to phone-bcp. So if the question is whether the problem is well-specified enough to modify the charter so as to enable work on solutions, my answer is "no". If the question is whether I think ECRIT WG should add a problem statement work item to its charter, my answer is "yes". From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Friday, August 07, 2009 10:47 AM To: 'ecrit' Subject: [Ecrit] Premature Disconnect At the Stockholm meeting Brian Rosen presented Premature Disconnect (http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02) . After some amount of discussion, we told Brian to 'go away' and bring back a problem statement vs. a set of requirements so we could evaluate whether this is something we wanted to work on. I had hoped we would have time during the meeting for Brian to present the problem statement, but we ran out of time. Brian sent it to the list on 7/29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html). Now for the obvious questions. Do you have feedback regarding the problem statement? Do you think that this is a problem worth solving in ECRIT? Your feedback will determine whether we ask for AD approval to add this work to our charter. Please respond by COB Friday August 14, 2009. Thanks, Marc & Hannes ------=_NextPart_000_00A0_01CA1758.B8521B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Premature Disconnect

    The essence of the problem is described in Section 1.1 = draft-rosen-ecrit-premature-disconnect-rqmts:

     

       Occasionally, when on = an emergency call, a caller hangs up the call

       before the call taker = is finished acquiring enough information.

       Emergency calls are = stressful, and mistakes are inevitably made.  A

       mechanism is needed to re-establish communication between the caller

       and the call taker when = this happens.

     

     

    As was pointed out during the meeting, the question is = exactly what it means to “re-establish communication”, and in = particular, the role of the caller vs. the PSAP.   

     

    For me, Section 1.1 of the original document did not = provide the justification for the requirements that subsequently followed in = Sections 2 and 3.

     

    The problem statement posted to the list on July 29 is a = step in the right direction, in that it goes into more detail on the types of = behavior that might be desirable in different circumstances (e.g. answering of = the emergency call by IVR versus a dispatcher). 

     

    However, it still seems to me that the problem statement = (not requirements) deserves an expanded treatment which in particular goes = into the issues that can be encountered in “re-establishing = communication” with existing implementations, as well as those conforming to = phone-bcp. 

     

    So if the question is whether the problem is = well-specified enough to modify the charter so as to enable work on solutions, my answer is = “no”.

     

    If the question is whether I think ECRIT WG should add a = problem statement work item to its charter, my answer is “yes”. =

     

     

    From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Marc Linsner
    Sent: Friday, August 07, 2009 10:47 AM
    To: 'ecrit'
    Subject: [Ecrit] Premature Disconnect

     

    At the Stockholm meeting Brian Rosen presented Premature Disconnect (http://www= .ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconn= ect-rqmts-02).  After some amount of discussion, we told Brian to ‘go = away’ and bring back a problem statement vs. a set of requirements so we could evaluate whether this is something we wanted to work on.  I had = hoped we would have time during the meeting for Brian to present the problem = statement, but we ran out of time. Brian sent it to the list on 7/29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html).
    Now for the obvious questions.

    Do you have feedback regarding the problem statement?

    Do you think that this is a problem worth solving in ECRIT?

    Your feedback will determine whether we ask for AD approval to add this = work to our charter.  Please respond by COB Friday August 14, 2009.

    Thanks,

    Marc & Hannes

    ------=_NextPart_000_00A0_01CA1758.B8521B30-- From john@johnlange.ca Fri Aug 7 13:01:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFEF3A6EDF for ; Fri, 7 Aug 2009 13:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHSO8cgGI4hV for ; Fri, 7 Aug 2009 13:01:04 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 1A1843A695F for ; Fri, 7 Aug 2009 13:01:04 -0700 (PDT) Received: (qmail 19130 invoked from network); 7 Aug 2009 15:01:36 -0500 Received: from unknown (HELO ?10.179.179.201?) (74.198.148.45) by lh02.epicnet.ca with SMTP; 7 Aug 2009 15:01:33 -0500 From: John Lange To: "Dawson, Martin" In-Reply-To: References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <1249584170.5335.24.camel@vandium.darkcore.net> <6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> <1249587517.5335.80.camel@vandium.darkcore.net> <1249656835.5053.35.camel@vandium.darkcore.net> Content-Type: text/plain Date: Fri, 07 Aug 2009 14:59:45 -0500 Message-Id: <1249675185.5053.126.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: ecrit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 20:01:05 -0000 On Fri, 2009-08-07 at 10:40 -0500, Dawson, Martin wrote: > I'm saying that the investment in dynamic location determination > capabilities in the network is the most significant step an operator > needs to make toward ECRIT capability. So any architecture that does > this does represent a significant step toward ECRIT... whether that's > the intention or not. Certainly location determination is what it's all about and I grant you that having that capability in any form is a potential step forward. But I emphasis that the way it's implemented will have a large impact on future uses. A private network/proprietary implementation likely does not get you any closer to ECRIT compliance. Consider that, once implemented, the Ci2 infrastructure would have to be left in place to support users and devices that have come to rely on it. The private networks, the proprietary protocols, everything would have to stay indefinitely just as existing PSAP wireline will be around for the long hall. Though we may discuss bringing Ci2 into compliance with ECRIT as being an "upgrade", what we are really talking about is yet another complete infrastructure build while still keeping the legacy systems operating. If we are lucky there may be some components that can function on both networks but that seems unlikely given that given that the methodology and protocols described in Ci2 are not compatible with either current ECRIT work or even legacy NENAi2. Furthermore, once the system is deployed, who will be motivated to evolve to ECRIT compliance? The public? No. the Ci2 system works = nobody dies = no public outcry = no upgrade. The ILECs? No. Their competitors (the VOIP providers) are now tied into them as the monopoly supplier of emergency services. A perfect way to keep them less competitive. The regulator? No. See "The public" above. The PSAPs? No. See "The public" above. The VSPs? Yes! But who cares? See "the regulator" above. > I think that pretty much establishes that the extent of our > disagreement is only a matter of degree. Agreed. We are only arguing semantics at this point. I feel strongly that if Ci2 is implemented the way it is currently proposed it will be very bad for VOIP providers and by extension the Canadian public. -- John Lange http://www.johnlange.ca From john@johnlange.ca Fri Aug 7 13:36:41 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C400D3A6F8B for ; Fri, 7 Aug 2009 13:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz5t-s9bDCd2 for ; Fri, 7 Aug 2009 13:36:41 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id D4B6C3A6C35 for ; Fri, 7 Aug 2009 13:36:40 -0700 (PDT) Received: (qmail 27897 invoked from network); 7 Aug 2009 15:37:21 -0500 Received: from unknown (HELO ?10.179.179.201?) (74.198.148.45) by lh02.epicnet.ca with SMTP; 7 Aug 2009 15:37:20 -0500 From: John Lange To: ecrit Content-Type: text/plain Date: Fri, 07 Aug 2009 15:35:24 -0500 Message-Id: <1249677324.5053.129.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Framework For Emergency Calling in Canada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 20:36:41 -0000 Some on this mailing list may be interested in a document I filed with the CRTC (Canadian FCC) today regarding a proposed framework for VOIP E911 in Canada. I don't believe this mailing list supports attachments so I have made it available on my website: http://www.johnlange.ca/2009/08/07/a-framework-for-emergency-calling-in-canada/ Regards, -- John Lange http://www.johnlange.ca From Martin.Dawson@andrew.com Sat Aug 8 00:58:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41C93A6A48 for ; Sat, 8 Aug 2009 00:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX9HSMFsx7q0 for ; Sat, 8 Aug 2009 00:58:04 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 995B73A6964 for ; Sat, 8 Aug 2009 00:58:04 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_08_03_20_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 08 Aug 2009 03:20:51 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 02:58:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 8 Aug 2009 02:56:43 -0500 Message-ID: In-Reply-To: <1249675185.5053.126.camel@vandium.darkcore.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoXmc5tlCXGJ9VFSrGLqw7u8PxgRQAJ4+UQ References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <1249584170.5335.24.camel@vandium.darkcore.net> <6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> <1249587517.5335.80.camel@vandium.darkcore.net> <1249656835.5053.35.camel@vandium.darkcore.net> <1249675185.5053.126.camel@vandium.darkcore.net> From: "Dawson, Martin" To: "John Lange" X-OriginalArrivalTime: 08 Aug 2009 07:58:07.0651 (UTC) FILETIME=[F74AA730:01CA17FD] Cc: ecrit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 07:58:05 -0000 OK... I don't really have a view on whether Ci2 is the *best* first step=0D= =0Aor not.=0D=0A=0D=0APresumably the first "casualty" would be somebody fro= m an=0D=0AECRIT-compliant jurisdiction who expected they could make a relia= ble=0D=0Aemergency call on the WiFi hotspot they're visiting using the stan= dard=0D=0Aemergency client on their WiFi device.=0D=0A=0D=0ACheers,=0D=0AMa= rtin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: John Lange [mailto:jo= hn@johnlange.ca]=20=0D=0ASent: Saturday, 8 August 2009 6:00 AM=0D=0ATo: Daw= son, Martin=0D=0ACc: ecrit=0D=0ASubject: RE: [Ecrit] HUM on PhoneBCP=0D=0A=0D= =0AOn Fri, 2009-08-07 at 10:40 -0500, Dawson, Martin wrote:=0D=0A> I'm sayi= ng that the investment in dynamic location determination=0D=0A> capabilitie= s in the network is the most significant step an operator=0D=0A> needs to m= ake toward ECRIT capability. So any architecture that does=0D=0A> this does= represent a significant step toward ECRIT... whether that's=0D=0A> the int= ention or not.=0D=0A=0D=0ACertainly location determination is what it's all= about and I grant you=0D=0Athat having that capability in any form is a po= tential step forward.=0D=0A=0D=0ABut I emphasis that the way it's implement= ed will have a large impact on=0D=0Afuture uses. A private network/propriet= ary implementation likely does=0D=0Anot get you any closer to ECRIT complia= nce.=0D=0A=0D=0AConsider that, once implemented, the Ci2 infrastructure wou= ld have to be=0D=0Aleft in place to support users and devices that have com= e to rely on it.=0D=0AThe private networks, the proprietary protocols, ever= ything would have=0D=0Ato stay indefinitely just as existing PSAP wireline = will be around for=0D=0Athe long hall.=0D=0A=0D=0AThough we may discuss bri= nging Ci2 into compliance with ECRIT as being=0D=0Aan "upgrade", what we ar= e really talking about is yet another complete=0D=0Ainfrastructure build wh= ile still keeping the legacy systems operating.=0D=0A=0D=0AIf we are lucky = there may be some components that can function on both=0D=0Anetworks but th= at seems unlikely given that given that the methodology=0D=0Aand protocols = described in Ci2 are not compatible with either current=0D=0AECRIT work or = even legacy NENAi2.=0D=0A=0D=0AFurthermore, once the system is deployed, wh= o will be motivated to=0D=0Aevolve to ECRIT compliance=3F=0D=0A=0D=0AThe pu= blic=3F No. the Ci2 system works =3D nobody dies =3D no public outcry =3D=0D= =0Ano upgrade.=0D=0A=0D=0AThe ILECs=3F No. Their competitors (the VOIP prov= iders) are now tied into=0D=0Athem as the monopoly supplier of emergency se= rvices. A perfect way to=0D=0Akeep them less competitive.=0D=0A=0D=0AThe re= gulator=3F No. See "The public" above.=0D=0A=0D=0AThe PSAPs=3F No. See "The= public" above.=0D=0A=0D=0AThe VSPs=3F Yes! But who cares=3F See "the regul= ator" above.=0D=0A=0D=0A> I think that pretty much establishes that the ext= ent of our=0D=0A> disagreement is only a matter of degree.=0D=0A=0D=0AAgree= d. We are only arguing semantics at this point.=0D=0A=0D=0AI feel strongly = that if Ci2 is implemented the way it is currently=0D=0Aproposed it will be= very bad for VOIP providers and by extension the=0D=0ACanadian public.=0D=0A=0D= =0A--=20=0D=0AJohn Lange=0D=0Ahttp://www.johnlange.ca=0D=0A=0D=0A=0D=0A----= ---------------------------------------------------------------------------= -----------------=0D=0AThis message is for the designated recipient only an= d may=0D=0Acontain privileged, proprietary, or otherwise private informatio= n. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A From Hannes.Tschofenig@gmx.net Sat Aug 8 04:59:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71F43A691A for ; Sat, 8 Aug 2009 04:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[AWL=0.989, 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 Hnl54ElOXgdv for ; Sat, 8 Aug 2009 04:59:51 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3238B3A6917 for ; Sat, 8 Aug 2009 04:59:50 -0700 (PDT) Received: (qmail invoked by alias); 08 Aug 2009 11:59:52 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp018) with SMTP; 08 Aug 2009 13:59:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19u6No591FujGh7yI260ZWb/C3RufY1UkCKapF6LS 9x6ykqNmgVnYEZ From: "Hannes Tschofenig" To: "'Dawson, Martin'" , "'John Lange'" References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><1249584170.5335.24.camel@vandium.darkcore.net><6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com><1249587517.5335.80.camel@vandium.darkcore.net><1249656835.5053.35.camel@vandium.darkcore.net><1249675185.5053.126.camel@vandium.darkcore.net> Date: Sat, 8 Aug 2009 15:02:23 +0300 Message-ID: <05b601ca1820$17fc20e0$625aa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoXmc5tlCXGJ9VFSrGLqw7u8PxgRQAJ4+UQABdMN2A= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 11:59:53 -0000 Hi John, in addition to what Martin said about the negative impact on the "public". My guess is that the emergency services networks will move their networks to IP (because of the lower costs) and then they will not require the ILECs todo the gatewaying of all the calls. They will be able to get emergency calls directly from the VoIP providers. This will be less expensive, will support additional media and more extensible for future deployments. This is an evolution step we observe in many countries. One interesting data point I would like to understand is whether the PSAPs/emergency services networks have to pay to the ILECs for their emergency call routing and gatewaying "offering". If they have to then there is obviously incentive for them to move away from that model. Regarding the VSPs vs. the ILECs: It depends on the regulator to balance the responsibilities between the two. This is largely a discussion that relates to net neutrality (there was a nice plenary discussion about that topic at the last IETF meeting). Ciao Hannes PS: I am always curious why people see the step to a NENA i2.5 or pre-ECRIT architecture as so complicated particularly when the largest investment is in the location server capability in the access networks (and those have to be done anyway regardless of the chosen architecture). >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Dawson, Martin >Sent: 08 August, 2009 10:57 >To: John Lange >Cc: ecrit >Subject: Re: [Ecrit] HUM on PhoneBCP > >OK... I don't really have a view on whether Ci2 is the *best* >first step or not. > >Presumably the first "casualty" would be somebody from an >ECRIT-compliant jurisdiction who expected they could make a >reliable emergency call on the WiFi hotspot they're visiting >using the standard emergency client on their WiFi device. > >Cheers, >Martin > >-----Original Message----- >From: John Lange [mailto:john@johnlange.ca] >Sent: Saturday, 8 August 2009 6:00 AM >To: Dawson, Martin >Cc: ecrit >Subject: RE: [Ecrit] HUM on PhoneBCP > >On Fri, 2009-08-07 at 10:40 -0500, Dawson, Martin wrote: >> I'm saying that the investment in dynamic location determination >> capabilities in the network is the most significant step an operator >> needs to make toward ECRIT capability. So any architecture that does >> this does represent a significant step toward ECRIT... >whether that's >> the intention or not. > >Certainly location determination is what it's all about and I >grant you that having that capability in any form is a >potential step forward. > >But I emphasis that the way it's implemented will have a large >impact on future uses. A private network/proprietary >implementation likely does not get you any closer to ECRIT compliance. > >Consider that, once implemented, the Ci2 infrastructure would >have to be left in place to support users and devices that >have come to rely on it. >The private networks, the proprietary protocols, everything >would have to stay indefinitely just as existing PSAP wireline >will be around for the long hall. > >Though we may discuss bringing Ci2 into compliance with ECRIT >as being an "upgrade", what we are really talking about is yet >another complete infrastructure build while still keeping the >legacy systems operating. > >If we are lucky there may be some components that can function >on both networks but that seems unlikely given that given that >the methodology and protocols described in Ci2 are not >compatible with either current ECRIT work or even legacy NENAi2. > >Furthermore, once the system is deployed, who will be >motivated to evolve to ECRIT compliance? > >The public? No. the Ci2 system works = nobody dies = no public >outcry = no upgrade. > >The ILECs? No. Their competitors (the VOIP providers) are now >tied into them as the monopoly supplier of emergency services. >A perfect way to keep them less competitive. > >The regulator? No. See "The public" above. > >The PSAPs? No. See "The public" above. > >The VSPs? Yes! But who cares? See "the regulator" above. > >> I think that pretty much establishes that the extent of our >> disagreement is only a matter of degree. > >Agreed. We are only arguing semantics at this point. > >I feel strongly that if Ci2 is implemented the way it is >currently proposed it will be very bad for VOIP providers and >by extension the Canadian public. > >-- >John Lange >http://www.johnlange.ca > > >--------------------------------------------------------------- >--------------------------------- >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 fmenard@xittel.net Sat Aug 8 07:22:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7AC3A6BAD for ; Sat, 8 Aug 2009 07:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 YSeqRcIq-LA2 for ; Sat, 8 Aug 2009 07:22:26 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 636CD3A6B9E for ; Sat, 8 Aug 2009 07:22:26 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MZmoW-0003Hn-WC; Sat, 08 Aug 2009 10:22:29 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MZmoW-0007RL-KB; Sat, 08 Aug 2009 10:22:29 -0400 Message-Id: <953295D5-9472-46C4-901A-0BE3C8443ABA@xittel.net> From: Francois Menard To: John Lange In-Reply-To: <1249677324.5053.129.camel@vandium.darkcore.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 8 Aug 2009 10:22:28 -0400 References: <1249677324.5053.129.camel@vandium.darkcore.net> X-Mailer: Apple Mail (2.935.3) Cc: ecrit Subject: Re: [Ecrit] Framework For Emergency Calling in Canada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 14:22:27 -0000 In yesterday's submission to the CRTC, Manitoba Telephone Service / Allstream stated in paragraph 16 of its submission, that it could not implement a location determination platform for 70% of its broadband connections in Manitoba, particularly in Winnipeg, because its MOTOROLA DSLAMs which it uses for both DSL and IPTV are incapable of supporting Broadand Forum TR101 Intermediate Agent to pass the slot, port and shelf information back to the BRAS and then to the RADIUS server. Just an example that honest talk is possible on the public record of VoIP E-9-1-1 in this world. F. On 7-Aug-09, at 4:35 PM, John Lange wrote: > Some on this mailing list may be interested in a document I filed with > the CRTC (Canadian FCC) today regarding a proposed framework for VOIP > E911 in Canada. > > I don't believe this mailing list supports attachments so I have > made it > available on my website: > > http://www.johnlange.ca/2009/08/07/a-framework-for-emergency-calling-in-canada/ > > Regards, > -- > John Lange > http://www.johnlange.ca > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Francois Menard fmenard@xittel.net From fmenard@xittel.net Sat Aug 8 08:39:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146A73A6E51 for ; Sat, 8 Aug 2009 08:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 9Qc6YBviTiY0 for ; Sat, 8 Aug 2009 08:39:45 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 673AE3A67A2 for ; Sat, 8 Aug 2009 08:39:40 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MZo1G-000551-SG for ecrit@ietf.org; Sat, 08 Aug 2009 11:39:42 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MZo1G-0003f1-Ng for ecrit@ietf.org; Sat, 08 Aug 2009 11:39:42 -0400 Message-Id: <36E6ED93-ACE3-4AD2-A7FF-ACF11D5D5007@xittel.net> From: Francois Menard To: ecrit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 8 Aug 2009 11:39:42 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [Ecrit] Location Determination Platforms in DSL wholesale in Canada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 15:39:46 -0000 In yesterday's submission to the CRTC, the ILECs have submitted the following: --- For wholesale, the ILEC LDP will interact with the Wholesale ISP by responding to HELD location requests at the IP address assignment time by the Wholesale ISP. The Wholesale ISP will be responsible to update the ILEC LIS accordingly and in a timely fashion. ---- This language is very confusing to me. Does this mean that we are enabling LIS to LIS communications via HELD ? Question to the group: 1) What forms the query of the ISP into the ILEC LDP? 2) What forms the response of the ILEC LDP to the Wholesale ISP inside the HELD location request? 3) What forms the push update of the Wholesale ISP into the ILEC LIS? I have my suspicion that the ILEC has just devised a PIDF-LO carrying protocol in the form of HELD based on a L2TP AAA data atypical of DSL wholesale. Your enlightments will be great as the ILEC submission is mute on this. F. -- Francois Menard fmenard@xittel.net From James.Winterbottom@andrew.com Sat Aug 8 16:21:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DCD3A697F for ; Sat, 8 Aug 2009 16:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os1+KNjjLSFP for ; Sat, 8 Aug 2009 16:21:14 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9B8343A697E for ; Sat, 8 Aug 2009 16:21:14 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_08_18_44_01 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 08 Aug 2009 18:44:01 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 18:21:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 8 Aug 2009 18:20:30 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Determination Platforms in DSL wholesale in Canada Thread-Index: AcoYPnijR7OPD9GfRoaRUB7sBttBqwAQFnZc References: <36E6ED93-ACE3-4AD2-A7FF-ACF11D5D5007@xittel.net> From: "Winterbottom, James" To: "Francois Menard" , "ecrit" X-OriginalArrivalTime: 08 Aug 2009 23:21:17.0024 (UTC) FILETIME=[EDEE3E00:01CA187E] Subject: Re: [Ecrit] Location Determination Platforms in DSL wholesale in Canada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 23:21:15 -0000 Francois,=0D=0A=0D=0AWhy do you think that this mailing list has any more i= nsight into this than you do=3F=0D=0AWhy don't you simply ask the ILECs wha= t they mean=3F=0D=0A=0D=0ARegards=0D=0AJames=0D=0A=0D=0A=0D=0A-----Original= Message-----=0D=0AFrom: ecrit-bounces@ietf.org on behalf of Francois Menar= d=0D=0ASent: Sat 8/8/2009 10:39 AM=0D=0ATo: ecrit=0D=0ASubject: [Ecrit] Loc= ation Determination Platforms in DSL wholesale in Canada=0D=0A=20=0D=0A=0D=0A= In yesterday's submission to the CRTC, the ILECs have submitted the =20=0D=0A= following:=0D=0A=0D=0A---=0D=0AFor wholesale, the ILEC LDP will interact wi= th the Wholesale ISP by =20=0D=0Aresponding to HELD location requests at th= e IP address assignment time =20=0D=0Aby the Wholesale ISP.=0D=0A=0D=0AThe = Wholesale ISP will be responsible to update the ILEC LIS =20=0D=0Aaccording= ly and in a timely fashion.=0D=0A----=0D=0A=0D=0AThis language is very conf= using to me.=0D=0A=0D=0ADoes this mean that we are enabling LIS to LIS comm= unications via HELD =3F=0D=0A=0D=0AQuestion to the group:=0D=0A=0D=0A1) Wha= t forms the query of the ISP into the ILEC LDP=3F=0D=0A=0D=0A2) What forms = the response of the ILEC LDP to the Wholesale ISP inside =20=0D=0Athe HELD = location request=3F=0D=0A=0D=0A3) What forms the push update of the Wholesa= le ISP into the ILEC LIS=3F=0D=0A=0D=0AI have my suspicion that the ILEC ha= s just devised a PIDF-LO carrying =20=0D=0Aprotocol in the form of HELD bas= ed on a L2TP AAA data atypical of DSL =20=0D=0Awholesale.=0D=0A=0D=0AYour e= nlightments will be great as the ILEC submission is mute on this.=0D=0A=0D=0A= F.=0D=0A=0D=0A--=0D=0AFrancois Menard=0D=0Afmenard@xittel.net=0D=0A=0D=0A=0D= =0A=0D=0A_______________________________________________=0D=0AEcrit mailing= list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D= =0A=0D=0A=0D=0A------------------------------------------------------------= ------------------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0A[mf2]=0D= =0A From fmenard@xittel.net Sat Aug 8 17:15:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E8B3A6768; Sat, 8 Aug 2009 17:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clXwQAHYIxGU; Sat, 8 Aug 2009 17:15:23 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 10D323A66B4; Sat, 8 Aug 2009 17:15:22 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MZw4L-0008QO-Ld; Sat, 08 Aug 2009 20:15:25 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MZw4L-0001vY-DJ; Sat, 08 Aug 2009 20:15:25 -0400 Message-Id: <826C0AAE-B404-4797-91BB-0C694C76B63B@xittel.net> From: Francois Menard To: ecrit , geopriv@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 8 Aug 2009 20:15:25 -0400 References: <36E6ED93-ACE3-4AD2-A7FF-ACF11D5D5007@xittel.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [Ecrit] Location Determination Platforms in DSL wholesale in Canada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 00:15:24 -0000 I will, this will take interrogatories however, and the due date for asking them is August 28. However, I am certain that if they knew exactly, they could have been explicit about it. This is looking like a big fishing expedition, where their answer to this question will be something of the like: 'this question has been previously asked and the answer we provided was sufficient'. i.e. an answer proportional to the amount of collaboration which they have provided to this date... and dare I say, is the reason why this thing is dragging... and explains why nothing has been happening since March 2007. I am asking a very precise question to the ECRIT and GEOPRIV lists: Q. is HELD meant to be used as a PIDF-LO carrying protocol between two LISes and is there any standards track work done at the IETF to make this happen? The first LIS is being queried for a PIDF-LO in order to TDM route the call to the right PSAP by the emergency network operator. The other LIS is actually just a Location Determination Platform with a HELD interface.... F. On 8-Aug-09, at 7:20 PM, Winterbottom, James wrote: > Francois, > > Why do you think that this mailing list has any more insight into > this than you do? > Why don't you simply ask the ILECs what they mean? > > Regards > James > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Francois Menard > Sent: Sat 8/8/2009 10:39 AM > To: ecrit > Subject: [Ecrit] Location Determination Platforms in DSL wholesale > in Canada > > > In yesterday's submission to the CRTC, the ILECs have submitted the > following: > > --- > For wholesale, the ILEC LDP will interact with the Wholesale ISP by > responding to HELD location requests at the IP address assignment time > by the Wholesale ISP. > > The Wholesale ISP will be responsible to update the ILEC LIS > accordingly and in a timely fashion. > ---- > > This language is very confusing to me. > > Does this mean that we are enabling LIS to LIS communications via > HELD ? > > Question to the group: > > 1) What forms the query of the ISP into the ILEC LDP? > > 2) What forms the response of the ILEC LDP to the Wholesale ISP inside > the HELD location request? > > 3) What forms the push update of the Wholesale ISP into the ILEC LIS? > > I have my suspicion that the ILEC has just devised a PIDF-LO carrying > protocol in the form of HELD based on a L2TP AAA data atypical of DSL > wholesale. > > Your enlightments will be great as the ILEC submission is mute on > this. > > F. > > -- > Francois Menard > fmenard@xittel.net > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Francois Menard fmenard@xittel.net From root@core3.amsl.com Sun Aug 9 00:00:02 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1A21E3A6A4B; Sun, 9 Aug 2009 00:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090809070002.1A21E3A6A4B@core3.amsl.com> Date: Sun, 9 Aug 2009 00:00:02 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 07:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-07.txt Pages : 24 Date : 2009-08-08 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-sync-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-08234559.I-D@ietf.org> --NextPart-- From hannes.tschofenig@nsn.com Sun Aug 9 00:05:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B61D3A69E4 for ; Sun, 9 Aug 2009 00:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.974 X-Spam-Level: X-Spam-Status: No, score=-4.974 tagged_above=-999 required=5 tests=[AWL=1.624, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAO1XHQC4IqL for ; Sun, 9 Aug 2009 00:05:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A5F3D3A697B for ; Sun, 9 Aug 2009 00:04:59 -0700 (PDT) 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 n79751UT007376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 9 Aug 2009 09:05:01 +0200 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 n79751fV006398 for ; Sun, 9 Aug 2009 09:05:01 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Aug 2009 09:05:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA18BF.B65F7041" Date: Sun, 9 Aug 2009 10:07:33 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST Sync Draft Update Thread-Index: AcoYwBFn/W/ledE3T/+Zx30Goz9iZg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 09 Aug 2009 07:05:01.0696 (UTC) FILETIME=[B6BA4000:01CA18BF] Subject: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 07:05:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA18BF.B65F7041 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all,=20 I asked Roger to submit the PROTO writeup for the LoST sync draft after we got further confirmation from the implementers team. Then, Roger pointed me to the review by Richard and I have to say that I must have missed it. Here are Richards review comments:=20 http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html My response is inline:=20 I reviewed lost-sync-04 in order to update my earlier comments on -01. This version is much improved from the previous versions in terms of specificity (although it's still vague in places). It still seems to me that there are a few layers of detail missing. Specific comments below. --Richard 1. The document describes transactions for requesting and delivering mapping structures, but doesn't describe at all how these transactions create a synchronization system. There is clearly some tracking of state needed (especially for "pushMappings"), and the document is silent on how this state is initially established and then maintained. [Hannes] I added text throught the document to address this comments.=20 In particular I point to the need to keep state and also to the fact=20 that the document relies on manual configuration for setting up the=20 "peering" between the two nodes.=20 2. In a similar vein, it would be helpful for this document to have some discussion of how this synchronization system relates to others that are out there (e.g., rsync). Since the name of the draft is "synchronization", there should be some discussion of how bidirectional sync is handled. [Hannes] We had a discussion about this topic at the interim meeting and "downgraded" the document to an Experimental status to avoid having to=20 Analyse all available replication mechanisms. 3. It seems like there should really be only 3 message types here instead of 4: (1) a "syncRequest" message sent from destination to source (getMappingsRequest), (2) a "syncUpdate" message sent from source to destination (getMappingsResponse =3D=3D pushMappingsRequest), and (3) = a "syncResult" message sent from destination to source (pushMappingsResponse). There can still be two types of transaction, but they're determined by which type of message (syncRequest or syncUpdate) is sent in the HTTP request. [Hannes] We got similar feedback from the implementers. However, in a=20 subsequent discussion with them it turned out that this change is=20 rather a matter of style than anything technical. A change in the description along the lines as you suggested (and as they had suggested) as well only impacts the writing style of the document and not really=20 the implementation as such. Hence, I left the document as is.=20 4. In a similar vein to 2 and 3, the use of "client" and "server" is confusing. I would suggest using more appropriate names for these roles like "source" and "destination", along with some text that explains how these roles map to HTTP roles in each type of transaction. [Hannes] I added text regarding the HTTP/HTTPs roles and changed the=20 terminology in the document to reflect the source / destination terminology.=20 I hope it improved readability.=20 5. My comment about the security considerations has not been addressed. The security considerations section is essentially a pointer to LoST, but this protocol is only peripherally related to LoST (at a technical level). Since it's about synchronization, I would expect this document to note that the primary risk is the injection of false location information (since the mappings themselves are public), which means that the parties should use HTTPS to carry the XML, authenticate the source, and use a ciphersuite that provides integrity protection to messages. [Hannes] You are certainly right with this comment. I changed the text.=20 Here is the updated document:=20 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.txt Ciao Hannes ------_=_NextPart_001_01CA18BF.B65F7041 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable LoST Sync Draft Update

    Hi all,

    I asked Roger to submit the PROTO = writeup for the LoST sync draft after we got further confirmation from = the implementers team. Then, Roger pointed me to the review by Richard = and I have to say that I must have missed it. Here are Richards review = comments:

    http://www.ietf.org/mail-archive/web/ecrit/current/msg0612= 7.html

    My response is inline:

    I reviewed lost-sync-04 in order = to update my earlier comments on -01.
    This version is much improved from the previous versions in terms of
    specificity (although it's still vague in places).  It still seems = to me
    that there are a few layers of detail missing.  Specific comments = below.
    --Richard

    1. The document describes transactions for requesting and delivering
    mapping structures, but doesn't describe at all how these = transactions
    create a synchronization system.  There is clearly some tracking = of
    state needed (especially for "pushMappings"), and the document = is silent
    on how this state is initially established and then maintained.

    [Hannes] I added text throught = the document to address this comments.
    In particular I point to the = need to keep state and also to the fact
    that the document relies on = manual configuration for setting up the
    "peering" between the = two nodes.


    2. In a similar vein, it would be = helpful for this document to have some
    discussion of how this synchronization system relates to others that = are
    out there (e.g., rsync).  Since the name of the draft is
    "synchronization", there should be some discussion of how = bidirectional
    sync is handled.
    [Hannes] We had a discussion = about this topic at the interim meeting and
    "downgraded" the document to an Experimental status to avoid = having to
    Analyse all available replication mechanisms.

    3. It seems like there should = really be only 3 message types here
    instead of 4: (1) a "syncRequest" message sent from = destination to
    source (getMappingsRequest), (2) a "syncUpdate" message sent = from source
    to destination (getMappingsResponse =3D=3D pushMappingsRequest), and (3) = a
    "syncResult" message sent from destination to source
    (pushMappingsResponse).  There can still be two types of = transaction,
    but they're determined by which type of message (syncRequest or
    syncUpdate) is sent in the HTTP request.
    [Hannes] We got similar feedback = from the implementers. However, in a
    subsequent discussion with them it turned out that this change is
    rather a matter of style than anything technical. A change in the
    description along the lines as you suggested (and as they had suggested) =
    as well only impacts the writing = style of the document and not really
    the implementation as such. = Hence, I left the document as is.

    4. In a similar vein to 2 and 3, = the use of "client" and "server" is
    confusing.  I would suggest using more appropriate names for these = roles
    like "source" and "destination", along with some = text that explains how
    these roles map to HTTP roles in each type of transaction.
    [Hannes] I added text regarding = the HTTP/HTTPs roles and changed the
    terminology in the document to reflect the source / destination = terminology.
    I hope it improved readability. =

    5. My comment about the security = considerations has not been addressed.
     The security considerations section is essentially a pointer to = LoST,
    but this protocol is only peripherally related to LoST (at a = technical
    level).  Since it's about synchronization, I would expect this = document
    to note that the primary risk is the injection of false location
    information (since the mappings themselves are public), which means = that
    the parties should use HTTPS to carry the XML, authenticate the = source,
    and use a ciphersuite that provides integrity protection to = messages.

    [Hannes] You are certainly = right with this comment. I changed the text.


    Here is the updated document:
    http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.tx= t

    Ciao
    Hannes

    ------_=_NextPart_001_01CA18BF.B65F7041-- From Hannes.Tschofenig@gmx.net Sun Aug 9 00:05:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A008E3A69D3 for ; Sun, 9 Aug 2009 00:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.954, 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 LXC5UzMlYe1k for ; Sun, 9 Aug 2009 00:05:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0C6993A697B for ; Sun, 9 Aug 2009 00:05:25 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2009 06:58:49 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp059) with SMTP; 09 Aug 2009 08:58:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/h/KhMXArhKJw+s3ZiDJsrP3K3+go1Q3NjiQCdhy 91u+qhIpJMwE9N From: "Hannes Tschofenig" To: "'Francois Menard'" , "'ecrit'" , References: <36E6ED93-ACE3-4AD2-A7FF-ACF11D5D5007@xittel.net> <826C0AAE-B404-4797-91BB-0C694C76B63B@xittel.net> Date: Sun, 9 Aug 2009 10:01:22 +0300 Message-ID: <011801ca18bf$34a502d0$be5ca20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <826C0AAE-B404-4797-91BB-0C694C76B63B@xittel.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoYhoFzhkd4/pQmRaS7iZg4WuT51wAOC2fw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Ecrit] Location Determination Platforms in DSL wholesale inCanada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 07:05:26 -0000 Hi Francois, >Q. is HELD meant to be used as a PIDF-LO carrying protocol >between two LISes and is there any standards track work done >at the IETF to make this happen? A: The LIS-to-LIS communication is provided by the usage of http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions -09.txt http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-04 For a bit more background there is another document: http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp-00 Ciao Hannes > >F. > >On 8-Aug-09, at 7:20 PM, Winterbottom, James wrote: > >> Francois, >> >> Why do you think that this mailing list has any more insight >into this >> than you do? >> Why don't you simply ask the ILECs what they mean? >> >> Regards >> James >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org on behalf of Francois Menard >> Sent: Sat 8/8/2009 10:39 AM >> To: ecrit >> Subject: [Ecrit] Location Determination Platforms in DSL >wholesale in >> Canada >> >> >> In yesterday's submission to the CRTC, the ILECs have submitted the >> following: >> >> --- >> For wholesale, the ILEC LDP will interact with the Wholesale ISP by >> responding to HELD location requests at the IP address >assignment time >> by the Wholesale ISP. >> >> The Wholesale ISP will be responsible to update the ILEC LIS >> accordingly and in a timely fashion. >> ---- >> >> This language is very confusing to me. >> >> Does this mean that we are enabling LIS to LIS >communications via HELD >> ? >> >> Question to the group: >> >> 1) What forms the query of the ISP into the ILEC LDP? >> >> 2) What forms the response of the ILEC LDP to the Wholesale >ISP inside >> the HELD location request? >> >> 3) What forms the push update of the Wholesale ISP into the ILEC LIS? >> >> I have my suspicion that the ILEC has just devised a PIDF-LO >carrying >> protocol in the form of HELD based on a L2TP AAA data >atypical of DSL >> wholesale. >> >> Your enlightments will be great as the ILEC submission is mute on >> this. >> >> F. >> >> -- >> Francois Menard >> fmenard@xittel.net >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >Francois Menard >fmenard@xittel.net > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From fmenard@xittel.net Sun Aug 9 06:48:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808493A69D7; Sun, 9 Aug 2009 06:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 Vhmct2iMPUSo; Sun, 9 Aug 2009 06:48:11 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id E3EFB3A69B4; Sun, 9 Aug 2009 06:48:10 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1Ma8kv-0001X8-5x; Sun, 09 Aug 2009 09:48:13 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1Ma8kv-0001Af-94; Sun, 09 Aug 2009 09:48:13 -0400 From: Francois Menard To: Hannes Tschofenig In-Reply-To: <011801ca18bf$34a502d0$be5ca20a@nsnintra.net> X-Priority: 1 References: <36E6ED93-ACE3-4AD2-A7FF-ACF11D5D5007@xittel.net> <826C0AAE-B404-4797-91BB-0C694C76B63B@xittel.net> <011801ca18bf$34a502d0$be5ca20a@nsnintra.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 9 Aug 2009 09:48:12 -0400 X-Mailer: Apple Mail (2.935.3) Cc: geopriv@ietf.org, 'ecrit' Subject: Re: [Ecrit] Location Determination Platforms in DSL wholesale inCanada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 13:48:12 -0000 Hannes, thanks for the pointers. My assertion into my submission to our Canadian regulator, in my final concluding paragraph (of August 7), was: *********** CISP is Coalition of Internet Service Providers inc. (www.cfai-cisp.ca) 1. Finally, CISP submits that considering that the SIP location conveyance[1] standard draft is finally set to be forwarded for approval by the IESG in August 2009 as an IETF proposed standard, the widescale worldwide implementation is now guaranteed and known manufacturers of ATAs and SIP Phones in Canada are already working on its implementation. CISP submits that it will likely take less time to see wide scale roll out of SIP location conveyance than it will take for the Canadian industry to agree on ILEC hosted-LIS to ISP Location Determination platform specifications (and for which there are no standardization initiatives to begin with at this time). ************* So let's look at them one by one. 1) http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp-00 is dated November 9 2007 and which has expired on May 12, 2008. It does refer to draft-winterbottom-geopriv-lis2lis-req-00, which is not the latest version. 2) http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-04 This is standards track and expires on November 5 2009. This provides measurements data. The measurement data has to be provided by the ACCESS NETWORK PROVIDER to the Internet Service Provider in the context of WHOLESALE. My issue is the use of LIS to LIS in the CONVERSE DIRECTION, which is that of obtaining CIVIC However, this document also refers to: http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 dated November 19, 2007 and which has expired on May 22, 2008. Presumably, as this one goes forward, its reference to http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 will have to follow the same route than in raft-winterbottom- geopriv-held-identity-extensions-09 and get filtered out, for this not being an RFC. However http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 is is PRECISELY what I was trying to hunt down, insofar as whether the IETF had considered formalizing this LIS to LIS protocol. So we finally get to: 3) http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions-09 This document is standards-track and expires August 29, 2009. This document clearly shows as being the one that's closest to formalizing the use of HELD across INCUMBENT OPERATOR to COMPETITIVE ISP boundary I find this in section 1.1, which clearly points to the usage case we're considering here in Canada: *** A third party LR can be granted authorization to make requests for a given Target. In particular, network services can be permitted to retrieve location for a Device that is unable to acquire location information for itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This allows use of location-dependent applications--particularly essential services like emergency calling--where Devices do not support a location configuration protocol (LCP) or they are unable to successfully retrieve location information. *** However the problem is this is a PULL MODEL, and rather what we want here is a PUSH MODEL, where the ISP who operates a LOCATION DETERMINATION PLATFORM, would PUSH into the ILEC LIS, a TUPLET of information in the form of LOCATION-URI and/or CIRCUIT-ID and/or CABLE MODEM MAC ADDRESS along with the CIVIC PIDF-LO OBJECT. So I do not find that http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions-09 clearly stipulates what the LIS-to-LIS protocol ought to be, for the aforementioned application. So basically, I feel that my assertion, as I have filed it to the regulator is correct. There is no current standards-track initiative in the IETF to specific a protocol for LIS to LIS communications, which is what our incumbent telephone operators in Canada are trying to push for. This is a significant problem, which will need to be formally adressed by GEOPRIV. So a question to the group: Would the specification of HELD as a PUSH protocol to send PIDF-LO updates to a LOCATION INFORMATION SERVER in the context of an ISP LIS pushing this into an EMERGENCY SERVICE PROVIDER LIS, be welcomed by the group? I will further assert that http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 DID not anticipate the notion of providing LOCATION UPDATES, which are much more akin to PRESENCE I also find the notion of location updates to be referred to in 4) http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-04 This is also standards track. I find from the various versions of that document, that the notion of LOCATION UPDATES has washed out. So my conclusion, is that the Canadian ILEC proposed solution requires use of somekind of LIS UPDATE PUSH PROTOCOL which would probably be provisioned with a LOCATION URI computed by the ISP and a PIDF-LO provided by the ISP. And that one does not exist yet. Is developing one welcomed? I look for the feedback from the group, as in Canada, we have tremendous pressure from the regulator to make this work. However, the problem I see which is the biggest one, is not technical at all, and lies in the fact that being the Emergency Service Provider, the ILECs in Canada have the ability to monitor the entire competitive industry if they are getting Location Updates for all current broadband accesses of all competitors. This is why I favour the concept of SIPCORE PIDF-LO LOCATION CONVEYANCE, at the TIME of an emergency call, END-to-END, where the first end is the residential subscriber and the other end, is the ILEC which is OPERATING the Emergency Service Routing Proxy / Media Gateway (which in Canada, will not be on the Internet, but rather over an MPLS/ VPN private route to the ILEC and will more than likely require the Voice over IP service provider to implement a session border controller with media proxy). F. On 9-Aug-09, at 3:01 AM, Hannes Tschofenig wrote: > Hi Francois, > >> Q. is HELD meant to be used as a PIDF-LO carrying protocol >> between two LISes and is there any standards track work done >> at the IETF to make this happen? > > A: The LIS-to-LIS communication is provided by the usage of > http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions > -09.txt > http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-04 > > For a bit more background there is another document: > http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp-00 > > Ciao > Hannes > >> >> F. >> >> On 8-Aug-09, at 7:20 PM, Winterbottom, James wrote: >> >>> Francois, >>> >>> Why do you think that this mailing list has any more insight >> into this >>> than you do? >>> Why don't you simply ask the ILECs what they mean? >>> >>> Regards >>> James >>> >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org on behalf of Francois Menard >>> Sent: Sat 8/8/2009 10:39 AM >>> To: ecrit >>> Subject: [Ecrit] Location Determination Platforms in DSL >> wholesale in >>> Canada >>> >>> >>> In yesterday's submission to the CRTC, the ILECs have submitted the >>> following: >>> >>> --- >>> For wholesale, the ILEC LDP will interact with the Wholesale ISP by >>> responding to HELD location requests at the IP address >> assignment time >>> by the Wholesale ISP. >>> >>> The Wholesale ISP will be responsible to update the ILEC LIS >>> accordingly and in a timely fashion. >>> ---- >>> >>> This language is very confusing to me. >>> >>> Does this mean that we are enabling LIS to LIS >> communications via HELD >>> ? >>> >>> Question to the group: >>> >>> 1) What forms the query of the ISP into the ILEC LDP? >>> >>> 2) What forms the response of the ILEC LDP to the Wholesale >> ISP inside >>> the HELD location request? >>> >>> 3) What forms the push update of the Wholesale ISP into the ILEC >>> LIS? >>> >>> I have my suspicion that the ILEC has just devised a PIDF-LO >> carrying >>> protocol in the form of HELD based on a L2TP AAA data >> atypical of DSL >>> wholesale. >>> >>> Your enlightments will be great as the ILEC submission is mute on >>> this. >>> >>> F. >>> >>> -- >>> Francois Menard >>> fmenard@xittel.net >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> Francois Menard >> fmenard@xittel.net >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > Francois Menard fmenard@xittel.net From fmenard@xittelecom.com Sun Aug 9 06:48:35 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458483A6BE0; Sun, 9 Aug 2009 06:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgqAgUzO3yLA; Sun, 9 Aug 2009 06:48:34 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id D80C83A6BE9; Sun, 9 Aug 2009 06:48:33 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1Ma8lI-0001Yw-RP; Sun, 09 Aug 2009 09:48:37 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1Ma8lJ-0001Af-2f; Sun, 09 Aug 2009 09:48:37 -0400 From: Francois Menard To: Hannes Tschofenig In-Reply-To: <011801ca18bf$34a502d0$be5ca20a@nsnintra.net> X-Priority: 1 References: <36E6ED93-ACE3-4AD2-A7FF-ACF11D5D5007@xittel.net> <826C0AAE-B404-4797-91BB-0C694C76B63B@xittel.net> <011801ca18bf$34a502d0$be5ca20a@nsnintra.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 9 Aug 2009 09:48:36 -0400 X-Mailer: Apple Mail (2.935.3) Cc: geopriv@ietf.org, 'ecrit' Subject: Re: [Ecrit] Location Determination Platforms in DSL wholesale inCanada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 13:48:35 -0000 Hannes, thanks for the pointers. My assertion into my submission to our Canadian regulator, in my final concluding paragraph (of August 7), was: *********** CISP is Coalition of Internet Service Providers inc. (www.cfai-cisp.ca) 1. Finally, CISP submits that considering that the SIP location conveyance[1] standard draft is finally set to be forwarded for approval by the IESG in August 2009 as an IETF proposed standard, the widescale worldwide implementation is now guaranteed and known manufacturers of ATAs and SIP Phones in Canada are already working on its implementation. CISP submits that it will likely take less time to see wide scale roll out of SIP location conveyance than it will take for the Canadian industry to agree on ILEC hosted-LIS to ISP Location Determination platform specifications (and for which there are no standardization initiatives to begin with at this time). ************* So let's look at them one by one. 1) http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp-00 is dated November 9 2007 and which has expired on May 12, 2008. It does refer to draft-winterbottom-geopriv-lis2lis-req-00, which is not the latest version. 2) http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-04 This is standards track and expires on November 5 2009. This provides measurements data. The measurement data has to be provided by the ACCESS NETWORK PROVIDER to the Internet Service Provider in the context of WHOLESALE. My issue is the use of LIS to LIS in the CONVERSE DIRECTION, which is that of obtaining CIVIC However, this document also refers to: http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 dated November 19, 2007 and which has expired on May 22, 2008. Presumably, as this one goes forward, its reference to http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 will have to follow the same route than in raft-winterbottom- geopriv-held-identity-extensions-09 and get filtered out, for this not being an RFC. However http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 is is PRECISELY what I was trying to hunt down, insofar as whether the IETF had considered formalizing this LIS to LIS protocol. So we finally get to: 3) http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions-09 This document is standards-track and expires August 29, 2009. This document clearly shows as being the one that's closest to formalizing the use of HELD across INCUMBENT OPERATOR to COMPETITIVE ISP boundary I find this in section 1.1, which clearly points to the usage case we're considering here in Canada: *** A third party LR can be granted authorization to make requests for a given Target. In particular, network services can be permitted to retrieve location for a Device that is unable to acquire location information for itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This allows use of location-dependent applications--particularly essential services like emergency calling--where Devices do not support a location configuration protocol (LCP) or they are unable to successfully retrieve location information. *** However the problem is this is a PULL MODEL, and rather what we want here is a PUSH MODEL, where the ISP who operates a LOCATION DETERMINATION PLATFORM, would PUSH into the ILEC LIS, a TUPLET of information in the form of LOCATION-URI and/or CIRCUIT-ID and/or CABLE MODEM MAC ADDRESS along with the CIVIC PIDF-LO OBJECT. So I do not find that http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions-09 clearly stipulates what the LIS-to-LIS protocol ought to be, for the aforementioned application. So basically, I feel that my assertion, as I have filed it to the regulator is correct. There is no current standards-track initiative in the IETF to specific a protocol for LIS to LIS communications, which is what our incumbent telephone operators in Canada are trying to push for. This is a significant problem, which will need to be formally adressed by GEOPRIV. So a question to the group: Would the specification of HELD as a PUSH protocol to send PIDF-LO updates to a LOCATION INFORMATION SERVER in the context of an ISP LIS pushing this into an EMERGENCY SERVICE PROVIDER LIS, be welcomed by the group? I will further assert that http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 DID not anticipate the notion of providing LOCATION UPDATES, which are much more akin to PRESENCE I also find the notion of location updates to be referred to in 4) http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-04 This is also standards track. I find from the various versions of that document, that the notion of LOCATION UPDATES has washed out. So my conclusion, is that the Canadian ILEC proposed solution requires use of somekind of LIS UPDATE PUSH PROTOCOL which would probably be provisioned with a LOCATION URI computed by the ISP and a PIDF-LO provided by the ISP. And that one does not exist yet. Is developing one welcomed? I look for the feedback from the group, as in Canada, we have tremendous pressure from the regulator to make this work. However, the problem I see which is the biggest one, is not technical at all, and lies in the fact that being the Emergency Service Provider, the ILECs in Canada have the ability to monitor the entire competitive industry if they are getting Location Updates for all current broadband accesses of all competitors. This is why I favour the concept of SIPCORE PIDF-LO LOCATION CONVEYANCE, at the TIME of an emergency call, END-to-END, where the first end is the residential subscriber and the other end, is the ILEC which is OPERATING the Emergency Service Routing Proxy / Media Gateway (which in Canada, will not be on the Internet, but rather over an MPLS/ VPN private route to the ILEC and will more than likely require the Voice over IP service provider to implement a session border controller with media proxy). F. On 9-Aug-09, at 3:01 AM, Hannes Tschofenig wrote: > Hi Francois, > >> Q. is HELD meant to be used as a PIDF-LO carrying protocol >> between two LISes and is there any standards track work done >> at the IETF to make this happen? > > A: The LIS-to-LIS communication is provided by the usage of > http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions > -09.txt > http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-04 > > For a bit more background there is another document: > http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp-00 > > Ciao > Hannes > >> >> F. >> >> On 8-Aug-09, at 7:20 PM, Winterbottom, James wrote: >> >>> Francois, >>> >>> Why do you think that this mailing list has any more insight >> into this >>> than you do? >>> Why don't you simply ask the ILECs what they mean? >>> >>> Regards >>> James >>> >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org on behalf of Francois Menard >>> Sent: Sat 8/8/2009 10:39 AM >>> To: ecrit >>> Subject: [Ecrit] Location Determination Platforms in DSL >> wholesale in >>> Canada >>> >>> >>> In yesterday's submission to the CRTC, the ILECs have submitted the >>> following: >>> >>> --- >>> For wholesale, the ILEC LDP will interact with the Wholesale ISP by >>> responding to HELD location requests at the IP address >> assignment time >>> by the Wholesale ISP. >>> >>> The Wholesale ISP will be responsible to update the ILEC LIS >>> accordingly and in a timely fashion. >>> ---- >>> >>> This language is very confusing to me. >>> >>> Does this mean that we are enabling LIS to LIS >> communications via HELD >>> ? >>> >>> Question to the group: >>> >>> 1) What forms the query of the ISP into the ILEC LDP? >>> >>> 2) What forms the response of the ILEC LDP to the Wholesale >> ISP inside >>> the HELD location request? >>> >>> 3) What forms the push update of the Wholesale ISP into the ILEC >>> LIS? >>> >>> I have my suspicion that the ILEC has just devised a PIDF-LO >> carrying >>> protocol in the form of HELD based on a L2TP AAA data >> atypical of DSL >>> wholesale. >>> >>> Your enlightments will be great as the ILEC submission is mute on >>> this. >>> >>> F. >>> >>> -- >>> Francois Menard >>> fmenard@xittel.net >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> Francois Menard >> fmenard@xittel.net >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > Francois Menard fmenard@xittel.net Francois Menard fmenard@xittel.net From khwolf1@gmail.com Mon Aug 10 02:49:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9210A3A68EC for ; Mon, 10 Aug 2009 02:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cav+3mZuFi6F for ; Mon, 10 Aug 2009 02:49:25 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 2B61B3A6876 for ; Mon, 10 Aug 2009 02:49:25 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so388901fga.18 for ; Mon, 10 Aug 2009 02:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=05fErGtHaz5QvLrjFNgdle0eS8DztQ2uHGFCcirqxA4=; b=aN0KdyUd+ii3Z8EiF1PnezXtqV9TXxjHbmHnU9msJ5Epss63zmQTjrX74uKEuL4m4x OFQIIwse+0CKHHzxDTMemmEFWx4d46vds37WZ91lfYMD5p7hnfzHa/I93Fy9aknf04bY KfLeNBBkBgKjBgEDQt5qg5uJIcxshCP8MU278= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IHsycwBDm6rPKUjk49UbutgEbuF8esljk/Lbtr0V05TcBWp4118b0wPB31kvrZZJP5 Bq4/YNjgYR3nKBNMrUkBxoApRw4ECi3/kCQ6PBTcO6aH2Cr7L2LJq49rJaDNFDH4UWZi XUHY9xMGcLVcxrZzE+82ejrd8mVkePW20RBbI= MIME-Version: 1.0 Received: by 10.86.23.19 with SMTP id 19mr1396696fgw.50.1249897766187; Mon, 10 Aug 2009 02:49:26 -0700 (PDT) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> Date: Mon, 10 Aug 2009 11:49:26 +0200 Message-ID: From: Karl Heinz Wolf To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 09:49:26 -0000 Hannes, some time ago I asked you about lost-sync and the pushing of coverage regions up a tree. Pushing of coverage regions is mentioned in the introduction, but all the examples show complete mappings. So I wonder if you assume LoST URIs to be placed in the URI elements of the mappings to indicate that this is not a mapping but rather a coverage region in the boundary? cheers karl heinz On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > I asked Roger to submit the PROTO writeup for the LoST sync draft after w= e > got further confirmation from the implementers team. Then, Roger pointed = me > to the review by Richard and I have to say that I must have missed it. He= re > are Richards review comments: > > http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html > > My response is inline: > > I reviewed lost-sync-04 in order to update my earlier comments on -01. > This version is much improved from the previous versions in terms of > specificity (although it's still vague in places).=A0 It still seems to m= e > that there are a few layers of detail missing.=A0 Specific comments below= . > --Richard > > 1. The document describes transactions for requesting and delivering > mapping structures, but doesn't describe at all how these transactions > create a synchronization system.=A0 There is clearly some tracking of > state needed (especially for "pushMappings"), and the document is silent > on how this state is initially established and then maintained. > > [Hannes] I added text throught the document to address this comments. > In particular I point to the need to keep state and also to the fact > that the document relies on manual configuration for setting up the > "peering" between the two nodes. > > 2. In a similar vein, it would be helpful for this document to have some > discussion of how this synchronization system relates to others that are > out there (e.g., rsync).=A0 Since the name of the draft is > "synchronization", there should be some discussion of how bidirectional > sync is handled. > > [Hannes] We had a discussion about this topic at the interim meeting and > "downgraded" the document to an Experimental status to avoid having to > Analyse all available replication mechanisms. > > 3. It seems like there should really be only 3 message types here > instead of 4: (1) a "syncRequest" message sent from destination to > source (getMappingsRequest), (2) a "syncUpdate" message sent from source > to destination (getMappingsResponse =3D=3D pushMappingsRequest), and (3) = a > "syncResult" message sent from destination to source > (pushMappingsResponse).=A0 There can still be two types of transaction, > but they're determined by which type of message (syncRequest or > syncUpdate) is sent in the HTTP request. > > [Hannes] We got similar feedback from the implementers. However, in a > subsequent discussion with them it turned out that this change is > rather a matter of style than anything technical. A change in the > description along the lines as you suggested (and as they had suggested) > as well only impacts the writing style of the document and not really > the implementation as such. Hence, I left the document as is. > > 4. In a similar vein to 2 and 3, the use of "client" and "server" is > confusing.=A0 I would suggest using more appropriate names for these role= s > like "source" and "destination", along with some text that explains how > these roles map to HTTP roles in each type of transaction. > > [Hannes] I added text regarding the HTTP/HTTPs roles and changed the > terminology in the document to reflect the source / destination terminolo= gy. > I hope it improved readability. > > 5. My comment about the security considerations has not been addressed. > =A0The security considerations section is essentially a pointer to LoST, > but this protocol is only peripherally related to LoST (at a technical > level).=A0 Since it's about synchronization, I would expect this document > to note that the primary risk is the injection of false location > information (since the mappings themselves are public), which means that > the parties should use HTTPS to carry the XML, authenticate the source, > and use a ciphersuite that provides integrity protection to messages. > > [Hannes] You are certainly right with this comment. I changed the text. > > Here is the updated document: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.txt > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From Peter.Dawes@vodafone.com Mon Aug 10 03:35:37 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBAAD3A6DD4 for ; Mon, 10 Aug 2009 03:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awPQfEnfp+ip for ; Mon, 10 Aug 2009 03:35:36 -0700 (PDT) Received: from mailout06.vodafone.com (mailout06.vodafone.com [195.232.224.75]) by core3.amsl.com (Postfix) with ESMTP id 9AC9A3A6827 for ; Mon, 10 Aug 2009 03:35:35 -0700 (PDT) Received: from mailint06 (localhost [127.0.0.1]) by mailout06 (Postfix) with ESMTP id 622ED84686 for ; Mon, 10 Aug 2009 12:35:36 +0200 (CEST) Received: from avoexs01.internal.vodafone.com (unknown [145.230.4.134]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint06 (Postfix) with ESMTPS id 43F7A84426; Mon, 10 Aug 2009 12:35:36 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 12:35:37 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 12:35:37 +0200 Message-ID: In-Reply-To: <008401ca0ef9$80f18d40$82d4a7c0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] I-D Action:draft-ietf-ecrit-framework-10.txt Thread-Index: AcoO2aakInzg+9g0SmGaqhzQy8DJCQAH8EJAAqsWP7A= References: <20090727164501.BEB8828C0FF@core3.amsl.com> <008401ca0ef9$80f18d40$82d4a7c0$@net> From: "Dawes, Peter, VF-Group" To: "Brian Rosen" X-OriginalArrivalTime: 10 Aug 2009 10:35:37.0628 (UTC) FILETIME=[4CBE35C0:01CA19A6] Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 10:35:38 -0000 Hi Brian, Copied below is an e-mail I sent in April with comments and questions on draft-ietf-ecrit-framework-09.txt.=20 Peter Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distordedreference ------------------------------------------------------------------------ -------- To: "Gunnar Hellstrom" , , "Brian Rosen"
    =20 Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distordedreference=20 From: "Dawes, Peter, VF-Group" =20 Date: Thu, 2 Apr 2009 15:28:11 +0200=20 Delivered-to: ecrit at core3.amsl.com=20 In-reply-to: <003001c9afba$44702d70$211ea8c0 at GunnarH>=20 List-archive: =20 List-help: =20 List-id: =20 List-post: =20 List-subscribe: , =20 List-unsubscribe: , =20 Thread-index: AcmvLd81tlepZceYSYeGbih7J01RLgAhEWXwAPjl8JA=3D=20 Thread-topic: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distordedreference=20 ------------------------------------------------------------------------ -------- Hello Brian, I have been reading http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-09.txt to understand how it works, and I have some questions and comments about the draft text. I also spotted some editorial corrections, so I have put them at the bottom of this e-mail. Thanks for the very readable draft. Best Regards, Peter QUESTIONS/COMMENTS ------------------ [Page 2]/1. Terminology/"Location conveyance: Location conveyance delivers location information to another element." Is this 'location information' physical location or some other kind of location information? Also, maybe "to another element" should be deleted.=20 [Page 3]/2. Introduction "Such citizen/ visitor-to-authority calls can be distinguished from those that are created by responders (authority-to-authority) using public communications infrastructure often involving some kind of priority access as defined in Emergency Telecommunications Service (ETS) in IP Telephony [RFC4190]. They also can be distinguished from emergency warning systems that are authority-to-citizen." Does "can be distinguished" mean that by looking at the signalling you can tell whether the call is visitor-to-authority etc., or does it mean that the draft only applies to visitor-to-authority calls? [Page 6]/3. Overview of how emergency calls are placed " o The phone gets location via a Location Configuration Protocol (LCP), for example from the DHCP server in civic [RFC4776] and/or geo [RFC3825] forms, a HELD server" Should the ", a HELD server" be removed, or is a DHCP server also a HELD server? [Page 7]/3. Overview of how emergency calls are placed "o The phone obtains the local emergency dial string(s) from the LoST [RFC5222] server for its current location. It also receives and caches the PSAP URI obtained from the LoST server. . . . "o It refreshes its location via DHCP and updates the PSAP's URI by querying the LoST mapping server with its location." Does this mean that the dial strings and PSAP URI are initially pushed in some way from the LoST server, or does the phone query the LoST server in both cases? [Page 7]/3. Overview of how emergency calls are placed "o The proxy recognizes the call as an emergency call and routes the call using normal SIP routing mechanisms to the URI specified." Maybe this bullet should give a hint why the proxy needs to recognize the call as an emergency one. It could say "The proxy recognizes the call as an emergency call, e.g., to allow it to take remedial action if the phone location had not been included by the phone, and routes the call using normal SIP routing mechanisms to the URI specified." [Page 10]/3. Overview of how emergency calls are placed "A proxy in the PSAP chooses an available call taker and extends the call to its UA." Isn't this a function of a registrar and not a proxy? [Page 12]/5. Identifying an emergency call "For devices that are mobile or nomadic, an issue arises of whether the home or visited dial strings should be used. Many users would prefer that their home dialing sequences work no matter where they are. However, local laws and regulations may require that the visited dialing sequence(s) work. Therefore, the visited dial string must work. Devices may have a way to be configured or learn home dial strings." The last sentence doesn't seem to fit in with the rest of the paragraph. Is this paragraph making the point that a mobile or nomadic device must always query for the correct dial strings for its current location before making an emergency call? [Page 18]/6.3 Who adds location, endpoint or proxy "Proxy insertion of location complicates dial string recognition." I don't understand how Proxy insertion of location relates to dial string recognition. Should the sentence above be deleted?=20 [Page 26][Page 27]/8. Routing the call to the PSAP "There is no mechanism provided in [I-D.ietf-sip-location-conveyance] for a proxy to request the endpoint supply its location, because that would open the endpoint to an attack by any proxy on the path to get it to reveal location. The proxy can attempt to redirect a call to the service URN which, if the device recognizes the significance, would include location in the redirected call from the device." The paragraph above indicates that a proxy cannot request location from an endpoint, and then seems to describe a way to do it by redirecting the call to a service URN. Is this contradictory? [Page 27]/8. Routing the call to the PSAP "In order for the ESRP to route on media choice, the initial INVITE request has to supply an SDP offer." [Page 28]/9.2. SIP signaling requirements for User Agents "To enable media sensitive routing, the call should include an SDP offer." Enabling the ESRP to route on SDP seems to differ from normal SIP practice. I would have thought that using caller prefs only (e.g., audio, video) is normal. Also, since the ESRP doesn't know what the terminating end of the call will answer in terms of SDP, I would have thought that routing on the SDP in the offer might choose the wrong destination. [Page 28]/9.3. SIP signaling requirements for proxy servers "They should recognize emergency dial strings, inserting the Route header with the appropriate service URN." "They should query LoST with the location and put the resulting URI in the Request URI." I think that 9.3 has URN and URI the wrong way around. The PSAP URI goes in the Route header field and the service URN goes in the request URI.=20 GENERAL ------- The draft uses "end system" and "endpoint" in various locations, would it be better to use endpoint throughout? RFC3261 always says "header field" (e.g., "Via header field") and not just "header".=20 =20 EDITORIALS ---------- [Page 2]/1. Terminology/"Nomadic device (user): A nomadic user agent is connected to the network temporarily, for relatively short durations, but does not move significantly during the during the emergency call. Examples include a laptop using an IEEE 802.11 hotspot or a desk IP phone that is moved occasionally from one cubicle to another." "during the" is repeated. [Page 3]/1. Terminology/"RoutinglLocation: The routing location of a device is used for routing an emergency call and may not be as precise as the Dispatch Location." Space needed in "RoutinglLocation": [Page 3]/2. Introduction/"This document discusses how end device and applications create emergency calls," "device" should be "devices" [Page 14]/6.1. Types of location information "Jurisdictional refers to a civic location using actual political subdivisions, especially for the community name. Postal refers to a civic location for mail delivery." Needs colon after Jurisdictional and Postal. [Page 19]/6.4. Location and references to location "When location is transmitted by value, the location information is available to entity in the call path." "entity" should be "entities" [Page 20]/6.5 End system location configuration "Normally, mobile devices will acquire its location at call time for use in an emergency call routing. See Section 6.8 for a further discussion on location updates for dispatch location." "mobile devices" should be "a mobile device" [page 29]/11. Mid-call behavior "Therefore a PSAP may need to a REFER request [RFC3515] a call to a bridge for conferencing." should say "Therefore a PSAP may need to send a REFER request [RFC3515] to redirect a call to a bridge for conferencing." Also, "Requiring UI manipulation..." should say "Requiring URI manipulation..." [Page 30]/12. Call termination "i.e with a BYE request." should be "i.e., with a BYE request." [Page 31]/15. Testing "<> includes a description of an automated test procedure that validates routing, signaling and media path continuity." Is something missing from inside the "<>"?=20 -----Original Message----- From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of Gunnar Hellstrom Sent: 28 March 2009 15:31 To: ecrit at ietf.org; Brian Rosen Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distordedreference Brian, A minor editorial: I noticed that the reference to RFC 4103 in section 9.1 was distorded in editing. It looks like this now:=20 xref target=3D"RFC4103"/> It should look like this: [RFC4103] /Gunnar -----Original Message----- From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of Internet-Drafts at ietf.org Sent: Friday, March 27, 2009 11:45 PM To: i-d-announce at ietf.org Cc: ecrit at ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-09.txt Pages : 37 Date : 2009-03-27 The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit at ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ -------- References:=20 Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distorded reference=20 From: Gunnar Hellstrom Prev by Date: Re: [Ecrit] Use of SIPPING config framework for configuring location=20 Next by Date: Re: [Ecrit] Use of SIPPING config framework for configuring location=20 Previous by thread: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distorded reference=20 Next by thread: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-09.txt=20 Index(es):=20 Date=20 Thread =20 =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 27 July 2009 21:33 To: Internet-Drafts@ietf.org; i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-10.txt This update fixes idnits, and that is it. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Monday, July 27, 2009 12:45 PM > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-10.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Emergency Context Resolution with=20 > Internet Technologies Working Group of the IETF. >=20 >=20 > Title : Framework for Emergency Calling using Internet > Multimedia > Author(s) : B. Rosen, et al. > Filename : draft-ietf-ecrit-framework-10.txt > Pages : 37 > Date : 2009-07-27 >=20 > The IETF has standardized various aspects of placing emergency calls. > This document describes how all of those component parts are used to=20 > support emergency calls from citizens and visitors to authorities. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-10.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From drage@alcatel-lucent.com Mon Aug 10 04:43:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D826428C0EC for ; Mon, 10 Aug 2009 04:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 hV90cstEVBmI for ; Mon, 10 Aug 2009 04:42:51 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id BF4B63A6E3C for ; Mon, 10 Aug 2009 04:42:48 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n7ABg7gF032048 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Aug 2009 13:42:45 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 10 Aug 2009 13:40:56 +0200 From: "DRAGE, Keith (Keith)" To: "Dawson, Martin" , Marc Linsner , "Gabor.Bajko@nokia.com" , "ecrit@ietf.org" Date: Mon, 10 Aug 2009 13:40:55 +0200 Thread-Topic: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42AAJDiUoAAA+bkAAAFk66wAL5PVgAAdLrWgADhg5/A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE208700319FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 11:43:02 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE208700319FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Who knows what regulation. But the standard goes straight to a normative requirement to process a requ= est as an emergency call and route to an E-CSCF without any other option wh= en an emergency call is detected, so conformance to something claiming to b= e IMS is impossible without it. As for VOIP, the UE requirements require an INVITE with voice as the only t= ype of emergency call generated. The network processes all requests, e.g. I= NVITE, MESSAGE, or whatever, as an emergency call if so recognised. It is u= p to the PSAP to reject the ones it cannot handle (or the MGCF if the PSAP = is CS connected). regards Keith ________________________________ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Friday, August 07, 2009 9:09 AM To: DRAGE, Keith (Keith); Marc Linsner; Gabor.Bajko@nokia.com; ecrit@ietf.o= rg Subject: RE: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP h= um Thanks Keith, WRT: Where IMS is supported, there is also a requirement to support emergency ca= lling on IMS. Can you elaborate please? Where is this requirement applicable and by what = legislation/docket? I=92m assuming you=92d agree that IMS is in fact VoIP = =96 but I probably shouldn=92t. Cheers, Martin ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= RAGE, Keith (Keith) Sent: Friday, 7 August 2009 5:36 PM To: Marc Linsner; Gabor.Bajko@nokia.com; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP h= um Obviously mandates differ between different parts of the world, but certain= ly any wireless operator (2G or 3G) is currently required by the 3GPP stand= ards, reflecting national regulation, to provide ermegency calling where th= ey provide CS voice service on their networks. Where IMS is supported, there is also a requirement to support emergency ca= lling on IMS. For the deployments where an operator is providing LTE in an area not cover= ed by 2G or 3G service, there are indications prior to the network selectio= n to enable determination of whether an emergency call is possible over IMS= or not. What this essentially boils down to is that if you have an contract with a = 3G operator to give you voice service, then emergency calls will work on th= at phone, because the network operator is required to support it. That appl= ies whether there is an internet browser on the phone or not. As far as I know there is currently no mandate on any ISP or indeed interne= t VOIP provider to support emergency calls. That may come in the future, bu= t so far I have seen no evidence of it. So writing a document that claims that some other mechanism is the way to o= ffer emergency calls, and then shouting from the rooftops that this applies= to mobile phones, is more likely to result in deaths than not. regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Wednesday, August 05, 2009 8:30 PM To: Gabor.Bajko@nokia.com; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP h= um Gabor, But reliability and mobility were the main architectural design ch= oices in 3GPP. That is why they ended up with that complex architecture! T= he procedures themselves are a consequence of the architecture. Carriers plan to switch emergency call handling from CS to PS domain, and = they wanted a network controlled ES, they did not want to rely on the hand= set doing the whole procedure because of the liability. Support for emerge= ncy calls is not a revenue generator for carriers, they'd be happy leaving= the tasks up to the client if there were no consequences of emergency cal= ls failing for whatever reason. And just to answer James point, ISPs offering broadband internet service c= an not be paralelled with carriers operating networks using 3GPP standards= . The ISPs do not commit to offer you service with less than a few minutes= outage per year, they provide no mobility and they are not mandated to su= pport emergency services. - gabor [Marc] Are you implying that 3GPP carriers operating a packet voice service= have a different mandate for supporting emergency services than an OTT pro= vider that sells packet voice services? (my understanding, which could be = wrong, is that VoIP is VoIP no matter who is the SP) Or is this a 3GPP self-inflicted mandate that is trying to emulate 2G circu= it-switched services? -Marc- ---------------------------------------------------------------------------= --------------------- 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] --_000_EDC0A1AE77C57744B664A310A0B23AE208700319FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: ECRIT/IMS - independent discussion from the PhoneBCP hum</TITLE= > <META http-equiv=3DContent-Type content=3D"text/html; charset=3DWindows-125= 2"> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Batang; } @font-face { font-family: Tahoma; } @font-face { font-family: Calibri; } @font-face { font-family: @Batang; } @page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt;= } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } SPAN.EmailStyle17 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-AU vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Who knows what regulation.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>But the standard goes straight to a normative requ= irement=20 to process a request as an emergency call and route to an E-CSCF without an= y=20 other option when an emergency call is detected, so conformance to somethin= g=20 claiming to be IMS is impossible without it.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>As for VOIP, the UE requirements require an INVITE= with=20 voice as the only type of emergency call generated. The network processes a= ll=20 requests, e.g. INVITE, MESSAGE, or whatever, as an emergency call if s= o=20 recognised. It is up to the PSAP to reject the ones it cannot handle (or th= e=20 MGCF if the PSAP is CS connected).</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>regards</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D203000211-08082009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Keith</FONT></SPAN></DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Dawson, Martin=20 [mailto:Martin.Dawson@andrew.com] <BR><B>Sent:</B> Friday, August 07, 200= 9=20 9:09 AM<BR><B>To:</B> DRAGE, Keith (Keith); Marc Linsner;=20 Gabor.Bajko@nokia.com; ecrit@ietf.org<BR><B>Subject:</B> RE: [Ecrit] ECRI= T/IMS=20 - independent discussion from the PhoneBCP hum<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks=20 Keith,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o= :p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">WRT:<o:p></o:p= ></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Where IMS is=20 supported, there is also a requirement to support emergency calling on=20 IMS.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o= :p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Can you elabor= ate=20 please? Where is this requirement applicable and by what legislation/dock= et?=20 I=92m assuming you=92d agree that IMS is in fact VoIP =96 but I probably= =20 shouldn=92t.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o= :p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Cheers,<o:p></= o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Martin<o:p></o= :p></SPAN></FONT></P> <DIV> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT= =20 face=3D"Times New Roman" size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE: = 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</= SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] <B><SPAN style=3D"FONT-WEIGHT: bold">On B= ehalf=20 Of </SPAN></B>DRAGE, Keith (Keith)<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, 7 August 2009 5:36=20 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Marc Linsner;=20 Gabor.Bajko@nokia.com; ecrit@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [Ecrit] ECRIT/IMS -=20 independent discussion from the PhoneBCP hum</SPAN></FONT><SPAN=20 lang=3DEN-US><o:p></o:p></SPAN></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Obviously mand= ates=20 differ between different parts of the world, but certainly any wireless=20 operator (2G or 3G) is currently required by the 3GPP standards, reflecti= ng=20 national regulation, to provide ermegency calling where they provide CS v= oice=20 service on their networks.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Where IMS is=20 supported, there is also a requirement to support emergency calling on=20 IMS.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">For the deploy= ments=20 where an operator is providing LTE in an area not covered by 2G or 3G ser= vice,=20 there are indications prior to the network selection to enable determinat= ion=20 of whether an emergency call is possible over IMS or=20 not.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">What this esse= ntially=20 boils down to is that if you have an contract with a 3G operator to give = you=20 voice service, then emergency calls will work on that phone, because the= =20 network operator is required to support it. That applies whether there is= an=20 internet browser on the phone or not.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">As far as I kn= ow=20 there is currently no mandate on any ISP or indeed internet VOIP provider= to=20 support emergency calls. That may come in the future, but so far I have s= een=20 no evidence of it. </SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">So writing a d= ocument=20 that claims that some other mechanism is the way to offer emergency calls= , and=20 then shouting from the rooftops that this applies to mobile phones, is mo= re=20 likely to result in deaths than not. </SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">regards</SPAN>= </FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Keith</SPAN></= FONT><o:p></o:p></P> <BLOCKQUOTE=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: mediu= m none; PADDING-LEFT: 2pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt 2.3pt; = BORDER-LEFT: blue 1pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FON= T=20 face=3D"Times New Roman" size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE= : 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT face=3DTaho= ma=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:= </SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> ecrit-bounces@ietf.org= =20 [mailto:ecrit-bounces@ietf.org] <B><SPAN style=3D"FONT-WEIGHT: bold">On= Behalf=20 Of </SPAN></B>Marc Linsner<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, August 05, 2009= 8:30=20 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20 Gabor.Bajko@nokia.com; ecrit@ietf.org<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [Ecrit] ECRIT/IMS -= =20 independent discussion from the PhoneBCP hum</SPAN></FONT><SPAN=20 lang=3DEN-US><o:p></o:p></SPAN></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT face=3DCalibri= =20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri">Gabor,</SPAN></FONT><o:= p></o:p></P> <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"> <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT face=3D"Co= urier New"=20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><BR></SPAN></= FONT><FONT=20 face=3DCalibri size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri"><BR></SPAN></FONT><= B><U><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"><Gabor>=20 But reliability and mobility were  the main architectural desi= gn=20 choices in 3GPP. That is why they ended up  with that complex= =20 architecture! The procedures themselves are a consequence  of = the=20 architecture.<BR></SPAN></FONT></U></B><FONT face=3DCalibri size=3D= 2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri"><BR></SPAN></FONT><= B><U><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">Carriers=20 plan to switch emergency call handling  from CS to PS domain, = and=20 they wanted a network controlled ES, they did not  want to rel= y on=20 the handset doing the whole procedure because of the  liabilit= y.=20 Support for emergency calls is not a revenue generator  for=20 carriers, they'd be happy leaving the tasks up to the client if=20  there were no consequences of emergency calls failing for wha= tever=20  reason.<BR></SPAN></FONT></U></B><FONT face=3DCalibri size=3D= 2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri"><BR></SPAN></FONT><= B><U><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">And=20 just to answer James point, ISPs offering  broadband internet= =20 service can not be paralelled with carriers operating  network= s=20 using 3GPP standards. The ISPs do not commit to offer you service=20  with less than a few minutes outage per year, they provide no= =20 mobility and  they are not mandated to support emergency=20  services.<BR></SPAN></FONT></U></B><FONT face=3DCalibri size= =3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri"><BR></SPAN></FONT><= FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><BR></SPAN></= FONT><FONT=20 face=3DCalibri size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri"><BR></SPAN></FONT><= B><U><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">-=20 gabor<BR></SPAN></FONT></U></B><FONT face=3DCalibri size=3D2><SPAN= =20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri"><BR><BR>[Marc] Are = you=20 implying that 3GPP carriers operating a packet voice service have a= =20 different mandate for supporting emergency services than an OTT pro= vider=20 that sells packet voice services?  (my understanding, which co= uld=20 be wrong, is that VoIP is VoIP no matter who is the SP)<BR><BR>Or i= s=20 this a 3GPP self-inflicted mandate that is trying to emulate 2G=20 circuit-switched services?<BR><BR><BR>-Marc-<BR></SPAN></FONT><FONT= =20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><BR><BR></SPA= N></FONT><o:p></o:p></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></DIV><BR><B= R> <TABLE style=3D"COLOR: black" bgColor=3Dwhite> <TBODY> <TR> <TD><BR>-------------------------------------------------------------= -----------------------------------<BR>This message is for&n= bsp;the designated recipient only and may<BR>conta= in privileged, proprietary, or otherwise private&n= bsp;information.  <BR>If you have received it=  in error, please notify the sender<BR>immedi= ately and delete the original.  Any unau= thorized use of<BR>this email is prohibited.<BR>--= ---------------------------------------------------------------------------= -------------------<BR>[mf2]</TD></TR></TBODY></TABLE></BLOCKQUOTE></BODY><= /HTML> --_000_EDC0A1AE77C57744B664A310A0B23AE208700319FRMRSSXCHMBSC3d_-- From hannes.tschofenig@nsn.com Mon Aug 10 05:09:31 2009 Return-Path: <hannes.tschofenig@nsn.com> 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 29E933A6E2D for <ecrit@core3.amsl.com>; Mon, 10 Aug 2009 05:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, MANGLED_LOAN=2.3, 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 ytQwkbdRTvO1 for <ecrit@core3.amsl.com>; Mon, 10 Aug 2009 05:09:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 958813A6E0C for <ecrit@ietf.org>; Mon, 10 Aug 2009 05:09:29 -0700 (PDT) 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 n7AC9Us4022405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2009 14:09:30 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7AC9U0I022177; Mon, 10 Aug 2009 14:09:30 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 14:09:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 15:12:01 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> In-Reply-To: <f77644530908100249n42a2766pf181e69ca16d4260@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Sync Draft Update Thread-Index: AcoZn9oC1A6Mhef0RAWYfzox2uP/ewABwUag References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <f77644530908100249n42a2766pf181e69ca16d4260@mail.gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> To: "ext Karl Heinz Wolf" <khwolf1@gmail.com> X-OriginalArrivalTime: 10 Aug 2009 12:09:30.0493 (UTC) FILETIME=[6A3132D0:01CA19B3] Cc: ECRIT <ecrit@ietf.org> Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 10 Aug 2009 12:09:31 -0000 Hi Karl Heinz,=20 Hi all,=20 Thanks for this question.=20 To provide a bit of background to your question let us take an example = provided in=20 http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt On page 10 an example of mappings stored at a server are outlined:=20 country A1 A2 A3 resource or LoST server US NJ Bergen Leonia sip:psap@leonianj.gov US NJ Bergen Fort Lee sip:emergency@fortleenj.org US NJ Bergen Teaneck sip:police@teanecknjgov.org US NJ Bergen Englewood englewoodnj.gov In this case, the first three mappings point to PSAPs (or ESRPs; one = cannot differentiate based on the mapping data). The final mapping, = however, points to a LoST server.=20 So, <uri> element of the <mapping> element accepts only URIs. The output = of the U-NAPTR process (described in Section 4 of = http://www.ietf.org/rfc/rfc5222.txt) leads to a HTTP/HTTPS URI. So, the URI that is associated with the boundary is using a HTTP and = HTTPS URL scheme.=20 The input unfortunatley isn't; it is just a DNS name.=20 In earlier versions of the LoST specifications we defined a new URI = scheme (namely lost://) but later removed it. As such, there is no LoST = URI to put into the <uri> element.=20 So, do we have a problem here?=20 Ciao Hannes PS: I have to check what the implementers have implemented here.=20 >Hannes, > >some time ago I asked you about lost-sync and the pushing of=20 >coverage regions up a tree. >Pushing of coverage regions is mentioned in the introduction,=20 >but all the examples show complete mappings. >So I wonder if you assume LoST URIs to be placed in the URI=20 >elements of the mappings to indicate that this is not a=20 >mapping but rather a coverage region in the boundary? > >cheers >karl heinz > >On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN -=20 >FI/Espoo)<hannes.tschofenig@nsn.com> wrote: >> Hi all, >> >> I asked Roger to submit the PROTO writeup for the LoST sync draft=20 >> after we got further confirmation from the implementers team. Then,=20 >> Roger pointed me to the review by Richard and I have to say that I=20 >> must have missed it. Here are Richards review comments: >> >> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >> >> My response is inline: >> >> I reviewed lost-sync-04 in order to update my earlier=20 >comments on -01. >> This version is much improved from the previous versions in terms of=20 >> specificity (although it's still vague in places).=A0 It still=20 >seems to=20 >> me that there are a few layers of detail missing.=A0 Specific=20 >comments below. >> --Richard >> >> 1. The document describes transactions for requesting and delivering=20 >> mapping structures, but doesn't describe at all how these=20 >transactions=20 >> create a synchronization system.=A0 There is clearly some tracking of = >> state needed (especially for "pushMappings"), and the document is=20 >> silent on how this state is initially established and then=20 >maintained. >> >> [Hannes] I added text throught the document to address this comments. >> In particular I point to the need to keep state and also to the fact=20 >> that the document relies on manual configuration for setting up the=20 >> "peering" between the two nodes. >> >> 2. In a similar vein, it would be helpful for this document to have=20 >> some discussion of how this synchronization system relates to others=20 >> that are out there (e.g., rsync).=A0 Since the name of the draft is=20 >> "synchronization", there should be some discussion of how=20 >> bidirectional sync is handled. >> >> [Hannes] We had a discussion about this topic at the interim meeting=20 >> and "downgraded" the document to an Experimental status to avoid=20 >> having to Analyse all available replication mechanisms. >> >> 3. It seems like there should really be only 3 message types here=20 >> instead of 4: (1) a "syncRequest" message sent from destination to=20 >> source (getMappingsRequest), (2) a "syncUpdate" message sent from=20 >> source to destination (getMappingsResponse =3D=3D = pushMappingsRequest),=20 >> and (3) a "syncResult" message sent from destination to source=20 >> (pushMappingsResponse).=A0 There can still be two types of=20 >transaction,=20 >> but they're determined by which type of message (syncRequest or >> syncUpdate) is sent in the HTTP request. >> >> [Hannes] We got similar feedback from the implementers.=20 >However, in a=20 >> subsequent discussion with them it turned out that this change is=20 >> rather a matter of style than anything technical. A change in the=20 >> description along the lines as you suggested (and as they had=20 >> suggested) as well only impacts the writing style of the=20 >document and=20 >> not really the implementation as such. Hence, I left the=20 >document as is. >> >> 4. In a similar vein to 2 and 3, the use of "client" and "server" is=20 >> confusing.=A0 I would suggest using more appropriate names for these=20 >> roles like "source" and "destination", along with some text that=20 >> explains how these roles map to HTTP roles in each type of=20 >transaction. >> >> [Hannes] I added text regarding the HTTP/HTTPs roles and changed the=20 >> terminology in the document to reflect the source /=20 >destination terminology. >> I hope it improved readability. >> >> 5. My comment about the security considerations has not been=20 >addressed. >> =A0The security considerations section is essentially a=20 >pointer to LoST,=20 >> but this protocol is only peripherally related to LoST (at a=20 >technical=20 >> level).=A0 Since it's about synchronization, I would expect this=20 >> document to note that the primary risk is the injection of false=20 >> location information (since the mappings themselves are=20 >public), which=20 >> means that the parties should use HTTPS to carry the XML,=20 >authenticate=20 >> the source, and use a ciphersuite that provides integrity=20 >protection to messages. >> >> [Hannes] You are certainly right with this comment. I=20 >changed the text. >> >> Here is the updated document: >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.txt >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > From L.Liess@telekom.de Mon Aug 10 06:58:03 2009 Return-Path: <L.Liess@telekom.de> 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 7CAAB3A67B3 for <ecrit@core3.amsl.com>; Mon, 10 Aug 2009 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=-1.743, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ8Z92uCfTmG for <ecrit@core3.amsl.com>; Mon, 10 Aug 2009 06:57:59 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 4E82D3A6834 for <ecrit@ietf.org>; Mon, 10 Aug 2009 06:57:56 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 10 Aug 2009 15:57:50 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 15:57:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA19C2.8BD6414C" Date: Mon, 10 Aug 2009 15:57:49 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003480A25@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <046201ca1776$1a2bfa70$4e83ef50$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rAAA0M6gAACNUgwAAM0rIAAksimsA== References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <EB921991A86A974C80EAFA46AD428E1E063584A2@aopex4.andrew.com> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <EB921991A86A974C80EAFA46AD428E1E063B9A43@aopex4.andrew.com> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <042001ca175f$a92e0d60$fb8a2820$@net> <40FB0FFB97588246A1BEFB05759DC8A00348055D@S4DE9JSAANI.ost.t-com.de> <046201ca1776$1a2bfa70$4e83ef50$@net> From: <L.Liess@telekom.de> To: <br@brianrosen.net>, <Martin.Dawson@andrew.com>, <R.Jesske@telekom.de>, <ecrit@ietf.org> X-OriginalArrivalTime: 10 Aug 2009 13:57:50.0583 (UTC) FILETIME=[8C8C3870:01CA19C2] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 10 Aug 2009 13:58:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA19C2.8BD6414C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, =20 My expectation was that framework and phonepcb contain enough options to = cover also short term scenarios and help us to implement VoIP emergency = calling now. This seems not to be the case. We can not require now from = our SIP-proxy vendors to comply with the framework and phone-pcb because = this does not work with the existing EDs. Currently, ECRIT does not = offer all components to build an EC architecture which works now. As a = result, DT and other carriers must build and require from their vendors = proprietary solutions which work now. =20 We can take the approach that Hannes describes and do it later, it's = better than not at all. However, when people already have proprietary = solutions in place, it is difficult change them. =20 Concerning the local dial string, we do not have currently any plans for = something different from 112 and the national EC dial string (110) or to = allow the nomadic usage of the VoIP service outside Germany.=20 =20 Laura =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, August 07, 2009 5:46 PM To: Liess, Laura; Martin.Dawson@andrew.com; Jesske, Roland; = ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =09 =09 Laura =20 I don't think we're going to get to the point where the IETF rolls back = -framework and -phonebcp far enough to suit you. The approach that = Hannes described, which is to finish the current work as is, and then go = back and see if we can standardize a way for VoIP services to connect to = older systems with more limited capabilities using OBO and other tricks, = makes some sense to me. =20 =20 However, device vendors have to build devices that work in countries = that are more aggressively upgrading their emergency systems, without = unduly burdening you. What I'm attempting to do is to figure out a way = that you can work with a -phonebcp compliant device, without incurring a = lot of cost. =20 We're not going to make it zero. =20 If you don't like a poly, return any street address in the area code. = In most cases, it could be a PIDF with a couple of A levels that works = for the town. =20 All that matters is that if a -phonebcp client queries an LCP, it = should get a location that, when passed to LoST, gets the right URI. If = the location is coarse, that is okay; it works. I'd like you to deploy = HELD and LoST servers in your networks that return the right thing to = the endpoint and not just to the OBO proxy, but even if you don't, = phonebcp compliant end devices will "work" in your network: their = attempts to reach LIS and LoST servers will fail, and they will send = emergency calls without location and PSAP URI, and your proxy can fill = in the right stuff. =20 You don't need -phonebcp compliant endpoints. Good for you. However, = vendors ought to make phonebcp compliant endpoints so that they work = everywhere. =20 If you want less that that, then I'm not sure IETF can oblige, since we = don't do nation specific solutions and some nations need the full = -phonebcp spec. =20 One complication you should consider: devices need to know the local = dial string(s) for emergency calls. In the IETF architecture, LoST = provides that. What were you planning on doing? =20 Brian =20 =20 From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, August 07, 2009 10:45 AM To: br@brianrosen.net; Martin.Dawson@andrew.com; R.Jesske@telekom.de; = ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Brian, =20 Please see comments inline. =20 =20 =20 =09 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, August 07, 2009 3:05 PM To: Liess, Laura; Martin.Dawson@andrew.com; Jesske, Roland; = ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP Actually, the PIDF-LO is designed to cater for all the variations in = addressing. You don't mean "location used for emergency calls", you = mean "key for location used for emergency calls". The area code is not = the location, it is a key that is mapped to PSAP URI.=20 [[LLi]] This is correct. =20 The telephone number (with its area code) is the identifier you = would use with HELD to get the location, from which LoST would get you = a PSAP URI. [[LLi]] Here we don't use the phone number. The proxy sends the = IP-address to the LIS. The LIS finds out the access hardware (DSLAM = port) corresponding to the IP-address and assigns a temporary string to = it (kind of LbyR). It also finds out the phone area code for this = hardware. With the phone area code, the LIS queries a table which = contains the phone area codes and the corresponding PSAP URI, then = delivers the the string (LbyR) and the PSAP-URI to the SIP proxy. The = SIP proxy routes the call and sends the LbyR to the PSAP. In very few = cases, PSAPs dereference the the LyBR to a civic address.=20 We do not have any kind of geo data or poligons in our database. In = principle we have the the civic address, but the access to this data is = quite slow. I think other fixed networks carriers here have more or = less the same.=20 =20 This seems trivial for you to implement: you deploy a HELD server that = takes telephone number and returns a polygon representing the area code = boundary, and you deploy a LoST server that takes that polygon and = returns the PSAP URI associated with it. =20 This would be no more expensive than what you are proposing. = Proxies could use this or phonebcp compatible endpoints could use it. =20 =20 NENA is planning on doing pretty much this same thing to handle legacy = wireline networks where telephone number is currently the key to the = location database (ALI). The LIS will store location as the key (using = held-identity), and a gateway will construct an LbyR from the phone = number. All the rest of the ecrit compatible infrastructure can then = use the Location URI to get location, route, etc. =20 Making what you now see as a one step mapping (area code to PSAP URI) = into a two step (telephone number to polygon, polygon to PSAP URI) is a = bit more complex, but not any significant difference in deployment. It = also works for wireless (cell sector/ID to polygon, polygon to PSAP = URI), and of course, would be upwardly compatible with real location = based routing, should your systems evolve as we expect they evolve, or = something like EU regulations compel more accurate location services. [[LLi]] Nobody here is willing to putting geodata or poligons into the = access databases. And we could avoid doing this just by allowing the = LIS to query the local LOST with the LbyR and to deliver the PSAP URI to = the SIP proxy. =20 =20 Kind regards Laura =20 Brian =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of L.Liess@telekom.de Sent: Friday, August 07, 2009 7:59 AM To: Martin.Dawson@andrew.com; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Hi Martin, =20 Hi Laura, =20 I regard it as a goal of ECRIT - as derived from the goals of the = IETF generally - to define a structure that will allow an Internet = capable device to connect to a network anywhere in the world and be able = to make emergency calls. Just as FTP, email protocols, SIP and etc. all = work regardless of which network the devices attach to. I don't = understand how the kind of variations that you are requesting be added = to the specification will allow that to occur. [[LLi]] This is fine and usefull. Just that every country uses today = different formats for the location used for emergency calls. Changing = this will take time and costs money.=20 What is the harm in allowing ECs to work with local location formats = which are understood only by the LIS and the PSAP ?. I dont see why a = common location format must be implemented by everybody.=20 Maybe the EC could work like this :=20 =B7 The proxy discovers the LIS based on EDs IP-address using = reverse-DNS and SRV record (this is possible with "identity = extenssions")=20 =B7 It retrieves the location ( e.g. using HELD) in a local = format understood only by the LIS and the PSAP, which are in the same = country. The location is just a string which is passed transparently = through the network to the PSAP. In my opinion, it would be in principle = posible to use LbyR to transport local location identidfiers, e. g. = area-code@lis.telekom.de , but this is currently my personal opinion, I = didn' found any statemant or example in the drafts. =20 =B7 The LIS delivers, together with the LbyR above, the PSAP = URI. As far as I know there is currently no way to do this in HELD (or = did I miss something?). =20 =20 It would be an alternative which is interoperable and quite easy to = implement, without the need for the operators to change their location = databases. I think by allowing this scenario, interoperable EC could be = achieved earlier. And this does not exclude the scenario described in = the framework and phone-bcp, where the EDs retrieve deo or civic = location, which is needed for EC to work in private/enterprise networks. = =20 =20 =20 =20 The position appears to be that the German regulator doesn't require = anything - and the operators will not be proactive in following a = specification if it doesn't include what already exists. In that = context, I don't understand why there is a need for the BCP at all. = There may be no need to endorse it but, similarly, there should be no = need to object to it - since the operators will only put in place their = preferred version of the service in any case.=20 [[LLi]] This is not quite true. We have to ensure that EC works for = different AN- and VoIP-provider and for nomadic users in Germany by = 2013. Our current solution does not allow this and there is the same for = other carriers. We definitively need to define in Germany an = architecture which fullfills this requirements. It would be very usefull = if we can use standard protocols. But nobody will be willing to change = everything at once. Having a standard based architecture which is low = cost would be a great advantage.=20 =20 Kind regards Laura =20 =20 That's OK... insofar as it just means German networks aren't ECRIT = compatible - "compatibility" isn't a worthy goal in and of itself; it = has to actually mean any device can work anywhere. =20 Cheers, Martin =20 ________________________________ From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: Friday, 7 August 2009 12:29 AM To: Dawson, Martin; R.Jesske@telekom.de; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 Hi Martin,=20 =20 See comments inline [[LLi]]. =20 =20 Laura From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Dawson, Martin Sent: Wednesday, August 05, 2009 11:00 AM To: Jesske, Roland; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP Hi Roland, =20 I think what you're saying is that you don't think that Germany will = go on to implement full ECRIT support but will peg development at an = interim phase.=20 [[LLi]] We don't know how the realtime application networks or EC = will look like in 20 years. Roland's answer only applies to the next 5 = to 10 years.=20 =20 That would be disappointing - not least because full ECRIT = compliance would ultimately decrease the overhead associated with = emergency service support for operators as well as providing a more = universal service. =09 [[LLi]] This may be true for "green field" ISPs and VSPs but not = for incumbent carriers with existing infrastructure. And universal = service is not a requirement for us. Neither the German regulator = requires it nor is it a busines case. =20 =20 Nevertheless, I don't think that decision invalidates the BCP;=20 [[LLi]] We think it does, because some of the requirements are not = flexible enough to cover the deployments within the next years. The BCP = should be more flexible: =20 =B7 Allow additional location identifiers =20 =B7 Allow AN operated LOST=20 =B7 Provide a way to enable LOST-query based on national or = domain-specific location identifier. One posiblility is to allow the LIS = to query the LOST , but there are also other alternatives. =20 =B7 Allow and describe also network-centric, not only = ED-centric architectures. If I remember correctly, John Medland from BT = also recomended to use a more network- centric architecture, at least = for the next years.=20 =20 I think it just means that the German regulator and technical = advisory committees would point out the subset aspects of compliance = that would be applicable to that jurisdiction. =20 [[LLi]] Again, the draft is not flexible enough for it. If the BCP = contains requirements which are not realistic, people will just discard = the BCP and implement proprietary stuff. My expectation from a standard = body is to define protocols and architecture which people are willing to = implement in their network or products , not only in the lab. =20 [[LLi]] =20 We are not against the draft in principle. ECRIT provides us with = very valuable specifications as LbyR, HELD, identity extensions. But = targeting an architecture which requires everbody to invest without a = business case will not help the draft in the end, also if it becomes a = BCP. It would make sense to make it more flexible so people are willing = to adopt it. =20 =20 Actually, based on your description below, the NENA i2 architecture = would probably be a more straightforward baseline for analysis - as has = been done in the UK and Canada. Of course, it's generally recognized as = only an interim step, even in those jurisdictions. Other comments below. =20 Cheers, Martin =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of R.Jesske@telekom.de Sent: Wednesday, 5 August 2009 6:19 PM To: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP =20 =20 Dear all,=20 We would like the document to become a BCP as soon as possible so = the group can move on with other documents related to emergency calling = based on location-by-reference and ED's IP-address.=20 [[MCD]] I think you might mean "identity extensions" rather than = location-by-reference because LbyR still requires the ED to obtain the = reference - e.g. by HELD. [[LLi]] We use both, the IP-address as UE identity and LbyR. The = SIP-proxy uses the IP-address to query the LIS using HTTP (it's not HELD = but SOAP over HTTP, but anyway similar). The LIS responds with a numeric = string associated to the caller location, in principle a LbyR and with = the PSAP number. The proxy inserts the LbyR into the SIP-message (as = P-Asserted-ID because the PSAPs are in PSTN) and routes the message to = the PSAP. It's a low cost solution.=20 But we can not HUM for the current form of the document.=20 Back to the document: Some requirements are far form being = realistic, at least in Germany, some are not realistic at all. = Implementing these requirements cost a carrier a lot of money and there = is no ROI for it.=20 Just a few examples:=20 =B7 Requiring either geo or civic location does not provide = carriers with enough flexibility to reuse their existing mechanisms and = location databases. Routing of emergency calls is currently done in = Germany based on phone area code not on geo or civic location, at least = for the fixed network. For mobile networks the cell-id is used in = common. This is regulated by the german regulator.=20 [[MCD]] How many unique PSAP routes are required in Germany? The US = has lots (6000 plus) and Australia has two (and they are redundant so it = doesn't matter which one). Presumably geographic information, for PSAP = catchment areas, is the basis for determining which area codes are = relevant to begin with? After all, an area code is not intrinsically = geographic; it's a network routing value. If so, then some geographic = discriminator is already in play in terms of constructing the area code = based routing data (something like zip codes perhaps?) - and in that = case, it should be straightforward to by-pass the area code step in the = construction of routing that goes the correct PSAP URI.=20 [[LLi]] Currently, fixed networks carriers in Germany route the ECs = based only on the caller's area code. Sometime in the past, the = carriers, the regulator and the PSAPs operators (police, the Red Cross) = agreed to do so. This may change in the future, but it will take a quite = long time. =20 With nomadic VoIP devices (and it's no good being in denial about = this being the norm in the future) area code is no more reliable than it = is for conventional mobile phones. And, presumably, area code is not = used for conventional cellular emergency call routing? [[LLi]] As far as I know, mobile networks use the Cell-ID, not the = area code, and have a different table than the fixed network operators. = They are not going to change this. As to the nomadic SIP-users...if we = like it or not, very few of our customers use our SIP service nomadic, = let alone call EC from their laptop. =20 1 LOST as a national, let alone as a global directory = is not going to be implemented. The regulator will provide in the web a = static table which contains the PSAPs and the area for which they are = responsible (one or more area codes). Every carrier has to implement its = own routing database for emergency calls.=20 [[MCD]] Whatever the carriers implement (and they have to implement = something) could just as readily be done using LoST. Then visiting = devices, with no association with any local VoIP proxy server would = still be able to determine a route to the correct PSAP. Alternatively, = as long as the regulator is maintaining a web service with the routing = information, why not make that directly accessible using LoST and save = the operators the cost of duplicating the service at all? [[LLi]] There is a big difference between maintaining a web page = with a table which operator can print and implement in their darabases = and operating a database which is queried for every emergency call in = Germany, must have an availablity of 99,99...% , is secure enough...you = know. The regulator will not do this. =09 2 We have no intention to rely on end devices for location = information because:=20 =B7 ED provided location info is not trusted=20 [[MCD]] Location by reference mitigates this trust issue. The = emergency network can (automatically and before human resources are = engaged) assess the source of the reference, and the validity of the = location by dereference, without having to trust location provided = directly from the ED. There are more sophisticated approaches to = trustability even using LbyV - based on digital signatures across = appropriate attributes. This WG and Geopriv haven't really got to grips = with that... yet. [[LLi]] We build the SIP-network and EC now. ED-provided location = is needed if EC must work for private and enterprise networks and VPNs. = We have no such regulatory requirements. And we don't know of any = verdor of DSL-EDs which provides today SIP with LbyR and is as cheap as = the devices without it. If you do, please let me know.=20 The regulator ask us to guarantee that EC works. What if a customer = dials 112 and his end device does not send the location? So I have to = implement both solutions, with and without ED provided location, anyway. = =20 1 There are already a lot of existing EDs in usage which don't = send location. =20 [[MCD]] Quite right. ECRIT doesn't overly concern itself with that = interim situation. The UK and Canadian definitions for an interim = solution (limiting service to in-country VoIP proxy operators) both = assume third-party query via identity-extension to allow the proxy or = the VPC to make the query to the LIS. This isn't extensible to universal = emergency service access by all visiting devices but it does put the = necessary LIS functionality in place as a very good starting point. It = would be a pity if Germany were to cease the evolution there as it would = not fulfil the real promise of the Internet and the ECRIT model.=20 [[LLi]] I wonder who will drive and pay for upgrading the interim = solutions. Unfortunatelly, it's all about money... Think about it; all the complexity of putting location = determination infrastructure in place for the purposes of dispatch is = done - and then the next, simpler step, of using that to support the = routing procedure isn't taken... that would be a waste. =09 [[LLi]] Do you think this is an argument for a product manager? = They need a business case. =20 =20 =20 We don't intend to require our ED-vendors to provide location = because it is useless to us. =20 We could agree with the document with following changes:=20 o Other location identifiers then geo or civil are allowed. It = must be possibe that the data foermat is flexible due to different = requirements from regulators over the whole world. (e.G Germany area = codes for fixed- and Cell-Id for moile- providers)=20 o The MUST for the end devices to support location information, = DHCP location options and HELD shall be removed=20 o It must be possible for the VoIP-provider's proxy to use a LOST = (or an ESRP) provided by the AN or by other local provider on behalf of = the AN. =20 =20 There is no value in Hum-ing documents which one is not going to = implement and does not fit into regulated schemes like in Germany. = Currently, neither the IETF- nor the 3GPP-architecture for emergency = calling covers our real needs for the next 2 to 5 years and in the end = everybody still has its own proprietary implementation. =20 Best regards=20 Roland=20 =20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de <mailto:r.jesske@telekom.de> =20 http://www.telekom.de <http://www.telekom.de/> =20 =20 Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), = Albert Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 =20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] =20 =20 -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] =20 ------_=_NextPart_001_01CA19C2.8BD6414C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:x =3D=20 "urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20 "urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20 "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20 "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20 "urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b = =3D=20 "urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20 "urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20 "urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20 "urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20 "http://www.w3.org/TR/REC-html40" xmlns:q =3D=20 "http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc =3D=20 "http://microsoft.com/officenet/conferencing" XMLNS:D =3D "DAV:" = XMLNS:Repl =3D=20 "http://schemas.microsoft.com/repl/" xmlns:mt =3D=20 "http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2 =3D=20 "http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda =3D=20 "http://www.passport.com/NameSpace.xsd" xmlns:ois =3D=20 "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20 "http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20 "http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20 "http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20 "http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20 "http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20 "http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec = =3D=20 "http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20 "http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20 "http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20 "http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs =3D=20 "http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf =3D=20 "http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p =3D=20 "http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf =3D=20 "http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss =3D=20 "http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi =3D=20 "http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi =3D=20 "http://schemas.openxmlformats.org/package/2006/digital-signature" = xmlns:mver =3D=20 "http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = =3D=20 "http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20 "http://schemas.openxmlformats.org/package/2006/relationships" = xmlns:spwp =3D=20 "http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t =3D=20 "http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m = =3D=20 "http://schemas.microsoft.com/exchange/services/2006/messages" = xmlns:pptsl =3D=20 "http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl = =3D=20 "http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksSe= rvice"=20 XMLNS:Z =3D "urn:schemas-microsoft-com:" xmlns:st =3D = "=01"><HEAD><TITLE>Re: [Ecrit] HUM on PhoneBCP
    Brian,
     
    My expectation was that framework and = phonepcb contain=20 enough options to cover also = short=20 term scenarios and help us to implement VoIP emergency calling = now. This seems not to be the case. We can not require now = from our SIP-proxy vendors to comply with the framework and = phone-pcb=20 because this does not work with the existing = EDs.  Currently,=20 ECRIT does not offer all components to build an EC architecture=20 which works now. As a=20 result, DT and other carriers must build and = require=20 from their = vendors proprietary=20 solutions which work=20 now.
     
    We can take the approach that Hannes = describes and do=20 it later, it's better than not at all. = However,=20 when people already have proprietary solutions in place, it is difficult = change=20 them.
     
    Concerning the local=20 dial string, we do not have currently any plans for something=20 different from 112 and the national EC dial string (110) or to = allow the=20 nomadic usage of the VoIP service outside=20 Germany. 
     
    Laura
    =
     

    From: Brian Rosen = [mailto:br@brianrosen.net]=20
    Sent: Friday, August 07, 2009 5:46 PM
    To: Liess, = Laura;=20 Martin.Dawson@andrew.com; Jesske, Roland; ecrit@ietf.org
    Cc: = Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

    Laura

     

    I=20 don=92t think we=92re going to get to the point where the IETF rolls = back=20 =96framework and =96phonebcp far enough to suit you.  The = approach that=20 Hannes described, which is to finish the current work as is, and then = go back=20 and see if we can standardize a way for VoIP services to connect to = older=20 systems with more limited capabilities using OBO and other tricks, = makes some=20 sense to me. 

     

    However,=20 device vendors have to build devices that work in countries that are = more=20 aggressively upgrading their emergency systems, without unduly = burdening=20 you.  What I=92m attempting to do is to figure out a way that you = can work=20 with a =96phonebcp compliant device, without incurring a lot of=20 cost.

     

    We=92re=20 not going to make it zero.

     

    If=20 you don=92t like a poly, return any street address in the area = code.  In=20 most cases, it could be a PIDF with a couple of A levels that works = for the=20 town.

     

    All=20 that matters is that if a =96phonebcp client queries an LCP, it should = get a=20 location that, when passed to LoST, gets the right URI.  If the = location=20 is coarse, that is okay; it works.  I=92d like you to deploy HELD = and LoST=20 servers in your networks that return the right thing to the endpoint = and not=20 just to the OBO proxy, but even if you don=92t, phonebcp compliant end = devices=20 will =93work=94 in your network: their attempts to reach LIS and LoST = servers will=20 fail, and they will send emergency calls without location and PSAP = URI, and=20 your proxy can fill in the right stuff.

     

    You=20 don=92t need =96phonebcp compliant endpoints.  Good for = you.  However,=20 vendors ought to make phonebcp compliant endpoints so that they work=20 everywhere.

     

    If=20 you want less that that, then I=92m not sure IETF can oblige, since we = don=92t do=20 nation specific solutions and some nations need the full =96phonebcp=20 spec.

     

    One=20 complication you should consider: devices need to know the local dial=20 string(s) for emergency calls.  In the IETF architecture, LoST = provides=20 that.  What were you planning on doing?

     

    Brian

     

     

    From:=20 L.Liess@telekom.de [mailto:L.Liess@telekom.de]
    Sent: = Friday, August=20 07, 2009 10:45 AM
    To: br@brianrosen.net; = Martin.Dawson@andrew.com;=20 R.Jesske@telekom.de; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

     

    Hi=20 Brian,

     

    Please=20 see comments inline.  

     

     

    From: Brian=20 Rosen [mailto:br@brianrosen.net]
    Sent: Friday, August 07, = 2009=20 3:05 PM
    To: Liess, Laura; Martin.Dawson@andrew.com; = Jesske,=20 Roland; ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on=20 PhoneBCP

    Actually, the = PIDF-LO is=20 designed to cater for all the variations in addressing.  You = don=92t mean=20 =93location used for emergency calls=94, you mean =93key for = location used for=20 emergency calls=94.  The area code is not the location, it is a = key that=20 is mapped to PSAP URI. 
    [[LLi]] =20 This is correct.

     

      The = telephone number=20 (with its area code) is the identifier you would use with HELD to = get the=20 location,  from which LoST would get you a PSAP = URI.
    [[LLi]] Here=20 we don't use the phone number. The proxy sends the IP-address = to the=20 LIS. The LIS finds out the access hardware (DSLAM = port) =20 corresponding to the IP-address and assigns a temporary string = to it=20 (kind of LbyR). It also finds out the phone area code for this=20 hardware. With the phone area code, the LIS queries a table = which=20 contains the phone area codes and the corresponding PSAP = URI, =20 then delivers the the string (LbyR) and the PSAP-URI to the SIP=20 proxy. The SIP proxy routes the call and sends the LbyR to the = PSAP. In=20 very few cases, PSAPs dereference  the the LyBR to a civic = address.=20

    We do not have any = kind of geo=20 data or poligons in our database. In principle we have the the = civic=20 address, but the access to this data is quite = slow.  I think=20 other fixed networks carriers here have more or less the=20 same. 

     

    This seems trivial = for you to=20 implement: you deploy a HELD server that takes telephone number and = returns=20 a polygon representing the area code boundary, and you deploy a LoST = server=20 that takes that polygon and returns the PSAP URI associated with=20 it.   

      This would = be no more=20 expensive than what you are proposing.  Proxies could use this = or=20 phonebcp compatible endpoints could use it. 

     

    NENA is planning = on doing=20 pretty much this same thing to handle legacy wireline networks where = telephone number is currently the key to the location database = (ALI). =20 The LIS will store location as the key (using held-identity), and a = gateway=20 will construct an LbyR from the phone number.  All the rest of = the=20 ecrit compatible infrastructure can then use the Location URI to get = location, route, etc.

     

    Making what you = now see as a=20 one step mapping (area code to PSAP URI) into a two step (telephone = number=20 to polygon, polygon to PSAP URI) is a bit more complex, but not any=20 significant difference in deployment.  It also works for = wireless (cell=20 sector/ID to polygon, polygon to PSAP URI), and of course, would be = upwardly=20 compatible with real location based routing, should your systems = evolve as=20 we expect they evolve, or something like EU regulations compel more = accurate=20 location services.

    [[LLi]] Nobody here is=20 willing to putting geodata or poligons into the access=20 databases.  And we could avoid doing this just by allowing = the LIS=20 to query the local LOST with the LbyR and to deliver the PSAP URI to = the SIP=20 proxy.  

     

    Kind = regards

    Laura

     

    Brian

     

    From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of=20 L.Liess@telekom.de
    Sent: Friday, August 07, 2009 7:59=20 AM
    To: Martin.Dawson@andrew.com; R.Jesske@telekom.de;=20 ecrit@ietf.org
    Cc: = Reinhard.Lauster@t-mobile.at
    Subject:=20 Re: [Ecrit] HUM on PhoneBCP

     

     

    Hi Martin,=20  

    Hi Laura,

     

    I regard it=20 as a goal of ECRIT =96 as derived from the goals of the IETF = generally =96 to=20 define a structure that will allow an Internet capable device to = connect=20 to a network anywhere in the world and be able to make emergency = calls.=20 Just as FTP, email protocols, SIP and etc. all work regardless of = which=20 network the devices attach to. I don=92t understand how the kind = of=20 variations that you are requesting be added to the specification = will=20 allow that to occur.

    [[LLi]] = This is fine=20 and usefull. Just that every country uses today different formats = for the=20 location used for emergency calls. Changing this will take time = and costs=20 money.

    What is = the harm in=20 allowing ECs to work with local location formats which are = understood only=20 by the LIS and the PSAP ?. I dont see why a common location = format must=20 be implemented by everybody.

    Maybe the EC could work like = this :

    =B7        =20 The proxy = discovers the=20 LIS based on EDs IP-address using reverse-DNS and SRV record (this = is=20 possible with "identity extenssions")

    =B7        =20 It=20 retrieves the location ( e.g. using HELD) in a local format = understood=20 only by the LIS and the PSAP, which are in the same country. The = location=20 is just a string which is passed transparently through the network = to the=20 PSAP. In my opinion, it would be in principle  posible = to use=20 LbyR to transport local location identidfiers, e.=20 g.  area-code@lis.telekom.de , but this is = currently my=20 personal opinion, I didn' found any statemant or example in = the=20 drafts.   =20

    =B7        =20 The=20 LIS delivers, together with the LbyR above, the PSAP URI.  As = far as=20 I know there is currently no way to do this in HELD (or did I = miss=20 = something?).        
     

    It would be an=20 alternative which is interoperable and quite easy to = implement,=20 without the need for the operators to change their location=20 databases. I think by allowing this scenario, interoperable = EC could=20 be achieved earlier. And this does not exclude the scenario = described=20 in the framework and phone-bcp, where the EDs retrieve deo or = civic=20 location, which is needed for EC to work in = private/enterprise=20 networks.  
      

        

     

    The=20 position appears to be that the German regulator doesn=92t require = anything=20 =96 and the operators will not be proactive in following a = specification if=20 it doesn=92t include what already exists. In that context, I = don=92t=20 understand why there is a need for the BCP at all. There may be no = need to=20 endorse it but, similarly, there should be no need to object to it = =96 since=20 the operators will only put in place their preferred version of = the=20 service in any case.
    [[LLi]]  = This is=20 not quite true. We have to ensure that EC works for different AN- = and=20 VoIP-provider and for nomadic users in Germany by 2013. Our = current=20 solution does not allow this and there is the same for other=20 carriers. We definitively need to define in Germany=20 an architecture which fullfills this requirements. It would = be very=20 usefull if we can use standard protocols. But nobody will be = willing=20 to change everything at once.  Having a standard based = architecture=20 which is low cost would be a great advantage.=20

     

    Kind=20 regards

    Laura     

     

     That=92s OK=85 insofar as it just means German = networks=20 aren=92t ECRIT compatible =96 =93compatibility=94 isn=92t a worthy = goal in and of=20 itself; it has to actually mean any device can work = anywhere.

     

    Cheers,

    Martin

     

    From:=20 L.Liess@telekom.de [mailto:L.Liess@telekom.de]
    Sent: = Friday, 7=20 August 2009 12:29 AM
    To: Dawson, Martin; = R.Jesske@telekom.de;=20 ecrit@ietf.org
    Cc:=20 Reinhard.Lauster@t-mobile.at
    Subject: RE: [Ecrit] HUM on = PhoneBCP

     

    Hi Martin,=20

     

    See=20 comments inline [[LLi]].

     

     

    Laura

    From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawson,=20 Martin
    Sent: Wednesday, August 05, 2009 11:00 = AM
    To:=20 Jesske, Roland; ecrit@ietf.org
    Subject: Re: [Ecrit] = HUM on=20 PhoneBCP

    Hi=20 Roland,

     

    I think=20 what you=92re saying is that you don=92t think that Germany will = go on to=20 implement full ECRIT support but will peg development at an = interim=20 phase.
    [[LLi]]  We = don't=20 know how the realtime application networks or EC will look = like=20 in 20 years. Roland's answer only applies to the = next 5=20 to 10 years. 

     

     That would be disappointing =96 not least = because full=20 ECRIT compliance would ultimately decrease the overhead = associated with=20 emergency service support for operators as well as providing a = more=20 universal service.

    [[LLi]]  This=20 may be true for "green field" ISPs and VSPs but not for = incumbent=20 carriers with existing infrastructure.  And universal = service=20 is not a requirement for us. Neither the German regulator=20 requires it nor is it a busines=20 case.   

     

    Nevertheless, I don=92t think that = decision=20 invalidates the BCP;
    [[LLi]]  = We think=20 it does, because some of the requirements are not = flexible=20 enough to cover the deployments within the next = years.  The=20 BCP should be more flexible:  

    =B7        =20 Allow = additional=20 location identifiers 

    =B7        =20 Allow=20 AN operated LOST =

    =B7        =20 Provide a=20 way to enable LOST-query based on national or=20 domain-specific location identifier. One posiblility is=20 to allow the LIS to query the LOST , but = there are=20 also other alternatives. =20

    =B7        =20 Allow and describe=20 also network-centric, not only ED-centric = architectures. If=20 I  remember correctly, John Medland from BT also = recomended to=20 use a more network- centric architecture, at least for the next = years.=20

     

    I think=20 it just means that the German regulator and technical advisory=20 committees would point out the subset aspects of compliance that = would=20 be applicable to that jurisdiction.  
    [[LLi]]  Again, the draft is not = flexible=20 enough for it.  If the BCP contains requirements which = are not realistic, people will just discard the=20 BCP and implement proprietary stuff. My expectation = from a=20 standard body is to define protocols and architecture which = people=20 are willing to implement in their network or products , not only = in the=20 lab.

     

    [[LLi]] 

    We are=20 not against the draft in principle. ECRIT provides  us with very valuable = specifications=20 as LbyR, HELD, identity extensions. But targeting an = architecture=20 which requires everbody to invest without a business=20 case will not help the draft in the end, also if = it=20 becomes a BCP.  It would make sense to make it more=20 flexible so people are willing to adopt=20 it.    

     

     Actually, based on your description below, = the NENA i2=20 architecture would probably be a more straightforward baseline = for=20 analysis =96 as has been done in the UK and Canada. Of course, = it=92s=20 generally recognized as only an interim step, even in those=20 jurisdictions.

    Other=20 comments below.

     

    Cheers,

    Martin

     

    From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of=20 R.Jesske@telekom.de
    Sent: Wednesday, 5 August 2009 = 6:19=20 PM
    To: ecrit@ietf.org
    Subject: Re: [Ecrit] = HUM on=20 PhoneBCP

     

     

    Dear all,=20
    We would like the document to = become a BCP=20 as soon as possible so the group can move on with other = documents=20 related to emergency calling based on location-by-reference and = ED=92s=20 IP-address.

    [[MCD]] I think you might = mean=20 =93identity extensions=94 rather than location-by-reference = because LbyR=20 still requires the ED to obtain the reference =96 e.g. by = HELD.
    [[LLi]] We use both, the IP-address = as UE=20 identity and LbyR. The SIP-proxy uses the IP-address to query = the LIS=20 using HTTP (it's not HELD but SOAP over HTTP, but anyway = similar).=20 The LIS responds with a numeric string associated to the = caller=20 location, in principle a LbyR and with the = PSAP number. The=20 proxy inserts the LbyR into the SIP-message (as = P-Asserted-ID=20 because the PSAPs are in PSTN) and routes the message to = the=20 PSAP.  It's a low cost=20 solution. 

    But we can not HUM for = the current=20 form of the document.

    Back to the document: = Some=20 requirements are far form being realistic, at least in Germany, = some are=20 not realistic at all. Implementing these requirements cost a = carrier a=20 lot of money and there is no ROI for it.

    Just a few examples: =

    =B7      =20 Requiring either geo or civic location does not provide carriers = with=20 enough flexibility to reuse their existing mechanisms and = location=20 databases. Routing of emergency calls is currently done in = Germany based=20 on phone area code not on geo or civic location, at least for = the fixed=20 network. For mobile networks the cell-id is used in common. This = is=20 regulated by the german regulator.

    [[MCD]] How many unique = PSAP routes=20 are required in Germany? The US has lots (6000 plus) and = Australia has=20 two (and they are redundant so it doesn=92t matter which one). = Presumably=20 geographic information, for PSAP catchment areas, is the basis = for=20 determining which area codes are relevant to begin with? After = all, an=20 area code is not intrinsically geographic; it=92s a network = routing value.=20 If so, then some geographic discriminator is already in play in = terms of=20 constructing the area code based routing data (something like = zip codes=20 perhaps?) =96 and in that case, it should be straightforward to = by-pass=20 the area code step in the construction of routing that goes the = correct=20 PSAP URI.
    [[LLi]] Currently, fixed = networks=20 carriers in Germany route the ECs based only on the = caller's=20 area code. Sometime in the past, the carriers, the = regulator=20 and the PSAPs operators (police, the Red Cross) agreed to do=20 so. This may change in the future, but it will take a quite = long=20 = time.      

     With nomadic VoIP = devices (and=20 it=92s no good being in denial about this being the norm in the = future)=20 area code is no more reliable than it is for conventional mobile = phones.=20 And, presumably, area code is not used for conventional cellular = emergency call routing?
    [[LLi]]  As=20 far as I know, mobile networks use the Cell-ID, not the area = code, and=20 have a different table than the fixed network = operators. They are=20 not going to change this.  As to the nomadic SIP-users...if = we like=20 it or not, very few of our customers use our = SIP=20 service nomadic, let alone call EC from their=20 = laptop.         

    1           &n= bsp; =20 LOST as a national, let alone as a = global=20 directory is not going to be implemented. The regulator will = provide in=20 the web a static table which contains the PSAPs and the area for = which=20 they are responsible (one or more area codes). Every carrier has = to=20 implement its own routing database for emergency calls.

    [[MCD]] Whatever the = carriers=20 implement (and they have to implement something) could just as = readily=20 be done using LoST. Then visiting devices, with no association = with=20 any local VoIP proxy server would still be able to determine a = route=20 to the correct PSAP. Alternatively, as long as the regulator = is=20 maintaining a web service with the routing information, why = not make=20 that directly accessible using LoST and save the operators the = cost of=20 duplicating the service at all?
    [[LLi]]  There is a big difference = between=20 maintaining a web page with a table which operator can = print and=20 implement in their darabases and operating a database = which is=20 queried for every emergency call in Germany, must = have an=20 availablity of 99,99...% ,  is secure = enough...you=20 know. The regulator will not do this.


    2       We have = no=20 intention to rely on end devices for location information = because:=20
    =B7       ED = provided location=20 info is not trusted

    [[MCD]] Location by = reference=20 mitigates this trust issue. The emergency network can = (automatically and=20 before human resources are engaged) assess the source of the = reference,=20 and the validity of the location by dereference, without having = to trust=20 location provided directly from the ED. There are more = sophisticated=20 approaches to trustability even using LbyV =96 based on digital = signatures=20 across appropriate attributes. This WG and Geopriv haven=92t = really got to=20 grips with that=85 yet.
    [[LLi]]  We=20 build the SIP-network and EC now. ED-provided location is=20 needed if EC must work for private and enterprise = networks and VPNs.  We have no such regulatory=20 requirements.  And we don't know of = any verdor of=20 DSL-EDs which provides today SIP with LbyR and is as = cheap as=20 the devices without it. If you do, please let me=20 know. 

    The regulator ask = us to=20 guarantee that EC works. What if a customer dials 112 and=20 his end device does not send the location? So I = have to=20 implement both solutions, with and without ED provided location, = anyway.  
    1       = There are=20 already a lot of existing EDs in usage which don=92t send=20 location.   

    [[MCD]] Quite right. = ECRIT doesn=92t=20 overly concern itself with that interim situation. The UK and = Canadian=20 definitions for an interim solution (limiting service to = in-country VoIP=20 proxy operators) both assume third-party query via = identity-extension to=20 allow the proxy or the VPC to make the query to the LIS. This = isn=92t=20 extensible to universal emergency service access by all visiting = devices=20 but it does put the necessary LIS functionality in place as a = very good=20 starting point.  It would be a pity if Germany were to = cease=20 the evolution there as it would not fulfil the real promise of = the=20 Internet and the ECRIT model.
    [[LLi]]  I wonder who will = drive and pay=20 for upgrading the interim=20 solutions.  Unfortunatelly, it's all about=20 money...

     Think about it; all = the=20 complexity of putting location determination infrastructure in = place for=20 the purposes of dispatch is done =96 and then the next, simpler = step, of=20 using that to support the routing procedure isn=92t taken=85 = that would be a=20 waste.

    [[LLi]]  Do you = think this=20 is an argument for a product manager? They need a business=20 case. 

     

     

      We=20 don=92t intend to require our ED-vendors to provide location = because it is=20 useless to us.  

    We could agree with the = document with=20 following changes:

    o   =20 Other location = identifiers then geo or civil are allowed. It must be possibe = that the=20 data foermat is flexible due to different requirements from = regulators=20 over the whole world. (e.G Germany area codes for fixed- and = Cell-Id for=20 moile- providers)

    o   =20 The=20 MUST for the end devices to support location information, DHCP = location=20 options and HELD shall be removed

    o   =20 It=20 must be possible for the VoIP-provider=92s proxy to use a LOST = (or an=20 ESRP) provided by the AN or by other local provider on behalf of = the=20 AN. 

     

     There is no value = in Hum-ing=20 documents which one is not going to implement and does not fit = into=20 regulated schemes like in Germany. Currently, neither the IETF- = nor the=20 3GPP-architecture for emergency calling covers our real needs = for the=20 next 2 to 5 years and in the end everybody still has its own = proprietary=20 implementation.   

    Best regards

    Roland

     

    Deutsche Telekom=20 Netzproduktion GmbH
    Zentrum Technik Einf=FChrung
    Roland Jesske
    Gateways, Protokolle, Konvergenz, = TE32-1
    Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,
    Postfach, = 64307=20 Darmstadt (Postanschrift)
    +496151 628 2766 = (Tel)
    +491718618445=20 (Mobile)
    E-Mail: r.jesske@telekom.de=20
    http://www.telekom.de=20

     

    Registerrechtliche=20 Unternehmensangaben:
    Deutsche = Telekom=20 Netzproduktion (DT NP) GmbH
    Aufsichtsrat: Timotheus H=F6ttges = (Vorsitzender)
    Gesch=E4ftsf=FChrung: Dr. Bruno=20 Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus=20 Peren
    Handelsregister: Amtsgericht Bonn HRB 14190
    Sitz der = Gesellschaft: Bonn
    USt-IdNr.: DE 814645262

     

     


    --------------------------------------------------------------= ----------------------------------
    This message is for&= nbsp;the designated recipient only and may
    co= ntain privileged, proprietary, or otherwise priv= ate information.  
    If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
    this email is proh= ibited.
    --------------------------------------------------------------= ----------------------------------
    [mf2]

     

     


    --------------------------------------------------------------= ----------------------------------
    This message is for&= nbsp;the designated recipient only and may
    co= ntain privileged, proprietary, or otherwise priv= ate information.  
    If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
    this email is proh= ibited.
    --------------------------------------------------------------= ----------------------------------
    [mf2]

     

    ------_=_NextPart_001_01CA19C2.8BD6414C-- From Martin.Dawson@andrew.com Mon Aug 10 07:49:54 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882403A68CE for ; Mon, 10 Aug 2009 07:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmysxLDmZO1H for ; Mon, 10 Aug 2009 07:49:45 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id D3E4C3A6D05 for ; Mon, 10 Aug 2009 07:49:31 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_10_10_12_20 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Aug 2009 10:12:20 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 09:49:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA19C9.C5DB260D" Date: Mon, 10 Aug 2009 09:49:33 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8YzgAILrVcAAHM9j8AAcJZvgAA/v42AAJDiUoAAA+bkAAAFk66wAL5PVgAAdLrWgADhg5/AAa+5g8A== References: From: "Dawson, Martin" To: "DRAGE, Keith (Keith)" , "Marc Linsner" , , X-OriginalArrivalTime: 10 Aug 2009 14:49:33.0856 (UTC) FILETIME=[C63E1A00:01CA19C9] Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 14:49:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA19C9.C5DB260D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Keith,=0D=0A=0D=0A=20=0D=0A=0D=0AYou didn't mean *statutory* require= ment then - so it's somewhat=0D=0Adifferent; there are no protocol police.=0D= =0A=0D=0A=20=0D=0A=0D=0ACan you point me to the normative requirement that = says IMS=0D=0Aimplementations must support the emergency procedures and E-C= SCF=3F Which=0D=0Aspecification is that in=3F=0D=0A=0D=0A=20=0D=0A=0D=0AChe= ers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A__________________________= ______=0D=0A=0D=0AFrom: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.c= om]=20=0D=0ASent: Monday, 10 August 2009 9:41 PM=0D=0ATo: Dawson, Martin; M= arc Linsner; Gabor.Bajko@nokia.com; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit= ] ECRIT/IMS - independent discussion from the=0D=0APhoneBCP hum=0D=0A=0D=0A= =20=0D=0A=0D=0AWho knows what regulation.=0D=0A=0D=0A=20=0D=0A=0D=0ABut the= standard goes straight to a normative requirement to process a=0D=0Areques= t as an emergency call and route to an E-CSCF without any other=0D=0Aoption= when an emergency call is detected, so conformance to something=0D=0Aclaim= ing to be IMS is impossible without it.=0D=0A=0D=0A=20=0D=0A=0D=0AAs for VO= IP, the UE requirements require an INVITE with voice as the=0D=0Aonly type = of emergency call generated. The network processes all=0D=0Arequests, e.g. = INVITE, MESSAGE, or whatever, as an emergency call if so=0D=0Arecognised. I= t is up to the PSAP to reject the ones it cannot handle (or=0D=0Athe MGCF i= f the PSAP is CS connected).=0D=0A=0D=0A=20=0D=0A=0D=0Aregards=0D=0A=0D=0A =0D= =0A=0D=0AKeith=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=0D=0A______________________= __________=0D=0A=0D=0A=0D=0A=09From: Dawson, Martin [mailto:Martin.Dawson@a= ndrew.com]=20=0D=0A=09Sent: Friday, August 07, 2009 9:09 AM=0D=0A=09To: DRA= GE, Keith (Keith); Marc Linsner; Gabor.Bajko@nokia.com;=0D=0Aecrit@ietf.org=0D= =0A=09Subject: RE: [Ecrit] ECRIT/IMS - independent discussion from the=0D=0A= PhoneBCP hum=0D=0A=0D=0A=09Thanks Keith,=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09WR= T:=0D=0A=0D=0A=09Where IMS is supported, there is also a requirement to sup= port=0D=0Aemergency calling on IMS.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Can you= elaborate please=3F Where is this requirement applicable=0D=0Aand by what = legislation/docket=3F I'm assuming you'd agree that IMS is in=0D=0Afact VoI= P - but I probably shouldn't.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Cheers,=0D=0A=0D= =0A=09Martin=0D=0A=0D=0A=09=0D=0A________________________________=0D=0A=0D=0A=0D= =0A=09From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A= Behalf Of DRAGE, Keith (Keith)=0D=0A=09Sent: Friday, 7 August 2009 5:36 PM=0D= =0A=09To: Marc Linsner; Gabor.Bajko@nokia.com; ecrit@ietf.org=0D=0A=09Subje= ct: Re: [Ecrit] ECRIT/IMS - independent discussion from the=0D=0APhoneBCP h= um=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Obviously mandates differ between differ= ent parts of the world,=0D=0Abut certainly any wireless operator (2G or 3G)= is currently required by=0D=0Athe 3GPP standards, reflecting national regu= lation, to provide ermegency=0D=0Acalling where they provide CS voice servi= ce on their networks.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Where IMS is supporte= d, there is also a requirement to support=0D=0Aemergency calling on IMS.=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09For the deployments where an operator is prov= iding LTE in an=0D=0Aarea not covered by 2G or 3G service, there are indica= tions prior to the=0D=0Anetwork selection to enable determination of whethe= r an emergency call=0D=0Ais possible over IMS or not.=0D=0A=0D=0A=09=20=0D=0A=0D= =0A=09What this essentially boils down to is that if you have an=0D=0Acontr= act with a 3G operator to give you voice service, then emergency=0D=0Acalls= will work on that phone, because the network operator is required=0D=0Ato = support it. That applies whether there is an internet browser on the=0D=0Ap= hone or not.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09As far as I know there is curr= ently no mandate on any ISP or=0D=0Aindeed internet VOIP provider to suppor= t emergency calls. That may come=0D=0Ain the future, but so far I have seen= no evidence of it.=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09So writing a documen= t that claims that some other mechanism is=0D=0Athe way to offer emergency = calls, and then shouting from the rooftops=0D=0Athat this applies to mobile= phones, is more likely to result in deaths=0D=0Athan not.=20=0D=0A=0D=0A=09= =20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09regards=0D=0A=0D=0A=09= =20=0D=0A=0D=0A=09Keith=0D=0A=0D=0A=09=09=20=0D=0A=0D=0A=09=09=0D=0A_______= _________________________=0D=0A=0D=0A=0D=0A=09=09From: ecrit-bounces@ietf.o= rg=0D=0A[mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner=0D=0A=09=09= Sent: Wednesday, August 05, 2009 8:30 PM=0D=0A=09=09To: Gabor.Bajko@nokia.c= om; ecrit@ietf.org=0D=0A=09=09Subject: Re: [Ecrit] ECRIT/IMS - independent = discussion=0D=0Afrom the PhoneBCP hum=0D=0A=0D=0A=09=09Gabor,=0D=0A=0D=0A=09= =09=09=09=0D=0A=09=09=09=09=0D=0A=09=09=09=09 But reliability and mo= bility=0D=0Awere the main architectural design choices in 3GPP. That is wh= y they=0D=0Aended up with that complex architecture! The procedures themse= lves are=0D=0Aa consequence of the architecture.=0D=0A=09=09=09=09=0D=0A=09= =09=09=09Carriers plan to switch emergency call=0D=0Ahandling from CS to P= S domain, and they wanted a network controlled ES,=0D=0Athey did not want = to rely on the handset doing the whole procedure=0D=0Abecause of the liabi= lity. Support for emergency calls is not a revenue=0D=0Agenerator for carr= iers, they'd be happy leaving the tasks up to the=0D=0Aclient if there wer= e no consequences of emergency calls failing for=0D=0Awhatever reason.=0D=0A= =09=09=09=09=0D=0A=09=09=09=09And just to answer James point, ISPs=0D=0Aoff= ering broadband internet service can not be paralelled with carriers=0D=0A= operating networks using 3GPP standards. The ISPs do not commit to=0D=0Aof= fer you service with less than a few minutes outage per year, they=0D=0Apr= ovide no mobility and they are not mandated to support emergency=0D=0Aserv= ices.=0D=0A=09=09=09=09=0D=0A=09=09=09=09=0D=0A=09=09=09=09=0D=0A=09=09=09=09= - gabor=0D=0A=09=09=09=09=0D=0A=09=09=09=09=0D=0A=09=09=09=09[Marc] Are you= implying that 3GPP=0D=0Acarriers operating a packet voice service have a d= ifferent mandate for=0D=0Asupporting emergency services than an OTT provide= r that sells packet=0D=0Avoice services=3F (my understanding, which could = be wrong, is that VoIP=0D=0Ais VoIP no matter who is the SP)=0D=0A=09=09=09= =09=0D=0A=09=09=09=09Or is this a 3GPP self-inflicted mandate=0D=0Athat is = trying to emulate 2G circuit-switched services=3F=0D=0A=09=09=09=09=0D=0A=09= =09=09=09=0D=0A=09=09=09=09-Marc-=0D=0A=09=09=09=09=0D=0A=09=09=09=09=0D=0A=0D= =0A=09=20=0D=0A=0D=0A=0D=0A------------------------------------------------= ------------------------=0D=0A------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information. =20=0D=0AIf you have received it in= error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------= ----------------------------------------------------------=0D=0A-----------= -------------=0D=0A[mf2]=0D=0A=0D=0A=09=20=0D=0A=0D=0A---------------------= ---------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA19C9.C5DB260D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= Re: ECRIT/IMS - independent discussion from the PhoneBCP hum=0D= =0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A
    =0D=0A=0D=0A

    T= hanks Keith,

    =0D=0A=0D=0A

    <= font size=3D2 color=3Dnavy face=3DArial> 

    =0D=0A=0D= =0A

    You didn’t = mean *statutory* requir= ement then – so it’s=0D=0Asomewhat different; there are no prot= ocol police.

    =0D=0A=0D=0A

    <= font size=3D2 color=3Dnavy face=3DArial> 

    =0D=0A=0D= =0A

    Can you point me = to the normative=0D=0Arequirement that says IMS implementations must suppor= t the emergency procedures=0D=0Aand E-CSCF=3F Which specification is that i= n=3F

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Cheers,

    =0D=0A=0D=0A

    Martin

    =0D=0A=0D=0A

     

    =0D=0A=0D= =0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A

    From:=0D=0ADRAGE, Keith (Keith) [mailto:drage@alcatel-= lucent.com]
    =0D=0ASent: = Monday, 10 August 2009 9:41=0D=0APM
    =0D=0ATo: Dawson, Martin; Marc Linsner;=0D=0AGabor.Bajko@nokia.c= om; ecrit@ietf.org
    =0D=0ASubject: RE: [Ecrit] ECRIT/IMS -=0D=0Aindependent discussion from the Phone= BCP hum

    =0D=0A=0D=0A<= /div>=0D=0A=0D=0A

     =0D=0A=0D=0A

    Who kn= ows what regulation.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    But the standard goes straight to a=0D= =0Anormative requirement to process a request as an emergency call and rout= e to an=0D=0AE-CSCF without any other option when an emergency call is dete= cted, so=0D=0Aconformance to something claiming to be IMS is impossible wit= hout it.

    =0D=0A=0D=0A

    &= nbsp;

    =0D=0A=0D=0A

    As for VOIP, the UE requirements require=0D=0Aan = INVITE with voice as the only type of emergency call generated. The network=0D= =0Aprocesses all requests, e.g. INVITE, MESSAGE, or whatever, as an em= ergency=0D=0Acall if so recognised. It is up to the PSAP to reject the ones= it cannot handle=0D=0A(or the MGCF if the PSAP is CS connected).

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    regards

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Keith

    =0D=0A=0D= =0A
    =0D=0A=0D=0A

     <= /span>

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>From:=0D=0ADaw= son, Martin [mailto:Martin.Dawson@andrew.com]
    =0D=0ASent: Friday, August 07, 2009 9:09=0D=0AAM
    =0D= =0ATo: DRAGE, Keith (Keith);= Marc=0D=0ALinsner; Gabor.Bajko@nokia.com; ecrit@ietf.org
    =0D=0ASubject:     RE: [Ecrit] ECRIT/IMS -=0D=0A= independent discussion from the PhoneBCP hum

    =0D=0A=0D=0A

    Thanks Keith,

    =0D=0A=0D=0A

     <= /font>

    =0D=0A=0D=0A

    WRT:

    =0D=0A=0D=0A

    Where IMS is supported, there is also a=0D=0Areq= uirement to support emergency calling on IMS.

    =0D= =0A=0D=0A

     =

    =0D=0A=0D=0A

    Can you elaborate please=3F Where is this=0D=0Arequirement = applicable and by what legislation/docket=3F I’m assuming you’d= agree=0D=0Athat IMS is in fact VoIP – but I probably shouldn’t= =2E

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Cheers,

    =0D=0A=0D=0A

    Martin

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D= =0A=0D=0A
    =0D=0A=0D= =0A
    =0D=0A=0D=0A

    From:=0D= =0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
    =0D= =0ASent: Friday, 7 August 20= 09 5:36=0D=0APM
    =0D=0ATo:= Marc Linsner;=0D=0AGabor.Bajko@nokia.com; ecrit@ietf.org
    =0D=0ASubject: Re: [Ecrit] ECRIT/IMS -=0D=0A= independent discussion from the PhoneBCP hum

    =0D=0A=0D=0A
    =0D=0A=0D=0A

    =  

    =0D=0A=0D=0A

    Obviously mandates differ between=0D=0Adiffe= rent parts of the world, but certainly any wireless operator (2G or 3G) is=0D= =0Acurrently required by the 3GPP standards, reflecting national regulation= , to=0D=0Aprovide ermegency calling where they provide CS voice service on = their=0D=0Anetworks.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Where IMS is supported, there is also = a=0D=0Arequirement to support emergency calling on IMS.<= /o:p>

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Fo= r the deployments where an operator is=0D=0Aproviding LTE in an area not co= vered by 2G or 3G service, there are indications=0D=0Aprior to the network = selection to enable determination of whether an emergency=0D=0Acall is poss= ible over IMS or not.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    What this essentially boils down to is=0D= =0Athat if you have an contract with a 3G operator to give you voice servic= e, then=0D=0Aemergency calls will work on that phone, because the network o= perator is=0D=0Arequired to support it. That applies whether there is an in= ternet browser on=0D=0Athe phone or not.

    =0D=0A=0D= =0A

     

    =0D=0A=0D=0A=

    As far as I know ther= e is currently no=0D=0Amandate on any ISP or indeed internet VOIP provider = to support emergency calls.=0D=0AThat may come in the future, but so far I = have seen no evidence of=0D=0Ait. 

    =0D= =0A=0D=0A

     

    =0D=0A=0D= =0A

    So writing a docu= ment that claims that=0D=0Asome other mechanism is the way to offer emergen= cy calls, and then shouting=0D=0Afrom the rooftops that this applies to mob= ile phones, is more likely to result=0D=0Ain deaths than not.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

     <= /font>

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    r= egards

    =0D=0A=0D=0A

    &nb= sp;

    =0D=0A=0D=0A

    Keith

    =0D=0A=0D=0A=0D=0A=0D=0A

     

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A

    From:=0D=0Aecrit-bounce= s@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
    =0D=0ASent: Wednesday, August 05, 2009=0D=0A8:30 PM=0D=0ATo: Gabor.Bajko@nokia= =2Ecom;=0D=0Aecrit@ietf.org
    =0D=0ASu= bject: Re: [Ecrit] ECRIT/IMS -=0D=0Aindependent discussion from = the PhoneBCP hum

    =0D=0A=0D= =0A

    Gabor,

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A


    =0D=0A    =0D=0A<Gab= or> But=0D=0Areliability and mobility were  the main architectural = design choices in=0D=0A3GPP. That is why they ended up  with that comp= lex architecture! The=0D=0Aprocedures themselves are a consequence  of= the architecture.
    =0D=0A
    =0D=0A<= /span>    Carriers plan= to switch=0D=0Aemergency call handling  from CS to PS domain, and the= y wanted a network=0D=0Acontrolled ES, they did not  want to rely on t= he handset doing the whole=0D=0Aprocedure because of the  liability. S= upport for emergency calls is not a=0D=0Arevenue generator  for carrie= rs, they'd be happy leaving the tasks up to=0D=0Athe client if  there = were no consequences of emergency calls failing for=0D=0Awhatever  rea= son.
    =0D=0A
    =0D=0A    <= b>And just to answer James=0D= =0Apoint, ISPs offering  broadband internet service can not be paralel= led=0D=0Awith carriers operating  networks using 3GPP standards. The I= SPs do not=0D=0Acommit to offer you service  with less than a few minu= tes outage per year,=0D=0Athey provide no mobility and  they are not m= andated to support emergency=0D=0A services.
    =0D=0A
    =0D=0A
    =0D= =0A
    =0D=0A    - gabor
    =0D=0A
    =0D=0A
    =0D=0A[Marc] Are you implying that 3GPP carriers opera= ting a packet voice service=0D=0Ahave a different mandate for supporting em= ergency services than an OTT provider=0D=0Athat sells packet voice services= =3F  (my understanding, which could be=0D=0Awrong, is that VoIP is VoI= P no matter who is the SP)
    =0D=0A
    =0D=0AOr is this a 3GPP self-inflic= ted mandate that is trying to emulate 2G=0D=0Acircuit-switched services=3F<= br>=0D=0A
    =0D=0A
    =0D=0A-Marc-
    =0D=0A
    =0D=0A    <= /o:p>

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A=0D=0A=0D=0A

     

    =0D=0A=0D=0A=0D=0A =0D=0A
    =0D=0A=

     

    =0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A

    <= tr>

    ----------------------------------------------------------------= --------------------------------
    =0D=0AThis message is fo= r the designated recipient only and may
    =0D= =0Acontain privileged, proprietary, or otherwise p= rivate information.  
    =0D=0AIf you have re= ceived it in error, please notify the se= nder
    =0D=0Aimmediately and delete the original. = ; Any unauthorized use of
    =0D=0Athis email = ;is prohibited.
    =0D=0A---------------------------------------------= ---------------------------------------------------
    =0D=0A[mf2]
    =0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01CA19C9.C5DB260D-- From john@johnlange.ca Mon Aug 10 14:15:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F163A6D69 for ; Mon, 10 Aug 2009 14:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.95 X-Spam-Level: * X-Spam-Status: No, score=1.95 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wevsNY0mxdae for ; Mon, 10 Aug 2009 14:15:25 -0700 (PDT) Received: from venus.bighostbox.com (host-150.epicnet.ca [64.201.170.150]) by core3.amsl.com (Postfix) with ESMTP id 36A6B3A6D15 for ; Mon, 10 Aug 2009 14:15:24 -0700 (PDT) Received: by venus.bighostbox.com (Postfix, from userid 501) id 3A5162280004; Mon, 10 Aug 2009 16:15:28 -0500 (CDT) Received: from 205.200.120.72 ([205.200.120.72]) by www.open-it.ca (Horde MIME library) with HTTP; Mon, 10 Aug 2009 16:15:28 -0500 Message-ID: <20090810161528.dn1am0meiaa88s44@www.open-it.ca> Date: Mon, 10 Aug 2009 16:15:28 -0500 From: John Lange To: Hannes Tschofenig References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><1249584170.5335.24.camel@vandium.darkcore.net><6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com><1249587517.5335.80.camel@vandium.darkcore.net><1249656835.5053.35.camel@vandium.darkcore.net><1249675185.5053.126.camel@vandium.darkcore.net> <05b601ca1820$17fc20e0$625aa20a@nsnintra.net> In-Reply-To: <05b601ca1820$17fc20e0$625aa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: "'Dawson, Martin'" , 'ecrit' Subject: [Ecrit] PSAP motivations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 21:15:26 -0000 I'm changing the topic on this thread to accurately reflect the fact =20 that were straying off topic for this mailing list ;) Quoting Hannes Tschofenig : > Hi John, > > in addition to what Martin said about the negative impact on the "public". > > My guess is that the emergency services networks will move their networks = to > IP (because of the lower costs) and then they will not require the ILECs > todo the gatewaying of all the calls. That will not happen any time soon. The PSAPs have sworn allegiance to =20 the ILECs and will not connect their equipment to anything except the =20 ILECs. They have reiterated this frequently. > They will be able to get emergency calls directly from the VoIP providers. As long as the current PSAP management is involved that will never =20 happen. They have stated this time and again. No PSAP system will ever =20 be connected to the Internet. > This will be less expensive, will > support additional media and more extensible for future deployments. This = is > an evolution step we observe in many countries. > > One interesting data point I would like to understand is whether the > PSAPs/emergency services networks have to pay to the ILECs for their > emergency call routing and gatewaying "offering". Yes the ILECs get compensation for their services though I do not know =20 the exact model and I suspect it's different in province. On top of that the various providers are allowed to charge a "911 =20 access fee" to every subscriber including wireless and standard =20 wireline. This is a major source of revenue which they are motivated =20 to protect. They recently took some heat about this when it was revealed that this =20 charge has nothing whatever to do with the actual cost of providing =20 the service and they are under no obligation to spend the money to =20 improve 911 service. Case in point, we still can't do location for cell phones despite the =20 fact that the one time cost of implementing the system would only be a =20 fraction of the money collected in 911 fees EACH YEAR. > If they have to then there is obviously incentive for them to move =20 > away from that model. I wouldn't say it's obvious. In fact I don't think saving the public =20 money is anywhere near the top of PSAP motivations. For example, =20 Ontario has something like 140(!) regional PSAPs (pretty much every =20 municipality has one but I can't seem to get a straight answer on =20 exactly how many there are). Roughly one PSAP for every 80,000 people. =20 One of the big stumbling blocks to this whole process is that PSAPs =20 will have to upgrade equipment. That gets expensive when you have to =20 do it 140 times. No PSAP is going to suggest "hey, this would be a good time =20 consolidate 140 PSAPs and save a bundle of money!" Rather, PSAPs are motivated by bad press. They avoid anything that may =20 cause them not to be able to do their jobs and that boils down to =20 "change". I agree with them that we should be conservative with regard to change =20 in the 911 system but the problem is the Canadian PSAPs have become a =20 too dogmatic fighting change. They actually tried to convince the CRTC to ban VOIP outright and =20 since then they've spent too much of their time fighting change rather =20 than considering what benefits new 911 systems could offer. > PS: I am always curious why people see the step to a NENA i2.5 or pre-ECRI= T > architecture as so complicated particularly when the largest investment is > in the location server capability in the access networks (and those have t= o > be done anyway regardless of the chosen architecture). Conversely, I find those kinds of statements as highly curious. From a =20 technical perspective, real-time IP location is complicated. But never =20 mind the technical, it's the politics that are the real challenge. Consider that all IP location proposals rely on the ASP to implement a =20 significant portion of the solution and that almost all ASPs (in =20 Canada) also provide phone service. Not only does spending money on IP location do nothing to enhance =20 their internet offerings, it actually enhances the VOIP service =20 offering of their competition. (yes I know you could technically argue =20 that location enhances their service but that will never result in =20 more customers, especially given that all ASPs would be required to =20 have the same thing) And that is only one example. Pretty much everyone agrees that a LIS is the first step in any system =20 but that's a long way from having a cost effective working IP location =20 system. --=20 John Lange ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From apenniston@geo-comm.com Mon Aug 10 14:18:19 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01AB13A6A72 for ; Mon, 10 Aug 2009 14:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdYC5MFlrFZ5 for ; Mon, 10 Aug 2009 14:18:17 -0700 (PDT) Received: from mail.geo-comm.com (geo-comm.com [66.173.42.242]) by core3.amsl.com (Postfix) with ESMTP id 826133A6F17 for ; Mon, 10 Aug 2009 14:18:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 16:20:17 -0500 Message-ID: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST Questions/Comments Thread-Index: AcoaAFwCRxMfYy0LRqmpfX/53hvJYw== From: "Avery Penniston" To: X-ST-MF-Message-Resent: 8/10/2009 16:20 Subject: [Ecrit] LoST Questions/Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 21:18:19 -0000 Hello, I have recently been reviewing the LoST proposed protocol in RFC 5222 and have some questions and comments that I am hoping I can get some help with. Since I have joined the list, discussion seems to be centered around newer topics than 5222, but I would appreciate any clarification, or comments on any of the points below. All references below refer to RFC 5222 unless stated otherwise. Avery 1.) Sec. 1 [Page3] states, "LoST satisfies the requirements [18] for mapping protocols." However I haven't seen how LoST handles this requirement from RFC 5012: "Ma13. URL for error reporting: The mapping protocol MUST support the ability to return a URL that can be used to report a suspected or known error within the mapping database." It seems that a source is returned, but not a specific URL for error reporting. 2.) Sec. 1[Page 3] states, "For civic addresses, LoST can indicate which parts of the civic address are known to be valid or invalid, thus providing address validation, as described in Section 3.5 of [18]. " However in Sec 3.5 of RFC 5012 it says that a location is valid if the location is recognizable, AND "can be mapped to one or more PSAPs". So is it implied that the request location is invalid if no mappings are returned in the findServiceResponse? If that is the case couldn't a notFound error returned imply the same? It just seems to me that perhaps the location might be valid whether or not it maps to a PSAP. 3.) Sec. 1 [Page 4] states that a LoST server optionally returns "hints" about the service boundary. As far as I could tell it was either a representation of the boundary itself or a reference to it. Not sure what is meant by hints. 4.) Sec. 2 [Page 5] in the definition for Service Boundary it states that it "circumscribes the region within which all locations map to the same service URI or set of URIs for a given service". I take this to mean that it is a polygon representing a service area. So when returning service boundaries either in mappings or in getServiceBoundaryResponse should the boundary returned be the exact boundary or can a subset of the service boundary be returned? 5.) Sec. 3 [Page 5] under it says that, "The same query type may also ask for location validation and for service numbers, either combined with a mapping request or separately". I understand that the location validation and service numbers are returned in the response, but I don't see any attribute in request that allows the explicit request for service numbers, nor do I see any query type that allows the location validation or service number query "separately". 6.) Sec. 5.1 [Page 7] Regarding the 'lastUpdated' attribute, is it intended that this time should be the time when the mapping is 'created' for example when map data is loaded on server, or when map data is updated, or when the mapping is returned to the client? This seems to imply that mappings should be created at a time prior to the request being responded to. Is that correct? 7.) Sec. 5.1 [Page 7] states, "A receiver can replace a mapping with another one having the same 'source' and sourceId' and a more recent time in 'lastUpdated'". I assume this means a client updating its cache, and not a LoST server in the middle of a recursive query? So replacing a mapping refers to replacing it in local cache and not replacing the mapping returned to a client with a newer one than the one received recursively? 8.) Sec. 5.2 [Page 8] How is it possible for a client to ever update its cache of mappings with an expiration of "NO-EXPIRATION"? It seems that the only way to get new mappings in this case is if it happens to receive a mapping with a newer 'lastUpdated' attribute. Until then the server would return invalid mapping information. When would it be advisable to use "NO-EXPIRATION"? Also, if a mapping does not contain any ServiceBoundary or ServiceBoundaryReference elements is there any reason to cache it? 9.) Sec. 5.4 [Page 8] When returning an "alternate service that approximates the desired service" is it implied here that the server MUST return a serviceSubstitution warning? 10.) Sec. 5.5 [Page 9] states, "If included in a response, the element MUST contain at least one service boundary that uses the same profile as the request". (Also point 9 under sec. 12.1) This could be difficult when trying to make a geodetic service boundary polygon 'fit' into a civic profile to match a request using a civic profile. I suppose you could omit the service boundary all together, but it would be nice to return the geodetic version of the service boundary. 11.) Sec. 5.6 [Page 10] states that, "a client receiving a mapping response can simply check if it already has a copy of the boundary with that identifier. If so, it can skip checking with the server whether the boundary has been updated. " So this implies that caching is not just for Mappings but also boundaries. Is it intended that servers should maintain a mapping cache and a separate service boundary cache? What about updating the service boundary information, as it seems that service boundaries do not have an expiration, lastUpdated, etc.? Also the part that says, "...skip checking with the server..." does this imply that if a service boundary reference is received by the client in a mapping, then the client should automatically check to see if that reference is current if it doesn't have that service boundary cached? If so how does it determine if it is 'current'? 12.) Sec. 5.8 [Page 10] Does LoST provide for alternate routing URIs? Not to be confused with a substitution. This alternate can help routing proxies or clients in the event that a service URI is unreachable. I know a mapping can contain multiple URIs, but each must use a different URN schema. 13.) Sec. 8.2.2 Fig. 3 [Page 13-14] In the returned civic service boundary, it implies the service is the city of Munich. I'm guessing this is okay as long as the civic city boundary does not extend beyond or overlap the service boundary. It also assumes that the A3 element is the smallest boundary element returned in the PIDF-LO; implying that the A1 and PC elements are either supersets or are ignored. Is there an established hierarchy of PIDF-LO civic boundary elements? 14.) Sec. 8.3.3 [Page 16] "In recursive mode, the LoST server initiates queries on behalf of the requester and returns the result to the requester". Does recursion imply querying to higher levels in the hierarchy? In other words if a LoST Server receives a request for a service outside the area it covers, should it consult a forest guide to determine where to query in order to fulfill the recursive query? Its parent? Should it only recurse to its children? 15.) Sec. 11 [Page 23] Why are via elements optional in listServicesByLocationResponse? They are required in a findServiceResponse are they not? 16.) Sec. 12 [Page 25] "Requests and responses containing or elements MUST contain location information in exactly one of the two baseline profiles." (also points 3 & 4 under sec. 12.1) Why can't a location be specified in both a civic and geodetic profile in the same request/response? 17.) Sec. 12.2 [Page 31] states, "If an authoritative server receives a query for which the area in the query overlaps the area for which the server has mapping information, then it MUST return either a mapping whose coverage area intersects the query area or a redirect to another server whose coverage area is a subset of the server's coverage area". Why redirect to just a subset, and not a neighboring coverage area? I.e. the case where a location polygon lies mostly in a neighboring county and only a small portion of that polygon is overlapping our service boundary. 18.) Sec. 12.3 [Page 31] states, "A response MAY contain more than one element with profile 'civic'". So I take this to mean that the request can have at most 1 location of each type of profile, but serviceBoundaries in the response are allowed multiple of type 'civic'. I'm not clear on the purpose here. 19.) Sec. 12.3 [Page 31] states, "Hence, a response may contain multiple elements with civic and/or geodetic location profiles". So it seems we can mix civic and geodetic-2d in the response, but not in the request location? Doesn't this contradict sec.12 on page 25? Avery Penniston - Software Developer GeoComm Inc. 601 W. Saint Germain St., Saint Cloud, MN 56301 Office: 320.240.0040 Fax: 320.240.2389 Toll Free: 888.436.2666 click here to visit www.geo-comm.com From br@brianrosen.net Mon Aug 10 18:57:29 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1EB3A6B10 for ; Mon, 10 Aug 2009 18:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHjsDJcaOiv4 for ; Mon, 10 Aug 2009 18:57:28 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B1BE83A6955 for ; Mon, 10 Aug 2009 18:57:28 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Magbt-0008Q3-2o; Mon, 10 Aug 2009 20:57:15 -0500 From: "Brian Rosen" To: "'John Lange'" , "'Hannes Tschofenig'" References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><1249584170.5335.24.camel@vandium.darkcore.net><6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com><1249587517.5335.80.camel@vandium.darkcore.net><1249656835.5053.35.camel@vandium.darkcore.net><1249675185.5053.126.camel@vandium.darkcore.net> <05b601ca1820$17fc20e0$625aa20a@nsnintra.net> <20090810161528.dn1am0meiaa88s44@www.open-it.ca> In-Reply-To: <20090810161528.dn1am0meiaa88s44@www.open-it.ca> Date: Mon, 10 Aug 2009 21:57:09 -0400 Message-ID: <004501ca1a27$0f5ed3c0$2e1c7b40$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoZ/6w17Tt42jnkR7GlVjdXuY0BqwAJx5EA 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: "'Dawson, Martin'" , 'ecrit' Subject: Re: [Ecrit] PSAP motivations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 01:57:29 -0000 Your PSAPs are a year or two behind ours. Ours said the same thing when we first started talking about i3. Just about all of them are now eager to get upgraded, although they aren't sure how they will pay for upgrades yet (or what it will cost). Fear, uncertainty, and doubt pervade this environment. Education changes the perceptions. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of John Lange > Sent: Monday, August 10, 2009 5:15 PM > To: Hannes Tschofenig > Cc: 'Dawson, Martin'; 'ecrit' > Subject: [Ecrit] PSAP motivations > > I'm changing the topic on this thread to accurately reflect the fact > that were straying off topic for this mailing list ;) > > Quoting Hannes Tschofenig : > > > Hi John, > > > > in addition to what Martin said about the negative impact on the > "public". > > > > My guess is that the emergency services networks will move their > networks to > > IP (because of the lower costs) and then they will not require the > ILECs > > todo the gatewaying of all the calls. > > That will not happen any time soon. The PSAPs have sworn allegiance to > the ILECs and will not connect their equipment to anything except the > ILECs. They have reiterated this frequently. > > > They will be able to get emergency calls directly from the VoIP > providers. > > As long as the current PSAP management is involved that will never > happen. They have stated this time and again. No PSAP system will ever > be connected to the Internet. > > > This will be less expensive, will > > support additional media and more extensible for future deployments. > This is > > an evolution step we observe in many countries. > > > > One interesting data point I would like to understand is whether the > > PSAPs/emergency services networks have to pay to the ILECs for their > > emergency call routing and gatewaying "offering". > > Yes the ILECs get compensation for their services though I do not know > the exact model and I suspect it's different in province. > > On top of that the various providers are allowed to charge a "911 > access fee" to every subscriber including wireless and standard > wireline. This is a major source of revenue which they are motivated > to protect. > > They recently took some heat about this when it was revealed that this > charge has nothing whatever to do with the actual cost of providing > the service and they are under no obligation to spend the money to > improve 911 service. > > Case in point, we still can't do location for cell phones despite the > fact that the one time cost of implementing the system would only be a > fraction of the money collected in 911 fees EACH YEAR. > > > If they have to then there is obviously incentive for them to move > > away from that model. > > I wouldn't say it's obvious. In fact I don't think saving the public > money is anywhere near the top of PSAP motivations. For example, > Ontario has something like 140(!) regional PSAPs (pretty much every > municipality has one but I can't seem to get a straight answer on > exactly how many there are). Roughly one PSAP for every 80,000 people. > One of the big stumbling blocks to this whole process is that PSAPs > will have to upgrade equipment. That gets expensive when you have to > do it 140 times. > > No PSAP is going to suggest "hey, this would be a good time > consolidate 140 PSAPs and save a bundle of money!" > > Rather, PSAPs are motivated by bad press. They avoid anything that may > cause them not to be able to do their jobs and that boils down to > "change". > > I agree with them that we should be conservative with regard to change > in the 911 system but the problem is the Canadian PSAPs have become a > too dogmatic fighting change. > > They actually tried to convince the CRTC to ban VOIP outright and > since then they've spent too much of their time fighting change rather > than considering what benefits new 911 systems could offer. > > > PS: I am always curious why people see the step to a NENA i2.5 or > pre-ECRIT > > architecture as so complicated particularly when the largest > investment is > > in the location server capability in the access networks (and those > have to > > be done anyway regardless of the chosen architecture). > > Conversely, I find those kinds of statements as highly curious. From a > technical perspective, real-time IP location is complicated. But never > mind the technical, it's the politics that are the real challenge. > > Consider that all IP location proposals rely on the ASP to implement a > significant portion of the solution and that almost all ASPs (in > Canada) also provide phone service. > > Not only does spending money on IP location do nothing to enhance > their internet offerings, it actually enhances the VOIP service > offering of their competition. (yes I know you could technically argue > that location enhances their service but that will never result in > more customers, especially given that all ASPs would be required to > have the same thing) > > And that is only one example. > > Pretty much everyone agrees that a LIS is the first step in any system > but that's a long way from having a cost effective working IP location > system. > > -- > John Lange > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From john.elwell@siemens-enterprise.com Tue Aug 11 00:56:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692EF3A67F4 for ; Tue, 11 Aug 2009 00:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6jQIS7h93lk for ; Tue, 11 Aug 2009 00:56:28 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7D3F73A69F3 for ; Tue, 11 Aug 2009 00:56:27 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KO7003B6CQ59V@siemenscomms.co.uk> for ecrit@ietf.org; Tue, 11 Aug 2009 08:56:30 +0100 (BST) Date: Tue, 11 Aug 2009 08:56:27 +0100 From: "Elwell, John" In-reply-to: <40FB0FFB97588246A1BEFB05759DC8A003480A25@S4DE9JSAANI.ost.t-com.de> To: L.Liess@telekom.de, br@brianrosen.net, Martin.Dawson@andrew.com, R.Jesske@telekom.de, ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0023D22B0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rAAA0M6gAACNUgwAAM0rIAAksimsAAmq6qQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <042001ca175f$a92e0d60$fb8a2820$@net> <40FB0FFB97588246A1BEFB05759DC8A00348055D@S4DE9JSAANI.ost.t-com.de> <046201ca1776$1a2bfa70$4e83ef50$@net> <40FB0FFB97588246A1BEFB05759DC8A003480A25@S4DE9JSAANI.ost.t-com.de> Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 07:56:30 -0000 =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of L.Liess@telekom.de > Sent: 10 August 2009 14:58 > To: br@brianrosen.net; Martin.Dawson@andrew.com;=20 > R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > Brian, > =20 > My expectation was that framework and phonepcb contain enough=20 > options to cover also short term scenarios and help us to=20 > implement VoIP emergency calling now. This seems not to be=20 > the case. We can not require now from our SIP-proxy vendors=20 > to comply with the framework and phone-pcb because this does=20 > not work with the existing EDs. Currently, ECRIT does not=20 > offer all components to build an EC architecture which works=20 > now. As a result, DT and other carriers must build and=20 > require from their vendors proprietary solutions which work now. > =20 > We can take the approach that Hannes describes and do it=20 > later, it's better than not at all. However, when people=20 > already have proprietary solutions in place, it is difficult=20 > change them. > =20 > Concerning the local dial string, we do not have currently=20 > any plans for something different from 112 and the national=20 > EC dial string (110) or to allow the nomadic usage of the=20 > VoIP service outside Germany.=20 [JRE] But how does a visiting device from the US, say, discover that the = local dial string in Germany is 112? John > =20 > Laura > =20 >=20 >=20 > ________________________________ >=20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, August 07, 2009 5:46 PM > To: Liess, Laura; Martin.Dawson@andrew.com; Jesske,=20 > Roland; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP > =09 > =09 >=20 > Laura >=20 > =20 >=20 > I don't think we're going to get to the point where the=20 > IETF rolls back -framework and -phonebcp far enough to suit=20 > you. The approach that Hannes described, which is to finish=20 > the current work as is, and then go back and see if we can=20 > standardize a way for VoIP services to connect to older=20 > systems with more limited capabilities using OBO and other=20 > tricks, makes some sense to me. =20 >=20 > =20 >=20 > However, device vendors have to build devices that work=20 > in countries that are more aggressively upgrading their=20 > emergency systems, without unduly burdening you. What I'm=20 > attempting to do is to figure out a way that you can work=20 > with a -phonebcp compliant device, without incurring a lot of cost. >=20 > =20 >=20 > We're not going to make it zero. >=20 > =20 >=20 > If you don't like a poly, return any street address in=20 > the area code. In most cases, it could be a PIDF with a=20 > couple of A levels that works for the town. >=20 > =20 >=20 > All that matters is that if a -phonebcp client queries=20 > an LCP, it should get a location that, when passed to LoST,=20 > gets the right URI. If the location is coarse, that is okay;=20 > it works. I'd like you to deploy HELD and LoST servers in=20 > your networks that return the right thing to the endpoint and=20 > not just to the OBO proxy, but even if you don't, phonebcp=20 > compliant end devices will "work" in your network: their=20 > attempts to reach LIS and LoST servers will fail, and they=20 > will send emergency calls without location and PSAP URI, and=20 > your proxy can fill in the right stuff. >=20 > =20 >=20 > You don't need -phonebcp compliant endpoints. Good for=20 > you. However, vendors ought to make phonebcp compliant=20 > endpoints so that they work everywhere. >=20 > =20 >=20 > If you want less that that, then I'm not sure IETF can=20 > oblige, since we don't do nation specific solutions and some=20 > nations need the full -phonebcp spec. >=20 > =20 >=20 > One complication you should consider: devices need to=20 > know the local dial string(s) for emergency calls. In the=20 > IETF architecture, LoST provides that. What were you=20 > planning on doing? >=20 > =20 >=20 > Brian >=20 > =20 >=20 > =20 >=20 > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > Sent: Friday, August 07, 2009 10:45 AM > To: br@brianrosen.net; Martin.Dawson@andrew.com;=20 > R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > Hi Brian, >=20 > =20 >=20 > Please see comments inline. =20 >=20 > =20 >=20 > =20 >=20 > ________________________________ >=20 > From: Brian Rosen=20 > [mailto:br@brianrosen.net]=20 > Sent: Friday, August 07, 2009 3:05 PM > To: Liess, Laura; Martin.Dawson@andrew.com;=20 > Jesske, Roland; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > Actually, the PIDF-LO is designed to cater for=20 > all the variations in addressing. You don't mean "location=20 > used for emergency calls", you mean "key for location used=20 > for emergency calls". The area code is not the location, it=20 > is a key that is mapped to PSAP URI.=20 > [[LLi]] This is correct. >=20 > =20 >=20 > The telephone number (with its area code) is=20 > the identifier you would use with HELD to get the location, =20 > from which LoST would get you a PSAP URI. > [[LLi]] Here we don't use the phone number. The=20 > proxy sends the IP-address to the LIS. The LIS finds out the=20 > access hardware (DSLAM port) corresponding to the IP-address=20 > and assigns a temporary string to it (kind of LbyR). It also=20 > finds out the phone area code for this hardware. With the=20 > phone area code, the LIS queries a table which contains the=20 > phone area codes and the corresponding PSAP URI, then=20 > delivers the the string (LbyR) and the PSAP-URI to the SIP=20 > proxy. The SIP proxy routes the call and sends the LbyR to=20 > the PSAP. In very few cases, PSAPs dereference the the LyBR=20 > to a civic address.=20 >=20 > We do not have any kind of geo data or poligons=20 > in our database. In principle we have the the civic address,=20 > but the access to this data is quite slow. I think other=20 > fixed networks carriers here have more or less the same.=20 >=20 > =20 >=20 > This seems trivial for you to implement: you=20 > deploy a HELD server that takes telephone number and returns=20 > a polygon representing the area code boundary, and you deploy=20 > a LoST server that takes that polygon and returns the PSAP=20 > URI associated with it. =20 >=20 > This would be no more expensive than what you=20 > are proposing. Proxies could use this or phonebcp compatible=20 > endpoints could use it. =20 >=20 > =20 >=20 > NENA is planning on doing pretty much this same=20 > thing to handle legacy wireline networks where telephone=20 > number is currently the key to the location database (ALI). =20 > The LIS will store location as the key (using held-identity),=20 > and a gateway will construct an LbyR from the phone number. =20 > All the rest of the ecrit compatible infrastructure can then=20 > use the Location URI to get location, route, etc. >=20 > =20 >=20 > Making what you now see as a one step mapping=20 > (area code to PSAP URI) into a two step (telephone number to=20 > polygon, polygon to PSAP URI) is a bit more complex, but not=20 > any significant difference in deployment. It also works for=20 > wireless (cell sector/ID to polygon, polygon to PSAP URI),=20 > and of course, would be upwardly compatible with real=20 > location based routing, should your systems evolve as we=20 > expect they evolve, or something like EU regulations compel=20 > more accurate location services. >=20 > [[LLi]] Nobody here is willing to putting=20 > geodata or poligons into the access databases. And we could=20 > avoid doing this just by allowing the LIS to query the local=20 > LOST with the LbyR and to deliver the PSAP URI to the SIP proxy. =20 >=20 > =20 >=20 > Kind regards >=20 > Laura >=20 > =20 >=20 > Brian >=20 > =20 >=20 > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of L.Liess@telekom.de > Sent: Friday, August 07, 2009 7:59 AM > To: Martin.Dawson@andrew.com;=20 > R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > =20 >=20 > Hi Martin, =20 >=20 > Hi Laura, >=20 > =20 >=20 > I regard it as a goal of ECRIT - as=20 > derived from the goals of the IETF generally - to define a=20 > structure that will allow an Internet capable device to=20 > connect to a network anywhere in the world and be able to=20 > make emergency calls. Just as FTP, email protocols, SIP and=20 > etc. all work regardless of which network the devices attach=20 > to. I don't understand how the kind of variations that you=20 > are requesting be added to the specification will allow that to occur. >=20 > [[LLi]] This is fine and usefull. Just=20 > that every country uses today different formats for the=20 > location used for emergency calls. Changing this will take=20 > time and costs money.=20 >=20 > What is the harm in allowing ECs to=20 > work with local location formats which are understood only by=20 > the LIS and the PSAP ?. I dont see why a common location=20 > format must be implemented by everybody.=20 >=20 > Maybe the EC could work like this :=20 >=20 > =B7 The proxy discovers the LIS=20 > based on EDs IP-address using reverse-DNS and SRV record=20 > (this is possible with "identity extenssions")=20 >=20 > =B7 It retrieves the location (=20 > e.g. using HELD) in a local format understood only by the LIS=20 > and the PSAP, which are in the same country. The location is=20 > just a string which is passed transparently through the=20 > network to the PSAP. In my opinion, it would be in principle =20 > posible to use LbyR to transport local location identidfiers,=20 > e. g. area-code@lis.telekom.de , but this is currently my=20 > personal opinion, I didn' found any statemant or example in=20 > the drafts. =20 >=20 > =B7 The LIS delivers, together=20 > with the LbyR above, the PSAP URI. As far as I know there is=20 > currently no way to do this in HELD (or did I miss=20 > something?). =20 > =20 >=20 > It would be an alternative which is=20 > interoperable and quite easy to implement, without the need=20 > for the operators to change their location databases. I think=20 > by allowing this scenario, interoperable EC could be achieved=20 > earlier. And this does not exclude the scenario described in=20 > the framework and phone-bcp, where the EDs retrieve deo or=20 > civic location, which is needed for EC to work in=20 > private/enterprise networks. =20 > =20 >=20 > =20 >=20 > =20 >=20 > The position appears to be that the=20 > German regulator doesn't require anything - and the operators=20 > will not be proactive in following a specification if it=20 > doesn't include what already exists. In that context, I don't=20 > understand why there is a need for the BCP at all. There may=20 > be no need to endorse it but, similarly, there should be no=20 > need to object to it - since the operators will only put in=20 > place their preferred version of the service in any case.=20 > [[LLi]] This is not quite true. We=20 > have to ensure that EC works for different AN- and=20 > VoIP-provider and for nomadic users in Germany by 2013. Our=20 > current solution does not allow this and there is the same=20 > for other carriers. We definitively need to define in Germany=20 > an architecture which fullfills this requirements. It would=20 > be very usefull if we can use standard protocols. But nobody=20 > will be willing to change everything at once. Having a=20 > standard based architecture which is low cost would be a=20 > great advantage.=20 >=20 > =20 >=20 > Kind regards >=20 > Laura =20 >=20 > =20 >=20 > That's OK... insofar as it just means=20 > German networks aren't ECRIT compatible - "compatibility"=20 > isn't a worthy goal in and of itself; it has to actually mean=20 > any device can work anywhere. >=20 > =20 >=20 > Cheers, >=20 > Martin >=20 > =20 >=20 > ________________________________ >=20 > From: L.Liess@telekom.de=20 > [mailto:L.Liess@telekom.de]=20 > Sent: Friday, 7 August 2009 12:29 AM > To: Dawson, Martin;=20 > R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > Hi Martin,=20 >=20 > =20 >=20 > See comments inline [[LLi]]. >=20 > =20 >=20 > =20 >=20 > Laura >=20 > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawson, Martin > Sent: Wednesday, August 05,=20 > 2009 11:00 AM > To: Jesske, Roland; ecrit@ietf.org > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > Hi Roland, >=20 > =20 >=20 > I think what you're saying is=20 > that you don't think that Germany will go on to implement=20 > full ECRIT support but will peg development at an interim phase.=20 > [[LLi]] We don't know how the=20 > realtime application networks or EC will look like in 20=20 > years. Roland's answer only applies to the next 5 to 10 years.=20 >=20 > =20 >=20 > That would be disappointing -=20 > not least because full ECRIT compliance would ultimately=20 > decrease the overhead associated with emergency service=20 > support for operators as well as providing a more universal service. > =09 > [[LLi]] This may be true for=20 > "green field" ISPs and VSPs but not for incumbent carriers=20 > with existing infrastructure. And universal service is not a=20 > requirement for us. Neither the German regulator requires it=20 > nor is it a busines case. =20 >=20 > =20 >=20 > Nevertheless, I don't think=20 > that decision invalidates the BCP;=20 > [[LLi]] We think it does,=20 > because some of the requirements are not flexible enough to=20 > cover the deployments within the next years. The BCP should=20 > be more flexible: =20 >=20 > =B7 Allow additional=20 > location identifiers =20 >=20 > =B7 Allow AN operated LOST=20 >=20 > =B7 Provide a way to=20 > enable LOST-query based on national or domain-specific=20 > location identifier. One posiblility is to allow the LIS to=20 > query the LOST , but there are also other alternatives. =20 >=20 > =B7 Allow and describe=20 > also network-centric, not only ED-centric architectures. If I=20 > remember correctly, John Medland from BT also recomended to=20 > use a more network- centric architecture, at least for the=20 > next years.=20 >=20 > =20 >=20 > I think it just means that the=20 > German regulator and technical advisory committees would=20 > point out the subset aspects of compliance that would be=20 > applicable to that jurisdiction. =20 > [[LLi]] Again, the draft is=20 > not flexible enough for it. If the BCP contains requirements=20 > which are not realistic, people will just discard the BCP and=20 > implement proprietary stuff. My expectation from a standard=20 > body is to define protocols and architecture which people are=20 > willing to implement in their network or products , not only=20 > in the lab. >=20 > =20 >=20 > [[LLi]] =20 >=20 > We are not against the draft in=20 > principle. ECRIT provides us with very valuable=20 > specifications as LbyR, HELD, identity extensions. But=20 > targeting an architecture which requires everbody to invest=20 > without a business case will not help the draft in the end,=20 > also if it becomes a BCP. It would make sense to make it=20 > more flexible so people are willing to adopt it. =20 >=20 > =20 >=20 > Actually, based on your=20 > description below, the NENA i2 architecture would probably be=20 > a more straightforward baseline for analysis - as has been=20 > done in the UK and Canada. Of course, it's generally=20 > recognized as only an interim step, even in those jurisdictions. >=20 > Other comments below. >=20 > =20 >=20 > Cheers, >=20 > Martin >=20 > =20 >=20 > ________________________________ >=20 > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: Wednesday, 5 August 2009 6:19 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > =20 >=20 > Dear all,=20 > We would like the document to=20 > become a BCP as soon as possible so the group can move on=20 > with other documents related to emergency calling based on=20 > location-by-reference and ED's IP-address.=20 >=20 > [[MCD]] I think you might mean=20 > "identity extensions" rather than location-by-reference=20 > because LbyR still requires the ED to obtain the reference -=20 > e.g. by HELD. > [[LLi]] We use both, the=20 > IP-address as UE identity and LbyR. The SIP-proxy uses the=20 > IP-address to query the LIS using HTTP (it's not HELD but=20 > SOAP over HTTP, but anyway similar). The LIS responds with a=20 > numeric string associated to the caller location, in=20 > principle a LbyR and with the PSAP number. The proxy inserts=20 > the LbyR into the SIP-message (as P-Asserted-ID because the=20 > PSAPs are in PSTN) and routes the message to the PSAP. It's=20 > a low cost solution.=20 >=20 > But we can not HUM for the=20 > current form of the document.=20 >=20 > Back to the document: Some=20 > requirements are far form being realistic, at least in=20 > Germany, some are not realistic at all. Implementing these=20 > requirements cost a carrier a lot of money and there is no=20 > ROI for it.=20 >=20 > Just a few examples:=20 >=20 > =B7 Requiring either geo or=20 > civic location does not provide carriers with enough=20 > flexibility to reuse their existing mechanisms and location=20 > databases. Routing of emergency calls is currently done in=20 > Germany based on phone area code not on geo or civic=20 > location, at least for the fixed network. For mobile networks=20 > the cell-id is used in common. This is regulated by the=20 > german regulator.=20 >=20 > [[MCD]] How many unique PSAP=20 > routes are required in Germany? The US has lots (6000 plus)=20 > and Australia has two (and they are redundant so it doesn't=20 > matter which one). Presumably geographic information, for=20 > PSAP catchment areas, is the basis for determining which area=20 > codes are relevant to begin with? After all, an area code is=20 > not intrinsically geographic; it's a network routing value.=20 > If so, then some geographic discriminator is already in play=20 > in terms of constructing the area code based routing data=20 > (something like zip codes perhaps?) - and in that case, it=20 > should be straightforward to by-pass the area code step in=20 > the construction of routing that goes the correct PSAP URI.=20 > [[LLi]] Currently, fixed=20 > networks carriers in Germany route the ECs based only on the=20 > caller's area code. Sometime in the past, the carriers, the=20 > regulator and the PSAPs operators (police, the Red Cross)=20 > agreed to do so. This may change in the future, but it will=20 > take a quite long time. =20 >=20 > With nomadic VoIP devices (and=20 > it's no good being in denial about this being the norm in the=20 > future) area code is no more reliable than it is for=20 > conventional mobile phones. And, presumably, area code is not=20 > used for conventional cellular emergency call routing? > [[LLi]] As far as I know,=20 > mobile networks use the Cell-ID, not the area code, and have=20 > a different table than the fixed network operators. They are=20 > not going to change this. As to the nomadic SIP-users...if=20 > we like it or not, very few of our customers use our SIP=20 > service nomadic, let alone call EC from their laptop. =20 >=20 > 1 LOST as a=20 > national, let alone as a global directory is not going to be=20 > implemented. The regulator will provide in the web a static=20 > table which contains the PSAPs and the area for which they=20 > are responsible (one or more area codes). Every carrier has=20 > to implement its own routing database for emergency calls.=20 >=20 > [[MCD]] Whatever the=20 > carriers implement (and they have to implement something)=20 > could just as readily be done using LoST. Then visiting=20 > devices, with no association with any local VoIP proxy server=20 > would still be able to determine a route to the correct PSAP.=20 > Alternatively, as long as the regulator is maintaining a web=20 > service with the routing information, why not make that=20 > directly accessible using LoST and save the operators the=20 > cost of duplicating the service at all? > [[LLi]] There is a big=20 > difference between maintaining a web page with a table which=20 > operator can print and implement in their darabases and=20 > operating a database which is queried for every emergency=20 > call in Germany, must have an availablity of 99,99...% , is=20 > secure enough...you know. The regulator will not do this. >=20 > =09 > 2 We have no=20 > intention to rely on end devices for location information because:=20 > =B7 ED provided=20 > location info is not trusted=20 >=20 > [[MCD]] Location by reference=20 > mitigates this trust issue. The emergency network can=20 > (automatically and before human resources are engaged) assess=20 > the source of the reference, and the validity of the location=20 > by dereference, without having to trust location provided=20 > directly from the ED. There are more sophisticated approaches=20 > to trustability even using LbyV - based on digital signatures=20 > across appropriate attributes. This WG and Geopriv haven't=20 > really got to grips with that... yet. > [[LLi]] We build the=20 > SIP-network and EC now. ED-provided location is needed if EC=20 > must work for private and enterprise networks and VPNs. We=20 > have no such regulatory requirements. And we don't know of=20 > any verdor of DSL-EDs which provides today SIP with LbyR and=20 > is as cheap as the devices without it. If you do, please let me know.=20 >=20 > The regulator ask us to=20 > guarantee that EC works. What if a customer dials 112 and his=20 > end device does not send the location? So I have to implement=20 > both solutions, with and without ED provided location, anyway. =20 > 1 There are already a lot=20 > of existing EDs in usage which don't send location. =20 >=20 > [[MCD]] Quite right. ECRIT=20 > doesn't overly concern itself with that interim situation.=20 > The UK and Canadian definitions for an interim solution=20 > (limiting service to in-country VoIP proxy operators) both=20 > assume third-party query via identity-extension to allow the=20 > proxy or the VPC to make the query to the LIS. This isn't=20 > extensible to universal emergency service access by all=20 > visiting devices but it does put the necessary LIS=20 > functionality in place as a very good starting point. It=20 > would be a pity if Germany were to cease the evolution there=20 > as it would not fulfil the real promise of the Internet and=20 > the ECRIT model.=20 > [[LLi]] I wonder who will=20 > drive and pay for upgrading the interim solutions. =20 > Unfortunatelly, it's all about money... >=20 > Think about it; all the=20 > complexity of putting location determination infrastructure=20 > in place for the purposes of dispatch is done - and then the=20 > next, simpler step, of using that to support the routing=20 > procedure isn't taken... that would be a waste. > =09 > [[LLi]] Do you think this is=20 > an argument for a product manager? They need a business case. =20 >=20 > =20 >=20 > =20 >=20 > We don't intend to require=20 > our ED-vendors to provide location because it is useless to us. =20 >=20 > We could agree with the=20 > document with following changes:=20 >=20 > o Other location identifiers=20 > then geo or civil are allowed. It must be possibe that the=20 > data foermat is flexible due to different requirements from=20 > regulators over the whole world. (e.G Germany area codes for=20 > fixed- and Cell-Id for moile- providers)=20 >=20 > o The MUST for the end=20 > devices to support location information, DHCP location=20 > options and HELD shall be removed=20 >=20 > o It must be possible for=20 > the VoIP-provider's proxy to use a LOST (or an ESRP) provided=20 > by the AN or by other local provider on behalf of the AN. =20 >=20 > =20 >=20 > There is no value in Hum-ing=20 > documents which one is not going to implement and does not=20 > fit into regulated schemes like in Germany. Currently,=20 > neither the IETF- nor the 3GPP-architecture for emergency=20 > calling covers our real needs for the next 2 to 5 years and=20 > in the end everybody still has its own proprietary implementation. =20 >=20 > Best regards=20 >=20 > Roland=20 >=20 > =20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Roland Jesske > Gateways, Protokolle, Konvergenz, TE32-1 > Heinrich-Hertz-Str. 3-7, 64295=20 > Darmstadt, > Postfach, 64307 Darmstadt=20 > (Postanschrift) > +496151 628 2766 (Tel) > +491718618445 (Mobile) > E-Mail: r.jesske@telekom.de=20 > =20 > http://www.telekom.de=20 > =20 >=20 > =20 >=20 > Registerrechtliche Unternehmensangaben: > Deutsche Telekom Netzproduktion=20 > (DT NP) GmbH > Aufsichtsrat: Timotheus H=F6ttges=20 > (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno=20 > Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht=20 > Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262=20 >=20 > =20 >=20 > =20 >=20 > =09 > =09 > -------------------------------------------------------------- > ---------------------------------- > This message is for the=20 > designated recipient only and may > contain privileged,=20 > proprietary, or otherwise private information. =20 > If you have received it in=20 > error, please notify the sender > immediately and delete the=20 > original. Any unauthorized use of > this email is prohibited. > =09 > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > =09 >=20 > =20 >=20 > =20 >=20 > =09 > =09 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated=20 > recipient only and may > contain privileged, proprietary, or=20 > otherwise private information. =20 > If you have received it in error,=20 > please notify the sender > immediately and delete the original. =20 > Any unauthorized use of > this email is prohibited. > =09 > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > =09 >=20 > =20 >=20 >=20 From hannes.tschofenig@nsn.com Tue Aug 11 01:01:03 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74EC3A6CC1 for ; Tue, 11 Aug 2009 01:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.165 X-Spam-Level: X-Spam-Status: No, score=-5.165 tagged_above=-999 required=5 tests=[AWL=1.434, 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 xOMj+n6ORxjr for ; Tue, 11 Aug 2009 01:01:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6CCE93A6A3D for ; Tue, 11 Aug 2009 01:01:02 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7B80sHr014764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Aug 2009 10:00:54 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7B80rSx007320; Tue, 11 Aug 2009 10:00:54 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 10:00:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2009 11:03:26 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501974AE4@FIESEXC015.nsn-intra.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0023D22B0@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rAAA0M6gAACNUgwAAM0rIAAksimsAAmq6qQAAAxkiA= References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de><40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de><40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de><042001ca175f$a92e0d60$fb8a2820$@net><40FB0FFB97588246A1BEFB05759DC8A00348055D@S4DE9JSAANI.ost.t-com.de><046201ca1776$1a2bfa70$4e83ef50$@net><40FB0FFB97588246A1BEFB05759DC8A003480A25@S4DE9JSAANI.ost.t-com.de> <0D5F89FAC29E2C41B98A6A762007F5D0023D22B0@GBNTHT12009MSX.gb002.siemens.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Elwell, John" , , , , , X-OriginalArrivalTime: 11 Aug 2009 08:00:54.0275 (UTC) FILETIME=[D9D8B530:01CA1A59] Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 08:01:03 -0000 >[JRE] But how does a visiting device from the US, say,=20 >discover that the local dial string in Germany is 112? RFC 5222: http://www.ietf.org/rfc/rfc5222.txt=20 (It would also discover any other emergency number used in Germany) From john.elwell@siemens-enterprise.com Tue Aug 11 01:04:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE2B3A6F89 for ; Tue, 11 Aug 2009 01:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV1ftDSYPIft for ; Tue, 11 Aug 2009 01:04:57 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 5A2943A6F7E for ; Tue, 11 Aug 2009 01:04:56 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KO7003ATD4BJM@siemenscomms.co.uk> for ecrit@ietf.org; Tue, 11 Aug 2009 09:04:59 +0100 (BST) Date: Tue, 11 Aug 2009 09:04:58 +0100 From: "Elwell, John" In-reply-to: <3D3C75174CB95F42AD6BCC56E5555B4501974AE4@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" , L.Liess@telekom.de, br@brianrosen.net, Martin.Dawson@andrew.com, R.Jesske@telekom.de, ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0023D22C0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rAAA0M6gAACNUgwAAM0rIAAksimsAAmq6qQAAAxkiAAABUZEA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <042001ca175f$a92e0d60$fb8a2820$@net> <40FB0FFB97588246A1BEFB05759DC8A00348055D@S4DE9JSAANI.ost.t-com.de> <046201ca1776$1a2bfa70$4e83ef50$@net> <40FB0FFB97588246A1BEFB05759DC8A003480A25@S4DE9JSAANI.ost.t-com.de> <0D5F89FAC29E2C41B98A6A762007F5D0023D22B0@GBNTHT12009MSX.gb002.siemens.net> <3D3C75174CB95F42AD6BCC56E5555B4501974AE4@FIESEXC015.nsn-intra.net> Cc: Reinhard.Lauster@t-mobile.at Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 08:04:57 -0000 I know that, but I thought Laura was arguing against the need to support LoST. With the rest of the thread stripped, my question below appears our of context. John=20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: 11 August 2009 09:03 > To: Elwell, John; L.Liess@telekom.de; br@brianrosen.net;=20 > Martin.Dawson@andrew.com; R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > >[JRE] But how does a visiting device from the US, say,=20 > >discover that the local dial string in Germany is 112? >=20 > RFC 5222: http://www.ietf.org/rfc/rfc5222.txt=20 >=20 > (It would also discover any other emergency number used in Germany) >=20 From L.Liess@telekom.de Tue Aug 11 02:13:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1170B3A6FCE for ; Tue, 11 Aug 2009 02:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lxwUgt7sbKT for ; Tue, 11 Aug 2009 02:13:09 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id A24973A6FD2 for ; Tue, 11 Aug 2009 02:13:08 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 11 Aug 2009 11:12:51 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 11:12:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2009 11:12:50 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003480C91@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0023D22B0@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoVlg1+uXzrYFJuRKibGSt8FCuF0QADzDswAACFEfAAMS1UkAANvlPQACtf+rAAA0M6gAACNUgwAAM0rIAAksimsAAmq6qQAABrjiA= References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A003431659@S4DE9JSAANI.ost.t-com.de> <042001ca175f$a92e0d60$fb8a2820$@net> <40FB0FFB97588246A1BEFB05759DC8A00348055D@S4DE9JSAANI.ost.t-com.de> <046201ca1776$1a2bfa70$4e83ef50$@net> <40FB0FFB97588246A1BEFB05759DC8A003480A25@S4DE9JSAANI.ost.t-com.de> <0D5F89FAC29E2C41B98A6A762007F5D0023D22B0@GBNTHT12009MSX.gb002.siemens.net> From: To: X-OriginalArrivalTime: 11 Aug 2009 09:12:51.0685 (UTC) FILETIME=[E7393150:01CA1A63] Cc: Martin.Dawson@andrew.com, ecrit@ietf.org, Reinhard.Lauster@t-mobile.at, R.Jesske@telekom.de Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 09:13:12 -0000 =20 John,=20 It depends on who operates the device. An IMS mobile operator will = support this because the P-CSCF will be in Germany and will recognize = 112 as an EC. For the fixed networks, we are not aware of any = requirements to support non-IMS nomadic devices operated from the US. It = is in principle a nice thing, but we do not have requirements for this. = =20 More than that, the new German law (March 2009) is more restrictive then = the old one. EC from mobile phones without valid SIM-card are no longer = allowed and carriers must ensure that they do not route calls originated = outside Germany to german PSAPs. This is because PSAPs have problems = to distinguish between real and bogus ECs. The real problem is the PSAPs = overload, they just do not have enough people to answer the calls they = get. Other than in US and Canada, there is no "112 access fee" in = Germany. =20 Laura -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Tuesday, August 11, 2009 9:56 AM To: Liess, Laura; br@brianrosen.net; Martin.Dawson@andrew.com; Jesske, = Roland; ecrit@ietf.org Cc: Reinhard.Lauster@t-mobile.at Subject: RE: [Ecrit] HUM on PhoneBCP =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of L.Liess@telekom.de > Sent: 10 August 2009 14:58 > To: br@brianrosen.net; Martin.Dawson@andrew.com;=20 > R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > Brian, > =20 > My expectation was that framework and phonepcb contain enough=20 > options to cover also short term scenarios and help us to=20 > implement VoIP emergency calling now. This seems not to be=20 > the case. We can not require now from our SIP-proxy vendors=20 > to comply with the framework and phone-pcb because this does=20 > not work with the existing EDs. Currently, ECRIT does not=20 > offer all components to build an EC architecture which works=20 > now. As a result, DT and other carriers must build and=20 > require from their vendors proprietary solutions which work now. > =20 > We can take the approach that Hannes describes and do it=20 > later, it's better than not at all. However, when people=20 > already have proprietary solutions in place, it is difficult=20 > change them. > =20 > Concerning the local dial string, we do not have currently=20 > any plans for something different from 112 and the national=20 > EC dial string (110) or to allow the nomadic usage of the=20 > VoIP service outside Germany.=20 [JRE] But how does a visiting device from the US, say, discover that the = local dial string in Germany is 112? John > =20 > Laura > =20 >=20 >=20 > ________________________________ >=20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, August 07, 2009 5:46 PM > To: Liess, Laura; Martin.Dawson@andrew.com; Jesske,=20 > Roland; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP > =09 > =09 >=20 > Laura >=20 > =20 >=20 > I don't think we're going to get to the point where the=20 > IETF rolls back -framework and -phonebcp far enough to suit=20 > you. The approach that Hannes described, which is to finish=20 > the current work as is, and then go back and see if we can=20 > standardize a way for VoIP services to connect to older=20 > systems with more limited capabilities using OBO and other=20 > tricks, makes some sense to me. =20 >=20 > =20 >=20 > However, device vendors have to build devices that work=20 > in countries that are more aggressively upgrading their=20 > emergency systems, without unduly burdening you. What I'm=20 > attempting to do is to figure out a way that you can work=20 > with a -phonebcp compliant device, without incurring a lot of cost. >=20 > =20 >=20 > We're not going to make it zero. >=20 > =20 >=20 > If you don't like a poly, return any street address in=20 > the area code. In most cases, it could be a PIDF with a=20 > couple of A levels that works for the town. >=20 > =20 >=20 > All that matters is that if a -phonebcp client queries=20 > an LCP, it should get a location that, when passed to LoST,=20 > gets the right URI. If the location is coarse, that is okay;=20 > it works. I'd like you to deploy HELD and LoST servers in=20 > your networks that return the right thing to the endpoint and=20 > not just to the OBO proxy, but even if you don't, phonebcp=20 > compliant end devices will "work" in your network: their=20 > attempts to reach LIS and LoST servers will fail, and they=20 > will send emergency calls without location and PSAP URI, and=20 > your proxy can fill in the right stuff. >=20 > =20 >=20 > You don't need -phonebcp compliant endpoints. Good for=20 > you. However, vendors ought to make phonebcp compliant=20 > endpoints so that they work everywhere. >=20 > =20 >=20 > If you want less that that, then I'm not sure IETF can=20 > oblige, since we don't do nation specific solutions and some=20 > nations need the full -phonebcp spec. >=20 > =20 >=20 > One complication you should consider: devices need to=20 > know the local dial string(s) for emergency calls. In the=20 > IETF architecture, LoST provides that. What were you=20 > planning on doing? >=20 > =20 >=20 > Brian >=20 > =20 >=20 > =20 >=20 > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > Sent: Friday, August 07, 2009 10:45 AM > To: br@brianrosen.net; Martin.Dawson@andrew.com;=20 > R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > Hi Brian, >=20 > =20 >=20 > Please see comments inline. =20 >=20 > =20 >=20 > =20 >=20 > ________________________________ >=20 > From: Brian Rosen=20 > [mailto:br@brianrosen.net]=20 > Sent: Friday, August 07, 2009 3:05 PM > To: Liess, Laura; Martin.Dawson@andrew.com;=20 > Jesske, Roland; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > Actually, the PIDF-LO is designed to cater for=20 > all the variations in addressing. You don't mean "location=20 > used for emergency calls", you mean "key for location used=20 > for emergency calls". The area code is not the location, it=20 > is a key that is mapped to PSAP URI.=20 > [[LLi]] This is correct. >=20 > =20 >=20 > The telephone number (with its area code) is=20 > the identifier you would use with HELD to get the location, =20 > from which LoST would get you a PSAP URI. > [[LLi]] Here we don't use the phone number. The=20 > proxy sends the IP-address to the LIS. The LIS finds out the=20 > access hardware (DSLAM port) corresponding to the IP-address=20 > and assigns a temporary string to it (kind of LbyR). It also=20 > finds out the phone area code for this hardware. With the=20 > phone area code, the LIS queries a table which contains the=20 > phone area codes and the corresponding PSAP URI, then=20 > delivers the the string (LbyR) and the PSAP-URI to the SIP=20 > proxy. The SIP proxy routes the call and sends the LbyR to=20 > the PSAP. In very few cases, PSAPs dereference the the LyBR=20 > to a civic address.=20 >=20 > We do not have any kind of geo data or poligons=20 > in our database. In principle we have the the civic address,=20 > but the access to this data is quite slow. I think other=20 > fixed networks carriers here have more or less the same.=20 >=20 > =20 >=20 > This seems trivial for you to implement: you=20 > deploy a HELD server that takes telephone number and returns=20 > a polygon representing the area code boundary, and you deploy=20 > a LoST server that takes that polygon and returns the PSAP=20 > URI associated with it. =20 >=20 > This would be no more expensive than what you=20 > are proposing. Proxies could use this or phonebcp compatible=20 > endpoints could use it. =20 >=20 > =20 >=20 > NENA is planning on doing pretty much this same=20 > thing to handle legacy wireline networks where telephone=20 > number is currently the key to the location database (ALI). =20 > The LIS will store location as the key (using held-identity),=20 > and a gateway will construct an LbyR from the phone number. =20 > All the rest of the ecrit compatible infrastructure can then=20 > use the Location URI to get location, route, etc. >=20 > =20 >=20 > Making what you now see as a one step mapping=20 > (area code to PSAP URI) into a two step (telephone number to=20 > polygon, polygon to PSAP URI) is a bit more complex, but not=20 > any significant difference in deployment. It also works for=20 > wireless (cell sector/ID to polygon, polygon to PSAP URI),=20 > and of course, would be upwardly compatible with real=20 > location based routing, should your systems evolve as we=20 > expect they evolve, or something like EU regulations compel=20 > more accurate location services. >=20 > [[LLi]] Nobody here is willing to putting=20 > geodata or poligons into the access databases. And we could=20 > avoid doing this just by allowing the LIS to query the local=20 > LOST with the LbyR and to deliver the PSAP URI to the SIP proxy. =20 >=20 > =20 >=20 > Kind regards >=20 > Laura >=20 > =20 >=20 > Brian >=20 > =20 >=20 > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of L.Liess@telekom.de > Sent: Friday, August 07, 2009 7:59 AM > To: Martin.Dawson@andrew.com;=20 > R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > =20 >=20 > Hi Martin, =20 >=20 > Hi Laura, >=20 > =20 >=20 > I regard it as a goal of ECRIT - as=20 > derived from the goals of the IETF generally - to define a=20 > structure that will allow an Internet capable device to=20 > connect to a network anywhere in the world and be able to=20 > make emergency calls. Just as FTP, email protocols, SIP and=20 > etc. all work regardless of which network the devices attach=20 > to. I don't understand how the kind of variations that you=20 > are requesting be added to the specification will allow that to occur. >=20 > [[LLi]] This is fine and usefull. Just=20 > that every country uses today different formats for the=20 > location used for emergency calls. Changing this will take=20 > time and costs money.=20 >=20 > What is the harm in allowing ECs to=20 > work with local location formats which are understood only by=20 > the LIS and the PSAP ?. I dont see why a common location=20 > format must be implemented by everybody.=20 >=20 > Maybe the EC could work like this :=20 >=20 > =B7 The proxy discovers the LIS=20 > based on EDs IP-address using reverse-DNS and SRV record=20 > (this is possible with "identity extenssions")=20 >=20 > =B7 It retrieves the location (=20 > e.g. using HELD) in a local format understood only by the LIS=20 > and the PSAP, which are in the same country. The location is=20 > just a string which is passed transparently through the=20 > network to the PSAP. In my opinion, it would be in principle =20 > posible to use LbyR to transport local location identidfiers,=20 > e. g. area-code@lis.telekom.de , but this is currently my=20 > personal opinion, I didn' found any statemant or example in=20 > the drafts. =20 >=20 > =B7 The LIS delivers, together=20 > with the LbyR above, the PSAP URI. As far as I know there is=20 > currently no way to do this in HELD (or did I miss=20 > something?). =20 > =20 >=20 > It would be an alternative which is=20 > interoperable and quite easy to implement, without the need=20 > for the operators to change their location databases. I think=20 > by allowing this scenario, interoperable EC could be achieved=20 > earlier. And this does not exclude the scenario described in=20 > the framework and phone-bcp, where the EDs retrieve deo or=20 > civic location, which is needed for EC to work in=20 > private/enterprise networks. =20 > =20 >=20 > =20 >=20 > =20 >=20 > The position appears to be that the=20 > German regulator doesn't require anything - and the operators=20 > will not be proactive in following a specification if it=20 > doesn't include what already exists. In that context, I don't=20 > understand why there is a need for the BCP at all. There may=20 > be no need to endorse it but, similarly, there should be no=20 > need to object to it - since the operators will only put in=20 > place their preferred version of the service in any case.=20 > [[LLi]] This is not quite true. We=20 > have to ensure that EC works for different AN- and=20 > VoIP-provider and for nomadic users in Germany by 2013. Our=20 > current solution does not allow this and there is the same=20 > for other carriers. We definitively need to define in Germany=20 > an architecture which fullfills this requirements. It would=20 > be very usefull if we can use standard protocols. But nobody=20 > will be willing to change everything at once. Having a=20 > standard based architecture which is low cost would be a=20 > great advantage.=20 >=20 > =20 >=20 > Kind regards >=20 > Laura =20 >=20 > =20 >=20 > That's OK... insofar as it just means=20 > German networks aren't ECRIT compatible - "compatibility"=20 > isn't a worthy goal in and of itself; it has to actually mean=20 > any device can work anywhere. >=20 > =20 >=20 > Cheers, >=20 > Martin >=20 > =20 >=20 > ________________________________ >=20 > From: L.Liess@telekom.de=20 > [mailto:L.Liess@telekom.de]=20 > Sent: Friday, 7 August 2009 12:29 AM > To: Dawson, Martin;=20 > R.Jesske@telekom.de; ecrit@ietf.org > Cc: Reinhard.Lauster@t-mobile.at > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > Hi Martin,=20 >=20 > =20 >=20 > See comments inline [[LLi]]. >=20 > =20 >=20 > =20 >=20 > Laura >=20 > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of Dawson, Martin > Sent: Wednesday, August 05,=20 > 2009 11:00 AM > To: Jesske, Roland; ecrit@ietf.org > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > Hi Roland, >=20 > =20 >=20 > I think what you're saying is=20 > that you don't think that Germany will go on to implement=20 > full ECRIT support but will peg development at an interim phase.=20 > [[LLi]] We don't know how the=20 > realtime application networks or EC will look like in 20=20 > years. Roland's answer only applies to the next 5 to 10 years.=20 >=20 > =20 >=20 > That would be disappointing -=20 > not least because full ECRIT compliance would ultimately=20 > decrease the overhead associated with emergency service=20 > support for operators as well as providing a more universal service. > =09 > [[LLi]] This may be true for=20 > "green field" ISPs and VSPs but not for incumbent carriers=20 > with existing infrastructure. And universal service is not a=20 > requirement for us. Neither the German regulator requires it=20 > nor is it a busines case. =20 >=20 > =20 >=20 > Nevertheless, I don't think=20 > that decision invalidates the BCP;=20 > [[LLi]] We think it does,=20 > because some of the requirements are not flexible enough to=20 > cover the deployments within the next years. The BCP should=20 > be more flexible: =20 >=20 > =B7 Allow additional=20 > location identifiers =20 >=20 > =B7 Allow AN operated LOST=20 >=20 > =B7 Provide a way to=20 > enable LOST-query based on national or domain-specific=20 > location identifier. One posiblility is to allow the LIS to=20 > query the LOST , but there are also other alternatives. =20 >=20 > =B7 Allow and describe=20 > also network-centric, not only ED-centric architectures. If I=20 > remember correctly, John Medland from BT also recomended to=20 > use a more network- centric architecture, at least for the=20 > next years.=20 >=20 > =20 >=20 > I think it just means that the=20 > German regulator and technical advisory committees would=20 > point out the subset aspects of compliance that would be=20 > applicable to that jurisdiction. =20 > [[LLi]] Again, the draft is=20 > not flexible enough for it. If the BCP contains requirements=20 > which are not realistic, people will just discard the BCP and=20 > implement proprietary stuff. My expectation from a standard=20 > body is to define protocols and architecture which people are=20 > willing to implement in their network or products , not only=20 > in the lab. >=20 > =20 >=20 > [[LLi]] =20 >=20 > We are not against the draft in=20 > principle. ECRIT provides us with very valuable=20 > specifications as LbyR, HELD, identity extensions. But=20 > targeting an architecture which requires everbody to invest=20 > without a business case will not help the draft in the end,=20 > also if it becomes a BCP. It would make sense to make it=20 > more flexible so people are willing to adopt it. =20 >=20 > =20 >=20 > Actually, based on your=20 > description below, the NENA i2 architecture would probably be=20 > a more straightforward baseline for analysis - as has been=20 > done in the UK and Canada. Of course, it's generally=20 > recognized as only an interim step, even in those jurisdictions. >=20 > Other comments below. >=20 > =20 >=20 > Cheers, >=20 > Martin >=20 > =20 >=20 > ________________________________ >=20 > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: Wednesday, 5 August 2009 6:19 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > =20 >=20 > Dear all,=20 > We would like the document to=20 > become a BCP as soon as possible so the group can move on=20 > with other documents related to emergency calling based on=20 > location-by-reference and ED's IP-address.=20 >=20 > [[MCD]] I think you might mean=20 > "identity extensions" rather than location-by-reference=20 > because LbyR still requires the ED to obtain the reference -=20 > e.g. by HELD. > [[LLi]] We use both, the=20 > IP-address as UE identity and LbyR. The SIP-proxy uses the=20 > IP-address to query the LIS using HTTP (it's not HELD but=20 > SOAP over HTTP, but anyway similar). The LIS responds with a=20 > numeric string associated to the caller location, in=20 > principle a LbyR and with the PSAP number. The proxy inserts=20 > the LbyR into the SIP-message (as P-Asserted-ID because the=20 > PSAPs are in PSTN) and routes the message to the PSAP. It's=20 > a low cost solution.=20 >=20 > But we can not HUM for the=20 > current form of the document.=20 >=20 > Back to the document: Some=20 > requirements are far form being realistic, at least in=20 > Germany, some are not realistic at all. Implementing these=20 > requirements cost a carrier a lot of money and there is no=20 > ROI for it.=20 >=20 > Just a few examples:=20 >=20 > =B7 Requiring either geo or=20 > civic location does not provide carriers with enough=20 > flexibility to reuse their existing mechanisms and location=20 > databases. Routing of emergency calls is currently done in=20 > Germany based on phone area code not on geo or civic=20 > location, at least for the fixed network. For mobile networks=20 > the cell-id is used in common. This is regulated by the=20 > german regulator.=20 >=20 > [[MCD]] How many unique PSAP=20 > routes are required in Germany? The US has lots (6000 plus)=20 > and Australia has two (and they are redundant so it doesn't=20 > matter which one). Presumably geographic information, for=20 > PSAP catchment areas, is the basis for determining which area=20 > codes are relevant to begin with? After all, an area code is=20 > not intrinsically geographic; it's a network routing value.=20 > If so, then some geographic discriminator is already in play=20 > in terms of constructing the area code based routing data=20 > (something like zip codes perhaps?) - and in that case, it=20 > should be straightforward to by-pass the area code step in=20 > the construction of routing that goes the correct PSAP URI.=20 > [[LLi]] Currently, fixed=20 > networks carriers in Germany route the ECs based only on the=20 > caller's area code. Sometime in the past, the carriers, the=20 > regulator and the PSAPs operators (police, the Red Cross)=20 > agreed to do so. This may change in the future, but it will=20 > take a quite long time. =20 >=20 > With nomadic VoIP devices (and=20 > it's no good being in denial about this being the norm in the=20 > future) area code is no more reliable than it is for=20 > conventional mobile phones. And, presumably, area code is not=20 > used for conventional cellular emergency call routing? > [[LLi]] As far as I know,=20 > mobile networks use the Cell-ID, not the area code, and have=20 > a different table than the fixed network operators. They are=20 > not going to change this. As to the nomadic SIP-users...if=20 > we like it or not, very few of our customers use our SIP=20 > service nomadic, let alone call EC from their laptop. =20 >=20 > 1 LOST as a=20 > national, let alone as a global directory is not going to be=20 > implemented. The regulator will provide in the web a static=20 > table which contains the PSAPs and the area for which they=20 > are responsible (one or more area codes). Every carrier has=20 > to implement its own routing database for emergency calls.=20 >=20 > [[MCD]] Whatever the=20 > carriers implement (and they have to implement something)=20 > could just as readily be done using LoST. Then visiting=20 > devices, with no association with any local VoIP proxy server=20 > would still be able to determine a route to the correct PSAP.=20 > Alternatively, as long as the regulator is maintaining a web=20 > service with the routing information, why not make that=20 > directly accessible using LoST and save the operators the=20 > cost of duplicating the service at all? > [[LLi]] There is a big=20 > difference between maintaining a web page with a table which=20 > operator can print and implement in their darabases and=20 > operating a database which is queried for every emergency=20 > call in Germany, must have an availablity of 99,99...% , is=20 > secure enough...you know. The regulator will not do this. >=20 > =09 > 2 We have no=20 > intention to rely on end devices for location information because:=20 > =B7 ED provided=20 > location info is not trusted=20 >=20 > [[MCD]] Location by reference=20 > mitigates this trust issue. The emergency network can=20 > (automatically and before human resources are engaged) assess=20 > the source of the reference, and the validity of the location=20 > by dereference, without having to trust location provided=20 > directly from the ED. There are more sophisticated approaches=20 > to trustability even using LbyV - based on digital signatures=20 > across appropriate attributes. This WG and Geopriv haven't=20 > really got to grips with that... yet. > [[LLi]] We build the=20 > SIP-network and EC now. ED-provided location is needed if EC=20 > must work for private and enterprise networks and VPNs. We=20 > have no such regulatory requirements. And we don't know of=20 > any verdor of DSL-EDs which provides today SIP with LbyR and=20 > is as cheap as the devices without it. If you do, please let me know.=20 >=20 > The regulator ask us to=20 > guarantee that EC works. What if a customer dials 112 and his=20 > end device does not send the location? So I have to implement=20 > both solutions, with and without ED provided location, anyway. =20 > 1 There are already a lot=20 > of existing EDs in usage which don't send location. =20 >=20 > [[MCD]] Quite right. ECRIT=20 > doesn't overly concern itself with that interim situation.=20 > The UK and Canadian definitions for an interim solution=20 > (limiting service to in-country VoIP proxy operators) both=20 > assume third-party query via identity-extension to allow the=20 > proxy or the VPC to make the query to the LIS. This isn't=20 > extensible to universal emergency service access by all=20 > visiting devices but it does put the necessary LIS=20 > functionality in place as a very good starting point. It=20 > would be a pity if Germany were to cease the evolution there=20 > as it would not fulfil the real promise of the Internet and=20 > the ECRIT model.=20 > [[LLi]] I wonder who will=20 > drive and pay for upgrading the interim solutions. =20 > Unfortunatelly, it's all about money... >=20 > Think about it; all the=20 > complexity of putting location determination infrastructure=20 > in place for the purposes of dispatch is done - and then the=20 > next, simpler step, of using that to support the routing=20 > procedure isn't taken... that would be a waste. > =09 > [[LLi]] Do you think this is=20 > an argument for a product manager? They need a business case. =20 >=20 > =20 >=20 > =20 >=20 > We don't intend to require=20 > our ED-vendors to provide location because it is useless to us. =20 >=20 > We could agree with the=20 > document with following changes:=20 >=20 > o Other location identifiers=20 > then geo or civil are allowed. It must be possibe that the=20 > data foermat is flexible due to different requirements from=20 > regulators over the whole world. (e.G Germany area codes for=20 > fixed- and Cell-Id for moile- providers)=20 >=20 > o The MUST for the end=20 > devices to support location information, DHCP location=20 > options and HELD shall be removed=20 >=20 > o It must be possible for=20 > the VoIP-provider's proxy to use a LOST (or an ESRP) provided=20 > by the AN or by other local provider on behalf of the AN. =20 >=20 > =20 >=20 > There is no value in Hum-ing=20 > documents which one is not going to implement and does not=20 > fit into regulated schemes like in Germany. Currently,=20 > neither the IETF- nor the 3GPP-architecture for emergency=20 > calling covers our real needs for the next 2 to 5 years and=20 > in the end everybody still has its own proprietary implementation. =20 >=20 > Best regards=20 >=20 > Roland=20 >=20 > =20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Roland Jesske > Gateways, Protokolle, Konvergenz, TE32-1 > Heinrich-Hertz-Str. 3-7, 64295=20 > Darmstadt, > Postfach, 64307 Darmstadt=20 > (Postanschrift) > +496151 628 2766 (Tel) > +491718618445 (Mobile) > E-Mail: r.jesske@telekom.de=20 > =20 > http://www.telekom.de=20 > =20 >=20 > =20 >=20 > Registerrechtliche Unternehmensangaben: > Deutsche Telekom Netzproduktion=20 > (DT NP) GmbH > Aufsichtsrat: Timotheus H=F6ttges=20 > (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno=20 > Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht=20 > Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262=20 >=20 > =20 >=20 > =20 >=20 > =09 > =09 > -------------------------------------------------------------- > ---------------------------------- > This message is for the=20 > designated recipient only and may > contain privileged,=20 > proprietary, or otherwise private information. =20 > If you have received it in=20 > error, please notify the sender > immediately and delete the=20 > original. Any unauthorized use of > this email is prohibited. > =09 > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > =09 >=20 > =20 >=20 > =20 >=20 > =09 > =09 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated=20 > recipient only and may > contain privileged, proprietary, or=20 > otherwise private information. =20 > If you have received it in error,=20 > please notify the sender > immediately and delete the original. =20 > Any unauthorized use of > this email is prohibited. > =09 > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > =09 >=20 > =20 >=20 >=20 From ngwilcox@gmail.com Tue Aug 11 06:09:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF3E3A6EC9 for ; Tue, 11 Aug 2009 06:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU7i9p9OJSmI for ; Tue, 11 Aug 2009 06:09:38 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id C608F3A6DBC for ; Tue, 11 Aug 2009 06:08:38 -0700 (PDT) Received: by gxk9 with SMTP id 9so5041378gxk.13 for ; Tue, 11 Aug 2009 06:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zPschsj6oXBPV/ZBfYWvbepk5qwsi2lw6dWqWE+4nhY=; b=VZ0AouMnbLDiezQVm9sLWHTA3FFTG4grTjz557CWqIdJsDxgk5MZoIwbjj+13r9lst FPTQOZywuqrqJImkgWH3OUwpRfoe4qSpCyVS6/tG5zPYZlKmMdQzA67+ZE00a33lN9WK tZkNMZk0pOhuP54IDq0AaUzUQDOWmeGKn1Tu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dshep0Y9gxRBfN7R3CGZqfADh/WKZAZv5XuZ5NHqxusTpcXeAQk7H09SnmMH4hujyU ocu2q3qRNfQQ6TnF9dwEQo0PFCz1qfck2NC2IUw5+QW2NsgEhyHGMNdmQ17KGDOSgBL1 dhg3iO4adL2i15XCQQM1EVnHBhhUfo56Y0HEw= MIME-Version: 1.0 Received: by 10.100.108.20 with SMTP id g20mr239209anc.52.1249996071673; Tue, 11 Aug 2009 06:07:51 -0700 (PDT) In-Reply-To: <20090810161528.dn1am0meiaa88s44@www.open-it.ca> References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> <1249587517.5335.80.camel@vandium.darkcore.net> <1249656835.5053.35.camel@vandium.darkcore.net> <1249675185.5053.126.camel@vandium.darkcore.net> <05b601ca1820$17fc20e0$625aa20a@nsnintra.net> <20090810161528.dn1am0meiaa88s44@www.open-it.ca> Date: Tue, 11 Aug 2009 09:07:51 -0400 Message-ID: <181f29c0908110607s91797d2q4d1a8898b0fb06f8@mail.gmail.com> From: Nate Wilcox To: John Lange Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Dawson, Martin" , ecrit Subject: Re: [Ecrit] PSAP motivations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 13:09:39 -0000 Huh? Major PSAP jurisdictions in the US are in the process of moving to IP (Oklahoma City, OK (ACOG), San Antonio, Texas (Bexar Metro), North West Chicago, IL (NWCDS)) and at least 2 ILEC's that I know of (Embarq and AT&T) are actively engaged in moving their 9-1-1 systems to VoIP. Direct connectivity to the Internet is a common piece of the overall ESInet that these agencies/companies are deploying. In fact, last week in San Antonio we delivered test 9-1-1 calls from clients on the Internet directly to 9-1-1 call taking positions - we used PIDF-LO capable clients and derived location information in a variety of formats from a LIS. Nate Wilcox On Mon, Aug 10, 2009 at 5:15 PM, John Lange wrote: > I'm changing the topic on this thread to accurately reflect the fact that > were straying off topic for this mailing list ;) > > Quoting Hannes Tschofenig : > >> Hi John, >> >> in addition to what Martin said about the negative impact on the "public". >> >> My guess is that the emergency services networks will move their networks >> to >> IP (because of the lower costs) and then they will not require the ILECs >> todo the gatewaying of all the calls. > > That will not happen any time soon. The PSAPs have sworn allegiance to the > ILECs and will not connect their equipment to anything except the ILECs. > They have reiterated this frequently. > >> They will be able to get emergency calls directly from the VoIP providers. > > As long as the current PSAP management is involved that will never happen. > They have stated this time and again. No PSAP system will ever be connected > to the Internet. > >> This will be less expensive, will >> support additional media and more extensible for future deployments. This >> is >> an evolution step we observe in many countries. >> >> One interesting data point I would like to understand is whether the >> PSAPs/emergency services networks have to pay to the ILECs for their >> emergency call routing and gatewaying "offering". > > Yes the ILECs get compensation for their services though I do not know the > exact model and I suspect it's different in province. > > On top of that the various providers are allowed to charge a "911 access > fee" to every subscriber including wireless and standard wireline. This is a > major source of revenue which they are motivated to protect. > > They recently took some heat about this when it was revealed that this > charge has nothing whatever to do with the actual cost of providing the > service and they are under no obligation to spend the money to improve 911 > service. > > Case in point, we still can't do location for cell phones despite the fact > that the one time cost of implementing the system would only be a fraction > of the money collected in 911 fees EACH YEAR. > >> If they have to then there is obviously incentive for them to move away >> from that model. > > I wouldn't say it's obvious. In fact I don't think saving the public money > is anywhere near the top of PSAP motivations. For example, Ontario has > something like 140(!) regional PSAPs (pretty much every municipality has one > but I can't seem to get a straight answer on exactly how many there are). > Roughly one PSAP for every 80,000 people. One of the big stumbling blocks to > this whole process is that PSAPs will have to upgrade equipment. That gets > expensive when you have to do it 140 times. > > No PSAP is going to suggest "hey, this would be a good time consolidate 140 > PSAPs and save a bundle of money!" > > Rather, PSAPs are motivated by bad press. They avoid anything that may cause > them not to be able to do their jobs and that boils down to "change". > > I agree with them that we should be conservative with regard to change in > the 911 system but the problem is the Canadian PSAPs have become a too > dogmatic fighting change. > > They actually tried to convince the CRTC to ban VOIP outright and since then > they've spent too much of their time fighting change rather than considering > what benefits new 911 systems could offer. > >> PS: I am always curious why people see the step to a NENA i2.5 or >> pre-ECRIT >> architecture as so complicated particularly when the largest investment is >> in the location server capability in the access networks (and those have >> to >> be done anyway regardless of the chosen architecture). > > Conversely, I find those kinds of statements as highly curious. From a > technical perspective, real-time IP location is complicated. But never mind > the technical, it's the politics that are the real challenge. > > Consider that all IP location proposals rely on the ASP to implement a > significant portion of the solution and that almost all ASPs (in Canada) > also provide phone service. > > Not only does spending money on IP location do nothing to enhance their > internet offerings, it actually enhances the VOIP service offering of their > competition. (yes I know you could technically argue that location enhances > their service but that will never result in more customers, especially given > that all ASPs would be required to have the same thing) > > And that is only one example. > > Pretty much everyone agrees that a LIS is the first step in any system but > that's a long way from having a cost effective working IP location system. > > -- > John Lange > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From john@johnlange.ca Tue Aug 11 12:09:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991F43A7019 for ; Tue, 11 Aug 2009 12:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LxDZplL6xE6 for ; Tue, 11 Aug 2009 12:09:46 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 1A4853A701F for ; Tue, 11 Aug 2009 12:09:14 -0700 (PDT) Received: (qmail 12136 invoked from network); 11 Aug 2009 16:38:47 -0500 Received: from unknown (HELO ?192.168.5.94?) (192.168.5.94) by lh02.epicnet.ca with SMTP; 11 Aug 2009 16:38:46 -0500 From: John Lange To: Nate Wilcox In-Reply-To: <181f29c0908110607s91797d2q4d1a8898b0fb06f8@mail.gmail.com> References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <6e04e83a0908061223v1a835c7n930ffe565d722f19@mail.gmail.com> <1249587517.5335.80.camel@vandium.darkcore.net> <1249656835.5053.35.camel@vandium.darkcore.net> <1249675185.5053.126.camel@vandium.darkcore.net> <05b601ca1820$17fc20e0$625aa20a@nsnintra.net> <20090810161528.dn1am0meiaa88s44@www.open-it.ca> <181f29c0908110607s91797d2q4d1a8898b0fb06f8@mail.gmail.com> Content-Type: text/plain Date: Tue, 11 Aug 2009 14:00:04 -0500 Message-Id: <1250017204.4999.11.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: "Dawson, Martin" , ecrit Subject: Re: [Ecrit] PSAP motivations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 19:09:47 -0000 On Tue, 2009-08-11 at 09:07 -0400, Nate Wilcox wrote: > Huh? > > Major PSAP jurisdictions in the US are in the process of moving to IP Note that my comments are always with regard to Canadian PSAPs unless stated otherwise. I apologize for any confusion. -- John Lange http://www.johnlange.ca From john.medland@bt.com Tue Aug 11 14:33:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE20E3A69BA for ; Tue, 11 Aug 2009 14:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbz2LO70Jgyt for ; Tue, 11 Aug 2009 14:33:35 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 5B5973A68C2 for ; Tue, 11 Aug 2009 14:33:35 -0700 (PDT) Received: from E03MVA1-UKBR.domain1.systemhost.net ([193.113.197.102]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 22:32:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2009 22:32:36 +0100 Message-ID: In-Reply-To: <023d01ca104f$9c7a9320$d56fb960$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Problem statement for Premature Disconnect thread-index: AcoQL1oZuKBSx9XaTT2+vFzbYGen7QAIAPggAgyzAyA= From: To: X-OriginalArrivalTime: 11 Aug 2009 21:32:39.0574 (UTC) FILETIME=[40778B60:01CA1ACB] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Problem statement for Premature Disconnect X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 21:33:36 -0000 Brian, This looks to be very useful and I'd like to add an extra dimension to requirements please. One of main problems we have in answering emergency calls in UK PSAPs is when a caller does not answer or is incoherent at the start of a call and then clears. The PSAP has not had time to establish whether or not there's a genuine emergency or whether the call is accidental or is a result of a child "playing" with the phone (a particular issue since we have three digits the same with 999 as an emergency code!). If the PSAP is able to influence or affect the release/ending of the emergency call it provides an efficient way of establishing whether or not help is required.=20 This is currently achieved by setting of Last Party Release in C7 signalling, which means a caller cannot make another call until the PSAP is satisfied that an emergency service is not required, usually by caller confirming (adult finds child playing with phone or adult realises they have misdialled) - it does not work on ISDN calls though. =20 Thanks=20 John=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 29 July 2009 14:22 To: ecrit@ietf.org Subject: Re: [Ecrit] Problem statement for Premature Disconnect There is a small typo in this. The ECRIT work group would complete requirements for handling premature disconnect. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Rosen, Brian > Sent: Wednesday, July 29, 2009 5:31 AM > To: ecrit@ietf.org > Subject: [Ecrit] Problem statement for Premature Disconnect >=20 > I was asked to reword a problem statement on premature disconnect that > might be acceptable to begin work on, probably a design team on=20 > requirements. I propose: >=20 > In emergency calls, people are stressed. They sometimes try to=20 > disconnect a call where communication between the caller and the call=20 > taker has begun, but before the call taker has acquired enough=20 > information to direct appropriate response. That circumstance is=20 > known as "premature disconnect". In those circumstances the device=20 > should behave differently. For example, the device may alert rather=20 > than disconnect. The behavior of the device would be UI driven, and=20 > thus not specifiable by the IETF, although advice might be given. >=20 > Special behavior is not always desirable. For example, in high call=20 > volume circumstances, the call may be answered by the PSAP at an IVR,=20 > in which case no special behavior is desired. The device may not=20 > implement the specification, or for some reason, it may not be=20 > available for a particular emergency call. For this reason, some form > of signaling at the beginning of the call is needed to negotiate=20 > enabling the special behavior. >=20 > It is desirable that the PSAP be aware that the user has attempted to=20 > disconnect/reconnect, and it may be useful for the PSAP to be able to=20 > influence the behavior of the device. Some form of signaling for this > purpose is desirable, but need not be reliable, since it is advisory. >=20 > In all circumstances the user must maintain control of his device, and > it must be possible for the user to take some action to complete a=20 > disconnect. >=20 > The geopriv work group would complete requirements for handling=20 > premature disconnect. Some of the resulting protocol work may need to > be accomplished in other RAI work groups. > _______________________________________________ > 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 hannes.tschofenig@nsn.com Wed Aug 12 04:35:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9393A6A5E for ; Wed, 12 Aug 2009 04:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-2.482, BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksDmWh2+CC8k for ; Wed, 12 Aug 2009 04:35:49 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2C2AB3A6805 for ; Wed, 12 Aug 2009 04:35:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7CBPq4Y025854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2009 13:25:52 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7CBPoTe014433; Wed, 12 Aug 2009 13:25:52 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 13:25:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 14:28:23 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450197512C@FIESEXC015.nsn-intra.net> In-Reply-To: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Questions/Comments Thread-Index: AcoaAFwCRxMfYy0LRqmpfX/53hvJYwAlqv2w References: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Avery Penniston" , X-OriginalArrivalTime: 12 Aug 2009 11:25:50.0864 (UTC) FILETIME=[A5990900:01CA1B3F] Subject: Re: [Ecrit] LoST Questions/Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 11:35:50 -0000 Hi Avery,=20 Thanks for the very detailed reading of the document and for your feedback.=20 See my comments below:=20 >Hello, > >I have recently been reviewing the LoST proposed protocol in=20 >RFC 5222 and have some questions and comments that I am hoping=20 >I can get some help with. Since I have joined the list,=20 >discussion seems to be centered around newer topics than 5222,=20 >but I would appreciate any clarification, or comments on any=20 >of the points below. All references below refer to RFC 5222=20 >unless stated otherwise. > >Avery > > >1.) Sec. 1 [Page3] states, "LoST satisfies the requirements [18] >for mapping protocols." However I haven't seen how LoST=20 >handles this requirement from RFC 5012: >"Ma13. URL for error reporting: The mapping protocol MUST=20 >support the ability to return a URL that can be used to report=20 >a suspected or known error within the mapping database." It=20 >seems that a source is returned, but not a specific URL for=20 >error reporting. Strictly speaking we satisfy the requirement as we "provide the possibility to return ..." with the extension points offered via RelaxNG. :-) More seriously, you are right that we did not define an XML element that could carry a URL for error reporting.=20 > > >2.) Sec. 1[Page 3] states, "For civic addresses, LoST can indicate >which parts of the civic address are known to be valid or=20 >invalid, thus providing address validation, as described in=20 >Section 3.5 of [18]. " >However in Sec 3.5 of RFC 5012 it says that a location is=20 >valid if the location is recognizable, AND "can be mapped to=20 >one or more PSAPs". So is it implied that the request=20 >location is invalid if no mappings are returned in the=20 >findServiceResponse? If that is the case couldn't a notFound=20 >error returned imply the same? It just seems to me that=20 >perhaps the location might be valid whether or not it maps to a PSAP. You are again touch on some sensitive issues. Yes, we have noticed that we used different semantics for the term "location validation" over time. This has a bit to do with the work done together with NENA where the terminology also changed over time.=20 Looking at RFC 5012 we could call this definition as being valid for routing purposes: Location validation: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference system (e.g., United States Postal Address or the WGS-84 datum) and can be mapped to one or more PSAPs. While it is desirable to determine that a location exists, validation may not ensure that such a location exists, but rather may only ensure that the location falls within some range of known values. Location validation ensures that a location is able to be referenced for mapping, but makes no assumption about the association between the caller and the caller's location. However, the LoST document actually uses a different definition for location validation, namely one that refers only to civic addresses and the existence of the address (with respect to a database) for dispatch purposes.=20 For example, if you have the address Otto-Hahn-Ring 100, Munich would not be valid with the semantic used in LoST but would be valid according to RFC 5012 (if there is a PSAP boundary that covers the entire region). How do we fix this? Good question. We could re-issue an update to RFC 5012 to fix the terminology. We could also re-issue RFC 5222 and include updated terminology there. I don't know what the group thinks about that. > >3.) Sec. 1 [Page 4] states that a LoST server optionally returns >"hints" about the service boundary. As far as I could tell it=20 >was either a representation of the boundary itself or a=20 >reference to it. >Not sure what is meant by hints. The LoST server either returns nothing, the boundary or a reference to it.=20 The boundary returned in LoST may or may not reflect the exact boundary. This is what is meant by hint.=20 =20 > >4.) Sec. 2 [Page 5] in the definition for Service Boundary it states >that it "circumscribes the region within which all locations=20 >map to the same service URI or set of URIs for a given=20 >service". I take this to mean that it is a polygon=20 >representing a service area. So when returning service=20 >boundaries either in mappings or in getServiceBoundaryResponse=20 >should the boundary returned be the exact boundary or can a=20 >subset of the service boundary be returned? It does not need to be the exact boundary. When a boundary is returned then it has to be a subset (described with the above-stated definition). The boundary may be described using a civic or a geodetic location format.=20 > >5.) Sec. 3 [Page 5] under it says that, "The same >query type may also ask for location validation and for=20 >service numbers, either combined with a mapping request or=20 >separately". I understand that the location validation and=20 >service numbers are returned in the response, but I don't see=20 >any attribute in request that allows the=20 >explicit request for service numbers, nor do I see any query=20 >type that allows the location validation or service number=20 >query "separately". There is no mechanisms to ask for location validation or for service numbers separately.=20 The query returns the service numbers in the element. The is a mandatory element.=20 > >6.) Sec. 5.1 [Page 7] Regarding the 'lastUpdated' attribute, is it >intended that this time should be the time when the mapping is=20 >'created' >for example when map data is loaded on server, or when map=20 >data is updated, or when the mapping is returned to the=20 >client? This seems to imply that mappings should be created at=20 >a time prior to the request being responded to. Is that correct? The 'lastUpdated' attribute refers to the time when the mapping was created. Whenever the mapping is changed then a new timestamp must be created.=20 The mappings are indeed created prior to the query. =20 > >7.) Sec. 5.1 [Page 7] states, "A receiver can replace a mapping >with another one having the same 'source' and sourceId' and a=20 >more recent time in 'lastUpdated'". >I assume this means a client updating its cache, and not a=20 >LoST server in the middle of a recursive query? So replacing a=20 >mapping refers to replacing it in local cache and not=20 >replacing the mapping returned to a client with a newer one=20 >than the one received recursively? You are right that this refers to the cache.=20 > >8.) Sec. 5.2 [Page 8] How is it possible for a client to ever update >its cache of mappings with an expiration of "NO-EXPIRATION"? >It seems that the only way to get new mappings in this case is=20 >if it happens to receive a mapping with a newer 'lastUpdated'=20 >attribute. Until then the server would return invalid mapping=20 >information. When would it be advisable to use=20 >"NO-EXPIRATION"? Also, if a mapping does not contain any=20 >ServiceBoundary or ServiceBoundaryReference elements is there=20 >any reason to cache it? The usage of "NO-EXPIRATION" is IMHO only useful in controlled environments where you want to force caching for a long time. If there is no boundary associated with the mapping then the information the client gets depends on the location it used in the request. For example, if I asked for Germany then the response it gets would be either be an error, or a mapping and that mapping would be usable for all places within Germany.=20 >9.) Sec. 5.4 [Page 8] When returning an "alternate service that >approximates the desired service" is it implied here that the=20 >server MUST return a serviceSubstitution warning? Yes. The element would then contain the Service URN that was used for the lookup.=20 > >10.) Sec. 5.5 [Page 9] states, "If included in a response, the > element MUST contain at least one service=20 >boundary that uses the same profile as the request". (Also=20 >point 9 under sec. >This could be difficult when trying to make a geodetic=20 >service boundary polygon 'fit' into a civic profile to match a=20 >request using a civic profile. I suppose you could omit the=20 >service boundary all together, but it would be nice to return=20 >the geodetic version of the service boundary. We discussed this offlist and I agree that it would be useful to provide this type of feature. An additional warning code would have to be specified.=20 > >11.) Sec. 5.6 [Page 10] states that, "a client receiving a mapping >response can simply check if it already has a copy of the=20 >boundary with that identifier. If so, it can skip checking=20 >with the server whether the >boundary has been updated. " So this implies that caching=20 >is not just >for Mappings but also boundaries. This is a mapping: New York City Police Department urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 sip:nypd@example.com 911 It may contain a service boundary.=20 You always cache the whole thing; not parts of it.=20 When when you compare whether you have something in the cache already then the place to start the search is the unique identifier. > Is it intended that servers=20 >should maintain a mapping cache and a separate service=20 >boundary cache? Nope; not in my understanding of an implementation.=20 What about updating the service boundary=20 >information, as it seems that service boundaries do not have=20 >an expiration, lastUpdated, etc.? =20 The mapping as a whole has this information and it applies to the mapping structure in general.=20 > >Also the part that says, "...skip checking with the server..."=20 >does this imply that if a service boundary reference is=20 >received by the client in a mapping, then the client should=20 >automatically check to see if that reference is current if it=20 >doesn't have that service boundary cached? If so how does it=20 >determine if it is 'current'? The 'source', 'sourceId', and 'lastUpdated' attributes uniquely identify a particular mapping record.=20 If a client receives a mapping that does not include a serviceBoundary element but rather a element then by checking these three attributes mentioned above it could tell whether it is useful to perform the lookup. Whenever the mapping data is changed then the unique identification has to change as well.=20 > >12.) Sec. 5.8 [Page 10] Does LoST provide for alternate routing URIs? >Not to be confused with a substitution. This alternate can=20 >help routing proxies or clients in the event that a service=20 >URI is unreachable. I know a mapping can contain multiple=20 >URIs, but each must use a different URN schema. The current spec does not allow multiple URIs with the same URI scheme to be returned.=20 It is, however, possible to provide "load balancing" via the usage of DNS. The returned URIs will need to be resolved via DNS, see Section 4 of RFC 5222.=20 It is also possible to return multiple elements in the response. We actually did not say whether you could include the same URI in these mappings. Hmmmm.=20 > >13.) Sec. 8.2.2 Fig. 3 [Page 13-14] In the returned civic service >boundary, it implies the service is the city of Munich. The service that is being asked for is 'urn:service:sos.police'. In the example we assume that the query for 'urn:service:sos.police' will lead to a result for this specific service. > I'm=20 >guessing this is okay as long as the civic city boundary does=20 >not extend beyond >or overlap the service boundary. The query in Figure 3 provides this address:=20 =20 DE Bavaria Munich Otto-Hahn-Ring 6 81675 If there is a police PSAP who is responsible for that area then we are fine. From the response in Figure 4 we can tell that the indicated boundary that will lead to the same result is=20 DE Bavaria Munich 81675 As mentioned previously, this may not be the real boundary for that PSAP.=20 So, the address in Figure 3 has to be within the indicated boundary. There are corner cases I forgot to mention -- largely for the geodetic case where the provided location is not a boundary but rather a location shape with less accuracy. Then, the provided location may overlap with multiple boundaries and then you need to figure out with what boundary it overlaps most.=20 It=20 It also assumes that the A3 element >is the smallest boundary element returned in the PIDF-LO;=20 >implying that the A1 and PC elements are either supersets or=20 >are ignored. Is there an established hierarchy of PIDF-LO=20 >civic boundary elements? =20 There is no hierarchy of PIDF-LO elements as such.=20 > >14.) Sec. 8.3.3 [Page 16] "In recursive mode, the LoST server >initiates queries on behalf of the requester and returns the=20 >result to the requester". Does recursion imply querying to=20 >higher levels in the hierarchy? In other words if a LoST=20 >Server receives a request for a service outside the area it=20 >covers, should it consult a forest guide to determine where to=20 >query in order to fulfill the recursive query? Its parent? =20 >Should it only recurse to its children? =20 This depends largely on the setup of the LoST infrastructure.=20 Let's pick an example: An ISP runs a caching LoST server and the authoritive LoST servers are run by the government of a specific country. The country LoST server is the forest guide.=20 So, an ISP LoST server could be configured to first talk to the country LoST servers. If the request is still not fulfilled then the country LoST server would then talk to other forest guides.=20 > >15.) Sec. 11 [Page 23] Why are via elements optional in >listServicesByLocationResponse? They are required in a=20 >findServiceResponse are they not? The statement in Section 11 is wrong:=20 " This response MAY contain elements (see Section 6) and MUST contain a element, consisting of a whitespace-separated list of service URNs. " The elements are mandatory (also in the RelaxNG schema).=20 > >16.) Sec. 12 [Page 25] "Requests and responses containing >or elements MUST contain location=20 >information in exactly one of the two baseline profiles."=20 >(also points 3 & 4 under sec. >12.1) Why can't a location be specified in both a civic and=20 >geodetic profile in the same request/response? The request only carries one location element at the time. If the end host (or whatever entity) has multiple location objects then it needs to issue separate queries.=20 RFC 5222 defines two mandatory-to-implement baseline location profiles, namely a geodetic-2d and a civic profile.=20 Page 25 then says:=20 " Requests and responses containing or elements MUST contain location information in exactly one of the two baseline profiles, in addition to zero or more additional profiles. " There is no negotiation happening between the involved parties and we would like to avoid the case where you get a response but you have no clue what it means.=20 For example, if someone defines a new civic location profiles that allows to express interior location in a more precise fashion then you could still add location using this new profile but you have to include location using the fields known from the currently defined civic profile as well.=20 > >17.) Sec. 12.2 [Page 31] states, "If an authoritative server receives >a query for which the area in the query overlaps the area for=20 >which the server has mapping information, then it MUST return=20 >either a mapping >whose coverage area intersects the query area or a redirect=20 >to another >server whose coverage area is a subset of the server's coverage area". >Why redirect to just a subset, and not a neighboring coverage area? >I.e. the case where a location polygon lies mostly in a=20 >neighboring county and only a small portion of that polygon is=20 >overlapping our service boundary. > The paragraph you are referring to was written to discuss the case where the provided location information is in the form of a location shape that a certain amount of uncertainty (expressed using the different shape types). Then, you can run into the case that multiple mapping could be returned. You might want todo that. However, one needs to avoid the case where you redirect forwards and backwards and no result is being produced. These paragraphs are trying to explain these scenarios.=20 >18.) Sec. 12.3 [Page 31] states, "A response MAY contain more than >one element with profile 'civic'". So I=20 >take this to >mean that the request can have at most 1 location of each type=20 >of profile, but serviceBoundaries in the response are allowed=20 >multiple of type 'civic'. I'm not clear on the purpose here. The propose of allowing multiple elements is to be able to express more complex "shapes". For example, imagine that a PSAP serves "Finland, Espoo", "Finland, Helsinki", "Finland, Vantaa" and "Finland, Kauniainen".=20 > >19.) Sec. 12.3 [Page 31] states, "Hence, a response may contain >multiple elements with civic and/or geodetic=20 >location profiles". So it seems we can mix civic and=20 >geodetic-2d in the response, but not in the request location? =20 >Doesn't this contradict >sec.12 on page 25? The reason is that the group decided that a request for multiple location elements (which might point to different physical locations) should better be dealt with by issuing multiple independent queries. Ciao Hannes > > >Avery Penniston - Software Developer >GeoComm Inc. >601 W. Saint Germain St., Saint Cloud, MN 56301 >Office: 320.240.0040 Fax: 320.240.2389 Toll Free: 888.436.2666=20 >click here to visit www.geo-comm.com > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From rbarnes@bbn.com Wed Aug 12 10:06:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8F13A6AD0 for ; Wed, 12 Aug 2009 10:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 JWepOZnmSDZw for ; Wed, 12 Aug 2009 10:06:55 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C3BD13A68BE for ; Wed, 12 Aug 2009 10:06:55 -0700 (PDT) Received: from [128.89.254.188] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MbGI7-0003uv-FY; Wed, 12 Aug 2009 12:03:08 -0400 Message-ID: <4A82F5CC.8000500@bbn.com> Date: Wed, 12 Aug 2009 13:03:08 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: John Lange References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <02d601ca16b1$e2464940$a6d2dbc0$@net> <1249586131.5335.57.camel@vandium.darkcore.net> In-Reply-To: <1249586131.5335.57.camel@vandium.darkcore.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 17:06:56 -0000 >> If your networks don’t deploy DHCP/HELD, and the regulator is happy to >> force relationships between access networks and calling networks, so >> that OBO becomes viable: fine. Devices that are –phonebcp compliant >> will work. > > That is the absolute critical point! To be precise, however, the scenario Brian is describing still leaves a gap: VoIP users that use a VoIP provider outside of the jurisdiction will not be able to make emergency calls. For instance, if I took a Vonage ATA to Canada, and Vonage didn't have a pre-existing relationship with the ISP I was using, Vonage would be unable to route my calls. What Brian is describing is a transition strategy. As you point out, John, it's a critical one, and the path most jurisdictions are starting with. But it's not the complete solution. --Richard From br@brianrosen.net Wed Aug 12 10:07:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D2C3A6B94 for ; Wed, 12 Aug 2009 10:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.762 X-Spam-Level: X-Spam-Status: No, score=-0.762 tagged_above=-999 required=5 tests=[AWL=-1.755, BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtbViEFpOyIr for ; Wed, 12 Aug 2009 10:07:57 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9733D3A6AFC for ; Wed, 12 Aug 2009 10:07:56 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MbFSW-0008CG-J0; Wed, 12 Aug 2009 10:09:52 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Avery Penniston'" , References: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local> <3D3C75174CB95F42AD6BCC56E5555B450197512C@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450197512C@FIESEXC015.nsn-intra.net> Date: Wed, 12 Aug 2009 11:09:50 -0400 Message-ID: <007501ca1b5e$f43ec2b0$dcbc4810$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoaAFwCRxMfYy0LRqmpfX/53hvJYwAlqv2wADGC9+A= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] LoST Questions/Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 17:07:59 -0000 I think the Error Reporting URI is obtained by querying LoST with a distinguished service URN, which yields the URI of the error reporting service. We need to define that service URN. I'd like to start a discussion of: > There is no hierarchy of PIDF-LO elements as such. I think this is an impractical answer, and the A levels are a hierarchy. If I say it's good in Munich, it's good in Munich DE, and not any Munich, for example. The higher A levels are by default included. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Wednesday, August 12, 2009 7:28 AM > To: ext Avery Penniston; ecrit@ietf.org > Subject: Re: [Ecrit] LoST Questions/Comments > > Hi Avery, > > Thanks for the very detailed reading of the document and for your > feedback. > See my comments below: > > >Hello, > > > >I have recently been reviewing the LoST proposed protocol in > >RFC 5222 and have some questions and comments that I am hoping > >I can get some help with. Since I have joined the list, > >discussion seems to be centered around newer topics than 5222, > >but I would appreciate any clarification, or comments on any > >of the points below. All references below refer to RFC 5222 > >unless stated otherwise. > > > >Avery > > > > > >1.) Sec. 1 [Page3] states, "LoST satisfies the requirements [18] > >for mapping protocols." However I haven't seen how LoST > >handles this requirement from RFC 5012: > >"Ma13. URL for error reporting: The mapping protocol MUST > >support the ability to return a URL that can be used to report > >a suspected or known error within the mapping database." It > >seems that a source is returned, but not a specific URL for > >error reporting. > > Strictly speaking we satisfy the requirement as we "provide the > possibility to return ..." with the extension points offered via > RelaxNG. :-) > > More seriously, you are right that we did not define an XML element > that > could carry a URL for error reporting. > > > > > > >2.) Sec. 1[Page 3] states, "For civic addresses, LoST can indicate > >which parts of the civic address are known to be valid or > >invalid, thus providing address validation, as described in > >Section 3.5 of [18]. " > >However in Sec 3.5 of RFC 5012 it says that a location is > >valid if the location is recognizable, AND "can be mapped to > >one or more PSAPs". So is it implied that the request > >location is invalid if no mappings are returned in the > >findServiceResponse? If that is the case couldn't a notFound > >error returned imply the same? It just seems to me that > >perhaps the location might be valid whether or not it maps to a PSAP. > > You are again touch on some sensitive issues. Yes, we have noticed that > we used different semantics for the term "location validation" over > time. This has a bit to do with the work done together with NENA where > the terminology also changed over time. > > > Looking at RFC 5012 we could call this definition as being valid for > routing purposes: > > Location validation: A caller location is considered valid if the > civic or geographic location is recognizable within an acceptable > location reference system (e.g., United States Postal Address or > the WGS-84 datum) and can be mapped to one or more PSAPs. While > it is desirable to determine that a location exists, validation > may not ensure that such a location exists, but rather may only > ensure that the location falls within some range of known values. > Location validation ensures that a location is able to be > referenced for mapping, but makes no assumption about the > association between the caller and the caller's location. > > However, the LoST document actually uses a different definition for > location validation, namely one that refers only to civic addresses and > the existence of the address (with respect to a database) for dispatch > purposes. > > For example, if you have the address Otto-Hahn-Ring 100, Munich would > not be valid with the semantic used in LoST but would be valid > according > to RFC 5012 (if there is a PSAP boundary that covers the entire > region). > > > > How do we fix this? Good question. We could re-issue an update to RFC > 5012 to fix the terminology. We could also re-issue RFC 5222 and > include > updated terminology there. I don't know what the group thinks about > that. > > > > > >3.) Sec. 1 [Page 4] states that a LoST server optionally returns > >"hints" about the service boundary. As far as I could tell it > >was either a representation of the boundary itself or a > >reference to it. > >Not sure what is meant by hints. > > The LoST server either returns nothing, the boundary or a reference to > it. > The boundary returned in LoST may or may not reflect the exact > boundary. > This is what is meant by hint. > > > > > >4.) Sec. 2 [Page 5] in the definition for Service Boundary it states > >that it "circumscribes the region within which all locations > >map to the same service URI or set of URIs for a given > >service". I take this to mean that it is a polygon > >representing a service area. So when returning service > >boundaries either in mappings or in getServiceBoundaryResponse > >should the boundary returned be the exact boundary or can a > >subset of the service boundary be returned? > > It does not need to be the exact boundary. When a boundary is returned > then it has to be a subset (described with the above-stated > definition). > > > The boundary may be described using a civic or a geodetic location > format. > > > > >5.) Sec. 3 [Page 5] under it says that, "The same > >query type may also ask for location validation and for > >service numbers, either combined with a mapping request or > >separately". I understand that the location validation and > >service numbers are returned in the response, but I don't see > >any attribute in request that allows the > >explicit request for service numbers, nor do I see any query > >type that allows the location validation or service number > >query "separately". > > There is no mechanisms to ask for location validation or for service > numbers separately. > > The query returns the service numbers in the > element. The is a mandatory element. > > > > > >6.) Sec. 5.1 [Page 7] Regarding the 'lastUpdated' attribute, is it > >intended that this time should be the time when the mapping is > >'created' > >for example when map data is loaded on server, or when map > >data is updated, or when the mapping is returned to the > >client? This seems to imply that mappings should be created at > >a time prior to the request being responded to. Is that correct? > > The 'lastUpdated' attribute refers to the time when the mapping was > created. > Whenever the mapping is changed then a new timestamp must be created. > > The mappings are indeed created prior to the query. > > > > > >7.) Sec. 5.1 [Page 7] states, "A receiver can replace a mapping > >with another one having the same 'source' and sourceId' and a > >more recent time in 'lastUpdated'". > >I assume this means a client updating its cache, and not a > >LoST server in the middle of a recursive query? So replacing a > >mapping refers to replacing it in local cache and not > >replacing the mapping returned to a client with a newer one > >than the one received recursively? > > You are right that this refers to the cache. > > > > >8.) Sec. 5.2 [Page 8] How is it possible for a client to ever update > >its cache of mappings with an expiration of "NO-EXPIRATION"? > >It seems that the only way to get new mappings in this case is > >if it happens to receive a mapping with a newer 'lastUpdated' > >attribute. Until then the server would return invalid mapping > >information. When would it be advisable to use > >"NO-EXPIRATION"? Also, if a mapping does not contain any > >ServiceBoundary or ServiceBoundaryReference elements is there > >any reason to cache it? > > The usage of "NO-EXPIRATION" is IMHO only useful in controlled > environments where you want to force caching for a long time. > > If there is no boundary associated with the mapping then the > information > the client gets depends on the location it used in the request. For > example, if I asked for Germany then the response it gets would be > either be an error, or a mapping and that mapping would be usable for > all places within Germany. > > > >9.) Sec. 5.4 [Page 8] When returning an "alternate service that > >approximates the desired service" is it implied here that the > >server MUST return a serviceSubstitution warning? > > Yes. The element would then contain the Service URN that was > used for the lookup. > > > > > >10.) Sec. 5.5 [Page 9] states, "If included in a response, the > > element MUST contain at least one service > >boundary that uses the same profile as the request". (Also > >point 9 under sec. > > > >This could be difficult when trying to make a geodetic > >service boundary polygon 'fit' into a civic profile to match a > >request using a civic profile. I suppose you could omit the > >service boundary all together, but it would be nice to return > >the geodetic version of the service boundary. > > We discussed this offlist and I agree that it would be useful to > provide > this type of feature. An additional warning code would have to be > specified. > > > > > >11.) Sec. 5.6 [Page 10] states that, "a client receiving a mapping > >response can simply check if it already has a copy of the > >boundary with that identifier. If so, it can skip checking > >with the server whether the > >boundary has been updated. " So this implies that caching > >is not just > >for Mappings but also boundaries. > > This is a mapping: > > expires="2007-01-01T01:44:33Z" > lastUpdated="2006-11-01T01:00:00Z" > source="authoritative.example" > sourceId="cf19bbb038fb4ade95852795f045387d"> > > New York City Police Department > > urn:service:sos.police > > > > > 37.775 -122.4194 > 37.555 -122.4194 > 37.555 -122.4264 > 37.775 -122.4264 > 37.775 -122.4194 > > > > > sip:nypd@example.com > 911 > > > It may contain a service boundary. > > You always cache the whole thing; not parts of it. > When when you compare whether you have something in the cache already > then the place to start the search is the unique identifier. > > > Is it intended that servers > >should maintain a mapping cache and a separate service > >boundary cache? > > Nope; not in my understanding of an implementation. > > What about updating the service boundary > >information, as it seems that service boundaries do not have > >an expiration, lastUpdated, etc.? > > The mapping as a whole has this information and it applies to the > mapping structure in general. > > > > >Also the part that says, "...skip checking with the server..." > >does this imply that if a service boundary reference is > >received by the client in a mapping, then the client should > >automatically check to see if that reference is current if it > >doesn't have that service boundary cached? If so how does it > >determine if it is 'current'? > > The 'source', 'sourceId', and 'lastUpdated' attributes uniquely > identify > a particular mapping record. > > If a client receives a mapping that does not include a serviceBoundary > element but rather a element then by > checking > these three attributes mentioned above it could tell whether it is > useful to perform the lookup. Whenever the mapping data is changed then > the unique identification has to change as well. > > > > > > >12.) Sec. 5.8 [Page 10] Does LoST provide for alternate routing URIs? > >Not to be confused with a substitution. This alternate can > >help routing proxies or clients in the event that a service > >URI is unreachable. I know a mapping can contain multiple > >URIs, but each must use a different URN schema. > > The current spec does not allow multiple URIs with the same URI scheme > to be returned. > > It is, however, possible to provide "load balancing" via the usage of > DNS. The returned URIs will need to be resolved via DNS, see Section 4 > of RFC 5222. > > It is also possible to return multiple elements in the > response. We actually did not say whether you could include the same > URI > in these mappings. Hmmmm. > > > > > >13.) Sec. 8.2.2 Fig. 3 [Page 13-14] In the returned civic service > >boundary, it implies the service is the city of Munich. > > The service that is being asked for is 'urn:service:sos.police'. In the > example we assume that the query for 'urn:service:sos.police' will lead > to a result for this specific service. > > > I'm > >guessing this is okay as long as the civic city boundary does > >not extend beyond > >or overlap the service boundary. > > The query in Figure 3 provides this address: > > DE > Bavaria > Munich > Otto-Hahn-Ring > 6 > 81675 > > If there is a police PSAP who is responsible for that area then we are > fine. From the response in Figure 4 we can tell that the indicated > boundary that will lead to the same result is > > DE > Bavaria > Munich > 81675 > > As mentioned previously, this may not be the real boundary for that > PSAP. > > So, the address in Figure 3 has to be within the indicated boundary. > There are corner cases I forgot to mention -- largely for the geodetic > case where the provided location is not a boundary but rather a > location > shape with less accuracy. Then, the provided location may overlap with > multiple boundaries and then you need to figure out with what boundary > it overlaps most. > > > > It > It also assumes that the A3 element > >is the smallest boundary element returned in the PIDF-LO; > >implying that the A1 and PC elements are either supersets or > >are ignored. Is there an established hierarchy of PIDF-LO > >civic boundary elements? > > There is no hierarchy of PIDF-LO elements as such. > > > > >14.) Sec. 8.3.3 [Page 16] "In recursive mode, the LoST server > >initiates queries on behalf of the requester and returns the > >result to the requester". Does recursion imply querying to > >higher levels in the hierarchy? In other words if a LoST > >Server receives a request for a service outside the area it > >covers, should it consult a forest guide to determine where to > >query in order to fulfill the recursive query? Its parent? > >Should it only recurse to its children? > > This depends largely on the setup of the LoST infrastructure. > > Let's pick an example: An ISP runs a caching LoST server and the > authoritive LoST servers are run by the government of a specific > country. The country LoST server is the forest guide. > > So, an ISP LoST server could be configured to first talk to the country > LoST servers. If the request is still not fulfilled then the country > LoST server would then talk to other forest guides. > > > > > >15.) Sec. 11 [Page 23] Why are via elements optional in > >listServicesByLocationResponse? They are required in a > >findServiceResponse are they not? > > The statement in Section 11 is wrong: > > " > This response MAY contain > elements (see Section 6) and MUST contain a > element, consisting of a whitespace-separated list of service URNs. > " > > The elements are mandatory (also in the RelaxNG schema). > > > > > >16.) Sec. 12 [Page 25] "Requests and responses containing > >or elements MUST contain location > >information in exactly one of the two baseline profiles." > >(also points 3 & 4 under sec. > >12.1) Why can't a location be specified in both a civic and > >geodetic profile in the same request/response? > > The request only carries one location element at the time. If the end > host (or whatever entity) has multiple location objects then it needs > to > issue separate queries. > > RFC 5222 defines two mandatory-to-implement baseline location profiles, > namely a geodetic-2d and a civic profile. > > Page 25 then says: > > " > Requests and responses containing or > elements MUST contain location information in exactly one of the two > baseline profiles, in addition to zero or more additional profiles. > " > > There is no negotiation happening between the involved parties and we > would like to avoid the case where you get a response but you have no > clue what it means. > > For example, if someone defines a new civic location profiles that > allows to express interior location in a more precise fashion then you > could still add location using this new profile but you have to include > location using the fields known from the currently defined civic > profile > as well. > > > > > >17.) Sec. 12.2 [Page 31] states, "If an authoritative server receives > >a query for which the area in the query overlaps the area for > >which the server has mapping information, then it MUST return > >either a mapping > >whose coverage area intersects the query area or a redirect > >to another > >server whose coverage area is a subset of the server's coverage > area". > >Why redirect to just a subset, and not a neighboring coverage area? > >I.e. the case where a location polygon lies mostly in a > >neighboring county and only a small portion of that polygon is > >overlapping our service boundary. > > > > The paragraph you are referring to was written to discuss the case > where > the provided location information is in the form of a location shape > that a certain amount of uncertainty (expressed using the different > shape types). Then, you can run into the case that multiple mapping > could be returned. You might want todo that. However, one needs to > avoid > the case where you redirect forwards and backwards and no result is > being produced. These paragraphs are trying to explain these scenarios. > > > > >18.) Sec. 12.3 [Page 31] states, "A response MAY contain more than > >one element with profile 'civic'". So I > >take this to > >mean that the request can have at most 1 location of each type > >of profile, but serviceBoundaries in the response are allowed > >multiple of type 'civic'. I'm not clear on the purpose here. > > The propose of allowing multiple elements is to be > able to express more complex "shapes". For example, imagine that a PSAP > serves "Finland, Espoo", "Finland, Helsinki", "Finland, Vantaa" and > "Finland, Kauniainen". > > > > >19.) Sec. 12.3 [Page 31] states, "Hence, a response may contain > >multiple elements with civic and/or geodetic > >location profiles". So it seems we can mix civic and > >geodetic-2d in the response, but not in the request location? > >Doesn't this contradict > >sec.12 on page 25? > > The reason is that the group decided that a request for multiple > location elements (which might point to different physical locations) > should better be dealt with by issuing multiple independent queries. > > > > Ciao > Hannes > > > > > >Avery Penniston - Software Developer > >GeoComm Inc. > >601 W. Saint Germain St., Saint Cloud, MN 56301 > >Office: 320.240.0040 Fax: 320.240.2389 Toll Free: 888.436.2666 > >click here to visit www.geo-comm.com > > > >_______________________________________________ > >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 apenniston@geo-comm.com Wed Aug 12 13:49:35 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5443A6948 for ; Wed, 12 Aug 2009 13:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjMMtgd2QGbF for ; Wed, 12 Aug 2009 13:49:32 -0700 (PDT) Received: from mail.geo-comm.com (geo-comm.com [66.173.42.242]) by core3.amsl.com (Postfix) with ESMTP id D6F4628C155 for ; Wed, 12 Aug 2009 13:49:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 15:51:08 -0500 Message-ID: <909A20ADCD98AD4FB9984A87063A5605031671CA@exchange.geo-comm.local> In-Reply-To: <007501ca1b5e$f43ec2b0$dcbc4810$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Questions/Comments Thread-Index: AcoaAFwCRxMfYy0LRqmpfX/53hvJYwAlqv2wADGC9+AABr76sA== References: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local><3D3C75174CB95F42AD6BCC56E5555B450197512C@FIESEXC015.nsn-intra.net> <007501ca1b5e$f43ec2b0$dcbc4810$@net> From: "Avery Penniston" To: "Brian Rosen" , "Tschofenig, Hannes (NSN - FI/Espoo)" , Subject: Re: [Ecrit] LoST Questions/Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:49:35 -0000 Hi Hannes, Brian, et al., I think a hierarchy for PIDF-LO is essential for comparing civic locations in order to mitigate relational ambiguity of locations. Brian mentioned that the A elements already provide a level of hierarchy, and it makes sense, for example, to include the country code to disambiguate Munich, DE from any Munich. But what about cases where the A1 element is provided as well,(i.e. Munich, Bavaria, DE), and a comparison location does not include that element (i.e. Munich, DE). Should these locations not be equal because one contains additional information? The answer might be that, no, they are equivalent because there is only 1 Munich in Germany, and the A1 element becomes irrelevant. But this forces another burden on the LoST Server to verify, if any elements in the A levels (above the lowest one provided) are missing, that a child element's value is only found only once in the higher A element that it is aware of in order to be valid. So for example, if a location had a fictitious PIDF-LO of deZeppelin Square, then the LoST server would have to check all of Germany to make sure there is only 1 neighborhood of that name. This becomes more tedious the bigger the 'gap' between the highest and lowest A element provided. Brian, on the other topic for error reporting, are you suggesting a new query/response type for LoST? Such as: urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 urn:service:sos.police mailto:LoSTErrors@SomeCounty.com Also, I have added some additional comments on my original points below: 2.)[Address Validating] I can see this is a bit tricky as it seems the LVF=20 requirement from NENA may seek a different interpretation of what it means to be valid. But it seems to me that it only makes sense to ask a LoST server if a location is valid for routing. Asking it for validity for dispatch=20 seems to fall under the scope of a local PSAP. It seems that LoST's function=20 is simply to route a call to that PSAP, and defining whether an address is=20 complete or accurate enough(valid) seems beyond scope. But since NENA has a=20 genuine need for this, I can see how it might seem easy to logically group LoST with dispatch validation from NENA's point of view. 5.)[Service Numbers] Maybe 5222 should not include the part about being able=20 to query separately. Also the Relax-NG schema for mapping shows the=20 "ServiceNumber"element to be optional. 6.)[lastUpdated Attribute] I have another question regarding the 'lastUpdated'=20 attribute. Suppose in a LoST server a mapping is returned by value normally, then a client requests that it be returned by reference which the server then does. Should the lastUpdated attribute be updated? Or does the 'lastUpdated' only refer to changes in either the service URIs and/or the service boundary definition? 8.) [NO-EXPIRATION attribute] So I gather that a seeker can infer the service=20 boundary (or subset of it) by using the location it passed in.=20 11.) [Service Boundary caching] This is still a bit confusing. Does the word 'identifier' here refer to the SourceId of the mapping, not the key of the service boundary? And 'checking with the server whether the boundary has been updated' refers to re-querying the server for findService to see if the mapping lastUpdated is newer than what is cached, rather than calling getServiceBoundary?? 12.) [Alternate Mappings] I wasn't really suggesting the case where a server goes down and needs to fail-over, I was suggesting a scenario where a=20 natural disaster occurs in ZoneA, and overflow can go to ZoneB's PSAP in a temporary fashion. I suppose a response could return multiple mappings and include some element in LoST's extensibility indicating when a mapping is an alternate. 16.) [request/response profiles] As far as 'the request only carries one location element at a time', that is not the impression I got from 5222 nor the RELAX schema which indicates 1 or more. It says "The query communicates location=20 information using one or more elements". I understand each LoST server must understand both 'civic' and 'geodetic-2d' base profiles, which means that as long as the request/response contains 'a' base profile, it should be ok. What I was getting at is why there is a separation necessary between the civic and geodetic in a request. 17.) [Redirect] So what you are saying, is that if a LoST server can answer a=20 query it must, or redirect to a server which is a child server? 19.) [request/response profiles again] Please see my comments on 16 above. Also=20 please note the 'and/or' in my orginal quote from RFC 5222. This seems to say that a response can contain a civic AND geodetic location. This seems to contradict=20 sec. 12 [Page 25] where it says "Requests and responses containing or elements MUST contain location information in exactly one=20 of the two baseline profiles." Note the phrase 'exactly one'. Thanks for taking the time to look at my questions/comments. Avery > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, August 12, 2009 10:10 AM > To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; Avery Penniston; > ecrit@ietf.org > Subject: Re: [Ecrit] LoST Questions/Comments >=20 > I think the Error Reporting URI is obtained by querying LoST with a > distinguished service URN, which yields the URI of the error reporting > service. We need to define that service URN. >=20 > I'd like to start a discussion of: > > There is no hierarchy of PIDF-LO elements as such. > I think this is an impractical answer, and the A levels are a > hierarchy. >=20 > If I say it's good in Munich, it's good in Munich DE, and not any > Munich, > for example. The higher A levels are by default included. >=20 > Brian >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of Tschofenig, Hannes (NSN - FI/Espoo) > > Sent: Wednesday, August 12, 2009 7:28 AM > > To: ext Avery Penniston; ecrit@ietf.org > > Subject: Re: [Ecrit] LoST Questions/Comments > > > > Hi Avery, > > > > Thanks for the very detailed reading of the document and for your > > feedback. > > See my comments below: > > > > >Hello, > > > > > >I have recently been reviewing the LoST proposed protocol in > > >RFC 5222 and have some questions and comments that I am hoping > > >I can get some help with. Since I have joined the list, > > >discussion seems to be centered around newer topics than 5222, > > >but I would appreciate any clarification, or comments on any > > >of the points below. All references below refer to RFC 5222 > > >unless stated otherwise. > > > > > >Avery > > > > > > > > >1.) Sec. 1 [Page3] states, "LoST satisfies the requirements > [18] > > >for mapping protocols." However I haven't seen how LoST > > >handles this requirement from RFC 5012: > > >"Ma13. URL for error reporting: The mapping protocol MUST > > >support the ability to return a URL that can be used to report > > >a suspected or known error within the mapping database." It > > >seems that a source is returned, but not a specific URL for > > >error reporting. > > > > Strictly speaking we satisfy the requirement as we "provide the > > possibility to return ..." with the extension points offered via > > RelaxNG. :-) > > > > More seriously, you are right that we did not define an XML element > > that > > could carry a URL for error reporting. > > > > > > > > > > >2.) Sec. 1[Page 3] states, "For civic addresses, LoST can > indicate > > >which parts of the civic address are known to be valid or > > >invalid, thus providing address validation, as described in > > >Section 3.5 of [18]. " > > >However in Sec 3.5 of RFC 5012 it says that a location is > > >valid if the location is recognizable, AND "can be mapped to > > >one or more PSAPs". So is it implied that the request > > >location is invalid if no mappings are returned in the > > >findServiceResponse? If that is the case couldn't a notFound > > >error returned imply the same? It just seems to me that > > >perhaps the location might be valid whether or not it maps to a > PSAP. > > > > You are again touch on some sensitive issues. Yes, we have noticed > that > > we used different semantics for the term "location validation" over > > time. This has a bit to do with the work done together with NENA > where > > the terminology also changed over time. > > > > > > Looking at RFC 5012 we could call this definition as being valid for > > routing purposes: > > > > Location validation: A caller location is considered valid if the > > civic or geographic location is recognizable within an > acceptable > > location reference system (e.g., United States Postal Address > or > > the WGS-84 datum) and can be mapped to one or more PSAPs. > While > > it is desirable to determine that a location exists, validation > > may not ensure that such a location exists, but rather may only > > ensure that the location falls within some range of known > values. > > Location validation ensures that a location is able to be > > referenced for mapping, but makes no assumption about the > > association between the caller and the caller's location. > > > > However, the LoST document actually uses a different definition for > > location validation, namely one that refers only to civic addresses > and > > the existence of the address (with respect to a database) for > dispatch > > purposes. > > > > For example, if you have the address Otto-Hahn-Ring 100, Munich would > > not be valid with the semantic used in LoST but would be valid > > according > > to RFC 5012 (if there is a PSAP boundary that covers the entire > > region). > > > > > > > > How do we fix this? Good question. We could re-issue an update to RFC > > 5012 to fix the terminology. We could also re-issue RFC 5222 and > > include > > updated terminology there. I don't know what the group thinks about > > that. > > > > > > > > > >3.) Sec. 1 [Page 4] states that a LoST server optionally > returns > > >"hints" about the service boundary. As far as I could tell it > > >was either a representation of the boundary itself or a > > >reference to it. > > >Not sure what is meant by hints. > > > > The LoST server either returns nothing, the boundary or a reference > to > > it. > > The boundary returned in LoST may or may not reflect the exact > > boundary. > > This is what is meant by hint. > > > > > > > > > >4.) Sec. 2 [Page 5] in the definition for Service Boundary it > states > > >that it "circumscribes the region within which all locations > > >map to the same service URI or set of URIs for a given > > >service". I take this to mean that it is a polygon > > >representing a service area. So when returning service > > >boundaries either in mappings or in getServiceBoundaryResponse > > >should the boundary returned be the exact boundary or can a > > >subset of the service boundary be returned? > > > > It does not need to be the exact boundary. When a boundary is > returned > > then it has to be a subset (described with the above-stated > > definition). > > > > > > The boundary may be described using a civic or a geodetic location > > format. > > > > > > > >5.) Sec. 3 [Page 5] under it says that, "The same > > >query type may also ask for location validation and for > > >service numbers, either combined with a mapping request or > > >separately". I understand that the location validation and > > >service numbers are returned in the response, but I don't see > > >any attribute in request that allows the > > >explicit request for service numbers, nor do I see any query > > >type that allows the location validation or service number > > >query "separately". > > > > There is no mechanisms to ask for location validation or for service > > numbers separately. > > > > The query returns the service numbers in the > > element. The is a mandatory element. > > > > > > > > > >6.) Sec. 5.1 [Page 7] Regarding the 'lastUpdated' attribute, is > it > > >intended that this time should be the time when the mapping is > > >'created' > > >for example when map data is loaded on server, or when map > > >data is updated, or when the mapping is returned to the > > >client? This seems to imply that mappings should be created at > > >a time prior to the request being responded to. Is that correct? > > > > The 'lastUpdated' attribute refers to the time when the mapping was > > created. > > Whenever the mapping is changed then a new timestamp must be created. > > > > The mappings are indeed created prior to the query. > > > > > > > > > >7.) Sec. 5.1 [Page 7] states, "A receiver can replace a > mapping > > >with another one having the same 'source' and sourceId' and a > > >more recent time in 'lastUpdated'". > > >I assume this means a client updating its cache, and not a > > >LoST server in the middle of a recursive query? So replacing a > > >mapping refers to replacing it in local cache and not > > >replacing the mapping returned to a client with a newer one > > >than the one received recursively? > > > > You are right that this refers to the cache. > > > > > > > >8.) Sec. 5.2 [Page 8] How is it possible for a client to ever > update > > >its cache of mappings with an expiration of "NO-EXPIRATION"? > > >It seems that the only way to get new mappings in this case is > > >if it happens to receive a mapping with a newer 'lastUpdated' > > >attribute. Until then the server would return invalid mapping > > >information. When would it be advisable to use > > >"NO-EXPIRATION"? Also, if a mapping does not contain any > > >ServiceBoundary or ServiceBoundaryReference elements is there > > >any reason to cache it? > > > > The usage of "NO-EXPIRATION" is IMHO only useful in controlled > > environments where you want to force caching for a long time. > > > > If there is no boundary associated with the mapping then the > > information > > the client gets depends on the location it used in the request. For > > example, if I asked for Germany then the response it gets would be > > either be an error, or a mapping and that mapping would be usable for > > all places within Germany. > > > > > > >9.) Sec. 5.4 [Page 8] When returning an "alternate service that > > >approximates the desired service" is it implied here that the > > >server MUST return a serviceSubstitution warning? > > > > Yes. The element would then contain the Service URN that > was > > used for the lookup. > > > > > > > > > >10.) Sec. 5.5 [Page 9] states, "If included in a response, the > > > element MUST contain at least one service > > >boundary that uses the same profile as the request". (Also > > >point 9 under sec. > > > > > > >This could be difficult when trying to make a geodetic > > >service boundary polygon 'fit' into a civic profile to match a > > >request using a civic profile. I suppose you could omit the > > >service boundary all together, but it would be nice to return > > >the geodetic version of the service boundary. > > > > We discussed this offlist and I agree that it would be useful to > > provide > > this type of feature. An additional warning code would have to be > > specified. > > > > > > > > > >11.) Sec. 5.6 [Page 10] states that, "a client receiving a > mapping > > >response can simply check if it already has a copy of the > > >boundary with that identifier. If so, it can skip checking > > >with the server whether the > > >boundary has been updated. " So this implies that caching > > >is not just > > >for Mappings but also boundaries. > > > > This is a mapping: > > > > > expires=3D"2007-01-01T01:44:33Z" > > lastUpdated=3D"2006-11-01T01:00:00Z" > > source=3D"authoritative.example" > > sourceId=3D"cf19bbb038fb4ade95852795f045387d"> > > > > New York City Police Department > > > > urn:service:sos.police > > > > > > > > > > 37.775 -122.4194 > > 37.555 -122.4194 > > 37.555 -122.4264 > > 37.775 -122.4264 > > 37.775 -122.4194 > > > > > > > > > > sip:nypd@example.com > > 911 > > > > > > It may contain a service boundary. > > > > You always cache the whole thing; not parts of it. > > When when you compare whether you have something in the cache already > > then the place to start the search is the unique identifier. > > > > > Is it intended that servers > > >should maintain a mapping cache and a separate service > > >boundary cache? > > > > Nope; not in my understanding of an implementation. > > > > What about updating the service boundary > > >information, as it seems that service boundaries do not have > > >an expiration, lastUpdated, etc.? > > > > The mapping as a whole has this information and it applies to the > > mapping structure in general. > > > > > > > >Also the part that says, "...skip checking with the server..." > > >does this imply that if a service boundary reference is > > >received by the client in a mapping, then the client should > > >automatically check to see if that reference is current if it > > >doesn't have that service boundary cached? If so how does it > > >determine if it is 'current'? > > > > The 'source', 'sourceId', and 'lastUpdated' attributes uniquely > > identify > > a particular mapping record. > > > > If a client receives a mapping that does not include a > serviceBoundary > > element but rather a element then by > > checking > > these three attributes mentioned above it could tell whether it is > > useful to perform the lookup. Whenever the mapping data is changed > then > > the unique identification has to change as well. > > > > > > > > > > > >12.) Sec. 5.8 [Page 10] Does LoST provide for alternate routing > URIs? > > >Not to be confused with a substitution. This alternate can > > >help routing proxies or clients in the event that a service > > >URI is unreachable. I know a mapping can contain multiple > > >URIs, but each must use a different URN schema. > > > > The current spec does not allow multiple URIs with the same URI > scheme > > to be returned. > > > > It is, however, possible to provide "load balancing" via the usage of > > DNS. The returned URIs will need to be resolved via DNS, see Section > 4 > > of RFC 5222. > > > > It is also possible to return multiple elements in the > > response. We actually did not say whether you could include the same > > URI > > in these mappings. Hmmmm. > > > > > > > > > >13.) Sec. 8.2.2 Fig. 3 [Page 13-14] In the returned civic > service > > >boundary, it implies the service is the city of Munich. > > > > The service that is being asked for is 'urn:service:sos.police'. In > the > > example we assume that the query for 'urn:service:sos.police' will > lead > > to a result for this specific service. > > > > > I'm > > >guessing this is okay as long as the civic city boundary does > > >not extend beyond > > >or overlap the service boundary. > > > > The query in Figure 3 provides this address: > > > > DE > > Bavaria > > Munich > > Otto-Hahn-Ring > > 6 > > 81675 > > > > If there is a police PSAP who is responsible for that area then we > are > > fine. From the response in Figure 4 we can tell that the indicated > > boundary that will lead to the same result is > > > > DE > > Bavaria > > Munich > > 81675 > > > > As mentioned previously, this may not be the real boundary for that > > PSAP. > > > > So, the address in Figure 3 has to be within the indicated boundary. > > There are corner cases I forgot to mention -- largely for the > geodetic > > case where the provided location is not a boundary but rather a > > location > > shape with less accuracy. Then, the provided location may overlap > with > > multiple boundaries and then you need to figure out with what > boundary > > it overlaps most. > > > > > > > > It > > It also assumes that the A3 element > > >is the smallest boundary element returned in the PIDF-LO; > > >implying that the A1 and PC elements are either supersets or > > >are ignored. Is there an established hierarchy of PIDF-LO > > >civic boundary elements? > > > > There is no hierarchy of PIDF-LO elements as such. > > > > > > > >14.) Sec. 8.3.3 [Page 16] "In recursive mode, the LoST server > > >initiates queries on behalf of the requester and returns the > > >result to the requester". Does recursion imply querying to > > >higher levels in the hierarchy? In other words if a LoST > > >Server receives a request for a service outside the area it > > >covers, should it consult a forest guide to determine where to > > >query in order to fulfill the recursive query? Its parent? > > >Should it only recurse to its children? > > > > This depends largely on the setup of the LoST infrastructure. > > > > Let's pick an example: An ISP runs a caching LoST server and the > > authoritive LoST servers are run by the government of a specific > > country. The country LoST server is the forest guide. > > > > So, an ISP LoST server could be configured to first talk to the > country > > LoST servers. If the request is still not fulfilled then the country > > LoST server would then talk to other forest guides. > > > > > > > > > >15.) Sec. 11 [Page 23] Why are via elements optional in > > >listServicesByLocationResponse? They are required in a > > >findServiceResponse are they not? > > > > The statement in Section 11 is wrong: > > > > " > > This response MAY contain > > elements (see Section 6) and MUST contain a > > element, consisting of a whitespace-separated list of service > URNs. > > " > > > > The elements are mandatory (also in the RelaxNG schema). > > > > > > > > > >16.) Sec. 12 [Page 25] "Requests and responses containing > > > >or elements MUST contain location > > >information in exactly one of the two baseline profiles." > > >(also points 3 & 4 under sec. > > >12.1) Why can't a location be specified in both a civic and > > >geodetic profile in the same request/response? > > > > The request only carries one location element at the time. If the end > > host (or whatever entity) has multiple location objects then it needs > > to > > issue separate queries. > > > > RFC 5222 defines two mandatory-to-implement baseline location > profiles, > > namely a geodetic-2d and a civic profile. > > > > Page 25 then says: > > > > " > > Requests and responses containing or > > elements MUST contain location information in exactly one of the > two > > baseline profiles, in addition to zero or more additional > profiles. > > " > > > > There is no negotiation happening between the involved parties and we > > would like to avoid the case where you get a response but you have no > > clue what it means. > > > > For example, if someone defines a new civic location profiles that > > allows to express interior location in a more precise fashion then > you > > could still add location using this new profile but you have to > include > > location using the fields known from the currently defined civic > > profile > > as well. > > > > > > > > > >17.) Sec. 12.2 [Page 31] states, "If an authoritative server > receives > > >a query for which the area in the query overlaps the area for > > >which the server has mapping information, then it MUST return > > >either a mapping > > >whose coverage area intersects the query area or a redirect > > >to another > > >server whose coverage area is a subset of the server's coverage > > area". > > >Why redirect to just a subset, and not a neighboring coverage area? > > >I.e. the case where a location polygon lies mostly in a > > >neighboring county and only a small portion of that polygon is > > >overlapping our service boundary. > > > > > > > The paragraph you are referring to was written to discuss the case > > where > > the provided location information is in the form of a location shape > > that a certain amount of uncertainty (expressed using the different > > shape types). Then, you can run into the case that multiple mapping > > could be returned. You might want todo that. However, one needs to > > avoid > > the case where you redirect forwards and backwards and no result is > > being produced. These paragraphs are trying to explain these > scenarios. > > > > > > > > >18.) Sec. 12.3 [Page 31] states, "A response MAY contain more > than > > >one element with profile 'civic'". So I > > >take this to > > >mean that the request can have at most 1 location of each type > > >of profile, but serviceBoundaries in the response are allowed > > >multiple of type 'civic'. I'm not clear on the purpose here. > > > > The propose of allowing multiple elements is to be > > able to express more complex "shapes". For example, imagine that a > PSAP > > serves "Finland, Espoo", "Finland, Helsinki", "Finland, Vantaa" and > > "Finland, Kauniainen". > > > > > > > >19.) Sec. 12.3 [Page 31] states, "Hence, a response may contain > > >multiple elements with civic and/or geodetic > > >location profiles". So it seems we can mix civic and > > >geodetic-2d in the response, but not in the request location? > > >Doesn't this contradict > > >sec.12 on page 25? > > > > The reason is that the group decided that a request for multiple > > location elements (which might point to different physical locations) > > should better be dealt with by issuing multiple independent queries. > > > > > > > > Ciao > > Hannes > > > > > > > > >Avery Penniston - Software Developer > > >GeoComm Inc. > > >601 W. Saint Germain St., Saint Cloud, MN 56301 > > >Office: 320.240.0040 Fax: 320.240.2389 Toll Free: 888.436.2666 > > >click here to visit www.geo-comm.com > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Wed Aug 12 14:36:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9FD93A67A8 for ; Wed, 12 Aug 2009 14:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.506 X-Spam-Level: X-Spam-Status: No, score=0.506 tagged_above=-999 required=5 tests=[AWL=-1.883, BAYES_00=-2.599, FRT_PENIS1=3.592, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5aHZRbbOlMg for ; Wed, 12 Aug 2009 14:36:10 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6F8BA28C147 for ; Wed, 12 Aug 2009 14:36:10 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_12_16_58_25 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 12 Aug 2009 16:58:24 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 16:35:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 16:31:40 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Questions/Comments Thread-Index: AcoaAFwCRxMfYy0LRqmpfX/53hvJYwAlqv2wADGC9+AABr76sAAHDguU References: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local><3D3C75174CB95F42AD6BCC56E5555B450197512C@FIESEXC015.nsn-intra.net><007501ca1b5e$f43ec2b0$dcbc4810$@net> <909A20ADCD98AD4FB9984A87063A5605031671CA@exchange.geo-comm.local> From: "Winterbottom, James" To: "Avery Penniston" , "Brian Rosen" , "Tschofenig, Hannes (NSN - FI/Espoo)" , X-OriginalArrivalTime: 12 Aug 2009 21:35:35.0936 (UTC) FILETIME=[D4000000:01CA1B94] Subject: Re: [Ecrit] LoST Questions/Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 21:36:11 -0000 Hi Avery,=0D=0A=0D=0AThere are quite strong recommendations being made in G= eopriv about countries profiling civic addresses for their jurisdictions.=0D= =0Ahttp://www.ietf.org/id/draft-ietf-geopriv-civic-address-recommendations-= 03.txt=0D=0A=0D=0ADoing this ensures that civic addresses have specific for= ms for specific countries and the comparison issues you describe below beco= me unnecessary, because you don't conform to the normalized form for the ju= risdiction then your location is invalid.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org on be= half of Avery Penniston=0D=0ASent: Wed 8/12/2009 3:51 PM=0D=0ATo: Brian Ros= en; Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org=0D=0ASubject: Re: [= Ecrit] LoST Questions/Comments=0D=0A=20=0D=0AHi Hannes, Brian, et al.,=0D=0A=0D= =0A=0D=0AI think a hierarchy for PIDF-LO is essential for comparing civic=0D= =0Alocations in order to mitigate relational ambiguity of locations. Brian=0D= =0Amentioned that the A elements already provide a level of hierarchy, and=0D= =0Ait makes sense, for example, to include the country code to disambiguate=0D= =0AMunich, DE from any Munich. But what about cases where the A1 element=0D= =0Ais provided as well,(i.e. Munich, Bavaria, DE), and a comparison=0D=0Alo= cation does not include that element (i.e. Munich, DE). Should these=0D=0A= locations not be equal because one contains additional information=3F The=0D= =0Aanswer might be that, no, they are equivalent because there is only 1=0D= =0AMunich in Germany, and the A1 element becomes irrelevant. But this=0D=0A= forces another burden on the LoST Server to verify, if any elements in=0D=0A= the A levels (above the lowest one provided) are missing, that a child=0D=0A= element's value is only found only once in the higher A element that it=0D=0A= is aware of in order to be valid. So for example, if a location had a=0D=0A= fictitious PIDF-LO of deZeppelin Square,=0D=0At= hen the LoST server would have to check all of Germany to make sure=0D=0Ath= ere is only 1 neighborhood of that name. This becomes more tedious=0D=0Ath= e bigger the 'gap' between the highest and lowest A element provided.=0D=0A=0D= =0ABrian, on the other topic for error reporting, are you suggesting a new=0D= =0Aquery/response type for LoST=3F Such as:=0D=0A =0D=0A = urn:service:sos.police=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A = 37.775 -122.4194=0D=0A 37.555 -= 122.4194=0D=0A 37.555 -122.4264=0D=0A= 37.775 -122.4264=0D=0A 37= =2E775 -122.4194=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A=0D=0A =0D=0A urn:service= :sos.police=0D=0A mailto:LoSTErrors@SomeCounty.com=0D= =0A =0D=0A=0D=0A=0D=0AAlso, I have added some addit= ional comments on my original points below:=0D=0A=0D=0A2.)[Address Validati= ng] I can see this is a bit tricky as it seems the=0D=0ALVF=20=0D=0Arequire= ment from NENA may seek a different interpretation of what it=0D=0Ameans=0D= =0Ato be valid. But it seems to me that it only makes sense to ask a LoST=0D= =0Aserver if a location is valid for routing. Asking it for validity for=0D= =0Adispatch=20=0D=0Aseems to fall under the scope of a local PSAP. It seem= s that LoST's=0D=0Afunction=20=0D=0Ais simply to route a call to that PSAP,= and defining whether an address=0D=0Ais=20=0D=0Acomplete or accurate enoug= h(valid) seems beyond scope. But since NENA=0D=0Ahas a=20=0D=0Agenuine nee= d for this, I can see how it might seem easy to logically=0D=0Agroup LoST=0D= =0Awith dispatch validation from NENA's point of view.=0D=0A=0D=0A5.)[Servi= ce Numbers] Maybe 5222 should not include the part about being=0D=0Aable =0D= =0Ato query separately. Also the Relax-NG schema for mapping shows the=20=0D= =0A"ServiceNumber"element to be optional.=0D=0A=0D=0A6.)[lastUpdated Attrib= ute] I have another question regarding the=0D=0A'lastUpdated'=20=0D=0Aattri= bute. Suppose in a LoST server a mapping is returned by value=0D=0Anormall= y,=0D=0Athen a client requests that it be returned by reference which the s= erver=0D=0Athen does.=0D=0AShould the lastUpdated attribute be updated=3F O= r does the 'lastUpdated'=0D=0Aonly refer=0D=0Ato changes in either the serv= ice URIs and/or the service boundary=0D=0Adefinition=3F=0D=0A=0D=0A8.) [NO-= EXPIRATION attribute] So I gather that a seeker can infer the=0D=0Aservice =0D= =0Aboundary (or subset of it) by using the location it passed in.=20=0D=0A=0D= =0A11.) [Service Boundary caching] This is still a bit confusing. Does the=0D= =0Aword=0D=0A'identifier' here refer to the SourceId of the mapping, not th= e key of=0D=0Athe=0D=0Aservice boundary=3F And 'checking with the server wh= ether the boundary has=0D=0Abeen=0D=0Aupdated' refers to re-querying the se= rver for findService to see if the=0D=0Amapping=0D=0AlastUpdated is newer t= han what is cached, rather than calling=0D=0AgetServiceBoundary=3F=3F=0D=0A=0D= =0A=0D=0A12.) [Alternate Mappings] I wasn't really suggesting the case wher= e a=0D=0Aserver=0D=0Agoes down and needs to fail-over, I was suggesting a s= cenario where a=20=0D=0Anatural disaster occurs in ZoneA, and overflow can = go to ZoneB's PSAP in=0D=0Aa=0D=0Atemporary fashion. I suppose a response = could return multiple mappings=0D=0Aand include=0D=0Asome element in LoST's= extensibility indicating when a mapping is an=0D=0Aalternate.=0D=0A=0D=0A1= 6.) [request/response profiles] As far as 'the request only carries one=0D=0A= location=0D=0Aelement at a time', that is not the impression I got from 522= 2 nor the=0D=0ARELAX schema=0D=0Awhich indicates 1 or more. It says "The query communicates=0D=0Alocation=20=0D=0Ainformation using one = or more elements".=0D=0A=0D=0AI understand each LoST server must= understand both 'civic' and=0D=0A'geodetic-2d' base=0D=0Aprofiles, which m= eans that as long as the request/response contains 'a'=0D=0Abase=0D=0Aprofi= le, it should be ok. What I was getting at is why there is a=0D=0Aseparati= on=0D=0Anecessary between the civic and geodetic in a request.=0D=0A=0D=0A1= 7.) [Redirect] So what you are saying, is that if a LoST server can=0D=0Aan= swer a=20=0D=0Aquery it must, or redirect to a server which is a child serv= er=3F=0D=0A=0D=0A19.) [request/response profiles again] Please see my comme= nts on 16=0D=0Aabove. Also=20=0D=0Aplease note the 'and/or' in my orginal = quote from RFC 5222. This seems=0D=0Ato say that=0D=0Aa response can conta= in a civic AND geodetic location. This seems to=0D=0Acontradict=20=0D=0Ase= c. 12 [Page 25] where it says "Requests and responses containing=0D=0A=0D=0Aor elements MUST contain location information = in=0D=0Aexactly one=20=0D=0Aof the two baseline profiles." Note the phrase = 'exactly one'.=0D=0A=0D=0A=0D=0A=0D=0AThanks for taking the time to look at= my questions/comments.=0D=0A=0D=0AAvery=0D=0A=0D=0A=0D=0A-----------------= ---------------------------------------------------------------------------= ----=0D=0AThis message is for the designated recipient only and may=0D=0Aco= ntain privileged, proprietary, or otherwise private information. =20=0D=0AI= f you have received it in error, please notify the sender=0D=0Aimmediately = and delete the original. Any unauthorized use of=0D=0Athis email is prohib= ited.=0D=0A----------------------------------------------------------------= --------------------------------=0D=0A[mf2]=0D=0A From Martin.Thomson@andrew.com Wed Aug 12 16:16:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DA83A6AE9 for ; Wed, 12 Aug 2009 16:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-1.790, BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niKivFTIRRti for ; Wed, 12 Aug 2009 16:16:36 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id ED6243A681C for ; Wed, 12 Aug 2009 16:16:35 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_12_18_38_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); Wed, 12 Aug 2009 18:38:48 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 18:15:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 12 Aug 2009 18:16:01 -0500 Message-ID: In-Reply-To: <909A20ADCD98AD4FB9984A87063A5605031671CA@exchange.geo-comm.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Questions/Comments - civic hierarchy Thread-Index: AcoaAFwCRxMfYy0LRqmpfX/53hvJYwAlqv2wADGC9+AABr76sAAKb7Sw References: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local><3D3C75174CB95F42AD6BCC56E5555B450197512C@FIESEXC015.nsn-intra.net><007501ca1b5e$f43ec2b0$dcbc4810$@net> <909A20ADCD98AD4FB9984A87063A5605031671CA@exchange.geo-comm.local> From: "Thomson, Martin" To: "Avery Penniston" , "Brian Rosen" , "Tschofenig, Hannes (NSN - FI/Espoo)" , X-OriginalArrivalTime: 12 Aug 2009 23:15:59.0644 (UTC) FILETIME=[DA68E5C0:01CA1BA2] Subject: Re: [Ecrit] LoST Questions/Comments - civic hierarchy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 23:16:36 -0000 SGkgQXZlcnksDQoNCldoZW4geW91IHJlcXVlc3QgYSBoaWVyYXJjaHksIG9yIG9yZGVyaW5nLCBv ZiBjaXZpYyBhZGRyZXNzZXMsIHRoaXMgaXMgT0sgZm9yIHRoZSB0b3AtbGV2ZWwgQSogcGFyYW1l dGVycywgYnV0IGl0IHF1aWNrbHkgZmFpbHMgYXQgb3RoZXIgbGV2ZWxzLiAgSXQgaXMgZXZlbiBu b3QgcG9zc2libGUgd2hlbiBjb21wYXJpbmcgQSogcGFyYW1ldGVycyB3aXRoIG5vbi1BKiBwYXJh bWV0ZXJzLiAgDQoNCkZvciBpbnN0YW5jZSwgcG9zdGFsIGNvZGVzIG9mdGVuIGNvdmVyIGFuIGFy ZWEgZXF1aXZhbGVudCB0byBhIHN1YnVyYiBpbiBzY2FsZSwgd2hpY2ggaXMgQTQuICBUaG9yb3Vn aGZhcmVzIGZyZXF1ZW50bHkgcGFzcyB0aHJvdWdoIG11bHRpcGxlIHN1YnVyYnMgKEE0KSwgc29t ZXRpbWVzIGV2ZW4gc3RhdGVzIChBMSkuDQoNCldoaWxlIGl0J3MgbmljZSBpbiB0aGVvcnksIHlv dSBjYW4ndCByZWx5IG9uIG9yZGVyaW5nIG91dHNpZGUgb2YgQSouICBBcyBhIGhpbnQsIHRoZSBj aXZpYyBhZGRyZXNzICJib3VuZGFyeSIgY2FuIG9ubHkgYmUgaW50ZXJwcmV0ZWQgaW4gYSB2ZXJ5 IG5hcnJvdyB3YXk6IA0KDQogIElmIGFueSBvZiB0aGUgcHJvdmlkZWQgZWxlbWVudHMgY2hhbmdl IGZyb20gdGhhdCBzcGVjaWZpZWQsIHRoZSBwcm92aWRlZCBzZXJ2aWNlIFVSSSBubyBsb25nZXIg YXBwbGllcyBhbmQgYSBuZXcgTG9TVCByZXF1ZXN0IGlzIG5lZWRlZC4NCg0KSXQncyBhIHNoYW1l IHRoYXQgTG9TVCBkb2Vzbid0IGFjdHVhbGx5IHNheSB0aGlzLiAgSXQgc2hvdWxkLg0KDQotLU1h cnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGVjcml0LWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g T2YgQXZlcnkgUGVubmlzdG9uDQo+IFNlbnQ6IFRodXJzZGF5LCAxMyBBdWd1c3QgMjAwOSA2OjUx IEFNDQo+IFRvOiBCcmlhbiBSb3NlbjsgVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bv byk7IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIExvU1QgUXVlc3Rpb25z L0NvbW1lbnRzDQo+IA0KPiBIaSBIYW5uZXMsIEJyaWFuLCBldCBhbC4sDQo+IA0KPiANCj4gSSB0 aGluayBhIGhpZXJhcmNoeSBmb3IgUElERi1MTyBpcyBlc3NlbnRpYWwgZm9yIGNvbXBhcmluZyBj aXZpYw0KPiBsb2NhdGlvbnMgaW4gb3JkZXIgdG8gbWl0aWdhdGUgcmVsYXRpb25hbCBhbWJpZ3Vp dHkgb2YgbG9jYXRpb25zLiBCcmlhbg0KPiBtZW50aW9uZWQgdGhhdCB0aGUgQSBlbGVtZW50cyBh bHJlYWR5IHByb3ZpZGUgYSBsZXZlbCBvZiBoaWVyYXJjaHksIGFuZA0KPiBpdCBtYWtlcyBzZW5z ZSwgZm9yIGV4YW1wbGUsIHRvIGluY2x1ZGUgdGhlIGNvdW50cnkgY29kZSB0bw0KPiBkaXNhbWJp Z3VhdGUNCj4gTXVuaWNoLCBERSBmcm9tIGFueSBNdW5pY2guICBCdXQgd2hhdCBhYm91dCBjYXNl cyB3aGVyZSB0aGUgQTEgZWxlbWVudA0KPiBpcyBwcm92aWRlZCBhcyB3ZWxsLChpLmUuIE11bmlj aCwgQmF2YXJpYSwgREUpLCBhbmQgYSBjb21wYXJpc29uDQo+IGxvY2F0aW9uIGRvZXMgbm90IGlu Y2x1ZGUgdGhhdCBlbGVtZW50IChpLmUuIE11bmljaCwgREUpLiAgU2hvdWxkIHRoZXNlDQo+IGxv Y2F0aW9ucyBub3QgYmUgZXF1YWwgYmVjYXVzZSBvbmUgY29udGFpbnMgYWRkaXRpb25hbCBpbmZv cm1hdGlvbj8NCj4gVGhlDQo+IGFuc3dlciBtaWdodCBiZSB0aGF0LCBubywgdGhleSBhcmUgZXF1 aXZhbGVudCBiZWNhdXNlIHRoZXJlIGlzIG9ubHkgMQ0KPiBNdW5pY2ggaW4gR2VybWFueSwgYW5k IHRoZSBBMSBlbGVtZW50IGJlY29tZXMgaXJyZWxldmFudC4gIEJ1dCB0aGlzDQo+IGZvcmNlcyBh bm90aGVyIGJ1cmRlbiBvbiB0aGUgTG9TVCBTZXJ2ZXIgdG8gdmVyaWZ5LCBpZiBhbnkgZWxlbWVu dHMgaW4NCj4gdGhlIEEgbGV2ZWxzIChhYm92ZSB0aGUgbG93ZXN0IG9uZSBwcm92aWRlZCkgYXJl IG1pc3NpbmcsIHRoYXQgYSBjaGlsZA0KPiBlbGVtZW50J3MgdmFsdWUgaXMgb25seSBmb3VuZCBv bmx5IG9uY2UgaW4gdGhlIGhpZ2hlciBBIGVsZW1lbnQgdGhhdCBpdA0KPiBpcyBhd2FyZSBvZiBp biBvcmRlciB0byBiZSB2YWxpZC4gIFNvIGZvciBleGFtcGxlLCBpZiBhIGxvY2F0aW9uIGhhZCBh DQo+IGZpY3RpdGlvdXMgUElERi1MTyBvZiA8Y291bnRyeT5kZTwvY291bnRyeT48QTU+WmVwcGVs aW4gU3F1YXJlPC9BNT4sDQo+IHRoZW4gdGhlIExvU1Qgc2VydmVyIHdvdWxkIGhhdmUgdG8gY2hl Y2sgYWxsIG9mIEdlcm1hbnkgdG8gbWFrZSBzdXJlDQo+IHRoZXJlIGlzIG9ubHkgMSBuZWlnaGJv cmhvb2Qgb2YgdGhhdCBuYW1lLiAgVGhpcyBiZWNvbWVzIG1vcmUgdGVkaW91cw0KPiB0aGUgYmln Z2VyIHRoZSAnZ2FwJyBiZXR3ZWVuIHRoZSBoaWdoZXN0IGFuZCBsb3dlc3QgQSBlbGVtZW50IHBy b3ZpZGVkLg0KPiANCjxzbmlwPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkg YW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHBy aXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdp bmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== From RMarshall@telecomsys.com Thu Aug 13 09:48:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7663A6945 for ; Thu, 13 Aug 2009 09:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV0It3HqFT7q for ; Thu, 13 Aug 2009 09:48:25 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id 005213A68CF for ; Thu, 13 Aug 2009 09:48:24 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Thu, 13 Aug 2009 09:46:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1C35.7FF54A17" Date: Thu, 13 Aug 2009 09:46:01 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750DBFEAB2@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF75 ECRIT Meeting Notes, July 29, 2009 Thread-Index: AcocNYpmdIG4Bhl/SoyydgYO2Jipug== From: "Roger Marshall" To: "ecrit" Subject: [Ecrit] IETF75 ECRIT Meeting Notes, July 29, 2009 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:48:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1C35.7FF54A17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the ECRIT meeting notes that I received and have posted in the Meeting Materials. Thanks go to Spencer! Please reply to the list with any corrections, etc. Roger Marshall=20 *** ECRIT Meeting Notes - IETF75, Stockholm date/time: Wed July 29/ 0900-1130 taken by: Spencer Dawkins 1.1.1 Status Update Hannes is attending virtually this time. Keith - still have outstanding comments on -framework and -phonebcp.=20 This was discussed on June 3rd teleconference, Keith was going to review these documents, but the comments haven't been addressed. No solution has been offered by anyone. Chairs discussed with ADs and can sort this out during IESG evaluation. Cullen said concerns about advancing the document don't have to be solved. Ted - if there's consensus in the working group that the problem needs to be solved, and it isn't solved, that's not good. If the working group doesn't think the problem needs to be solved, that's a different state, but the chairs haven't asked the working group if the problem needs to be solved. Keith - absence of consensus about the proposed text doesn't mean that we addressed the concern. James Polk - proposed text was shot down. Ted - do you think we've had a consensus call on whether there's a problem here? Marc - could have been asked better, but we thought that it was asked. Will add a topic at the end of the session about this. Brian Rosen - actually seeing planned deployments for next year. Need to get these documents finished in time to be used. Marc - EENA is going to line up with NENA, since NENA is ahead. Marc and Hannes are both on the EENA calls as well. 1.1.2 Specifying Holes in LoST Service Boundaries=20 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-01 .txt Cullen raised some concerns about the additional feature that this document requires. =20 He suggested that an alternative would not require support of interior polygons, or holes. Confirmation whether WG is OK with the current direction or whether changes are necessary. Alex - thinks the alternative proposal to create borders is plain wrong. Cullen - fine with this conclusion - asking if it's been discussed. We have running code, but have we discussed it? Is there a technical reason why we're making the decision? GIS systems work with holes - the alternative (to use borders) requires GIS systems to change. Anyone against the current text? No one speaking against it here. 1.1.3 Geocoding and Reverse-geocoding Using Location-to-Service Translation =20 http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.t xt Introduction and discussion around this idea. Geocoding is turning coordinates into civic location.=20 This is being done in ECRIT because all LOST work will happen in ECRIT - Dublin decision. Why not do this in HELD? Think LOST will be in almost all endpoints that are intelligent enough to use this function, not true of HELD. Will have an update in August, fully populated. Know I need to add URNs. Martin - not sure LOST is the right way to query this information. LOST, HELD, or HTTP POST are the alternatives. Think LOST makes the most sense. Richard Barnes - LOST is for discovery, not for geocoding itself. Brian - NENA thinking web service was more appropriate (even on the same box) - needs a different interface. Should be RESTish. Alex - Should separate discovery from the service itself. Ted - think reusing LOST is reasonable, but agree that LOST model is to return a pointer to somewhere else (even if the pointer points to the same box). How do we find the geocoding servers?=20 Martin Thompson - would not be opposed to doing a LOST step as part of the solution. Richard - LOST is fine for discovery, not for geocoding itself.=20 Merge this with geopriv geocoding document (which also does half the problem)? Richard doesn't think this is necessary.=20 Andy - there are better questions to ask - how many times do clients want to ask? What latency is required? How many rounds of transactions do you want to go through, to get the answer? What's best for the client? Hannes thinks proposal makes sense, doesn't care about the number of documents. Looking at number of round trips depends on the type of service - emergency VS non-emergency, for example. Other transformations? Standardized forms of address as an example. Form of URN? If we're doing discovery, probably only need one URN form. 1.1.4 Using Imprecise Location for Emergency Context Resolution=20 http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc What is necessary to finish this work?=20 Document has been through a couple of revisions around civic addresses, but think it's through? Martin - think there's still a hole around civic addresses and service boundaries. Maybe it's not your problem, but there's a problem that needs to be addressed.=20 Brian - don't assume that there's only one way to interpret the data. Want to be cautious about how prescriptive we are. Martin - document discusses general requirements of location independent of type of location. 1.1.5 Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary=20 http://tools.ietf.org/id/draft-wolf-ecrit-lost-servicelistboundary Status of the work and remaining open issues. listServicesByLocation provides a service list, but the area where that service list is valid isn't known. Proposing ServiceListBoundary to provide this information. Ted - we've had this discussion three times in the past and reached the opposite conclusion - need comprehensive knowledge of what services are offered everywhere, and that's computationally painful. You don't re-query unless you need a new service or some period of time has passed. Do you think the service list will churn? Need to get Henning and Karl-Heinz in a room - proxies at both ends in THIS room. Ted - if you're the service provider for Austria, and you're in Vienna which is flat, you STILL find out about mountain rescue in the country, rather than trying to figure out whether you need to be told about mountain rescue. Don't think the issues we're discussing here have been resolved, but don't think they need to be resolved before we accept the document as a working group item. 1.1.6 Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices=20 http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces s What are the open issues with the draft? Are there decisions we can make with the group in the room?=20 Three classifications of "unauthenticated/unauthorized" - no access provider, no VoIP provider, zero-balance with VoIP provider. Brian Rosen - not "VoIP provider", but "service provider". Hannes - Brian's suggestion is fine. "No access provider" is the hardest classification to deal with. WiMAX draft was aligned for this, but has now changed. 1.1.7 Premature Disconnect Indication http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts Discussion got stuck. Attempt to refresh it.=20 Disconnect by user isn't always wrong, and user needs to be in control (don't brick the phone).=20 We have years of experience with this feature.=20 Abandoned call (user disconnects before call is answered by a human call-taker) is a separate issue. Randy - Debate is about whether this is UI or signaling? Actually three cases (signaling at call setup, signaling at call setup and at disconnect time). Draft has gone through several revisions, and has now expired. Draft wasn't acceptable to "do it on the UI" crowd, who demanded more rewrites and promised alternative text, which hasn't happened. "Signal PSAP controlled disconnect" crowd needs solutions. Ted - do we agree that this is a problem that has to be solved? Don't think we've decided that. Randy - think we got wedged because we were only considering two of the three cases (and still allowed serious failure cases).=20 Ted - we're going back to a circuit-switched model that we're not using today, we're going back to a wireline model that we're not even using in cellular. Brian - typically the IETF doesn't do user interactions (although there are discussions in some documents, so starting there should be OK in the IETF). Not opposed to compromise, but don't want to keep trying text changes without some direction, and we need to decide something quickly or the people who need the solution will forum-shop. James Polk - problem is that the requirement starts at disconnect time. Brian - no, that's when the user experience starts, but it doesn't have to be entirely reactive. Ted - you keep coming back and hoping for "yes", but if this had been put forward as a BOF, you would be done (asked twice and been told "no" twice). This isn't going to satisfy Canadian PSAP requirements. This is coming from a time that has passed, and it's not going to be in the code path for half the devices that are out there. Brian - does IETF think that something needs to be done? That was my hope for today. Ted - network can't meet these requirements. If requirements change and this is advisory, the answer could change, but not with the current requirements. Brian - we can come up with an acceptable compromise. Ted - what I need is that user has to agree to the function, and the user can turn the function off (actually, the user's DEVICE has to agree to the function, but).=20 Cullen - is the working group willing to work on this? Keith - is this about early disconnect AND abandoned call? Marc - trying to figure out if we care at all, then let design team fight this out. Might be able to get some movement in SOME direction. Ted - please ask the rest of the group! Randy - only for premature disconnect? Brian - separate the two, only premature disconnect. Are we working on this at all? Think about abandoned call if we make any progress at all. Alex - concerned that we are sneaking legal requirements into the device using protocol mechanisms.=20 Bernard - we're having problem statement discussions now. Need to do that first before we work on protocol mechanisms. Keith - want to do problem statement in an author draft, then adopt as WG item. Brian read text from the current draft that talks about the problem - could reword, but there is text today. Ted - UI-only feature doesn't give you reconnect. Once they send a BYE, network state is torn down and we're not talking about reconnect at all. Brian - could reconnect, or could prevent disconnect - user experience is the same. Ted - no, it's not. Brian - if you close a phone, the only reasonable thing to do is an alert.=20 Ted - when you open a phone, you can tell the difference. Randy - we keep reaching an impasse because requirements sincerely TRY to avoid solutions, but current text assumes a solution. If a small design team can't come up with problem statement text, can't do a solution, either. Keith - not prepared to work on this today. Hoped author draft discussion would move this forward. 1.1.8 Trustworthy Location Information=20 http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location-02. txt What is in the updated version? Does the group want the work?=20 Discussion about the direction of the work. Where is the right place? GEOPRIV/ECRIT? "Prank" emergency calls becoming substantial and serious problem (including SWAT team dispatches). Most pranks spoof both identity and location. These are independent issues. Location could be trusted (Germany) or unknown by PSAP (Ausrria). Marc - in US, carriers still last six digits of ESN into phone number so they have a chance of tracing the caller. Martin - cellular handles unauthenticated calls to some extent. On the border of proprietary, but they handle the calls (generate IMEI, etc). Additional VoIP issues - authentication at multiple layers, anonymous access devices, and lack of link between link identity and SIP identity. Draft focuses on malicious end host. NENA i2 has requirements for "trustworthy location".=20 LLDP-MED endpoint can make an "end run" around return routability.=20 If you know what you're doing, you can generate GPS readings that spoof your location. Potential solutions put forward thus far all have holes. Are VPC and ERDB operators prepared to operate as CAs? Once you've built the bunker, what are the conditions for signing certs? How do PSAPs manage these ACLs and LbyR credentials? Marc - PSAP is still going to accept a call from unauthenticated caller and will always believe the caller about the caller's location. Bernard - lots of expensive infrastructure here, it's complex through the roof.=20 Brian - we can do this, we're going to this, the next generation will have this and be "secure enough".=20 Bernard - if you have a rocket and a pig, I believe you when you say you're launching the pig to the moon. My question is "why?" Brian - installing this infrastructure, could extend to issue certs to a LIS. Martin - number of comments, but this presentation is a critique of i2 - what is the purpose of the presentation? Bernard - to understand the meaning of "trustworthy location". Can cut and paste LbyRs into anything and they still work. What's an alternative definition of "trustworthy location" - auditability after the fact, or determining "prank calls" with an acceptable rate of false positives? 1.1.9 Continued PHONEBCP discussion Is PHONEBCP ready for publication? No one had anything to say. Keith - comments also applied to FRAMEWORK, they both cover the world. The rest of the people thought this was only PHONEBCP. Taking a hum - ready for publication? 70-30 for/against in the room, going to the list... Cullen - nothing will happen to the document until chairs call consensus on the list question. 1.1.10 Real-time text activities relevant for ECRIT=20 http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-01.t xt http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-06.txt http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-02.t xt Status update regarding real-time text activities. Has anybody read the drafts? Not yet...=20 Robert - this is a DISPATCH conversation - it's what DISPATCH is for. Marc asking that people read the drafts and think about emergency services... CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_001_01CA1C35.7FF54A17 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF75 ECRIT Meeting Notes, July 29, 2009

    Here are the ECRIT meeting notes that I re= ceived and have posted in the Meeting Materials.  Thanks go to Spencer= !

    Please reply to the list with any correcti= ons, etc.

    Roger Marshall

    ***

    ECRIT Meeting Notes - IETF75, Stockholm
    date/time: Wed July 29/ 0900-1130
    taken by: Spencer Dawkins


    1.1.1      &= nbsp;     Status Update
    Hannes is attending virtually this time.<= /FONT>

    Keith – still have outstanding comme= nts on –framework and –phonebcp.

    This was discussed on June 3rd teleconfere= nce, Keith was going to review these documents, but  the comments have= n’t been addressed. No solution has been offered by anyone. Chairs di= scussed  with ADs and can sort this out during IESG evaluation. Cullen= said concerns about advancing  the document don’t have to be so= lved.

    Ted = – if there’s consensus in = the working group that the problem needs to be solved, and it  isnR= 17;t solved, that’s not good. If the working group doesn’t thin= k the problem needs to be  solved, that’s a different state, but= the chairs haven’t asked the working group if the  problem need= s to be solved.

    Keith – absence of consensus about t= he proposed text doesn’t mean that we addressed the  concern.

    James Polk – proposed text was shot = down.

    Ted = – do you think we’ve had a= consensus call on whether there’s a problem here?

    Marc – could have been asked better,= but we thought that it was asked. Will add a topic at the  end of the= session about this.

    Brian Rosen – actually seeing planne= d deployments for next year. Need to get these documents  finished in = time to be used.

    Marc – EENA is going to line up with= NENA, since NENA is ahead. Marc and Hannes are both on  the EENA call= s as well.

    1.1.2      &= nbsp;     Specifying Holes in LoST Service Boundaries <= /FONT>
    http:/= /www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-01.txt

        Cullen raised some conc= erns about the additional feature that this document requires. 

       He suggested that an alternat= ive would not require support of interior polygons, or holes.

       Confirmation whether WG is OK= with the current direction or whether changes are necessary.

    Alex – thinks the alternative propos= al to create borders is plain wrong.

    Cullen – fine with this conclusion – asking if it’s been discussed. We have running code, but = have we discussed it? Is there a technical reason why we’re making t= he decision?

    GIS systems work with holes – the al= ternative (to use borders) requires GIS systems to change.

    Anyone against the current text? No one sp= eaking against it here.

    1.1.3      &= nbsp;     Geocoding and Reverse-geocoding Using Locatio= n-to-Service Translation 
    http://w= ww.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.txt

       Introduction and discussion a= round this idea.

    Geocoding is turning coordinates into civi= c location.

    This is being done in ECRIT because all LO= ST work will happen in ECRIT –<= /FONT> Dublin decision.

    Why not do this in HELD? Think LOST will b= e in almost all endpoints that are intelligent  enough to use this fun= ction, not true of HELD.

    Will have an update in August, fully popul= ated. Know I need to add URNs.

    Martin – not sure LOST is the right = way to query this information.

    LOST, HELD, or HTTP POST are the alternati= ves. Think LOST makes the most sense.

    Richard Barnes - LOST is for discovery, no= t for geocoding itself.

    Brian – NENA thinking web service wa= s more appropriate (even on the same box) – needs a  different i= nterface. Should be RESTish.

    Alex - Should separate discovery from the = service itself.

    Ted = – think reusing LOST is reasonab= le, but agree that LOST model is to return a pointer to  somewhere els= e (even if the pointer points to the same box).

    How do we find the geocoding servers?

    Martin Thompson – would not be oppos= ed to doing a LOST step as part of the solution.

    Richard – LOST is fine for discovery= , not for geocoding itself.

    Merge this with geopriv geocoding document= (which also does half the problem)? Richard doesn’t  think this= is necessary.

    Andy – there are better questions to= ask – how many times do clients want to ask? What latency  is r= equired? How many rounds of transactions do you want to go through, to get = the answer?  What’s best for the client?

    Hannes thinks proposal makes sense, doesn&= #8217;t care about the number of documents. Looking at  number of roun= d trips depends on the type of service – emergency VS non-emergency, = for  example.

    Other transformations? Standardized forms = of address as an example.

    Form of URN? If we’re doing discover= y, probably only need one URN form.

    1.1.4      &= nbsp;     Using Imprecise Location for Emergency Contex= t Resolution
    http://tools.ietf.org/id/draf= t-barnes-ecrit-rough-loc

       What is necessary to finish t= his work?

    Document has been through a couple of revi= sions around civic addresses, but think it’s  through?

    Martin – think there’s still a= hole around civic addresses and service boundaries. Maybe it’s = not your problem, but there’s a problem that needs to be addressed. =

    Brian – don’t assume that ther= e’s only one way to interpret the data. Want to be cautious  abo= ut how prescriptive we are.

    Martin – document discusses general = requirements of location independent of type of location.

    1.1.5      &= nbsp;     Location-to-Service Translation Protocol (LoS= T) Extension:  ServiceListBoundary
    http://tools.iet= f.org/id/draft-wolf-ecrit-lost-servicelistboundary

       Status of the work and remain= ing open issues.

    listServicesByLocation provides a service = list, but the area where that service list is valid  isn’t known= . Proposing ServiceListBoundary to provide this information.

    Ted = – we’ve had this discussio= n three times in the past and reached the opposite conclusion – = need comprehensive knowledge of what services are offered everywhere, and = that’s  computationally painful. You don’t re-query unless= you need a new service or some period of  time has passed. Do you thi= nk the service list will churn?

    Need to get Henning and Karl-Heinz in a ro= om – proxies at both ends in THIS room.

    Ted = – if you’re the service pr= ovider for Austria, and you’re in Vienna which is flat, you  STI= LL find out about mountain rescue in the country, rather than trying to fig= ure out whether  you need to be told about mountain rescue.

    Don’t think the issues we’re d= iscussing here have been resolved, but don’t think they need to = be resolved before we accept the document as a working group item.<= /P>

    1.1.6      &= nbsp;     Extensions to the Emergency Services Architec= ture for dealing with  Unauthenticated and Unauthorized Devices

    http://too= ls.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access<= /A>

       What are the open issues with= the draft? Are there decisions we can make with the group in  the roo= m?

    Three classifications of “unauthenti= cated/unauthorized” – no access provider, no VoIP  provide= r, zero-balance with VoIP provider.

    Brian Rosen – not “VoIP provid= er”, but “service provider”.

    Hannes – Brian’s suggestion is= fine.

     “No access provider” is = the hardest classification to deal with. WiMAX draft was aligned for  = this, but has now changed.

    1.1.7      &= nbsp;     Premature Disconnect Indication
    http://tool= s.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts

       Discussion got stuck. Attempt= to refresh it.

    Disconnect by user isn’t always wron= g, and user needs to be in control (don’t brick the  phone).

    We have years of experience with this feat= ure.

    Abandoned call (user disconnects before ca= ll is answered by a human call-taker) is a separate  issue.

    Randy - Debate is about whether this is UI= or signaling? Actually three cases (signaling at  call setup, signali= ng at call setup and at disconnect time).

    Draft has gone through several revisions, = and has now expired. Draft wasn’t acceptable to “do  it on= the UI” crowd, who demanded more rewrites and promised alternative t= ext, which hasn’t  happened. “Signal PSAP controlled disco= nnect” crowd needs solutions.

    Ted = – do we agree that this is a pro= blem that has to be solved? Don’t think we’ve decided  tha= t.

    Randy – think we got wedged because = we were only considering two of the three cases (and still  allowed se= rious failure cases).

    Ted = – we’re going back to a ci= rcuit-switched model that we’re not using today, we’re going&nb= sp; back to a wireline model that we’re not even using in cellular.

    Brian – typically the IETF doesnR= 17;t do user interactions (although there are discussions in  some doc= uments, so starting there should be OK in the IETF).

    Not opposed to compromise, but don’t= want to keep trying text changes without some direction,  and we need= to decide something quickly or the people who need the solution will forum= -shop.

    James Polk – problem is that the req= uirement starts at disconnect time.

    Brian – no, that’s when the us= er experience starts, but it doesn’t have to be entirely  reacti= ve.

    Ted = – you keep coming back and hopin= g for “yes”, but if this had been put forward as a BOF,  y= ou would be done (asked twice and been told “no” twice). This i= sn’t going to satisfy Canadian  PSAP requirements. This is comin= g from a time that has passed, and it’s not going to be in the  = code path for half the devices that are out there.

    Brian – does IETF think that somethi= ng needs to be done? That was my hope for today.

    Ted = – network can’t meet these= requirements. If requirements change and this is advisory, the  answe= r could change, but not with the current requirements.

    Brian – we can come up with an accep= table compromise.

    Ted = – what I need is that user has t= o agree to the function, and the user can turn the  function off (actu= ally, the user’s DEVICE has to agree to the function, but).

    Cullen – is the working group willin= g to work on this?

    Keith – is this about early disconne= ct AND abandoned call?

    Marc – trying to figure out if we ca= re at all, then let design team fight this out. Might be  able to get = some movement in SOME direction.

    Ted = – please ask the rest of the gro= up!

    Randy – only for premature disconnec= t?

    Brian – separate the two, only prema= ture disconnect. Are we working on this at all? Think  about abandoned= call if we make any progress at all.

    Alex – concerned that we are sneakin= g legal requirements into the device using protocol  mechanisms.

    Bernard – we’re having problem= statement discussions now. Need to do that first before we work  on p= rotocol mechanisms.

    Keith – want to do problem statement= in an author draft, then adopt as WG item.

    Brian read text from the current draft tha= t talks about the problem – could reword, but there  is text tod= ay.

    Ted = – UI-only feature doesn’t = give you reconnect. Once they send a BYE, network state is torn  down = and we’re not talking about reconnect at all.

    Brian – could reconnect, or could pr= event disconnect – user experience is the same.

    Ted = – no, it’s not.

    Brian – if you close a phone, the on= ly reasonable thing to do is an alert.

    Ted = – when you open a phone, you can= tell the difference.

    Randy – we keep reaching an impasse = because requirements sincerely TRY to avoid solutions, but  current te= xt assumes a solution. If a small design team can’t come up with prob= lem statement  text, can’t do a solution, either.

    Keith – not prepared to work on this= today. Hoped author draft discussion would move this  forward.

    1.1.8      &= nbsp;     Trustworthy Location Information
    http://= tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location-02.txt=

       What is in the updated versio= n? Does the group want the work?

       Discussion about the directio= n of the work. Where is the right place? GEOPRIV/ECRIT?

    “Prank” emergency calls becomi= ng substantial and serious problem (including SWAT team  dispatches).<= /FONT>

    Most pranks spoof both identity and locati= on. These are independent issues. Location could be  trusted (Germany)= or unknown by PSAP (Ausrria).

    Marc – in US, carriers still last si= x digits of ESN into phone number so they have a chance of  tracing th= e caller.

    Martin – cellular handles unauthenti= cated calls to some extent. On the border of proprietary,  but they ha= ndle the calls (generate IMEI, etc).

    Additional VoIP issues – authentic= ation at multiple layers, anonymous access devices, and lack  of link = between link identity and SIP identity.

    Draft focuses on malicious end host.

    NENA i2 has requirements for “trustw= orthy location”.

    LLDP-MED endpoint can make an “end r= un” around return routability.

    If you know what you’re doing, you c= an generate GPS readings that spoof your location.

    Potential solutions put forward thus far a= ll have holes.

    Are VPC and ERDB operators prepared to ope= rate as CAs?

    Once you’ve built the bunker, what a= re the conditions for signing certs?

    How do PSAPs manage these ACLs and LbyR cr= edentials?

    Marc – PSAP is still going to accept= a call from unauthenticated caller and will always  believe the calle= r about the caller’s location.

    Bernard – lots of expensive infrastr= ucture here, it’s complex through the roof.

    Brian – we can do this, we’re = going to this, the next generation will have this and be “secure = ; enough”.

    Bernard – if you have a rocket and a= pig, I believe you when you say you’re launching the pig  to th= e moon. My question is “why?”

    Brian – installing this infrastructu= re, could extend to issue certs to a LIS.

    Martin – number of comments, but thi= s presentation is a critique of i2 &#= 8211; what is the purpose  of the= presentation?

    Bernard – to understand the meaning = of “trustworthy location”.  Can cut and paste LbyRs into&n= bsp; anything and they still work.

    What’s an alternative definition of = “trustworthy location” &#= 8211; auditability after the fact, or&= nbsp; determining “prank calls” with an acceptable rate of fals= e positives?

    1.1.9      &= nbsp;     Continued PHONEBCP discussion
    Is PHONEBCP ready for publication? No one= had anything to say.

    Keith – comments also applied to FRA= MEWORK, they both cover the world.

    The rest of the people thought this was on= ly PHONEBCP.

    Taking a hum – ready for publication= ? 70-30 for/against in the room, going to the list…

    Cullen – nothing will happen to the = document until chairs call consensus on the list question.

    1.1.10      = Real-time text activities relevant for ECRIT
    http://w= ww.ietf.org/internet-drafts/draft-hellstrom-text-conference-01.txt

    http://www.ie= tf.org/internet-drafts/draft-hellstrom-textpreview-06.txt

    http://ww= w.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-02.txt

       Status update regarding real-= time text activities.

    Has anybody read the drafts? Not yet…= ;

    Robert – this is a DISPATCH conversa= tion – it’s what DISPATCH is for.

    Marc asking that people read the drafts an= d think about emergency services…

    CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

    ------_=_NextPart_001_01CA1C35.7FF54A17-- From john@johnlange.ca Thu Aug 13 12:46:17 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800EA3A6BA8 for ; Thu, 13 Aug 2009 12:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN12NE0-h+U6 for ; Thu, 13 Aug 2009 12:46:16 -0700 (PDT) Received: from mail.epicnet.ca (mail.epicnet.ca [64.201.170.210]) by core3.amsl.com (Postfix) with ESMTP id 5CDAF3A67FF for ; Thu, 13 Aug 2009 12:46:16 -0700 (PDT) Received: (qmail 12431 invoked from network); 13 Aug 2009 18:07:41 -0500 Received: from unknown (HELO ?192.168.5.123?) (192.168.5.123) by lh02.epicnet.ca with SMTP; 13 Aug 2009 18:07:41 -0500 From: John Lange To: Richard Barnes In-Reply-To: <4A82F5CC.8000500@bbn.com> References: <9886E5FCA6D76549A3011068483A4BD404BFF773@S4DE8PSAAQB.mitte.t-com.de> <40FB0FFB97588246A1BEFB05759DC8A00343138F@S4DE9JSAANI.ost.t-com.de> <02d601ca16b1$e2464940$a6d2dbc0$@net> <1249586131.5335.57.camel@vandium.darkcore.net> <4A82F5CC.8000500@bbn.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 13 Aug 2009 14:44:56 -0500 Message-Id: <1250192696.5213.29.camel@vandium.darkcore.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 8bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:46:17 -0000 On Wed, 2009-08-12 at 13:03 -0400, Richard Barnes wrote: > >> If your networks don’t deploy DHCP/HELD, and the regulator is happy to > >> force relationships between access networks and calling networks, so > >> that OBO becomes viable: fine. Devices that are –phonebcp compliant > >> will work. > > > > That is the absolute critical point! > > To be precise, however, the scenario Brian is describing still leaves a > gap: VoIP users that use a VoIP provider outside of the jurisdiction > will not be able to make emergency calls. Actually, it might be better to say "may not be able to" or at least "there would likely not be any regulatory requirement that the emergency call be completed." > For instance, if I took a > Vonage ATA to Canada, and Vonage didn't have a pre-existing relationship > with the ISP I was using, Vonage would be unable to route my calls. Most likely that would be true but if the jurisdictions implement the same solutions then there is chance that companies that have a presence in both areas would be able to support their customers that roam between them. That is why I suggest it might be possible to complete calls. > What Brian is describing is a transition strategy. As you point out, > John, it's a critical one, and the path most jurisdictions are starting > with. But it's not the complete solution. The best case scenario is for ECRIT to get the standards done that comprise the interim solution before the various jurisdictions start implementing them. Hopefully we would all have something compatible if and when phone-bcp/ecrit-framework ever becomes practical to implement. -- John Lange http://www.johnlange.ca From apenniston@geo-comm.com Thu Aug 13 14:09:34 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8063A67B6 for ; Thu, 13 Aug 2009 14:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1I7VH-McQ+m for ; Thu, 13 Aug 2009 14:09:33 -0700 (PDT) Received: from mail.geo-comm.com (geo-comm.com [66.173.42.242]) by core3.amsl.com (Postfix) with ESMTP id 064803A62C1 for ; Thu, 13 Aug 2009 14:09:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 13 Aug 2009 16:09:26 -0500 Message-ID: <909A20ADCD98AD4FB9984A87063A5605031676E0@exchange.geo-comm.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Questions/Comments - civic hierarchy Thread-Index: AcoaAFwCRxMfYy0LRqmpfX/53hvJYwAlqv2wADGC9+AABr76sAAKb7SwAC1fruA= References: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local><3D3C75174CB95F42AD6BCC56E5555B450197512C@FIESEXC015.nsn-intra.net><007501ca1b5e$f43ec2b0$dcbc4810$@net> <909A20ADCD98AD4FB9984A87063A5605031671CA@exchange.geo-comm.local> From: "Avery Penniston" To: "Thomson, Martin" , "Brian Rosen" , "Tschofenig, Hannes (NSN - FI/Espoo)" , Subject: Re: [Ecrit] LoST Questions/Comments - civic hierarchy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 21:09:34 -0000 SmFtZXMsIHRoYW5rcyBmb3IgdGhlIGluZm8gb24gdGhlIHdvcmsgZ29pbmcgb24gaW4gR2VvcHJp di4gIEknbSBpbnRlcmVzdGVkIHRvIHNlZSBob3cgdGhhdCBkaXNjdXNzaW9uIHNoYWtlcyBvdXQu ICBTcGVjaWZpY2FsbHkgb24gaG93IGFiYnJldmlhdGlvbnMvYWx0ZXJuYXRlIHNwZWxsaW5ncyBz aG91bGQgYmUgaGFuZGxlZCwgaG93IGVsZW1lbnRzIG90aGVyIHRoYW4gQSBlbGVtZW50cyBnZXQg ZGVmaW5lZCBmb3Igc3VwZXIvc3ViIHNldHMsICBhbmQgaG93IHRvIGNvbXBhcmUgb3B0aW9uYWwg ZWxlbWVudHMgd2hlbiBsZWZ0IGJsYW5rIGluIG9uZSBsb2NhdGlvbiwgYnV0IHN1cHBsaWVkIGlu IGFub3RoZXIuICBQZXJoYXBzIHRoZSBxdWVzdGlvbnMgSSBoYXZlIGFib3V0IGNpdmljIGxvY2F0 aW9uIGNvbXBhcmlzb24gYmVsb25nIGluIHRoZSBHZW9wcml2IFdHLg0KDQpNYXJ0aW4sIEkgdGhp bmsgd2hhdCB5b3UgYXJlIHNheWluZyBpcyB0aGF0IGlmIHR3byBjaXZpYyBsb2NhdGlvbnMgZG8g bm90IG1hdGNoIGV4YWN0bHkgKGJvdGggdGhlIGVsZW1lbnRzIHByb3ZpZGVkLCBhbmQgdGhlIGJs YW5rIGVsZW1lbnRzKSB0aGVuLCBjdXJyZW50bHksIExvU1Qgc2hvdWxkIGNvbnNpZGVyIHRoZW0g bm90IGVxdWFsLiAgQnV0IHNob3VsZCBMb1NUIHRyeSB0byBkZXRlcm1pbmUgaWYgb25lIGxvY2F0 aW9uICdmaXRzJyBpbnNpZGUgYW5vdGhlcj8gIEZvciBleGFtcGxlIGEgcmVzb2x2ZXIgd2FudHMg dG8gY2hlY2sgaWYgYSBsb2NhdGlvbiBpcyBmb3VuZCB3aXRoaW4gb25lIG9mIGl0cyBjYWNoZWQg bWFwcGluZyBzZXJ2aWNlIGJvdW5kYXJpZXMuIA0KDQogSWYgdGhlIHJlcXVlc3QgbG9jYXRpb24g aXMgc29tZXRoaW5nIGxpa2U6DQogICAgICAgICAgPGNvdW50cnk+REU8L2NvdW50cnk+DQogICAg ICAgICAgPEExPkJhdmFyaWE8L0ExPg0KICAgICAgICAgIDxBMz5NdW5pY2g8L0EzPg0KICAgICAg ICAgIDxBNj5PdHRvLUhhaG4tUmluZzwvQTY+DQogICAgICAgICAgPEhOTz42PC9ITk8+DQogICAg ICAgICAgPFBDPjgxNjc1PC9QQz4NCg0KU2hvdWxkIGl0IGF0dGVtcHQgdG8gbWF0Y2ggaXQgd2l0 aCBhIGNhY2hlZCBtYXBwaW5nIHRoYXQgaGFzIGEgYm91bmRhcnkgbGlrZSB0aGlzPzoNCiAgICAg ICAgICA8Y291bnRyeT5ERTwvY291bnRyeT4NCiAgICAgICAgICA8UEM+ODE2NzU8L1BDPg0KDQpX aXRob3V0IGhhdmluZyBzb21lIHR5cGUgb2YgZGVmaW5pdGlvbiB0aGF0IGRlc2NyaWJlcyBob3cg dGhlIGRpZmZlcmVudCBDQVR5cGUgZWxlbWVudHMgcmVsYXRlIHRvIG9uZSBhbm90aGVyIHNwYXRp YWxseSwgbG9jYXRpb24gbWF0Y2hpbmcgY291bGQgYmUgcXVpdGUgYW4gZXhwZW5zaXZlIHRhc2sg b24gdGhlIHNlcnZlci4gDQoNCkF2ZXJ5DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBUaG9tc29uLCBNYXJ0aW4gW21haWx0bzpNYXJ0aW4uVGhvbXNvbkBhbmRyZXcu Y29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxMiwgMjAwOSA2OjE2IFBNDQo+IFRvOiBB dmVyeSBQZW5uaXN0b247IEJyaWFuIFJvc2VuOyBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJ L0VzcG9vKTsNCj4gZWNyaXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtFY3JpdF0gTG9TVCBR dWVzdGlvbnMvQ29tbWVudHMgLSBjaXZpYyBoaWVyYXJjaHkNCj4gDQo+IEhpIEF2ZXJ5LA0KPiAN Cj4gV2hlbiB5b3UgcmVxdWVzdCBhIGhpZXJhcmNoeSwgb3Igb3JkZXJpbmcsIG9mIGNpdmljIGFk ZHJlc3NlcywgdGhpcyBpcw0KPiBPSyBmb3IgdGhlIHRvcC1sZXZlbCBBKiBwYXJhbWV0ZXJzLCBi dXQgaXQgcXVpY2tseSBmYWlscyBhdCBvdGhlcg0KPiBsZXZlbHMuICBJdCBpcyBldmVuIG5vdCBw b3NzaWJsZSB3aGVuIGNvbXBhcmluZyBBKiBwYXJhbWV0ZXJzIHdpdGggbm9uLQ0KPiBBKiBwYXJh bWV0ZXJzLg0KPiANCj4gRm9yIGluc3RhbmNlLCBwb3N0YWwgY29kZXMgb2Z0ZW4gY292ZXIgYW4g YXJlYSBlcXVpdmFsZW50IHRvIGEgc3VidXJiDQo+IGluIHNjYWxlLCB3aGljaCBpcyBBNC4gIFRo b3JvdWdoZmFyZXMgZnJlcXVlbnRseSBwYXNzIHRocm91Z2ggbXVsdGlwbGUNCj4gc3VidXJicyAo QTQpLCBzb21ldGltZXMgZXZlbiBzdGF0ZXMgKEExKS4NCj4gDQo+IFdoaWxlIGl0J3MgbmljZSBp biB0aGVvcnksIHlvdSBjYW4ndCByZWx5IG9uIG9yZGVyaW5nIG91dHNpZGUgb2YgQSouDQo+IEFz IGEgaGludCwgdGhlIGNpdmljIGFkZHJlc3MgImJvdW5kYXJ5IiBjYW4gb25seSBiZSBpbnRlcnBy ZXRlZCBpbiBhDQo+IHZlcnkgbmFycm93IHdheToNCj4gDQo+ICAgSWYgYW55IG9mIHRoZSBwcm92 aWRlZCBlbGVtZW50cyBjaGFuZ2UgZnJvbSB0aGF0IHNwZWNpZmllZCwgdGhlDQo+IHByb3ZpZGVk IHNlcnZpY2UgVVJJIG5vIGxvbmdlciBhcHBsaWVzIGFuZCBhIG5ldyBMb1NUIHJlcXVlc3QgaXMN Cj4gbmVlZGVkLg0KPiANCj4gSXQncyBhIHNoYW1lIHRoYXQgTG9TVCBkb2Vzbid0IGFjdHVhbGx5 IHNheSB0aGlzLiAgSXQgc2hvdWxkLg0KPiANCj4gLS1NYXJ0aW4NCj4gDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdpbnRlcmJvdHRvbSwgSmFtZXMgW21haWx0bzpKYW1l cy5XaW50ZXJib3R0b21AYW5kcmV3LmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTIs IDIwMDkgNDozMiBQTQ0KPiBUbzogQXZlcnkgUGVubmlzdG9uOyBCcmlhbiBSb3NlbjsgVHNjaG9m ZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7DQo+IGVjcml0QGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJFOiBbRWNyaXRdIExvU1QgUXVlc3Rpb25zL0NvbW1lbnRzDQo+IA0KPiBIaSBBdmVyeSwN Cj4gDQo+IFRoZXJlIGFyZSBxdWl0ZSBzdHJvbmcgcmVjb21tZW5kYXRpb25zIGJlaW5nIG1hZGUg aW4gR2VvcHJpdiBhYm91dA0KPiBjb3VudHJpZXMgcHJvZmlsaW5nIGNpdmljIGFkZHJlc3NlcyBm b3IgdGhlaXIganVyaXNkaWN0aW9ucy4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1p ZXRmLWdlb3ByaXYtY2l2aWMtYWRkcmVzcy0NCj4gcmVjb21tZW5kYXRpb25zLTAzLnR4dA0KPiAN Cj4gRG9pbmcgdGhpcyBlbnN1cmVzIHRoYXQgY2l2aWMgYWRkcmVzc2VzIGhhdmUgc3BlY2lmaWMg Zm9ybXMgZm9yDQo+IHNwZWNpZmljIGNvdW50cmllcyBhbmQgdGhlIGNvbXBhcmlzb24gaXNzdWVz IHlvdSBkZXNjcmliZSBiZWxvdyBiZWNvbWUNCj4gdW5uZWNlc3NhcnksIGJlY2F1c2UgeW91IGRv bid0IGNvbmZvcm0gdG8gdGhlIG5vcm1hbGl6ZWQgZm9ybSBmb3IgdGhlDQo+IGp1cmlzZGljdGlv biB0aGVuIHlvdXIgbG9jYXRpb24gaXMgaW52YWxpZC4NCj4gDQo+IENoZWVycw0KPiBKYW1lcw0K Pg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogZWNyaXQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0K PiA+IE9mIEF2ZXJ5IFBlbm5pc3Rvbg0KPiA+IFNlbnQ6IFRodXJzZGF5LCAxMyBBdWd1c3QgMjAw OSA2OjUxIEFNDQo+ID4gVG86IEJyaWFuIFJvc2VuOyBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAt IEZJL0VzcG9vKTsgZWNyaXRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBMb1NU IFF1ZXN0aW9ucy9Db21tZW50cw0KPiA+DQo+ID4gSGkgSGFubmVzLCBCcmlhbiwgZXQgYWwuLA0K PiA+DQo+ID4NCj4gPiBJIHRoaW5rIGEgaGllcmFyY2h5IGZvciBQSURGLUxPIGlzIGVzc2VudGlh bCBmb3IgY29tcGFyaW5nIGNpdmljDQo+ID4gbG9jYXRpb25zIGluIG9yZGVyIHRvIG1pdGlnYXRl IHJlbGF0aW9uYWwgYW1iaWd1aXR5IG9mIGxvY2F0aW9ucy4NCj4gQnJpYW4NCj4gPiBtZW50aW9u ZWQgdGhhdCB0aGUgQSBlbGVtZW50cyBhbHJlYWR5IHByb3ZpZGUgYSBsZXZlbCBvZiBoaWVyYXJj aHksDQo+IGFuZA0KPiA+IGl0IG1ha2VzIHNlbnNlLCBmb3IgZXhhbXBsZSwgdG8gaW5jbHVkZSB0 aGUgY291bnRyeSBjb2RlIHRvDQo+ID4gZGlzYW1iaWd1YXRlDQo+ID4gTXVuaWNoLCBERSBmcm9t IGFueSBNdW5pY2guICBCdXQgd2hhdCBhYm91dCBjYXNlcyB3aGVyZSB0aGUgQTENCj4gZWxlbWVu dA0KPiA+IGlzIHByb3ZpZGVkIGFzIHdlbGwsKGkuZS4gTXVuaWNoLCBCYXZhcmlhLCBERSksIGFu ZCBhIGNvbXBhcmlzb24NCj4gPiBsb2NhdGlvbiBkb2VzIG5vdCBpbmNsdWRlIHRoYXQgZWxlbWVu dCAoaS5lLiBNdW5pY2gsIERFKS4gIFNob3VsZA0KPiB0aGVzZQ0KPiA+IGxvY2F0aW9ucyBub3Qg YmUgZXF1YWwgYmVjYXVzZSBvbmUgY29udGFpbnMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbj8NCj4g PiBUaGUNCj4gPiBhbnN3ZXIgbWlnaHQgYmUgdGhhdCwgbm8sIHRoZXkgYXJlIGVxdWl2YWxlbnQg YmVjYXVzZSB0aGVyZSBpcyBvbmx5IDENCj4gPiBNdW5pY2ggaW4gR2VybWFueSwgYW5kIHRoZSBB MSBlbGVtZW50IGJlY29tZXMgaXJyZWxldmFudC4gIEJ1dCB0aGlzDQo+ID4gZm9yY2VzIGFub3Ro ZXIgYnVyZGVuIG9uIHRoZSBMb1NUIFNlcnZlciB0byB2ZXJpZnksIGlmIGFueSBlbGVtZW50cw0K PiBpbg0KPiA+IHRoZSBBIGxldmVscyAoYWJvdmUgdGhlIGxvd2VzdCBvbmUgcHJvdmlkZWQpIGFy ZSBtaXNzaW5nLCB0aGF0IGENCj4gY2hpbGQNCj4gPiBlbGVtZW50J3MgdmFsdWUgaXMgb25seSBm b3VuZCBvbmx5IG9uY2UgaW4gdGhlIGhpZ2hlciBBIGVsZW1lbnQgdGhhdA0KPiBpdA0KPiA+IGlz IGF3YXJlIG9mIGluIG9yZGVyIHRvIGJlIHZhbGlkLiAgU28gZm9yIGV4YW1wbGUsIGlmIGEgbG9j YXRpb24gaGFkDQo+IGENCj4gPiBmaWN0aXRpb3VzIFBJREYtTE8gb2YgPGNvdW50cnk+ZGU8L2Nv dW50cnk+PEE1PlplcHBlbGluIFNxdWFyZTwvQTU+LA0KPiA+IHRoZW4gdGhlIExvU1Qgc2VydmVy IHdvdWxkIGhhdmUgdG8gY2hlY2sgYWxsIG9mIEdlcm1hbnkgdG8gbWFrZSBzdXJlDQo+ID4gdGhl cmUgaXMgb25seSAxIG5laWdoYm9yaG9vZCBvZiB0aGF0IG5hbWUuICBUaGlzIGJlY29tZXMgbW9y ZSB0ZWRpb3VzDQo+ID4gdGhlIGJpZ2dlciB0aGUgJ2dhcCcgYmV0d2VlbiB0aGUgaGlnaGVzdCBh bmQgbG93ZXN0IEEgZWxlbWVudA0KPiBwcm92aWRlZC4NCj4gPg0KPiA8c25pcD4NCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhpcyBtZXNzYWdl IGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQo+IGNvbnRhaW4g cHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9u Lg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyDQo+IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0 aG9yaXplZCB1c2Ugb2YNCj4gdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFttZjJdDQo= From Martin.Thomson@andrew.com Thu Aug 13 16:16:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88CEB3A6A10 for ; Thu, 13 Aug 2009 16:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asf7vArfat0j for ; Thu, 13 Aug 2009 16:16:31 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 33F123A68B9 for ; Thu, 13 Aug 2009 16:16:31 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_13_18_24_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 13 Aug 2009 18:24:06 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 18:01:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 13 Aug 2009 18:01:18 -0500 Message-ID: In-Reply-To: <909A20ADCD98AD4FB9984A87063A5605031676E0@exchange.geo-comm.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Questions/Comments - civic hierarchy Thread-Index: AcoaAFwCRxMfYy0LRqmpfX/53hvJYwAlqv2wADGC9+AABr76sAAKb7SwAC1fruAAA+nmIA== References: <909A20ADCD98AD4FB9984A87063A56050310502E@exchange.geo-comm.local><3D3C75174CB95F42AD6BCC56E5555B450197512C@FIESEXC015.nsn-intra.net><007501ca1b5e$f43ec2b0$dcbc4810$@net> <909A20ADCD98AD4FB9984A87063A5605031671CA@exchange.geo-comm.local> <909A20ADCD98AD4FB9984A87063A5605031676E0@exchange.geo-comm.local> From: "Thomson, Martin" To: "Avery Penniston" , "Brian Rosen" , "Tschofenig, Hannes (NSN - FI/Espoo)" , X-OriginalArrivalTime: 13 Aug 2009 23:01:16.0645 (UTC) FILETIME=[F683B150:01CA1C69] Subject: Re: [Ecrit] LoST Questions/Comments - civic hierarchy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 23:16:32 -0000 PiBNYXJ0aW4sIEkgdGhpbmsgd2hhdCB5b3UgYXJlIHNheWluZyBpcyB0aGF0IGlmIHR3byBjaXZp YyBsb2NhdGlvbnMgZG8NCj4gbm90IG1hdGNoIGV4YWN0bHkgKGJvdGggdGhlIGVsZW1lbnRzIHBy b3ZpZGVkLCBhbmQgdGhlIGJsYW5rIGVsZW1lbnRzKQ0KPiB0aGVuLCBjdXJyZW50bHksIExvU1Qg c2hvdWxkIGNvbnNpZGVyIHRoZW0gbm90IGVxdWFsLiAgQnV0IHNob3VsZCBMb1NUDQo+IHRyeSB0 byBkZXRlcm1pbmUgaWYgb25lIGxvY2F0aW9uICdmaXRzJyBpbnNpZGUgYW5vdGhlcj8gIEZvciBl eGFtcGxlIGENCj4gcmVzb2x2ZXIgd2FudHMgdG8gY2hlY2sgaWYgYSBsb2NhdGlvbiBpcyBmb3Vu ZCB3aXRoaW4gb25lIG9mIGl0cyBjYWNoZWQNCj4gbWFwcGluZyBzZXJ2aWNlIGJvdW5kYXJpZXMu DQoNCldpdGhvdXQgdGhlIG5lZWQgZm9yIGludGVyb3BlcmFibGUgZXhjaGFuZ2UgZm9ybWF0cywg YW4gaW1wbGVtZW50YXRpb24gb2YgYSBMb1NUIHNlcnZlciBjb3VsZCBoYXZlIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24gdGhhdCBzYXlzIHRoYXQgb25lIGNpdmljIGFkZHJlc3MgaXMgZW50aXJlbHkg Y29udGFpbmVkIHdpdGhpbiBhbm90aGVyLiAgVGhpcyBpbmZvcm1hdGlvbiB3b3VsZCBub3QgbmVj ZXNzYXJpbHkgYmUgYWJsZSB0byBiZSByZXByZXNlbnRlZCBpbiB0aGUgc3luY2hyb25pemF0aW9u IHByb3RvY29sLiAgDQoNCj4gIElmIHRoZSByZXF1ZXN0IGxvY2F0aW9uIGlzIHNvbWV0aGluZyBs aWtlOg0KPiAgICAgICAgICAgPGNvdW50cnk+REU8L2NvdW50cnk+DQo+ICAgICAgICAgICA8QTE+ QmF2YXJpYTwvQTE+DQo+ICAgICAgICAgICA8QTM+TXVuaWNoPC9BMz4NCj4gICAgICAgICAgIDxB Nj5PdHRvLUhhaG4tUmluZzwvQTY+DQo+ICAgICAgICAgICA8SE5PPjY8L0hOTz4NCj4gICAgICAg ICAgIDxQQz44MTY3NTwvUEM+DQo+IA0KPiBTaG91bGQgaXQgYXR0ZW1wdCB0byBtYXRjaCBpdCB3 aXRoIGEgY2FjaGVkIG1hcHBpbmcgdGhhdCBoYXMgYSBib3VuZGFyeQ0KPiBsaWtlIHRoaXM/Og0K PiAgICAgICAgICAgPGNvdW50cnk+REU8L2NvdW50cnk+DQo+ICAgICAgICAgICA8UEM+ODE2NzU8 L1BDPg0KPiANCj4gV2l0aG91dCBoYXZpbmcgc29tZSB0eXBlIG9mIGRlZmluaXRpb24gdGhhdCBk ZXNjcmliZXMgaG93IHRoZSBkaWZmZXJlbnQNCj4gQ0FUeXBlIGVsZW1lbnRzIHJlbGF0ZSB0byBv bmUgYW5vdGhlciBzcGF0aWFsbHksIGxvY2F0aW9uIG1hdGNoaW5nDQo+IGNvdWxkIGJlIHF1aXRl IGFuIGV4cGVuc2l2ZSB0YXNrIG9uIHRoZSBzZXJ2ZXIuDQoNClllcywgSSB3b3VsZCBpbWFnaW5l IHRoYXQgdGhpcyBsb2NhdGlvbiBpcyBjb25zaWRlcmVkIHRvIGJlICJ3aXRoaW4iIHRoZSBzcGVj aWZpZWQgYm91bmRhcnkgImFkZHJlc3MiLiAgVGhlIGJvdW5kYXJ5IGVmZmVjdGl2ZWx5IHN0YXRl cyB0aGF0IGFueSBsb2NhdGlvbiB3aXRoIHRoZSBzYW1lIGNvdW50cnkgYW5kIHBvc3RhbCBjb2Rl IGlzIHdpdGhpbiB0aGUgYm91bmRhcnkuDQoNClRoZSBjb25zdW1lciBvZiBhIExvU1QgYm91bmRh cnkgKGNsaWVudCwgb3IgY2FjaGluZyBzZXJ2ZXIpIGhhcyBhIHZlcnkgc2ltcGxlIGFsZ29yaXRo bSB0byBmb2xsb3cuICBGb3IgZWFjaCBzcGVjaWZpZWQgZWxlbWVudCBpbiB0aGUgYm91bmRhcnkg ImFkZHJlc3MiLCBjb21wYXJlIGZvciBlcXVhbGl0eS4gIElmIGEgYm91bmRhcnktc3BlY2lmaWVk IGVsZW1lbnQgaXMgZWl0aGVyIG5vdCBlcXVhbCBvciBhYnNlbnQgaW4gdGhlIHJlcXVlc3QgYWRk cmVzcywgdGhlIGFkZHJlc3MgaXMgb3V0c2lkZSB0aGUgYm91bmRhcnkuICBBZGRpdGlvbmFsIGVs ZW1lbnRzIGluIHRoZSByZXF1ZXN0IGFkZHJlc3MgdGhhdCB3ZXJlIG5vdCBzcGVjaWZpZWQgaW4g dGhlIGJvdW5kYXJ5IGFkZHJlc3MgY2FuIG9ubHkgYmUgY29uc2lkZXJlZCB0byBiZSB1bmltcG9y dGFudC4NCg0KV29yc3QgY2FzZSwgd2hpY2ggaXMgYWx3YXlzIGF2YWlsYWJsZSwgaXMgdGhhdCB0 aGUgTG9TVCBzZXJ2ZXIgbWFpbnRhaW5zIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiBjaXZpYyBhZGRy ZXNzZXMgdGhhdCBhcmUgd2l0aGluIHRoZSBib3VuZGFyeS4gIE9idmlvdXNseSwgdGhlcmUgbWln aHQgYmUgY2VydGFpbiBzaW1wbGlmaWNhdGlvbnMgdGhhdCBjb3VsZCBiZSBtYWRlIChzdWNoIGFz IGlnbm9yaW5nIGludGVyaW9yIGVsZW1lbnRzKS4NCg0KVGhlc2UgdGhpbmdzIHdpbGwgdmFyeSwg ZGVwZW5kaW5nIG9uIHRoZSBuZWVkcyBvZiB0aGUgc3BlY2lmaWMgTG9TVCBhcHBsaWNhdGlvbi4g IEluIEF1c3RyYWxpYSBhbmQgbWFueSBvdGhlciBjb3VudHJpZXMgZW1lcmdlbmN5IHNlcnZpY2Vz IGFyZSBjZW50cmFsaXplZC4gIFRoZXJlZm9yZSwgYSBMb1NUIHNlcnZlciB0aGF0IHNlcnZlcyB0 aG9zZSBjb3VudHJpZXMgaXMgYWJsZSB0byBjb3JyZWN0bHkgZGV0ZXJtaW5lIGEgcm91dGUgZm9y IGVtZXJnZW5jeSBzZXJ2aWNlcyBiYXNlZCBvbiB0aGUgPGNvdW50cnk+IHRhZyBhbG9uZS4gIElu IHRoZSBVUywgdGhpbmdzIGFyZSBtdWNoIG1vcmUgY29tcGxpY2F0ZWQgYW5kIHRoZSBMb1NUIHNl cnZlciB0aGVyZWZvcmUgbmVlZHMgbXVjaCBtb3JlIGV4dGVuc2l2ZSBpbmZvcm1hdGlvbi4NCg0K VHdvIGltcG9ydGFudCBjb25zaWRlcmF0aW9uczoNCg0KIDEpICBJdCBpcyBub3QgcG9zc2libGUg dG8gaW5kaWNhdGUgdGhhdCBhIGNlcnRhaW4gZWxlbWVudCBNVVNUIGJlIGFic2VudCB3aGVuIGV4 cHJlc3NpbmcgYSBib3VuZGFyeS4gIFRoaXMgaXMgYSBmYWlsaW5nIG9mIHRoZSBzeXN0ZW0sIGFu ZCBvbmUgdGhhdCBtaWdodCBuZWVkIHRvIGJlIGFkZHJlc3NlZC4gIA0KDQogICBEZXBsb3ltZW50 IGV4cGVyaWVuY2UgbWlnaHQgc2hvdyB0aGF0IHRoaXMgaXMgbm90IG5lY2Vzc2FyeSwgYnV0IEkn dmUgc2VlbiBldmlkZW5jZSBlbm91Z2ggdGhhdCBjaXZpYyBhZGRyZXNzZXMgYXJlIGNhcGFibGUg b2YgcHJvZHVjaW5nIGp1c3QgYWJvdXQgYW55IGNvcm5lciBjYXNlIGltYWdpbmFibGUuDQoNCiAy KSAgQW55IHNpbmdsZSBib3VuZGFyeSAiYWRkcmVzcyIgaXMgbm90IG5lY2Vzc2FyaWx5IGNvbXBs ZXRlIG9uIGl0cyBvd24uICBBIGNvbXBsZXRlIGJvdW5kYXJ5IHNwZWNpZmljYXRpb24gbWlnaHQg cmVxdWlyZSB0aGUgdW5pb24gb2YgbXVsdGlwbGUgc3VjaCBib3VuZGFyaWVzLiAgSW4gc29tZSBj YXNlcywgdGhpcyBjYW4gZ2V0IGV4dHJlbWVseSBjb21wbGljYXRlZC4NCg0KICBUbyBnaXZlIGFu IGV4YW1wbGUgb2YgdGhpcywgaW1hZ2luZSB0aGUgY2FzZSB3aGVyZSBhIHJvYWQgaXMgdXNlZCBh cyBhIGRpdmlkaW5nIGxpbmUuICBJZiwgYXMgaXMgY29tbW9uIGluIG1hbnkgcGxhY2VzLCBvZGQg bnVtYmVyZWQgaG91c2VzIGFyZSBvbiBvbmUgc2lkZSBvZiB0aGUgcm9hZCBhbmQgZXZlbiBvbiB0 aGUgb3RoZXIsIHRoZSBib3VuZGFyeSBzcGVjaWZpY2F0aW9uIGZvciBlaXRoZXIgcmVnaW9uIGNh bm5vdCBzaW1wbHkgaW5kaWNhdGUgdGhlIHJvYWQsIGl0IG11c3Qgc3BlY2lmeSBlYWNoIGhvdXNl IG51bWJlciBpbmRpdmlkdWFsbHkuICBUaGF0J3MgcXVpdGUgY29zdGx5LCBidXQgdGhlIG9ubHkg Y2hvaWNlIGF2YWlsYWJsZSwgZ2l2ZW4gdGhlIHNwZWNpZmljYXRpb24gKG9yLCBhcyBJIG5vdGVk IHByZXZpb3VzbHksIGFic2VuY2UgdGhlcmVvZikuDQoNCkNoZWVycywNCk1hcnRpbg0KDQoNCj4g DQo+IEF2ZXJ5DQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IFRob21zb24sIE1hcnRpbiBbbWFpbHRvOk1hcnRpbi5UaG9tc29uQGFuZHJldy5jb21dDQo+ ID4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTIsIDIwMDkgNjoxNiBQTQ0KPiA+IFRvOiBBdmVy eSBQZW5uaXN0b247IEJyaWFuIFJvc2VuOyBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtDQo+IEZJ L0VzcG9vKTsNCj4gPiBlY3JpdEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIExv U1QgUXVlc3Rpb25zL0NvbW1lbnRzIC0gY2l2aWMgaGllcmFyY2h5DQo+ID4NCj4gPiBIaSBBdmVy eSwNCj4gPg0KPiA+IFdoZW4geW91IHJlcXVlc3QgYSBoaWVyYXJjaHksIG9yIG9yZGVyaW5nLCBv ZiBjaXZpYyBhZGRyZXNzZXMsIHRoaXMNCj4gaXMNCj4gPiBPSyBmb3IgdGhlIHRvcC1sZXZlbCBB KiBwYXJhbWV0ZXJzLCBidXQgaXQgcXVpY2tseSBmYWlscyBhdCBvdGhlcg0KPiA+IGxldmVscy4g IEl0IGlzIGV2ZW4gbm90IHBvc3NpYmxlIHdoZW4gY29tcGFyaW5nIEEqIHBhcmFtZXRlcnMgd2l0 aA0KPiBub24tDQo+ID4gQSogcGFyYW1ldGVycy4NCj4gPg0KPiA+IEZvciBpbnN0YW5jZSwgcG9z dGFsIGNvZGVzIG9mdGVuIGNvdmVyIGFuIGFyZWEgZXF1aXZhbGVudCB0byBhIHN1YnVyYg0KPiA+ IGluIHNjYWxlLCB3aGljaCBpcyBBNC4gIFRob3JvdWdoZmFyZXMgZnJlcXVlbnRseSBwYXNzIHRo cm91Z2gNCj4gbXVsdGlwbGUNCj4gPiBzdWJ1cmJzIChBNCksIHNvbWV0aW1lcyBldmVuIHN0YXRl cyAoQTEpLg0KPiA+DQo+ID4gV2hpbGUgaXQncyBuaWNlIGluIHRoZW9yeSwgeW91IGNhbid0IHJl bHkgb24gb3JkZXJpbmcgb3V0c2lkZSBvZiBBKi4NCj4gPiBBcyBhIGhpbnQsIHRoZSBjaXZpYyBh ZGRyZXNzICJib3VuZGFyeSIgY2FuIG9ubHkgYmUgaW50ZXJwcmV0ZWQgaW4gYQ0KPiA+IHZlcnkg bmFycm93IHdheToNCj4gPg0KPiA+ICAgSWYgYW55IG9mIHRoZSBwcm92aWRlZCBlbGVtZW50cyBj aGFuZ2UgZnJvbSB0aGF0IHNwZWNpZmllZCwgdGhlDQo+ID4gcHJvdmlkZWQgc2VydmljZSBVUkkg bm8gbG9uZ2VyIGFwcGxpZXMgYW5kIGEgbmV3IExvU1QgcmVxdWVzdCBpcw0KPiA+IG5lZWRlZC4N Cj4gPg0KPiA+IEl0J3MgYSBzaGFtZSB0aGF0IExvU1QgZG9lc24ndCBhY3R1YWxseSBzYXkgdGhp cy4gIEl0IHNob3VsZC4NCj4gPg0KPiA+IC0tTWFydGluDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFdpbnRlcmJvdHRvbSwgSmFtZXMgW21haWx0bzpKYW1l cy5XaW50ZXJib3R0b21AYW5kcmV3LmNvbV0NCj4gPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAx MiwgMjAwOSA0OjMyIFBNDQo+ID4gVG86IEF2ZXJ5IFBlbm5pc3RvbjsgQnJpYW4gUm9zZW47IFRz Y2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0NCj4gRkkvRXNwb28pOw0KPiA+IGVjcml0QGlldGYub3Jn DQo+ID4gU3ViamVjdDogUkU6IFtFY3JpdF0gTG9TVCBRdWVzdGlvbnMvQ29tbWVudHMNCj4gPg0K PiA+IEhpIEF2ZXJ5LA0KPiA+DQo+ID4gVGhlcmUgYXJlIHF1aXRlIHN0cm9uZyByZWNvbW1lbmRh dGlvbnMgYmVpbmcgbWFkZSBpbiBHZW9wcml2IGFib3V0DQo+ID4gY291bnRyaWVzIHByb2ZpbGlu ZyBjaXZpYyBhZGRyZXNzZXMgZm9yIHRoZWlyIGp1cmlzZGljdGlvbnMuDQo+ID4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWdlb3ByaXYtY2l2aWMtYWRkcmVzcy0NCj4gPiByZWNv bW1lbmRhdGlvbnMtMDMudHh0DQo+ID4NCj4gPiBEb2luZyB0aGlzIGVuc3VyZXMgdGhhdCBjaXZp YyBhZGRyZXNzZXMgaGF2ZSBzcGVjaWZpYyBmb3JtcyBmb3INCj4gPiBzcGVjaWZpYyBjb3VudHJp ZXMgYW5kIHRoZSBjb21wYXJpc29uIGlzc3VlcyB5b3UgZGVzY3JpYmUgYmVsb3cNCj4gYmVjb21l DQo+ID4gdW5uZWNlc3NhcnksIGJlY2F1c2UgeW91IGRvbid0IGNvbmZvcm0gdG8gdGhlIG5vcm1h bGl6ZWQgZm9ybSBmb3IgdGhlDQo+ID4ganVyaXNkaWN0aW9uIHRoZW4geW91ciBsb2NhdGlvbiBp cyBpbnZhbGlkLg0KPiA+DQo+ID4gQ2hlZXJzDQo+ID4gSmFtZXMNCj4gPg0KPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+IEJlaGFsZg0KPiA+ID4gT2Yg QXZlcnkgUGVubmlzdG9uDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgMTMgQXVndXN0IDIwMDkgNjo1 MSBBTQ0KPiA+ID4gVG86IEJyaWFuIFJvc2VuOyBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJ L0VzcG9vKTsNCj4gZWNyaXRAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIExv U1QgUXVlc3Rpb25zL0NvbW1lbnRzDQo+ID4gPg0KPiA+ID4gSGkgSGFubmVzLCBCcmlhbiwgZXQg YWwuLA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBJIHRoaW5rIGEgaGllcmFyY2h5IGZvciBQSURGLUxP IGlzIGVzc2VudGlhbCBmb3IgY29tcGFyaW5nIGNpdmljDQo+ID4gPiBsb2NhdGlvbnMgaW4gb3Jk ZXIgdG8gbWl0aWdhdGUgcmVsYXRpb25hbCBhbWJpZ3VpdHkgb2YgbG9jYXRpb25zLg0KPiA+IEJy aWFuDQo+ID4gPiBtZW50aW9uZWQgdGhhdCB0aGUgQSBlbGVtZW50cyBhbHJlYWR5IHByb3ZpZGUg YSBsZXZlbCBvZiBoaWVyYXJjaHksDQo+ID4gYW5kDQo+ID4gPiBpdCBtYWtlcyBzZW5zZSwgZm9y IGV4YW1wbGUsIHRvIGluY2x1ZGUgdGhlIGNvdW50cnkgY29kZSB0bw0KPiA+ID4gZGlzYW1iaWd1 YXRlDQo+ID4gPiBNdW5pY2gsIERFIGZyb20gYW55IE11bmljaC4gIEJ1dCB3aGF0IGFib3V0IGNh c2VzIHdoZXJlIHRoZSBBMQ0KPiA+IGVsZW1lbnQNCj4gPiA+IGlzIHByb3ZpZGVkIGFzIHdlbGws KGkuZS4gTXVuaWNoLCBCYXZhcmlhLCBERSksIGFuZCBhIGNvbXBhcmlzb24NCj4gPiA+IGxvY2F0 aW9uIGRvZXMgbm90IGluY2x1ZGUgdGhhdCBlbGVtZW50IChpLmUuIE11bmljaCwgREUpLiAgU2hv dWxkDQo+ID4gdGhlc2UNCj4gPiA+IGxvY2F0aW9ucyBub3QgYmUgZXF1YWwgYmVjYXVzZSBvbmUg Y29udGFpbnMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbj8NCj4gPiA+IFRoZQ0KPiA+ID4gYW5zd2Vy IG1pZ2h0IGJlIHRoYXQsIG5vLCB0aGV5IGFyZSBlcXVpdmFsZW50IGJlY2F1c2UgdGhlcmUgaXMg b25seQ0KPiAxDQo+ID4gPiBNdW5pY2ggaW4gR2VybWFueSwgYW5kIHRoZSBBMSBlbGVtZW50IGJl Y29tZXMgaXJyZWxldmFudC4gIEJ1dCB0aGlzDQo+ID4gPiBmb3JjZXMgYW5vdGhlciBidXJkZW4g b24gdGhlIExvU1QgU2VydmVyIHRvIHZlcmlmeSwgaWYgYW55IGVsZW1lbnRzDQo+ID4gaW4NCj4g PiA+IHRoZSBBIGxldmVscyAoYWJvdmUgdGhlIGxvd2VzdCBvbmUgcHJvdmlkZWQpIGFyZSBtaXNz aW5nLCB0aGF0IGENCj4gPiBjaGlsZA0KPiA+ID4gZWxlbWVudCdzIHZhbHVlIGlzIG9ubHkgZm91 bmQgb25seSBvbmNlIGluIHRoZSBoaWdoZXIgQSBlbGVtZW50DQo+IHRoYXQNCj4gPiBpdA0KPiA+ ID4gaXMgYXdhcmUgb2YgaW4gb3JkZXIgdG8gYmUgdmFsaWQuICBTbyBmb3IgZXhhbXBsZSwgaWYg YSBsb2NhdGlvbg0KPiBoYWQNCj4gPiBhDQo+ID4gPiBmaWN0aXRpb3VzIFBJREYtTE8gb2YgPGNv dW50cnk+ZGU8L2NvdW50cnk+PEE1PlplcHBlbGluDQo+IFNxdWFyZTwvQTU+LA0KPiA+ID4gdGhl biB0aGUgTG9TVCBzZXJ2ZXIgd291bGQgaGF2ZSB0byBjaGVjayBhbGwgb2YgR2VybWFueSB0byBt YWtlDQo+IHN1cmUNCj4gPiA+IHRoZXJlIGlzIG9ubHkgMSBuZWlnaGJvcmhvb2Qgb2YgdGhhdCBu YW1lLiAgVGhpcyBiZWNvbWVzIG1vcmUNCj4gdGVkaW91cw0KPiA+ID4gdGhlIGJpZ2dlciB0aGUg J2dhcCcgYmV0d2VlbiB0aGUgaGlnaGVzdCBhbmQgbG93ZXN0IEEgZWxlbWVudA0KPiA+IHByb3Zp ZGVkLg0KPiA+ID4NCj4gPiA8c25pcD4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBk ZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPiBjb250YWluIHByaXZpbGVnZWQs IHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4NCj4gPiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ ID4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVk IHVzZSBvZg0KPiA+IHRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gLS0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gW21mMl0NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUg ZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHBy b3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0K dGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpbbWYyXQ0K From Hannes.Tschofenig@gmx.net Mon Aug 17 10:35:25 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628EC3A6EF9 for ; Mon, 17 Aug 2009 10:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePzemVti8ypA for ; Mon, 17 Aug 2009 10:35:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2BEC03A6EFB for ; Mon, 17 Aug 2009 10:35:22 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2009 17:35:25 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp028) with SMTP; 17 Aug 2009 19:35:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Fx959ILSFkwrWRl8J++5jIbCps/gag/5MgOH9It C1XWbOz9jPNaS6 From: "Hannes Tschofenig" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ext Karl Heinz Wolf'" References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> Date: Mon, 17 Aug 2009 20:38:01 +0300 Message-ID: <001701ca1f61$78c16730$2549a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoZn9oC1A6Mhef0RAWYfzox2uP/ewABwUagAWkSv9A= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 17:35:25 -0000 As I explained in my previous mail there is a potential problem with the document.=20 My current suggestion is to re-introduce the "lost:" URI scheme (we had = it once in the LoST spec) Thoughts about it? Objections?=20 ------------------- Section (A): LoST Uniform Resource Locators and Their Resolution LoST servers are identified by LoST Uniform Resource Locators (URLs), which follow the format of URLs defined in RFC 3986, with the following ABNF: LoST-URI =3D "lost:" host 'host' is defined in Section 3.2.2 of RFC 3986. An example is 'lost:lostserver.example.com' If a LoST URL contains a host name rather than an IP address,=20 the resolution mechanism described in Section 4 of RFC 5222 is used.=20 =20 Section (B): URL Registration Template This registration template is in accordance with RFC 2717. URL scheme name: lost URL scheme syntax: See Section (A). Character encoding considerations: See Section (A). Intended Use: The intended usage is described in this document. Application and protocols which use this scheme: The usage of the LoST URL scheme is targeted for this document, namely for the exchange of mapping structures.=20 Interoperability considerations: None Security considerations: See Section 7 Relevant publications: This document provides the relevant context for this URL scheme. Contact: Hannes Tschofenig, Hannes.Tschofenig@gmx.net Author/Change controller: The IESG ------------------- Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: 10 August, 2009 15:12 >To: ext Karl Heinz Wolf >Cc: ECRIT >Subject: Re: [Ecrit] LoST Sync Draft Update > >Hi Karl Heinz, >Hi all,=20 > >Thanks for this question.=20 > >To provide a bit of background to your question let us take an=20 >example provided in=20 >http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt > >On page 10 an example of mappings stored at a server are outlined:=20 > > country A1 A2 A3 resource or LoST server > US NJ Bergen Leonia sip:psap@leonianj.gov > US NJ Bergen Fort Lee sip:emergency@fortleenj.org > US NJ Bergen Teaneck sip:police@teanecknjgov.org > US NJ Bergen Englewood englewoodnj.gov > >In this case, the first three mappings point to PSAPs (or=20 >ESRPs; one cannot differentiate based on the mapping data).=20 >The final mapping, however, points to a LoST server.=20 > >So, element of the element accepts only URIs.=20 >The output of the U-NAPTR process (described in Section 4 of=20 >http://www.ietf.org/rfc/rfc5222.txt) leads to a HTTP/HTTPS URI. > >So, the URI that is associated with the boundary is using a=20 >HTTP and HTTPS URL scheme.=20 >The input unfortunatley isn't; it is just a DNS name.=20 > >In earlier versions of the LoST specifications we defined a=20 >new URI scheme (namely lost://) but later removed it. As such,=20 >there is no LoST URI to put into the element.=20 > >So, do we have a problem here?=20 > >Ciao >Hannes > >PS: I have to check what the implementers have implemented here.=20 > >>Hannes, >> >>some time ago I asked you about lost-sync and the pushing of coverage=20 >>regions up a tree. >>Pushing of coverage regions is mentioned in the introduction, but all=20 >>the examples show complete mappings. >>So I wonder if you assume LoST URIs to be placed in the URI=20 >elements of=20 >>the mappings to indicate that this is not a mapping but rather a=20 >>coverage region in the boundary? >> >>cheers >>karl heinz >> >>On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN -=20 >>FI/Espoo) wrote: >>> Hi all, >>> >>> I asked Roger to submit the PROTO writeup for the LoST sync draft=20 >>> after we got further confirmation from the implementers team. Then,=20 >>> Roger pointed me to the review by Richard and I have to say that I=20 >>> must have missed it. Here are Richards review comments: >>> >>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>> >>> My response is inline: >>> >>> I reviewed lost-sync-04 in order to update my earlier >>comments on -01. >>> This version is much improved from the previous versions in=20 >terms of=20 >>> specificity (although it's still vague in places).=A0 It still >>seems to >>> me that there are a few layers of detail missing.=A0 Specific >>comments below. >>> --Richard >>> >>> 1. The document describes transactions for requesting and=20 >delivering=20 >>> mapping structures, but doesn't describe at all how these >>transactions >>> create a synchronization system.=A0 There is clearly some tracking = of=20 >>> state needed (especially for "pushMappings"), and the document is=20 >>> silent on how this state is initially established and then >>maintained. >>> >>> [Hannes] I added text throught the document to address this=20 >comments. >>> In particular I point to the need to keep state and also to=20 >the fact=20 >>> that the document relies on manual configuration for setting up the=20 >>> "peering" between the two nodes. >>> >>> 2. In a similar vein, it would be helpful for this document to have=20 >>> some discussion of how this synchronization system relates=20 >to others=20 >>> that are out there (e.g., rsync).=A0 Since the name of the draft is=20 >>> "synchronization", there should be some discussion of how=20 >>> bidirectional sync is handled. >>> >>> [Hannes] We had a discussion about this topic at the=20 >interim meeting=20 >>> and "downgraded" the document to an Experimental status to avoid=20 >>> having to Analyse all available replication mechanisms. >>> >>> 3. It seems like there should really be only 3 message types here=20 >>> instead of 4: (1) a "syncRequest" message sent from destination to=20 >>> source (getMappingsRequest), (2) a "syncUpdate" message sent from=20 >>> source to destination (getMappingsResponse =3D=3D = pushMappingsRequest),=20 >>> and (3) a "syncResult" message sent from destination to source=20 >>> (pushMappingsResponse).=A0 There can still be two types of >>transaction, >>> but they're determined by which type of message (syncRequest or >>> syncUpdate) is sent in the HTTP request. >>> >>> [Hannes] We got similar feedback from the implementers.=20 >>However, in a >>> subsequent discussion with them it turned out that this change is=20 >>> rather a matter of style than anything technical. A change in the=20 >>> description along the lines as you suggested (and as they had >>> suggested) as well only impacts the writing style of the >>document and >>> not really the implementation as such. Hence, I left the >>document as is. >>> >>> 4. In a similar vein to 2 and 3, the use of "client" and=20 >"server" is=20 >>> confusing.=A0 I would suggest using more appropriate names for these = >>> roles like "source" and "destination", along with some text that=20 >>> explains how these roles map to HTTP roles in each type of >>transaction. >>> >>> [Hannes] I added text regarding the HTTP/HTTPs roles and=20 >changed the=20 >>> terminology in the document to reflect the source / >>destination terminology. >>> I hope it improved readability. >>> >>> 5. My comment about the security considerations has not been >>addressed. >>> =A0The security considerations section is essentially a >>pointer to LoST, >>> but this protocol is only peripherally related to LoST (at a >>technical >>> level).=A0 Since it's about synchronization, I would expect this=20 >>> document to note that the primary risk is the injection of false=20 >>> location information (since the mappings themselves are >>public), which >>> means that the parties should use HTTPS to carry the XML, >>authenticate >>> the source, and use a ciphersuite that provides integrity >>protection to messages. >>> >>> [Hannes] You are certainly right with this comment. I >>changed the text. >>> >>> Here is the updated document: >>>=20 >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.txt >>> >>> 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 Hannes.Tschofenig@gmx.net Mon Aug 17 11:07:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E913A6F61 for ; Mon, 17 Aug 2009 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O5MvXopYkgd for ; Mon, 17 Aug 2009 11:06:57 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B2A8B3A6F60 for ; Mon, 17 Aug 2009 11:06:56 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2009 18:07:00 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp011) with SMTP; 17 Aug 2009 20:07:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19FWsUs85NFtmJKIpoTpmXCCSTanvDuM5TPWbsKzq lH+sSqeGOc5x22 From: "Hannes Tschofenig" To: "'Marc Linsner'" , "'ecrit'" References: Date: Mon, 17 Aug 2009 21:09:33 +0300 Message-ID: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01CA1F7F.071736F0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoXhxQtX8f3gqAXCEqhXCTtM2totQH3pMOg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55,0.53 Subject: [Ecrit] Please respond to the Premature Disconnect HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:07:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0029_01CA1F7F.071736F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI: We have not received a lot of feedback (maybe because of the holidays, maybe because of lack of interest, maybe because of the other discussions). So, help us to make a decision... _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: 07 August, 2009 20:47 To: 'ecrit' Subject: [Ecrit] Premature Disconnect At the Stockholm meeting Brian Rosen presented Premature Disconnect (http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02) . After some amount of discussion, we told Brian to 'go away' and bring back a problem statement vs. a set of requirements so we could evaluate whether this is something we wanted to work on. I had hoped we would have time during the meeting for Brian to present the problem statement, but we ran out of time. Brian sent it to the list on 7/29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html). Now for the obvious questions. Do you have feedback regarding the problem statement? Do you think that this is a problem worth solving in ECRIT? Your feedback will determine whether we ask for AD approval to add this work to our charter. Please respond by COB Friday August 14, 2009. Thanks, Marc & Hannes ------=_NextPart_000_0029_01CA1F7F.071736F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Premature Disconnect
    FYI: We have not received a lot of feedback = (maybe=20 because of the holidays, maybe because of lack of interest, maybe = because of the=20 other discussions). So, help us to make a = decision...

    From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc=20 Linsner
    Sent: 07 August, 2009 20:47
    To:=20 'ecrit'
    Subject: [Ecrit] Premature = Disconnect

    At the Stockholm meeting Brian Rosen = presented=20 Premature Disconnect (http://www= .ietf.org/proceedings/75/slides/ecrit-2.ppt)=20 based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconn= ect-rqmts-02).=20  After some amount of discussion, we told Brian to ‘go = away’ and bring=20 back a problem statement vs. a set of requirements so we could = evaluate=20 whether this is something we wanted to work on.  I had hoped we = would=20 have time during the meeting for Brian to present the problem = statement, but=20 we ran out of time. Brian sent it to the list on 7/29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html).
    Now=20 for the obvious questions.

    Do you have feedback regarding the = problem=20 statement?

    Do you think that this is a problem worth solving in = ECRIT?

    Your feedback will determine whether we ask for AD = approval to=20 add this work to our charter.  Please respond by COB Friday = August 14,=20 2009.

    Thanks,

    Marc & Hannes    =20 ------=_NextPart_000_0029_01CA1F7F.071736F0-- From br@brianrosen.net Mon Aug 17 11:16:41 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1DBA3A6836 for ; Mon, 17 Aug 2009 11:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Hd248arbcFK for ; Mon, 17 Aug 2009 11:16:39 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id AE4833A6407 for ; Mon, 17 Aug 2009 11:16:39 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Md6kz-0007tU-0z; Mon, 17 Aug 2009 13:16:33 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Karl Heinz Wolf'" References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <001701ca1f61$78c16730$2549a20a@nsnintra.net> In-Reply-To: <001701ca1f61$78c16730$2549a20a@nsnintra.net> Date: Mon, 17 Aug 2009 14:16:26 -0400 Message-ID: <003e01ca1f66$d92b9dc0$8b82d940$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoZn9oC1A6Mhef0RAWYfzox2uP/ewABwUagAWkSv9AABrnwUA== 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] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:16:41 -0000 I am not thrilled with defining a new scheme just for this purpose. Could we not just use http? There are no other uses for http in this context to get confused with. I especially do not want to go back and change how the protocol works, = as opposed to how you specify referral in lost-sync. I do wonder if we really should be consulting with the apps area and = come up with some other way to solve the class of problems that this typifies. = HELD has the same problem. What we want is a general solution to a URI that = uses HTTP transport, but expects to conform to a specific WSDL or REST = schema. Seems like a parameter is appropriate, rather than defining new schemes. I am not convinced lost-sync is useful, as I have stated before, but I = don't have any objection to finishing this work. Broan > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Monday, August 17, 2009 1:38 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); 'ext Karl Heinz Wolf' > Cc: 'ECRIT' > Subject: Re: [Ecrit] LoST Sync Draft Update >=20 > As I explained in my previous mail there is a potential problem with > the > document. >=20 > My current suggestion is to re-introduce the "lost:" URI scheme (we = had > it > once in the LoST spec) >=20 > Thoughts about it? Objections? >=20 > ------------------- >=20 > Section (A): LoST Uniform Resource Locators and Their Resolution >=20 >=20 > LoST servers are identified by LoST Uniform Resource Locators > (URLs), > which follow the format of URLs defined in RFC 3986, with the > following ABNF: >=20 > LoST-URI =3D "lost:" host >=20 > 'host' is defined in Section 3.2.2 of RFC 3986. >=20 > An example is 'lost:lostserver.example.com' >=20 > If a LoST URL contains a host name rather than an IP address, > the resolution mechanism described in Section 4 of RFC 5222 is = used. >=20 >=20 > Section (B): URL Registration Template >=20 >=20 > This registration template is in accordance with RFC 2717. >=20 > URL scheme name: >=20 > lost >=20 > URL scheme syntax: >=20 > See Section (A). >=20 > Character encoding considerations: >=20 > See Section (A). >=20 > Intended Use: >=20 > The intended usage is described in this document. >=20 > Application and protocols which use this scheme: >=20 > The usage of the LoST URL scheme is targeted for this document, > namely for the exchange of mapping structures. >=20 > Interoperability considerations: >=20 > None >=20 > Security considerations: >=20 > See Section 7 >=20 > Relevant publications: >=20 > This document provides the relevant context for this URL scheme. >=20 > Contact: >=20 > Hannes Tschofenig, Hannes.Tschofenig@gmx.net >=20 > Author/Change controller: >=20 > The IESG >=20 > ------------------- >=20 >=20 > Ciao > Hannes >=20 >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > >Sent: 10 August, 2009 15:12 > >To: ext Karl Heinz Wolf > >Cc: ECRIT > >Subject: Re: [Ecrit] LoST Sync Draft Update > > > >Hi Karl Heinz, > >Hi all, > > > >Thanks for this question. > > > >To provide a bit of background to your question let us take an > >example provided in > >http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt > > > >On page 10 an example of mappings stored at a server are outlined: > > > > country A1 A2 A3 resource or LoST server > > US NJ Bergen Leonia sip:psap@leonianj.gov > > US NJ Bergen Fort Lee sip:emergency@fortleenj.org > > US NJ Bergen Teaneck sip:police@teanecknjgov.org > > US NJ Bergen Englewood englewoodnj.gov > > > >In this case, the first three mappings point to PSAPs (or > >ESRPs; one cannot differentiate based on the mapping data). > >The final mapping, however, points to a LoST server. > > > >So, element of the element accepts only URIs. > >The output of the U-NAPTR process (described in Section 4 of > >http://www.ietf.org/rfc/rfc5222.txt) leads to a HTTP/HTTPS URI. > > > >So, the URI that is associated with the boundary is using a > >HTTP and HTTPS URL scheme. > >The input unfortunatley isn't; it is just a DNS name. > > > >In earlier versions of the LoST specifications we defined a > >new URI scheme (namely lost://) but later removed it. As such, > >there is no LoST URI to put into the element. > > > >So, do we have a problem here? > > > >Ciao > >Hannes > > > >PS: I have to check what the implementers have implemented here. > > > >>Hannes, > >> > >>some time ago I asked you about lost-sync and the pushing of = coverage > >>regions up a tree. > >>Pushing of coverage regions is mentioned in the introduction, but = all > >>the examples show complete mappings. > >>So I wonder if you assume LoST URIs to be placed in the URI > >elements of > >>the mappings to indicate that this is not a mapping but rather a > >>coverage region in the boundary? > >> > >>cheers > >>karl heinz > >> > >>On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - > >>FI/Espoo) wrote: > >>> Hi all, > >>> > >>> I asked Roger to submit the PROTO writeup for the LoST sync draft > >>> after we got further confirmation from the implementers team. = Then, > >>> Roger pointed me to the review by Richard and I have to say that I > >>> must have missed it. Here are Richards review comments: > >>> > >>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html > >>> > >>> My response is inline: > >>> > >>> I reviewed lost-sync-04 in order to update my earlier > >>comments on -01. > >>> This version is much improved from the previous versions in > >terms of > >>> specificity (although it's still vague in places).=A0 It still > >>seems to > >>> me that there are a few layers of detail missing.=A0 Specific > >>comments below. > >>> --Richard > >>> > >>> 1. The document describes transactions for requesting and > >delivering > >>> mapping structures, but doesn't describe at all how these > >>transactions > >>> create a synchronization system.=A0 There is clearly some tracking = of > >>> state needed (especially for "pushMappings"), and the document is > >>> silent on how this state is initially established and then > >>maintained. > >>> > >>> [Hannes] I added text throught the document to address this > >comments. > >>> In particular I point to the need to keep state and also to > >the fact > >>> that the document relies on manual configuration for setting up = the > >>> "peering" between the two nodes. > >>> > >>> 2. In a similar vein, it would be helpful for this document to = have > >>> some discussion of how this synchronization system relates > >to others > >>> that are out there (e.g., rsync).=A0 Since the name of the draft = is > >>> "synchronization", there should be some discussion of how > >>> bidirectional sync is handled. > >>> > >>> [Hannes] We had a discussion about this topic at the > >interim meeting > >>> and "downgraded" the document to an Experimental status to avoid > >>> having to Analyse all available replication mechanisms. > >>> > >>> 3. It seems like there should really be only 3 message types here > >>> instead of 4: (1) a "syncRequest" message sent from destination to > >>> source (getMappingsRequest), (2) a "syncUpdate" message sent from > >>> source to destination (getMappingsResponse =3D=3D = pushMappingsRequest), > >>> and (3) a "syncResult" message sent from destination to source > >>> (pushMappingsResponse).=A0 There can still be two types of > >>transaction, > >>> but they're determined by which type of message (syncRequest or > >>> syncUpdate) is sent in the HTTP request. > >>> > >>> [Hannes] We got similar feedback from the implementers. > >>However, in a > >>> subsequent discussion with them it turned out that this change is > >>> rather a matter of style than anything technical. A change in the > >>> description along the lines as you suggested (and as they had > >>> suggested) as well only impacts the writing style of the > >>document and > >>> not really the implementation as such. Hence, I left the > >>document as is. > >>> > >>> 4. In a similar vein to 2 and 3, the use of "client" and > >"server" is > >>> confusing.=A0 I would suggest using more appropriate names for = these > >>> roles like "source" and "destination", along with some text that > >>> explains how these roles map to HTTP roles in each type of > >>transaction. > >>> > >>> [Hannes] I added text regarding the HTTP/HTTPs roles and > >changed the > >>> terminology in the document to reflect the source / > >>destination terminology. > >>> I hope it improved readability. > >>> > >>> 5. My comment about the security considerations has not been > >>addressed. > >>> =A0The security considerations section is essentially a > >>pointer to LoST, > >>> but this protocol is only peripherally related to LoST (at a > >>technical > >>> level).=A0 Since it's about synchronization, I would expect this > >>> document to note that the primary risk is the injection of false > >>> location information (since the mappings themselves are > >>public), which > >>> means that the parties should use HTTPS to carry the XML, > >>authenticate > >>> the source, and use a ciphersuite that provides integrity > >>protection to messages. > >>> > >>> [Hannes] You are certainly right with this comment. I > >>changed the text. > >>> > >>> Here is the updated document: > >>> > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.txt > >>> > >>> 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 > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Hannes.Tschofenig@gmx.net Mon Aug 17 11:28:06 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954D23A6989 for ; Mon, 17 Aug 2009 11:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.934, 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 BZvZ5aIEDzLx for ; Mon, 17 Aug 2009 11:28:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1E26A3A689E for ; Mon, 17 Aug 2009 11:28:04 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2009 18:28:09 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp015) with SMTP; 17 Aug 2009 20:28:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+OdfVsLAGOpUnL1YXwhVp2kpk26auAujpC+4AvhH 5J4vtjV+uyxv98 From: "Hannes Tschofenig" To: "'ecrit'" Date: Mon, 17 Aug 2009 21:30:45 +0300 Message-ID: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcofaNVmS+J52KuCR+CYKGKdKpDamw== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:28:06 -0000 Hi all, please let us know if there is something incorrect or missing with the proposal for the new charter & milestones. Ciao Hannes & Marc ---------------- 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 Done Submit "Best Current Practice for Communications Services in support of Emergency Calling" to the IESG for consideration as a BCP RFC Done Submit "Framework for Emergency Calling using Internet Multimedia" to the IESG for consideration as a Standards Track RFC Aug 2009 Submit "Synchronizing Location-to-Service Translation (LoST) Servers" to the IESG for consideration as a Standards Track RFC Sep 2009 Submit "IANA Registering a SIP RPH Namespace for Local Emergency Communications" to the IESG for consideration as a Standards Track RFC Oct 2009 Submit "LoST ServiceListBoundary Extension" to the IESG for consideration as an Experimental RFC Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a Standards Track RFC Dec 2009 Submit "Location-to-Service Translation Protocol (LoST) Extensions" to the IESG for consideration as an Informational RFC Feb 2010 Submit "Using Imprecise Location for Emergency Context Resolution" to the IESG for consideration as an Informational RFC Mar 2010 Submit "Marking of Calls initiated by Public Safety Answering Points (PSAPs)" to the IESG for consideration as an Informational RFC Apr 2010 Submit "Emergency Services Architecture Extensions for Unauthenticated and Unauthorized Devices" to the IESG for consideration as an Experimental RFC From treese@telcordia.com Mon Aug 17 11:35:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E333A6F64 for ; Mon, 17 Aug 2009 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K1ris-06QEY for ; Mon, 17 Aug 2009 11:34:56 -0700 (PDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by core3.amsl.com (Postfix) with ESMTP id 310A13A6F71 for ; Mon, 17 Aug 2009 11:34:46 -0700 (PDT) Received: from rrc-dte-ieg01.dte.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id n7HIYoRH007170 for ; Mon, 17 Aug 2009 14:34:50 -0400 (EDT) X-AuditID: 80601416-00000fe8000018a4-80-4a89a2c6758e Received: from rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) by rrc-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 14:34:46 -0400 Received: from rrc-dte-exmb2.dte.telcordia.com ([128.96.180.27]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Mon, 17 Aug 2009 14:34:47 -0400 From: "Reese, Theresa E" To: Hannes Tschofenig , "'Marc Linsner'" , "'ecrit'" Date: Mon, 17 Aug 2009 14:34:45 -0400 Thread-Topic: [Ecrit] Please respond to the Premature Disconnect HUM Thread-Index: AcoXhxQtX8f3gqAXCEqhXCTtM2totQH3pMOgAADbi1A= Message-ID: References: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> In-Reply-To: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F794CEE42816844AA0FFAFACC80F229127E2F15FDErrcdteexmb2dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Please respond to the Premature Disconnect HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:35:01 -0000 --_000_F794CEE42816844AA0FFAFACC80F229127E2F15FDErrcdteexmb2dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that it is appropriate that this problem be addressed in ECRIT, and= that Brian's proposed Problem Statement is a good first step in the proces= s. Terry Reese From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Monday, August 17, 2009 2:10 PM To: 'Marc Linsner'; 'ecrit' Subject: [Ecrit] Please respond to the Premature Disconnect HUM FYI: We have not received a lot of feedback (maybe because of the holidays,= maybe because of lack of interest, maybe because of the other discussions)= . So, help us to make a decision... ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: 07 August, 2009 20:47 To: 'ecrit' Subject: [Ecrit] Premature Disconnect At the Stockholm meeting Brian Rosen presented Premature Disconnect (http:/= /www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit= -premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecri= t-premature-disconnect-rqmts-02). After some amount of discussion, we told= Brian to 'go away' and bring back a problem statement vs. a set of require= ments so we could evaluate whether this is something we wanted to work on. = I had hoped we would have time during the meeting for Brian to present the= problem statement, but we ran out of time. Brian sent it to the list on 7/= 29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html). Now for the obvious questions. Do you have feedback regarding the problem statement? Do you think that this is a problem worth solving in ECRIT? Your feedback will determine whether we ask for AD approval to add this wor= k to our charter. Please respond by COB Friday August 14, 2009. Thanks, Marc & Hannes --_000_F794CEE42816844AA0FFAFACC80F229127E2F15FDErrcdteexmb2dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Premature Disconnect

    I think that it is appropriate that this problem be addresse= d in ECRIT, and that Brian’s proposed Problem Statement is a good first st= ep in the process.

     

    Terry Reese

     

    From: ecrit-bounces= @ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig
    Sent: Monday, August 17, 2009 2:10 PM
    To: 'Marc Linsner'; 'ecrit'
    Subject: [Ecrit] Please respond to the Premature Disconnect HUM=

     

    FYI: We have not received a lot of feedback (maybe because of t= he holidays, maybe because of lack of interest, maybe because of the other discussions). So, help us to make a decision...

     

    From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
    Sent: 07 August, 2009 20:47
    To: 'ecrit'
    Subject: [Ecrit] Premature Disconnect

    At the Stockholm meeting Brian Rosen presented Premature Disconnect (http://www.i= etf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-= rqmts-02).  After some amount of discussion, we told Brian to ‘go away̵= 7; and bring back a problem statement vs. a set of requirements so we could evaluate whe= ther this is something we wanted to work on.  I had hoped we would have tim= e during the meeting for Brian to present the problem statement, but we ran o= ut of time. Brian sent it to the list on 7/29/09 (h= ttp://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html).

    Now for the obvious questions.

    Do you have feedback regarding the problem statement?

    Do you think that this is a problem worth solving in ECRIT?

    Your feedback will determine whether we ask for AD approval to add this wor= k to our charter.  Please respond by COB Friday August 14, 2009.

    Thanks,

    Marc & Hannes

    --_000_F794CEE42816844AA0FFAFACC80F229127E2F15FDErrcdteexmb2dt_-- From andy@hxr.us Mon Aug 17 12:27:28 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CF828C2F4 for ; Mon, 17 Aug 2009 12:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bfZXXhWqUQ5 for ; Mon, 17 Aug 2009 12:27:27 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id D7FAC28C305 for ; Mon, 17 Aug 2009 12:27:26 -0700 (PDT) Received: from zx80-2.arin.net ([::ffff:192.149.252.11]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 17 Aug 2009 15:27:17 -0400 id 015842FB.4A89AF15.00006735 Message-Id: <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> From: Andrew Newton To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 Aug 2009 15:27:17 -0400 References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> X-Mailer: Apple Mail (2.936) Cc: ECRIT Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 19:27:28 -0000 I think you could safely and naturally run the U-NAPTR process against the contents of the element to get what you need. A LOST URL scheme is not needed, and would have implications on tools that are fed them. -andy On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Karl Heinz, > Hi all, > > Thanks for this question. > > To provide a bit of background to your question let us take an > example provided in > http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt > > On page 10 an example of mappings stored at a server are outlined: > > country A1 A2 A3 resource or LoST server > US NJ Bergen Leonia sip:psap@leonianj.gov > US NJ Bergen Fort Lee sip:emergency@fortleenj.org > US NJ Bergen Teaneck sip:police@teanecknjgov.org > US NJ Bergen Englewood englewoodnj.gov > > In this case, the first three mappings point to PSAPs (or ESRPs; one > cannot differentiate based on the mapping data). The final mapping, > however, points to a LoST server. > > So, element of the element accepts only URIs. The > output of the U-NAPTR process (described in Section 4 of http://www.ietf.org/rfc/rfc5222.txt) > leads to a HTTP/HTTPS URI. > > So, the URI that is associated with the boundary is using a HTTP and > HTTPS URL scheme. > The input unfortunatley isn't; it is just a DNS name. > > In earlier versions of the LoST specifications we defined a new URI > scheme (namely lost://) but later removed it. As such, there is no > LoST URI to put into the element. > > So, do we have a problem here? > > Ciao > Hannes > > PS: I have to check what the implementers have implemented here. > >> Hannes, >> >> some time ago I asked you about lost-sync and the pushing of >> coverage regions up a tree. >> Pushing of coverage regions is mentioned in the introduction, >> but all the examples show complete mappings. >> So I wonder if you assume LoST URIs to be placed in the URI >> elements of the mappings to indicate that this is not a >> mapping but rather a coverage region in the boundary? >> >> cheers >> karl heinz >> >> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - >> FI/Espoo) wrote: >>> Hi all, >>> >>> I asked Roger to submit the PROTO writeup for the LoST sync draft >>> after we got further confirmation from the implementers team. Then, >>> Roger pointed me to the review by Richard and I have to say that I >>> must have missed it. Here are Richards review comments: >>> >>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>> >>> My response is inline: >>> >>> I reviewed lost-sync-04 in order to update my earlier >> comments on -01. >>> This version is much improved from the previous versions in terms of >>> specificity (although it's still vague in places). It still >> seems to >>> me that there are a few layers of detail missing. Specific >> comments below. >>> --Richard >>> >>> 1. The document describes transactions for requesting and delivering >>> mapping structures, but doesn't describe at all how these >> transactions >>> create a synchronization system. There is clearly some tracking of >>> state needed (especially for "pushMappings"), and the document is >>> silent on how this state is initially established and then >> maintained. >>> >>> [Hannes] I added text throught the document to address this >>> comments. >>> In particular I point to the need to keep state and also to the fact >>> that the document relies on manual configuration for setting up the >>> "peering" between the two nodes. >>> >>> 2. In a similar vein, it would be helpful for this document to have >>> some discussion of how this synchronization system relates to others >>> that are out there (e.g., rsync). Since the name of the draft is >>> "synchronization", there should be some discussion of how >>> bidirectional sync is handled. >>> >>> [Hannes] We had a discussion about this topic at the interim meeting >>> and "downgraded" the document to an Experimental status to avoid >>> having to Analyse all available replication mechanisms. >>> >>> 3. It seems like there should really be only 3 message types here >>> instead of 4: (1) a "syncRequest" message sent from destination to >>> source (getMappingsRequest), (2) a "syncUpdate" message sent from >>> source to destination (getMappingsResponse == pushMappingsRequest), >>> and (3) a "syncResult" message sent from destination to source >>> (pushMappingsResponse). There can still be two types of >> transaction, >>> but they're determined by which type of message (syncRequest or >>> syncUpdate) is sent in the HTTP request. >>> >>> [Hannes] We got similar feedback from the implementers. >> However, in a >>> subsequent discussion with them it turned out that this change is >>> rather a matter of style than anything technical. A change in the >>> description along the lines as you suggested (and as they had >>> suggested) as well only impacts the writing style of the >> document and >>> not really the implementation as such. Hence, I left the >> document as is. >>> >>> 4. In a similar vein to 2 and 3, the use of "client" and "server" is >>> confusing. I would suggest using more appropriate names for these >>> roles like "source" and "destination", along with some text that >>> explains how these roles map to HTTP roles in each type of >> transaction. >>> >>> [Hannes] I added text regarding the HTTP/HTTPs roles and changed the >>> terminology in the document to reflect the source / >> destination terminology. >>> I hope it improved readability. >>> >>> 5. My comment about the security considerations has not been >> addressed. >>> The security considerations section is essentially a >> pointer to LoST, >>> but this protocol is only peripherally related to LoST (at a >> technical >>> level). Since it's about synchronization, I would expect this >>> document to note that the primary risk is the injection of false >>> location information (since the mappings themselves are >> public), which >>> means that the parties should use HTTPS to carry the XML, >> authenticate >>> the source, and use a ciphersuite that provides integrity >> protection to messages. >>> >>> [Hannes] You are certainly right with this comment. I >> changed the text. >>> >>> Here is the updated document: >>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>> sync-07.txt >>> >>> 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 Martin.Thomson@andrew.com Mon Aug 17 13:29:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE0C3A6A4C for ; Mon, 17 Aug 2009 13:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXCUiuYaGaxQ for ; Mon, 17 Aug 2009 13:29:55 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 5B71F3A6DC7 for ; Mon, 17 Aug 2009 13:29:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_17_15_52_18 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, 17 Aug 2009 15:52:18 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 15:29:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 17 Aug 2009 15:29:27 -0500 Message-ID: In-Reply-To: <001701ca1f61$78c16730$2549a20a@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Sync Draft Update Thread-Index: AcoZn9oC1A6Mhef0RAWYfzox2uP/ewABwUagAWkSv9AAC4IZ0A== References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net><3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <001701ca1f61$78c16730$2549a20a@nsnintra.net> From: "Thomson, Martin" To: "Hannes Tschofenig" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Karl Heinz Wolf" X-OriginalArrivalTime: 17 Aug 2009 20:29:23.0221 (UTC) FILETIME=[68248C50:01CA1F79] Cc: ECRIT Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 20:29:56 -0000 SSB0ZW5kIHRvIGFncmVlIHdpdGggQnJvYW4gW3NpY10gb24gdGhlIG1pbnRpbmcgb2YgdGhlIFVS SSBzY2hlbWUuICBJdCBzaG91bGQgYmUgZW5vdWdoIHRvIHVzZSBhbiBIVFRQIFVSSSwgb3IganVz dCBhbiB1bmFkb3JuZWQgZG9tYWluIG5hbWUsIGRlcGVuZGluZyBvbiBjb250ZXh0Lg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgSGFubmVzIFRz Y2hvZmVuaWcNCj4gU2VudDogVHVlc2RheSwgMTggQXVndXN0IDIwMDkgMzozOCBBTQ0KPiBUbzog VHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7ICdleHQgS2FybCBIZWlueiBXb2xm Jw0KPiBDYzogJ0VDUklUJw0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBMb1NUIFN5bmMgRHJhZnQg VXBkYXRlDQo+IA0KPiBBcyBJIGV4cGxhaW5lZCBpbiBteSBwcmV2aW91cyBtYWlsIHRoZXJlIGlz IGEgcG90ZW50aWFsIHByb2JsZW0gd2l0aA0KPiB0aGUNCj4gZG9jdW1lbnQuDQo+IA0KPiBNeSBj dXJyZW50IHN1Z2dlc3Rpb24gaXMgdG8gcmUtaW50cm9kdWNlIHRoZSAibG9zdDoiIFVSSSBzY2hl bWUgKHdlIGhhZA0KPiBpdA0KPiBvbmNlIGluIHRoZSBMb1NUIHNwZWMpDQo+IA0KPiBUaG91Z2h0 cyBhYm91dCBpdD8gT2JqZWN0aW9ucz8NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IFNlY3Rpb24gKEEpOiBMb1NUIFVuaWZvcm0gUmVzb3VyY2UgTG9jYXRvcnMgYW5kIFRoZWlyIFJl c29sdXRpb24NCj4gDQo+IA0KPiAgICBMb1NUIHNlcnZlcnMgYXJlIGlkZW50aWZpZWQgYnkgTG9T VCBVbmlmb3JtIFJlc291cmNlIExvY2F0b3JzDQo+IChVUkxzKSwNCj4gICAgd2hpY2ggZm9sbG93 IHRoZSBmb3JtYXQgb2YgVVJMcyBkZWZpbmVkIGluIFJGQyAzOTg2LCB3aXRoIHRoZQ0KPiAgICBm b2xsb3dpbmcgQUJORjoNCj4gDQo+ICAgICAgIExvU1QtVVJJID0gImxvc3Q6IiBob3N0DQo+IA0K PiAgICAnaG9zdCcgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMi4yIG9mIFJGQyAzOTg2Lg0KPiAN Cj4gICAgQW4gZXhhbXBsZSBpcyAnbG9zdDpsb3N0c2VydmVyLmV4YW1wbGUuY29tJw0KPiANCj4g ICAgSWYgYSBMb1NUIFVSTCBjb250YWlucyBhIGhvc3QgbmFtZSByYXRoZXIgdGhhbiBhbiBJUCBh ZGRyZXNzLA0KPiAgICB0aGUgcmVzb2x1dGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rp b24gNCBvZiBSRkMgNTIyMiBpcyB1c2VkLg0KPiANCj4gDQo+IFNlY3Rpb24gKEIpOiBVUkwgUmVn aXN0cmF0aW9uIFRlbXBsYXRlDQo+IA0KPiANCj4gICAgVGhpcyByZWdpc3RyYXRpb24gdGVtcGxh dGUgaXMgaW4gYWNjb3JkYW5jZSB3aXRoIFJGQyAyNzE3Lg0KPiANCj4gICAgVVJMIHNjaGVtZSBu YW1lOg0KPiANCj4gICAgICAgbG9zdA0KPiANCj4gICAgVVJMIHNjaGVtZSBzeW50YXg6DQo+IA0K PiAgICAgICBTZWUgU2VjdGlvbiAoQSkuDQo+IA0KPiAgICBDaGFyYWN0ZXIgZW5jb2RpbmcgY29u c2lkZXJhdGlvbnM6DQo+IA0KPiAgICAgICBTZWUgU2VjdGlvbiAoQSkuDQo+IA0KPiAgICBJbnRl bmRlZCBVc2U6DQo+IA0KPiAgICAgICBUaGUgaW50ZW5kZWQgdXNhZ2UgaXMgZGVzY3JpYmVkIGlu IHRoaXMgZG9jdW1lbnQuDQo+IA0KPiAgICBBcHBsaWNhdGlvbiBhbmQgcHJvdG9jb2xzIHdoaWNo IHVzZSB0aGlzIHNjaGVtZToNCj4gDQo+ICAgICAgIFRoZSB1c2FnZSBvZiB0aGUgTG9TVCBVUkwg c2NoZW1lIGlzIHRhcmdldGVkIGZvciB0aGlzIGRvY3VtZW50LA0KPiAgICAgICBuYW1lbHkgZm9y IHRoZSBleGNoYW5nZSBvZiBtYXBwaW5nIHN0cnVjdHVyZXMuDQo+IA0KPiAgICBJbnRlcm9wZXJh YmlsaXR5IGNvbnNpZGVyYXRpb25zOg0KPiANCj4gICAgICAgTm9uZQ0KPiANCj4gICAgU2VjdXJp dHkgY29uc2lkZXJhdGlvbnM6DQo+IA0KPiAgICAgICBTZWUgU2VjdGlvbiA3DQo+IA0KPiAgICBS ZWxldmFudCBwdWJsaWNhdGlvbnM6DQo+IA0KPiAgICAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVz IHRoZSByZWxldmFudCBjb250ZXh0IGZvciB0aGlzIFVSTCBzY2hlbWUuDQo+IA0KPiAgICBDb250 YWN0Og0KPiANCj4gICAgICAgSGFubmVzIFRzY2hvZmVuaWcsIEhhbm5lcy5Uc2Nob2ZlbmlnQGdt eC5uZXQNCj4gDQo+ICAgIEF1dGhvci9DaGFuZ2UgY29udHJvbGxlcjoNCj4gDQo+ICAgICAgIFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4g DQo+IENpYW8NCj4gSGFubmVzDQo+IA0KPiANCj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID5Gcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0Bp ZXRmLm9yZ10NCj4gPk9uIEJlaGFsZiBPZiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0Vz cG9vKQ0KPiA+U2VudDogMTAgQXVndXN0LCAyMDA5IDE1OjEyDQo+ID5UbzogZXh0IEthcmwgSGVp bnogV29sZg0KPiA+Q2M6IEVDUklUDQo+ID5TdWJqZWN0OiBSZTogW0Vjcml0XSBMb1NUIFN5bmMg RHJhZnQgVXBkYXRlDQo+ID4NCj4gPkhpIEthcmwgSGVpbnosDQo+ID5IaSBhbGwsDQo+ID4NCj4g PlRoYW5rcyBmb3IgdGhpcyBxdWVzdGlvbi4NCj4gPg0KPiA+VG8gcHJvdmlkZSBhIGJpdCBvZiBi YWNrZ3JvdW5kIHRvIHlvdXIgcXVlc3Rpb24gbGV0IHVzIHRha2UgYW4NCj4gPmV4YW1wbGUgcHJv dmlkZWQgaW4NCj4gPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1lY3JpdC1tYXBw aW5nLWFyY2gtMDQudHh0DQo+ID4NCj4gPk9uIHBhZ2UgMTAgYW4gZXhhbXBsZSBvZiBtYXBwaW5n cyBzdG9yZWQgYXQgYSBzZXJ2ZXIgYXJlIG91dGxpbmVkOg0KPiA+DQo+ID4gICBjb3VudHJ5ICAg QTEgQTIgICAgICAgICBBMyAgICAgICAgcmVzb3VyY2Ugb3IgTG9TVCBzZXJ2ZXINCj4gPiAgIFVT ICAgICAgICBOSiBCZXJnZW4gICAgIExlb25pYSAgICBzaXA6cHNhcEBsZW9uaWFuai5nb3YNCj4g PiAgIFVTICAgICAgICBOSiBCZXJnZW4gICAgIEZvcnQgTGVlICBzaXA6ZW1lcmdlbmN5QGZvcnRs ZWVuai5vcmcNCj4gPiAgIFVTICAgICAgICBOSiBCZXJnZW4gICAgIFRlYW5lY2sgICBzaXA6cG9s aWNlQHRlYW5lY2tuamdvdi5vcmcNCj4gPiAgIFVTICAgICAgICBOSiBCZXJnZW4gICAgIEVuZ2xl d29vZCBlbmdsZXdvb2Ruai5nb3YNCj4gPg0KPiA+SW4gdGhpcyBjYXNlLCB0aGUgZmlyc3QgdGhy ZWUgbWFwcGluZ3MgcG9pbnQgdG8gUFNBUHMgKG9yDQo+ID5FU1JQczsgb25lIGNhbm5vdCBkaWZm ZXJlbnRpYXRlIGJhc2VkIG9uIHRoZSBtYXBwaW5nIGRhdGEpLg0KPiA+VGhlIGZpbmFsIG1hcHBp bmcsIGhvd2V2ZXIsIHBvaW50cyB0byBhIExvU1Qgc2VydmVyLg0KPiA+DQo+ID5TbywgPHVyaT4g ZWxlbWVudCBvZiB0aGUgPG1hcHBpbmc+IGVsZW1lbnQgYWNjZXB0cyBvbmx5IFVSSXMuDQo+ID5U aGUgb3V0cHV0IG9mIHRoZSBVLU5BUFRSIHByb2Nlc3MgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQg b2YNCj4gPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzUyMjIudHh0KSBsZWFkcyB0byBhIEhU VFAvSFRUUFMgVVJJLg0KPiA+DQo+ID5TbywgdGhlIFVSSSB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0 aCB0aGUgYm91bmRhcnkgaXMgdXNpbmcgYQ0KPiA+SFRUUCBhbmQgSFRUUFMgVVJMIHNjaGVtZS4N Cj4gPlRoZSBpbnB1dCB1bmZvcnR1bmF0bGV5IGlzbid0OyBpdCBpcyBqdXN0IGEgRE5TIG5hbWUu DQo+ID4NCj4gPkluIGVhcmxpZXIgdmVyc2lvbnMgb2YgdGhlIExvU1Qgc3BlY2lmaWNhdGlvbnMg d2UgZGVmaW5lZCBhDQo+ID5uZXcgVVJJIHNjaGVtZSAobmFtZWx5IGxvc3Q6Ly8pIGJ1dCBsYXRl ciByZW1vdmVkIGl0LiBBcyBzdWNoLA0KPiA+dGhlcmUgaXMgbm8gTG9TVCBVUkkgdG8gcHV0IGlu dG8gdGhlIDx1cmk+IGVsZW1lbnQuDQo+ID4NCj4gPlNvLCBkbyB3ZSBoYXZlIGEgcHJvYmxlbSBo ZXJlPw0KPiA+DQo+ID5DaWFvDQo+ID5IYW5uZXMNCj4gPg0KPiA+UFM6IEkgaGF2ZSB0byBjaGVj ayB3aGF0IHRoZSBpbXBsZW1lbnRlcnMgaGF2ZSBpbXBsZW1lbnRlZCBoZXJlLg0KPiA+DQo+ID4+ SGFubmVzLA0KPiA+Pg0KPiA+PnNvbWUgdGltZSBhZ28gSSBhc2tlZCB5b3UgYWJvdXQgbG9zdC1z eW5jIGFuZCB0aGUgcHVzaGluZyBvZiBjb3ZlcmFnZQ0KPiA+PnJlZ2lvbnMgdXAgYSB0cmVlLg0K PiA+PlB1c2hpbmcgb2YgY292ZXJhZ2UgcmVnaW9ucyBpcyBtZW50aW9uZWQgaW4gdGhlIGludHJv ZHVjdGlvbiwgYnV0IGFsbA0KPiA+PnRoZSBleGFtcGxlcyBzaG93IGNvbXBsZXRlIG1hcHBpbmdz Lg0KPiA+PlNvIEkgd29uZGVyIGlmIHlvdSBhc3N1bWUgTG9TVCBVUklzIHRvIGJlIHBsYWNlZCBp biB0aGUgVVJJDQo+ID5lbGVtZW50cyBvZg0KPiA+PnRoZSBtYXBwaW5ncyB0byBpbmRpY2F0ZSB0 aGF0IHRoaXMgaXMgbm90IGEgbWFwcGluZyBidXQgcmF0aGVyIGENCj4gPj5jb3ZlcmFnZSByZWdp b24gaW4gdGhlIGJvdW5kYXJ5Pw0KPiA+Pg0KPiA+PmNoZWVycw0KPiA+PmthcmwgaGVpbnoNCj4g Pj4NCj4gPj5PbiBTdW4sIEF1ZyA5LCAyMDA5IGF0IDk6MDcgQU0sIFRzY2hvZmVuaWcsIEhhbm5l cyAoTlNOIC0NCj4gPj5GSS9Fc3Bvbyk8aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT4gd3JvdGU6 DQo+ID4+PiBIaSBhbGwsDQo+ID4+Pg0KPiA+Pj4gSSBhc2tlZCBSb2dlciB0byBzdWJtaXQgdGhl IFBST1RPIHdyaXRldXAgZm9yIHRoZSBMb1NUIHN5bmMgZHJhZnQNCj4gPj4+IGFmdGVyIHdlIGdv dCBmdXJ0aGVyIGNvbmZpcm1hdGlvbiBmcm9tIHRoZSBpbXBsZW1lbnRlcnMgdGVhbS4gVGhlbiwN Cj4gPj4+IFJvZ2VyIHBvaW50ZWQgbWUgdG8gdGhlIHJldmlldyBieSBSaWNoYXJkIGFuZCBJIGhh dmUgdG8gc2F5IHRoYXQgSQ0KPiA+Pj4gbXVzdCBoYXZlIG1pc3NlZCBpdC4gSGVyZSBhcmUgUmlj aGFyZHMgcmV2aWV3IGNvbW1lbnRzOg0KPiA+Pj4NCj4gPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9lY3JpdC9jdXJyZW50L21zZzA2MTI3Lmh0bWwNCj4gPj4+DQo+ID4+ PiBNeSByZXNwb25zZSBpcyBpbmxpbmU6DQo+ID4+Pg0KPiA+Pj4gSSByZXZpZXdlZCBsb3N0LXN5 bmMtMDQgaW4gb3JkZXIgdG8gdXBkYXRlIG15IGVhcmxpZXINCj4gPj5jb21tZW50cyBvbiAtMDEu DQo+ID4+PiBUaGlzIHZlcnNpb24gaXMgbXVjaCBpbXByb3ZlZCBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9ucyBpbg0KPiA+dGVybXMgb2YNCj4gPj4+IHNwZWNpZmljaXR5IChhbHRob3VnaCBpdCdz IHN0aWxsIHZhZ3VlIGluIHBsYWNlcykuwqAgSXQgc3RpbGwNCj4gPj5zZWVtcyB0bw0KPiA+Pj4g bWUgdGhhdCB0aGVyZSBhcmUgYSBmZXcgbGF5ZXJzIG9mIGRldGFpbCBtaXNzaW5nLsKgIFNwZWNp ZmljDQo+ID4+Y29tbWVudHMgYmVsb3cuDQo+ID4+PiAtLVJpY2hhcmQNCj4gPj4+DQo+ID4+PiAx LiBUaGUgZG9jdW1lbnQgZGVzY3JpYmVzIHRyYW5zYWN0aW9ucyBmb3IgcmVxdWVzdGluZyBhbmQN Cj4gPmRlbGl2ZXJpbmcNCj4gPj4+IG1hcHBpbmcgc3RydWN0dXJlcywgYnV0IGRvZXNuJ3QgZGVz Y3JpYmUgYXQgYWxsIGhvdyB0aGVzZQ0KPiA+PnRyYW5zYWN0aW9ucw0KPiA+Pj4gY3JlYXRlIGEg c3luY2hyb25pemF0aW9uIHN5c3RlbS7CoCBUaGVyZSBpcyBjbGVhcmx5IHNvbWUgdHJhY2tpbmcg b2YNCj4gPj4+IHN0YXRlIG5lZWRlZCAoZXNwZWNpYWxseSBmb3IgInB1c2hNYXBwaW5ncyIpLCBh bmQgdGhlIGRvY3VtZW50IGlzDQo+ID4+PiBzaWxlbnQgb24gaG93IHRoaXMgc3RhdGUgaXMgaW5p dGlhbGx5IGVzdGFibGlzaGVkIGFuZCB0aGVuDQo+ID4+bWFpbnRhaW5lZC4NCj4gPj4+DQo+ID4+ PiBbSGFubmVzXSBJIGFkZGVkIHRleHQgdGhyb3VnaHQgdGhlIGRvY3VtZW50IHRvIGFkZHJlc3Mg dGhpcw0KPiA+Y29tbWVudHMuDQo+ID4+PiBJbiBwYXJ0aWN1bGFyIEkgcG9pbnQgdG8gdGhlIG5l ZWQgdG8ga2VlcCBzdGF0ZSBhbmQgYWxzbyB0bw0KPiA+dGhlIGZhY3QNCj4gPj4+IHRoYXQgdGhl IGRvY3VtZW50IHJlbGllcyBvbiBtYW51YWwgY29uZmlndXJhdGlvbiBmb3Igc2V0dGluZyB1cCB0 aGUNCj4gPj4+ICJwZWVyaW5nIiBiZXR3ZWVuIHRoZSB0d28gbm9kZXMuDQo+ID4+Pg0KPiA+Pj4g Mi4gSW4gYSBzaW1pbGFyIHZlaW4sIGl0IHdvdWxkIGJlIGhlbHBmdWwgZm9yIHRoaXMgZG9jdW1l bnQgdG8gaGF2ZQ0KPiA+Pj4gc29tZSBkaXNjdXNzaW9uIG9mIGhvdyB0aGlzIHN5bmNocm9uaXph dGlvbiBzeXN0ZW0gcmVsYXRlcw0KPiA+dG8gb3RoZXJzDQo+ID4+PiB0aGF0IGFyZSBvdXQgdGhl cmUgKGUuZy4sIHJzeW5jKS7CoCBTaW5jZSB0aGUgbmFtZSBvZiB0aGUgZHJhZnQgaXMNCj4gPj4+ ICJzeW5jaHJvbml6YXRpb24iLCB0aGVyZSBzaG91bGQgYmUgc29tZSBkaXNjdXNzaW9uIG9mIGhv dw0KPiA+Pj4gYmlkaXJlY3Rpb25hbCBzeW5jIGlzIGhhbmRsZWQuDQo+ID4+Pg0KPiA+Pj4gW0hh bm5lc10gV2UgaGFkIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIHRvcGljIGF0IHRoZQ0KPiA+aW50 ZXJpbSBtZWV0aW5nDQo+ID4+PiBhbmQgImRvd25ncmFkZWQiIHRoZSBkb2N1bWVudCB0byBhbiBF eHBlcmltZW50YWwgc3RhdHVzIHRvIGF2b2lkDQo+ID4+PiBoYXZpbmcgdG8gQW5hbHlzZSBhbGwg YXZhaWxhYmxlIHJlcGxpY2F0aW9uIG1lY2hhbmlzbXMuDQo+ID4+Pg0KPiA+Pj4gMy4gSXQgc2Vl bXMgbGlrZSB0aGVyZSBzaG91bGQgcmVhbGx5IGJlIG9ubHkgMyBtZXNzYWdlIHR5cGVzIGhlcmUN Cj4gPj4+IGluc3RlYWQgb2YgNDogKDEpIGEgInN5bmNSZXF1ZXN0IiBtZXNzYWdlIHNlbnQgZnJv bSBkZXN0aW5hdGlvbiB0bw0KPiA+Pj4gc291cmNlIChnZXRNYXBwaW5nc1JlcXVlc3QpLCAoMikg YSAic3luY1VwZGF0ZSIgbWVzc2FnZSBzZW50IGZyb20NCj4gPj4+IHNvdXJjZSB0byBkZXN0aW5h dGlvbiAoZ2V0TWFwcGluZ3NSZXNwb25zZSA9PSBwdXNoTWFwcGluZ3NSZXF1ZXN0KSwNCj4gPj4+ IGFuZCAoMykgYSAic3luY1Jlc3VsdCIgbWVzc2FnZSBzZW50IGZyb20gZGVzdGluYXRpb24gdG8g c291cmNlDQo+ID4+PiAocHVzaE1hcHBpbmdzUmVzcG9uc2UpLsKgIFRoZXJlIGNhbiBzdGlsbCBi ZSB0d28gdHlwZXMgb2YNCj4gPj50cmFuc2FjdGlvbiwNCj4gPj4+IGJ1dCB0aGV5J3JlIGRldGVy bWluZWQgYnkgd2hpY2ggdHlwZSBvZiBtZXNzYWdlIChzeW5jUmVxdWVzdCBvcg0KPiA+Pj4gc3lu Y1VwZGF0ZSkgaXMgc2VudCBpbiB0aGUgSFRUUCByZXF1ZXN0Lg0KPiA+Pj4NCj4gPj4+IFtIYW5u ZXNdIFdlIGdvdCBzaW1pbGFyIGZlZWRiYWNrIGZyb20gdGhlIGltcGxlbWVudGVycy4NCj4gPj5I b3dldmVyLCBpbiBhDQo+ID4+PiBzdWJzZXF1ZW50IGRpc2N1c3Npb24gd2l0aCB0aGVtIGl0IHR1 cm5lZCBvdXQgdGhhdCB0aGlzIGNoYW5nZSBpcw0KPiA+Pj4gcmF0aGVyIGEgbWF0dGVyIG9mIHN0 eWxlIHRoYW4gYW55dGhpbmcgdGVjaG5pY2FsLiBBIGNoYW5nZSBpbiB0aGUNCj4gPj4+IGRlc2Ny aXB0aW9uIGFsb25nIHRoZSBsaW5lcyBhcyB5b3Ugc3VnZ2VzdGVkIChhbmQgYXMgdGhleSBoYWQN Cj4gPj4+IHN1Z2dlc3RlZCkgYXMgd2VsbCBvbmx5IGltcGFjdHMgdGhlIHdyaXRpbmcgc3R5bGUg b2YgdGhlDQo+ID4+ZG9jdW1lbnQgYW5kDQo+ID4+PiBub3QgcmVhbGx5IHRoZSBpbXBsZW1lbnRh dGlvbiBhcyBzdWNoLiBIZW5jZSwgSSBsZWZ0IHRoZQ0KPiA+PmRvY3VtZW50IGFzIGlzLg0KPiA+ Pj4NCj4gPj4+IDQuIEluIGEgc2ltaWxhciB2ZWluIHRvIDIgYW5kIDMsIHRoZSB1c2Ugb2YgImNs aWVudCIgYW5kDQo+ID4ic2VydmVyIiBpcw0KPiA+Pj4gY29uZnVzaW5nLsKgIEkgd291bGQgc3Vn Z2VzdCB1c2luZyBtb3JlIGFwcHJvcHJpYXRlIG5hbWVzIGZvciB0aGVzZQ0KPiA+Pj4gcm9sZXMg bGlrZSAic291cmNlIiBhbmQgImRlc3RpbmF0aW9uIiwgYWxvbmcgd2l0aCBzb21lIHRleHQgdGhh dA0KPiA+Pj4gZXhwbGFpbnMgaG93IHRoZXNlIHJvbGVzIG1hcCB0byBIVFRQIHJvbGVzIGluIGVh Y2ggdHlwZSBvZg0KPiA+PnRyYW5zYWN0aW9uLg0KPiA+Pj4NCj4gPj4+IFtIYW5uZXNdIEkgYWRk ZWQgdGV4dCByZWdhcmRpbmcgdGhlIEhUVFAvSFRUUHMgcm9sZXMgYW5kDQo+ID5jaGFuZ2VkIHRo ZQ0KPiA+Pj4gdGVybWlub2xvZ3kgaW4gdGhlIGRvY3VtZW50IHRvIHJlZmxlY3QgdGhlIHNvdXJj ZSAvDQo+ID4+ZGVzdGluYXRpb24gdGVybWlub2xvZ3kuDQo+ID4+PiBJIGhvcGUgaXQgaW1wcm92 ZWQgcmVhZGFiaWxpdHkuDQo+ID4+Pg0KPiA+Pj4gNS4gTXkgY29tbWVudCBhYm91dCB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgaGFzIG5vdCBiZWVuDQo+ID4+YWRkcmVzc2VkLg0KPiA+Pj4g wqBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyBlc3NlbnRpYWxseSBhDQo+ ID4+cG9pbnRlciB0byBMb1NULA0KPiA+Pj4gYnV0IHRoaXMgcHJvdG9jb2wgaXMgb25seSBwZXJp cGhlcmFsbHkgcmVsYXRlZCB0byBMb1NUIChhdCBhDQo+ID4+dGVjaG5pY2FsDQo+ID4+PiBsZXZl bCkuwqAgU2luY2UgaXQncyBhYm91dCBzeW5jaHJvbml6YXRpb24sIEkgd291bGQgZXhwZWN0IHRo aXMNCj4gPj4+IGRvY3VtZW50IHRvIG5vdGUgdGhhdCB0aGUgcHJpbWFyeSByaXNrIGlzIHRoZSBp bmplY3Rpb24gb2YgZmFsc2UNCj4gPj4+IGxvY2F0aW9uIGluZm9ybWF0aW9uIChzaW5jZSB0aGUg bWFwcGluZ3MgdGhlbXNlbHZlcyBhcmUNCj4gPj5wdWJsaWMpLCB3aGljaA0KPiA+Pj4gbWVhbnMg dGhhdCB0aGUgcGFydGllcyBzaG91bGQgdXNlIEhUVFBTIHRvIGNhcnJ5IHRoZSBYTUwsDQo+ID4+ YXV0aGVudGljYXRlDQo+ID4+PiB0aGUgc291cmNlLCBhbmQgdXNlIGEgY2lwaGVyc3VpdGUgdGhh dCBwcm92aWRlcyBpbnRlZ3JpdHkNCj4gPj5wcm90ZWN0aW9uIHRvIG1lc3NhZ2VzLg0KPiA+Pj4N Cj4gPj4+IFtIYW5uZXNdIFlvdSBhcmUgY2VydGFpbmx5IHJpZ2h0IHdpdGggdGhpcyBjb21tZW50 LiBJDQo+ID4+Y2hhbmdlZCB0aGUgdGV4dC4NCj4gPj4+DQo+ID4+PiBIZXJlIGlzIHRoZSB1cGRh dGVkIGRvY3VtZW50Og0KPiA+Pj4NCj4gPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtZWNyaXQtbG9zdC1zeW5jLTA3LnR4dA0KPiA+Pj4NCj4gPj4+IENpYW8N Cj4gPj4+IEhhbm5lcw0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPj4+IEVjcml0 QGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vj cml0DQo+ID4+Pg0KPiA+Pj4NCj4gPj4NCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID5FY3JpdCBtYWlsaW5nIGxpc3QNCj4gPkVjcml0QGlldGYu b3JnDQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ID4N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGll bnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhl cndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0 aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9o aWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From rbarnes@bbn.com Mon Aug 17 13:53:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5543A6783 for ; Mon, 17 Aug 2009 13:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-1.256, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzc+QxhIr2jo for ; Mon, 17 Aug 2009 13:53:44 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D23FC3A6F1F for ; Mon, 17 Aug 2009 13:53:43 -0700 (PDT) Received: from [128.89.255.90] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Md8H1-0002aD-E9; Mon, 17 Aug 2009 15:53:43 -0400 Message-ID: <4A89C358.3020808@bbn.com> Date: Mon, 17 Aug 2009 16:53:44 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Thomson, Martin" References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net><3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <001701ca1f61$78c16730$2549a20a@nsnintra.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 20:53:45 -0000 +1 Thomson, Martin wrote: > I tend to agree with Broan [sic] on the minting of the URI scheme. It should be enough to use an HTTP URI, or just an unadorned domain name, depending on context. > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Hannes Tschofenig >> Sent: Tuesday, 18 August 2009 3:38 AM >> To: Tschofenig, Hannes (NSN - FI/Espoo); 'ext Karl Heinz Wolf' >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] LoST Sync Draft Update >> >> As I explained in my previous mail there is a potential problem with >> the >> document. >> >> My current suggestion is to re-introduce the "lost:" URI scheme (we had >> it >> once in the LoST spec) >> >> Thoughts about it? Objections? >> >> ------------------- >> >> Section (A): LoST Uniform Resource Locators and Their Resolution >> >> >> LoST servers are identified by LoST Uniform Resource Locators >> (URLs), >> which follow the format of URLs defined in RFC 3986, with the >> following ABNF: >> >> LoST-URI = "lost:" host >> >> 'host' is defined in Section 3.2.2 of RFC 3986. >> >> An example is 'lost:lostserver.example.com' >> >> If a LoST URL contains a host name rather than an IP address, >> the resolution mechanism described in Section 4 of RFC 5222 is used. >> >> >> Section (B): URL Registration Template >> >> >> This registration template is in accordance with RFC 2717. >> >> URL scheme name: >> >> lost >> >> URL scheme syntax: >> >> See Section (A). >> >> Character encoding considerations: >> >> See Section (A). >> >> Intended Use: >> >> The intended usage is described in this document. >> >> Application and protocols which use this scheme: >> >> The usage of the LoST URL scheme is targeted for this document, >> namely for the exchange of mapping structures. >> >> Interoperability considerations: >> >> None >> >> Security considerations: >> >> See Section 7 >> >> Relevant publications: >> >> This document provides the relevant context for this URL scheme. >> >> Contact: >> >> Hannes Tschofenig, Hannes.Tschofenig@gmx.net >> >> Author/Change controller: >> >> The IESG >> >> ------------------- >> >> >> Ciao >> Hannes >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >>> Sent: 10 August, 2009 15:12 >>> To: ext Karl Heinz Wolf >>> Cc: ECRIT >>> Subject: Re: [Ecrit] LoST Sync Draft Update >>> >>> Hi Karl Heinz, >>> Hi all, >>> >>> Thanks for this question. >>> >>> To provide a bit of background to your question let us take an >>> example provided in >>> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >>> >>> On page 10 an example of mappings stored at a server are outlined: >>> >>> country A1 A2 A3 resource or LoST server >>> US NJ Bergen Leonia sip:psap@leonianj.gov >>> US NJ Bergen Fort Lee sip:emergency@fortleenj.org >>> US NJ Bergen Teaneck sip:police@teanecknjgov.org >>> US NJ Bergen Englewood englewoodnj.gov >>> >>> In this case, the first three mappings point to PSAPs (or >>> ESRPs; one cannot differentiate based on the mapping data). >>> The final mapping, however, points to a LoST server. >>> >>> So, element of the element accepts only URIs. >>> The output of the U-NAPTR process (described in Section 4 of >>> http://www.ietf.org/rfc/rfc5222.txt) leads to a HTTP/HTTPS URI. >>> >>> So, the URI that is associated with the boundary is using a >>> HTTP and HTTPS URL scheme. >>> The input unfortunatley isn't; it is just a DNS name. >>> >>> In earlier versions of the LoST specifications we defined a >>> new URI scheme (namely lost://) but later removed it. As such, >>> there is no LoST URI to put into the element. >>> >>> So, do we have a problem here? >>> >>> Ciao >>> Hannes >>> >>> PS: I have to check what the implementers have implemented here. >>> >>>> Hannes, >>>> >>>> some time ago I asked you about lost-sync and the pushing of coverage >>>> regions up a tree. >>>> Pushing of coverage regions is mentioned in the introduction, but all >>>> the examples show complete mappings. >>>> So I wonder if you assume LoST URIs to be placed in the URI >>> elements of >>>> the mappings to indicate that this is not a mapping but rather a >>>> coverage region in the boundary? >>>> >>>> cheers >>>> karl heinz >>>> >>>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - >>>> FI/Espoo) wrote: >>>>> Hi all, >>>>> >>>>> I asked Roger to submit the PROTO writeup for the LoST sync draft >>>>> after we got further confirmation from the implementers team. Then, >>>>> Roger pointed me to the review by Richard and I have to say that I >>>>> must have missed it. Here are Richards review comments: >>>>> >>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>>> >>>>> My response is inline: >>>>> >>>>> I reviewed lost-sync-04 in order to update my earlier >>>> comments on -01. >>>>> This version is much improved from the previous versions in >>> terms of >>>>> specificity (although it's still vague in places). It still >>>> seems to >>>>> me that there are a few layers of detail missing. Specific >>>> comments below. >>>>> --Richard >>>>> >>>>> 1. The document describes transactions for requesting and >>> delivering >>>>> mapping structures, but doesn't describe at all how these >>>> transactions >>>>> create a synchronization system. There is clearly some tracking of >>>>> state needed (especially for "pushMappings"), and the document is >>>>> silent on how this state is initially established and then >>>> maintained. >>>>> [Hannes] I added text throught the document to address this >>> comments. >>>>> In particular I point to the need to keep state and also to >>> the fact >>>>> that the document relies on manual configuration for setting up the >>>>> "peering" between the two nodes. >>>>> >>>>> 2. In a similar vein, it would be helpful for this document to have >>>>> some discussion of how this synchronization system relates >>> to others >>>>> that are out there (e.g., rsync). Since the name of the draft is >>>>> "synchronization", there should be some discussion of how >>>>> bidirectional sync is handled. >>>>> >>>>> [Hannes] We had a discussion about this topic at the >>> interim meeting >>>>> and "downgraded" the document to an Experimental status to avoid >>>>> having to Analyse all available replication mechanisms. >>>>> >>>>> 3. It seems like there should really be only 3 message types here >>>>> instead of 4: (1) a "syncRequest" message sent from destination to >>>>> source (getMappingsRequest), (2) a "syncUpdate" message sent from >>>>> source to destination (getMappingsResponse == pushMappingsRequest), >>>>> and (3) a "syncResult" message sent from destination to source >>>>> (pushMappingsResponse). There can still be two types of >>>> transaction, >>>>> but they're determined by which type of message (syncRequest or >>>>> syncUpdate) is sent in the HTTP request. >>>>> >>>>> [Hannes] We got similar feedback from the implementers. >>>> However, in a >>>>> subsequent discussion with them it turned out that this change is >>>>> rather a matter of style than anything technical. A change in the >>>>> description along the lines as you suggested (and as they had >>>>> suggested) as well only impacts the writing style of the >>>> document and >>>>> not really the implementation as such. Hence, I left the >>>> document as is. >>>>> 4. In a similar vein to 2 and 3, the use of "client" and >>> "server" is >>>>> confusing. I would suggest using more appropriate names for these >>>>> roles like "source" and "destination", along with some text that >>>>> explains how these roles map to HTTP roles in each type of >>>> transaction. >>>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >>> changed the >>>>> terminology in the document to reflect the source / >>>> destination terminology. >>>>> I hope it improved readability. >>>>> >>>>> 5. My comment about the security considerations has not been >>>> addressed. >>>>> The security considerations section is essentially a >>>> pointer to LoST, >>>>> but this protocol is only peripherally related to LoST (at a >>>> technical >>>>> level). Since it's about synchronization, I would expect this >>>>> document to note that the primary risk is the injection of false >>>>> location information (since the mappings themselves are >>>> public), which >>>>> means that the parties should use HTTPS to carry the XML, >>>> authenticate >>>>> the source, and use a ciphersuite that provides integrity >>>> protection to messages. >>>>> [Hannes] You are certainly right with this comment. I >>>> changed the text. >>>>> Here is the updated document: >>>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.txt >>>>> 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 > > ------------------------------------------------------------------------------------------------ > 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 ted.ietf@gmail.com Mon Aug 17 21:52:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739083A6DF8 for ; Mon, 17 Aug 2009 21:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADcI9z6QDeZa for ; Mon, 17 Aug 2009 21:52:04 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 7EE5D3A6B9D for ; Mon, 17 Aug 2009 21:52:04 -0700 (PDT) Received: by pxi1 with SMTP id 1so1789582pxi.31 for ; Mon, 17 Aug 2009 21:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:message-id :in-reply-to:references:date:to:from:subject:content-type; bh=b80J56pYFcnP59BxGnVnBK+a1F1pwIa9QIGazBGN81I=; b=oakpiHDLxwSCUdSGVOrdyupZNrtvXNZceTznEZ/NDz/Eezk7OzYzxuwO80GWQWC9kW qbSGbmwa80XyBsTpJShI5luSjRxvte8631ToppX5U6u3hDtPgYody0bEWAF/eK/amItQ 8HmXgGsiVdJHusXH8hoWTMuDOyNxMv0n8yhiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:message-id:in-reply-to:references:date:to:from:subject :content-type; b=kESGBD7wyl8H0miZQkx0yeKMBstk9/quXMe5jwW1kT4P+j/RAe3+SGvEIff7w5ywe8 SQqLotn8pex+eGpVLjdk3xhNmPtRRBjMZIxz0lJ1FKTutA3NZI0Vz4++K8X9O0jU2T/S pCdlGEx7GbPvMCf0BG+f/lUmBhIY9FEZ6BX44= Received: by 10.115.102.38 with SMTP id e38mr5186177wam.207.1250571127905; Mon, 17 Aug 2009 21:52:07 -0700 (PDT) Received: from ?10.0.1.200? (c-67-188-159-73.hsd1.ca.comcast.net [67.188.159.73]) by mx.google.com with ESMTPS id v32sm5539038wah.48.2009.08.17.21.52.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Aug 2009 21:52:06 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> References: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> Date: Mon, 17 Aug 2009 21:52:00 -0700 To: "Hannes Tschofenig" , "'Marc Linsner'" , "'ecrit'" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] Please respond to the Premature Disconnect HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 04:52:05 -0000 At 9:09 PM +0300 8/17/09, Hannes Tschofenig wrote: >FYI: We have not received a lot of feedback (maybe because of the holidays, maybe because of lack of interest, maybe because of the other discussions). So, help us to make a decision... I'm not sure whether you're counting the discussion in Stockholm as part of this feedback, but my basic take remains the same. The PSAP can *ask* for this capability during a negotiation, but they have to take no for an answer and it must default off. As feedback on Brian's recent statement, I think this: >It is desirable that the PSAP be aware that the user has attempted to > disconnect/reconnect, and it may be useful for the PSAP to be able to > influence the behavior of the device. Some form of signaling for this > purpose is desirable, but need not be reliable, since it is advisory. doesn't really jibe with where we've been going. We've been talking about a case in which the user is given a cue that the disconnect may be premature and is given a mechanism to continue to disconnect. The "double press end" view of things, if you will. Waiting for the PSAP to get signalling on this is a non-starter for me personally, so I see this as potentially complicating the code paths for very little gain. Ted PS. (I'm on vacation until I start my new job, and I'm at the beach for much of the next 10 days; please expect slow responses). > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner >Sent: 07 August, 2009 20:47 >To: 'ecrit' >Subject: [Ecrit] Premature Disconnect > >At the Stockholm meeting Brian Rosen presented Premature Disconnect (http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02). After some amount of discussion, we told Brian to 'go away' and bring back a problem statement vs. a set of requirements so we could evaluate whether this is something we wanted to work on. I had hoped we would have time during the meeting for Brian to present the problem statement, but we ran out of time. Brian sent it to the list on 7/29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html). > >Now for the obvious questions. > >Do you have feedback regarding the problem statement? > >Do you think that this is a problem worth solving in ECRIT? > >Your feedback will determine whether we ask for AD approval to add this work to our charter. Please respond by COB Friday August 14, 2009. > >Thanks, > >Marc & Hannes > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From Ray.Bellis@nominet.org.uk Mon Aug 17 22:49:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3CB3A689A; Mon, 17 Aug 2009 22:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqXJ5qSvVkNq; Mon, 17 Aug 2009 22:49:40 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 9ED2C28C131; Mon, 17 Aug 2009 22:49:18 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=teLthnAYyYWY8ie3rH+NRym0NAXEzHyzb4dPmn7kN/2kgBo1QYqebGJU XuXwjYR3jRuC7av5YuXwBnicqUCCl2Hnen1IGifYGQRbv+38Q7jooY4PC cFEcalVMaNx03hS; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1250574564; x=1282110564; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20Please=20respond=20to=20the=20Premature=20Disconnect =20HUM|Date:=20Tue,=2018=20Aug=202009=2007:49:12=20+0200 |Message-ID:=20|To:=20Ted=20Hardie=20|Cc:=20"'ecrit'"=20,=0D =0A=09ecrit-bounces@ietf.org,=0D=0A=09"Hannes=20Tschofeni g"=20,=0D=0A=09"'Marc=20Linsne r'"=20|MIME-Version:=201.0 |In-Reply-To:=20 |References:=20=09<002 801ca1f65$e1c9fef0$2549a20a@nsnintra.net>=20; bh=bF3kMuhEdtRyGwOBxgwtE6yWUrstjpLoU0NOItFRDH0=; b=SuWlE6IpnCmFlWk2eYFAPao7+5ACAe7WELCSOhpMB1BtU+J2URINqAzD DZ+pqRL+nG8PQ1RtYlCX1JclkTeyc2NYQv6w7XUNN440C5nfk8hKY7ilN BErEoYJyUTeXn6m; X-IronPort-AV: E=Sophos;i="4.43,401,1246834800"; d="scan'208";a="16787279" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 Aug 2009 06:49:15 +0100 In-Reply-To: References: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> To: Ted Hardie MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 18 Aug 2009 07:49:12 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/08/2009 06:49:22 AM, Serialize complete at 18/08/2009 06:49:22 AM Content-Type: multipart/alternative; boundary="=_alternative 001FF7D1C1257616_=" Cc: 'ecrit' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Please respond to the Premature Disconnect HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 05:49:42 -0000 This is a multipart message in MIME format. --=_alternative 001FF7D1C1257616_= Content-Type: text/plain; charset="US-ASCII" > Waiting for the PSAP to get signalling > on this is a non-starter for me personally, so I see this as > potentially complicating the code paths for very little gain. As I understand it [*] several lives are saved annually and prosecutions succeed because of this functionality in the PSTN. In the latter case it's because the PSAP operator has been able to monitor and record evidence of a crime still in progress. Ray [*] admittedly hearsay, but I know a man who'd know for sure, but like me and you he's on vacation at the moment. --=_alternative 001FF7D1C1257616_= Content-Type: text/html; charset="US-ASCII" > Waiting for the PSAP to get signalling
    > on this is a non-starter for me personally, so I see this as
    > potentially complicating the code paths for very little gain.
    As I understand it [*] several lives are saved annually and prosecutions succeed because of this functionality in the PSTN.

    In the latter case it's because the PSAP operator has been able to monitor and record evidence of a crime still in progress.

    Ray

    [*] admittedly hearsay, but I know a man who'd know for sure, but like me and you he's on vacation at the moment.
    --=_alternative 001FF7D1C1257616_=-- From jmpolk@cisco.com Tue Aug 18 09:06:04 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DEA3A6E8E for ; Tue, 18 Aug 2009 09:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 2cwAFYutU95H for ; Tue, 18 Aug 2009 09:06:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4971D3A695F for ; Tue, 18 Aug 2009 09:06:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAIJuikqrR7PD/2dsb2JhbACIXbcbiC2QOwWEGQ X-IronPort-AV: E=Sophos;i="4.43,403,1246838400"; d="scan'208";a="229467080" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 18 Aug 2009 16:06:08 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7IG68Tx025957; Tue, 18 Aug 2009 09:06:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7IG68Pf001525; Tue, 18 Aug 2009 16:06:08 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 09:06:08 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 09:06:07 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Aug 2009 11:06:06 -0500 To: "Hannes Tschofenig" , "'ecrit'" From: "James M. Polk" In-Reply-To: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2009 16:06:07.0708 (UTC) FILETIME=[CBB249C0:01CA201D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1119; t=1250611568; x=1251475568; c=relaxed/simple; s=sjdkim3002; 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=20Rechartering=20&=20Mi lestone=20Update |Sender:=20; bh=b3+dLkoPXwtxTJF1eztJVT77Axpm7HP/ies/HQ1mX4w=; b=RlLODzd7oY+YhYSWiChMPVjraBUUR+7G2XCgn3MsM99ah302JK3yiBG+h3 NPzeYJil5GTLhxtPZecZihLU31FZCOv2613hGiuEsqwcUI5jiyvzJ1GDLFSM BrFivcI1P6; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:06:04 -0000 At 01:30 PM 8/17/2009, Hannes Tschofenig wrote: >Hi all, > >please let us know if there is something incorrect or missing with the >proposal for the new charter & milestones. > >Ciao >Hannes & Marc > >---------------- > >Sep 2009 Submit "IANA Registering a SIP RPH Namespace for Local >Emergency Communications" to the IESG for consideration as a Standards >Track RFC thanks for this ID a milestone >Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a >Standards Track RFC > >Mar 2010 Submit "Marking of Calls initiated by Public Safety >Answering Points (PSAPs)" to the IESG for consideration as an >Informational RFC I'm unfamiliar with either of these two IDs -- as individual or WG items. Looking at the tools page, it doesn't appear that either one exists yet, even as individual IDs. Can someone point me to either ID? I don't remember either topic being discussed in Stockholm, but I could have been distracted. James >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From Hannes.Tschofenig@gmx.net Tue Aug 18 09:45:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1213A6AAA for ; Tue, 18 Aug 2009 09:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=0.907, 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 VDkti4NABdhf for ; Tue, 18 Aug 2009 09:45:58 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B73243A68DD for ; Tue, 18 Aug 2009 09:45:57 -0700 (PDT) Received: (qmail invoked by alias); 18 Aug 2009 16:45:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp040) with SMTP; 18 Aug 2009 18:45:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+RsCR9CUuRJA2RTmYJeOgre8WyScC/XYQbZdJpwE /oD2ChTHaUuys9 From: "Hannes Tschofenig" To: "'James M. Polk'" , "'ecrit'" References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> Date: Tue, 18 Aug 2009 19:48:30 +0300 Message-ID: <005501ca2023$b819c040$8e01fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcogHcx3MirDE3BBS7SBZMkIm5IYNgABRcdA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:45:59 -0000 Hey James, >>Sep 2009 Submit "IANA Registering a SIP RPH Namespace for Local >>Emergency Communications" to the IESG for consideration as a >Standards >>Track RFC > >thanks for this ID a milestone We would have added it sooner but ... > > > >>Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a >>Standards Track RFC >> >>Mar 2010 Submit "Marking of Calls initiated by Public Safety >Answering >>Points (PSAPs)" to the IESG for consideration as an Informational RFC > >I'm unfamiliar with either of these two IDs -- as individual >or WG items. Looking at the tools page, it doesn't appear >that either one exists yet, even as individual IDs. Can >someone point me to either ID? RFC 5031bis refers to this document: http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy-00.txt We discussed the requirements for some time and now there is also a document available. The second document can be found here: http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt Since we only had a discussion about the problem, requirements and design choices but have not decided about the solution approach I put the milestone far out there (and that also provides us a chance for "load balancing"). (We had a HUM about both these documents in past meetings.) >I don't remember either topic being discussed in Stockholm, >but I could have been distracted. We had them on the initial agenda for the meeting but then Henning did not participate and I got ill. The meeting time was still used in a good fashion, I believe. Ciao Hannes PS: Another thing I should also mention that Marc and I would like to involve more folks with the chartered items to ensure continues progress. So, if everyone in the group has time available to help with the chartered items please let us know. We will post a mail about this in a separate mail. > >James > >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > From jmpolk@cisco.com Tue Aug 18 10:08:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84983A6C1B for ; Tue, 18 Aug 2009 10:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 gxfGUWj8WGvV for ; Tue, 18 Aug 2009 10:08:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 275533A6B28 for ; Tue, 18 Aug 2009 10:08:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoGAAt9ikqrR7PE/2dsb2JhbACIXLc/iC2QQwWEGQ X-IronPort-AV: E=Sophos;i="4.43,403,1246838400"; d="scan'208";a="369828064" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2009 17:08:47 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7IH8mEe025443; Tue, 18 Aug 2009 10:08:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n7IH8ms3003646; Tue, 18 Aug 2009 17:08:48 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.3959); Tue, 18 Aug 2009 10:08:48 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.118]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 10:08:47 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Aug 2009 12:08:46 -0500 To: "Hannes Tschofenig" , "'ecrit'" From: "James M. Polk" In-Reply-To: <005501ca2023$b819c040$8e01fe0a@nsnintra.net> References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> <005501ca2023$b819c040$8e01fe0a@nsnintra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2009 17:08:47.0752 (UTC) FILETIME=[8CDB7880:01CA2026] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2649; t=1250615328; x=1251479328; c=relaxed/simple; s=sjdkim4002; 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=20Rechartering=20&=20Mi lestone=20Update |Sender:=20; bh=f306F8z9PCOUVpkk3NBzlB58qRaFDRHuNVmK7HrqFyA=; b=aVxAzo0N/ZR/c4y/iAUGoeht/Q566koZ1B1oi0Hh1Z/IzIhFPcl7amu9uW MfQ6uyCl9HBs2HjEPzcROnA3q6wSEw9t1FYKWIyI8buI3vrh3wZehI4v2jH8 JWAl4uM1Kz; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:08:46 -0000 At 11:48 AM 8/18/2009, Hannes Tschofenig wrote: >Hey James, > > >>Sep 2009 Submit "IANA Registering a SIP RPH Namespace for Local > >>Emergency Communications" to the IESG for consideration as a > >Standards > >>Track RFC > > > >thanks for this ID a milestone > >We would have added it sooner but ... > >>Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a > >>Standards Track RFC > >> > >>Mar 2010 Submit "Marking of Calls initiated by Public Safety > >Answering > >>Points (PSAPs)" to the IESG for consideration as an Informational RFC > > > >I'm unfamiliar with either of these two IDs -- as individual > >or WG items. Looking at the tools page, it doesn't appear > >that either one exists yet, even as individual IDs. Can > >someone point me to either ID? > >RFC 5031bis refers to this document: >http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy-00.txt > >We discussed the requirements for some time and now there is also a document >available. I knew about this doc, but didn't understand this is being talked about as a formal "bis" ID (i.e., that it would obsolete 5031). If that's the case (which I think you just said it is), then shouldn't the filename change to draft-forte-ecrit-5031bis-00.txt ? This does make its intentions much more clear for everyone to understand. >The second document can be found here: >http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt > >Since we only had a discussion about the problem, requirements and design >choices but have not decided about the solution approach I put the milestone >far out there (and that also provides us a chance for "load balancing"). > >(We had a HUM about both these documents in past meetings.) I guess I didn't understand Forte's ID was replacing 5031, is all. > >I don't remember either topic being discussed in Stockholm, > >but I could have been distracted. > >We had them on the initial agenda for the meeting but then Henning did not >participate and I got ill. The meeting time was still used in a good >fashion, I believe. > >Ciao >Hannes > >PS: Another thing I should also mention that Marc and I would like to >involve more folks with the chartered items to ensure continues progress. >So, if everyone in the group has time available to help with the chartered >items please let us know. We will post a mail about this in a separate mail. > > > > > > >James > > > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > > From Hannes.Tschofenig@gmx.net Tue Aug 18 10:08:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE5028C2ED for ; Tue, 18 Aug 2009 10:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhJ0vjf2TDgR for ; Tue, 18 Aug 2009 10:08:51 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C1A5928C308 for ; Tue, 18 Aug 2009 10:08:50 -0700 (PDT) Received: (qmail invoked by alias); 18 Aug 2009 17:08:53 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 18 Aug 2009 19:08:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/gSaxwCM7gScCLbfBNnp41PdNuk3uHsidhbYKab0 KaCnW8IKeI7vm0 From: "Hannes Tschofenig" To: "'ext Andrew Newton'" References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> Date: Tue, 18 Aug 2009 20:11:29 +0300 Message-ID: <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcofcL62GI1SzQY5RACQ2t66WawEpgAXHN/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:08:52 -0000 Thanks for the suggestion. The proposal sounds indeed fairly good (and simple). Here is an example of how this could look like for mapping data used by an Austrian Forest Guide (FG). For this example I assumed that each state runs an independent LoST server and the FG would contain pointers to these LoST servers. I illustrated two such mappings below: Kaernten LoST Server urn:service:sos AT Kaernten 112 LoST Server Wien urn:service:sos AT Wien 112 Thoughts? Ciao Hannes >-----Original Message----- >From: ext Andrew Newton [mailto:andy@hxr.us] >Sent: 17 August, 2009 22:27 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: ext Karl Heinz Wolf; ECRIT >Subject: Re: [Ecrit] LoST Sync Draft Update > >I think you could safely and naturally run the U-NAPTR process >against the contents of the element to get what you >need. A LOST URL scheme is not needed, and would have >implications on tools that are fed them. > >-andy > >On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> Hi Karl Heinz, >> Hi all, >> >> Thanks for this question. >> >> To provide a bit of background to your question let us take an >> example provided in >> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >> >> On page 10 an example of mappings stored at a server are outlined: >> >> country A1 A2 A3 resource or LoST server >> US NJ Bergen Leonia sip:psap@leonianj.gov >> US NJ Bergen Fort Lee sip:emergency@fortleenj.org >> US NJ Bergen Teaneck sip:police@teanecknjgov.org >> US NJ Bergen Englewood englewoodnj.gov >> >> In this case, the first three mappings point to PSAPs (or >ESRPs; one >> cannot differentiate based on the mapping data). The final mapping, >> however, points to a LoST server. >> >> So, element of the element accepts only URIs. The >> output of the U-NAPTR process (described in Section 4 of >http://www.ietf.org/rfc/rfc5222.txt) >> leads to a HTTP/HTTPS URI. >> >> So, the URI that is associated with the boundary is using a >HTTP and >> HTTPS URL scheme. >> The input unfortunatley isn't; it is just a DNS name. >> >> In earlier versions of the LoST specifications we defined a new URI >> scheme (namely lost://) but later removed it. As such, there is no >> LoST URI to put into the element. >> >> So, do we have a problem here? >> >> Ciao >> Hannes >> >> PS: I have to check what the implementers have implemented here. >> >>> Hannes, >>> >>> some time ago I asked you about lost-sync and the pushing of >>> coverage regions up a tree. >>> Pushing of coverage regions is mentioned in the introduction, >>> but all the examples show complete mappings. >>> So I wonder if you assume LoST URIs to be placed in the URI >>> elements of the mappings to indicate that this is not a >>> mapping but rather a coverage region in the boundary? >>> >>> cheers >>> karl heinz >>> >>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - >>> FI/Espoo) wrote: >>>> Hi all, >>>> >>>> I asked Roger to submit the PROTO writeup for the LoST sync draft >>>> after we got further confirmation from the implementers team. Then, >>>> Roger pointed me to the review by Richard and I have to say that I >>>> must have missed it. Here are Richards review comments: >>>> >>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>> >>>> My response is inline: >>>> >>>> I reviewed lost-sync-04 in order to update my earlier >>> comments on -01. >>>> This version is much improved from the previous versions >in terms of >>>> specificity (although it's still vague in places). It still >>> seems to >>>> me that there are a few layers of detail missing. Specific >>> comments below. >>>> --Richard >>>> >>>> 1. The document describes transactions for requesting and >delivering >>>> mapping structures, but doesn't describe at all how these >>> transactions >>>> create a synchronization system. There is clearly some tracking of >>>> state needed (especially for "pushMappings"), and the document is >>>> silent on how this state is initially established and then >>> maintained. >>>> >>>> [Hannes] I added text throught the document to address this >>>> comments. >>>> In particular I point to the need to keep state and also >to the fact >>>> that the document relies on manual configuration for setting up the >>>> "peering" between the two nodes. >>>> >>>> 2. In a similar vein, it would be helpful for this document to have >>>> some discussion of how this synchronization system relates >to others >>>> that are out there (e.g., rsync). Since the name of the draft is >>>> "synchronization", there should be some discussion of how >>>> bidirectional sync is handled. >>>> >>>> [Hannes] We had a discussion about this topic at the >interim meeting >>>> and "downgraded" the document to an Experimental status to avoid >>>> having to Analyse all available replication mechanisms. >>>> >>>> 3. It seems like there should really be only 3 message types here >>>> instead of 4: (1) a "syncRequest" message sent from destination to >>>> source (getMappingsRequest), (2) a "syncUpdate" message sent from >>>> source to destination (getMappingsResponse == pushMappingsRequest), >>>> and (3) a "syncResult" message sent from destination to source >>>> (pushMappingsResponse). There can still be two types of >>> transaction, >>>> but they're determined by which type of message (syncRequest or >>>> syncUpdate) is sent in the HTTP request. >>>> >>>> [Hannes] We got similar feedback from the implementers. >>> However, in a >>>> subsequent discussion with them it turned out that this change is >>>> rather a matter of style than anything technical. A change in the >>>> description along the lines as you suggested (and as they had >>>> suggested) as well only impacts the writing style of the >>> document and >>>> not really the implementation as such. Hence, I left the >>> document as is. >>>> >>>> 4. In a similar vein to 2 and 3, the use of "client" and >"server" is >>>> confusing. I would suggest using more appropriate names for these >>>> roles like "source" and "destination", along with some text that >>>> explains how these roles map to HTTP roles in each type of >>> transaction. >>>> >>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >changed the >>>> terminology in the document to reflect the source / >>> destination terminology. >>>> I hope it improved readability. >>>> >>>> 5. My comment about the security considerations has not been >>> addressed. >>>> The security considerations section is essentially a >>> pointer to LoST, >>>> but this protocol is only peripherally related to LoST (at a >>> technical >>>> level). Since it's about synchronization, I would expect this >>>> document to note that the primary risk is the injection of false >>>> location information (since the mappings themselves are >>> public), which >>>> means that the parties should use HTTPS to carry the XML, >>> authenticate >>>> the source, and use a ciphersuite that provides integrity >>> protection to messages. >>>> >>>> [Hannes] You are certainly right with this comment. I >>> changed the text. >>>> >>>> Here is the updated document: >>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>>> sync-07.txt >>>> >>>> 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 andy@hxr.us Tue Aug 18 10:33:37 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996EB3A6C50 for ; Tue, 18 Aug 2009 10:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfM5k-SoxiAX for ; Tue, 18 Aug 2009 10:33:36 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 2CA0F3A6E23 for ; Tue, 18 Aug 2009 10:33:36 -0700 (PDT) Received: from zx80-2.arin.net ([::ffff:192.149.252.11]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 18 Aug 2009 13:33:29 -0400 id 015AC510.4A8AE5E9.00002AC6 Message-Id: From: Andrew Newton To: Hannes Tschofenig In-Reply-To: <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 13:33:28 -0400 References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> X-Mailer: Apple Mail (2.936) Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:33:37 -0000 Well... I guess... kinda. I'm not sure why it simply wouldn't look like a normal element complete with the set and the normal display name. If the intent is to sync the mappings, you shouldn't really need to change a thing. If the intent is for one server to tell another that it is authoritative for an area, that's not really syncing so much as plain configuration -- and I'm not sure you want to do that in a protocol. After all, the US forest guide isn't simply gonna take all service boundaries from lost.kaernten.example, as kaernten could claim a larger area than it really is responsible for -- a possible attach vector at worst, an opportunity for a grand screw up at best. At least that's how this strikes me. -andy On Aug 18, 2009, at 1:11 PM, Hannes Tschofenig wrote: > Thanks for the suggestion. The proposal sounds indeed fairly good (and > simple). > > Here is an example of how this could look like for mapping data used > by an > Austrian Forest Guide (FG). For this example I assumed that each > state runs > an independent LoST server and the FG would contain pointers to > these LoST > servers. I illustrated two such mappings below: > > expires="2009-01-01T01:44:33Z" > lastUpdated="2009-12-01T01:00:00Z" > source="lost.kaernten.example" > sourceId="e8b05a41d8d1415b80f2cdbb96ccf109"> > > Kaernten LoST Server > > urn:service:sos > profile="civic"> > xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > AT > Kaernten > > > > 112 > > > expires="2009-01-01T01:44:33Z" > lastUpdated="2009-12-01T01:00:00Z" > source="lost.wien.example" > sourceId="e8b05a41d8d1415b80f2cdbb96ccf109"> > > LoST Server Wien > > urn:service:sos > profile="civic"> > xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > AT > Wien > > > > 112 > > > > Thoughts? > > Ciao > Hannes > > > >> -----Original Message----- >> From: ext Andrew Newton [mailto:andy@hxr.us] >> Sent: 17 August, 2009 22:27 >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: ext Karl Heinz Wolf; ECRIT >> Subject: Re: [Ecrit] LoST Sync Draft Update >> >> I think you could safely and naturally run the U-NAPTR process >> against the contents of the element to get what you >> need. A LOST URL scheme is not needed, and would have >> implications on tools that are fed them. >> >> -andy >> >> On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) >> wrote: >> >>> Hi Karl Heinz, >>> Hi all, >>> >>> Thanks for this question. >>> >>> To provide a bit of background to your question let us take an >>> example provided in >>> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >>> >>> On page 10 an example of mappings stored at a server are outlined: >>> >>> country A1 A2 A3 resource or LoST server >>> US NJ Bergen Leonia sip:psap@leonianj.gov >>> US NJ Bergen Fort Lee sip:emergency@fortleenj.org >>> US NJ Bergen Teaneck sip:police@teanecknjgov.org >>> US NJ Bergen Englewood englewoodnj.gov >>> >>> In this case, the first three mappings point to PSAPs (or >> ESRPs; one >>> cannot differentiate based on the mapping data). The final mapping, >>> however, points to a LoST server. >>> >>> So, element of the element accepts only URIs. The >>> output of the U-NAPTR process (described in Section 4 of >> http://www.ietf.org/rfc/rfc5222.txt) >>> leads to a HTTP/HTTPS URI. >>> >>> So, the URI that is associated with the boundary is using a >> HTTP and >>> HTTPS URL scheme. >>> The input unfortunatley isn't; it is just a DNS name. >>> >>> In earlier versions of the LoST specifications we defined a new URI >>> scheme (namely lost://) but later removed it. As such, there is no >>> LoST URI to put into the element. >>> >>> So, do we have a problem here? >>> >>> Ciao >>> Hannes >>> >>> PS: I have to check what the implementers have implemented here. >>> >>>> Hannes, >>>> >>>> some time ago I asked you about lost-sync and the pushing of >>>> coverage regions up a tree. >>>> Pushing of coverage regions is mentioned in the introduction, >>>> but all the examples show complete mappings. >>>> So I wonder if you assume LoST URIs to be placed in the URI >>>> elements of the mappings to indicate that this is not a >>>> mapping but rather a coverage region in the boundary? >>>> >>>> cheers >>>> karl heinz >>>> >>>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - >>>> FI/Espoo) wrote: >>>>> Hi all, >>>>> >>>>> I asked Roger to submit the PROTO writeup for the LoST sync draft >>>>> after we got further confirmation from the implementers team. >>>>> Then, >>>>> Roger pointed me to the review by Richard and I have to say that I >>>>> must have missed it. Here are Richards review comments: >>>>> >>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>>> >>>>> My response is inline: >>>>> >>>>> I reviewed lost-sync-04 in order to update my earlier >>>> comments on -01. >>>>> This version is much improved from the previous versions >> in terms of >>>>> specificity (although it's still vague in places). It still >>>> seems to >>>>> me that there are a few layers of detail missing. Specific >>>> comments below. >>>>> --Richard >>>>> >>>>> 1. The document describes transactions for requesting and >> delivering >>>>> mapping structures, but doesn't describe at all how these >>>> transactions >>>>> create a synchronization system. There is clearly some tracking >>>>> of >>>>> state needed (especially for "pushMappings"), and the document is >>>>> silent on how this state is initially established and then >>>> maintained. >>>>> >>>>> [Hannes] I added text throught the document to address this >>>>> comments. >>>>> In particular I point to the need to keep state and also >> to the fact >>>>> that the document relies on manual configuration for setting up >>>>> the >>>>> "peering" between the two nodes. >>>>> >>>>> 2. In a similar vein, it would be helpful for this document to >>>>> have >>>>> some discussion of how this synchronization system relates >> to others >>>>> that are out there (e.g., rsync). Since the name of the draft is >>>>> "synchronization", there should be some discussion of how >>>>> bidirectional sync is handled. >>>>> >>>>> [Hannes] We had a discussion about this topic at the >> interim meeting >>>>> and "downgraded" the document to an Experimental status to avoid >>>>> having to Analyse all available replication mechanisms. >>>>> >>>>> 3. It seems like there should really be only 3 message types here >>>>> instead of 4: (1) a "syncRequest" message sent from destination to >>>>> source (getMappingsRequest), (2) a "syncUpdate" message sent from >>>>> source to destination (getMappingsResponse == >>>>> pushMappingsRequest), >>>>> and (3) a "syncResult" message sent from destination to source >>>>> (pushMappingsResponse). There can still be two types of >>>> transaction, >>>>> but they're determined by which type of message (syncRequest or >>>>> syncUpdate) is sent in the HTTP request. >>>>> >>>>> [Hannes] We got similar feedback from the implementers. >>>> However, in a >>>>> subsequent discussion with them it turned out that this change is >>>>> rather a matter of style than anything technical. A change in the >>>>> description along the lines as you suggested (and as they had >>>>> suggested) as well only impacts the writing style of the >>>> document and >>>>> not really the implementation as such. Hence, I left the >>>> document as is. >>>>> >>>>> 4. In a similar vein to 2 and 3, the use of "client" and >> "server" is >>>>> confusing. I would suggest using more appropriate names for these >>>>> roles like "source" and "destination", along with some text that >>>>> explains how these roles map to HTTP roles in each type of >>>> transaction. >>>>> >>>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >> changed the >>>>> terminology in the document to reflect the source / >>>> destination terminology. >>>>> I hope it improved readability. >>>>> >>>>> 5. My comment about the security considerations has not been >>>> addressed. >>>>> The security considerations section is essentially a >>>> pointer to LoST, >>>>> but this protocol is only peripherally related to LoST (at a >>>> technical >>>>> level). Since it's about synchronization, I would expect this >>>>> document to note that the primary risk is the injection of false >>>>> location information (since the mappings themselves are >>>> public), which >>>>> means that the parties should use HTTPS to carry the XML, >>>> authenticate >>>>> the source, and use a ciphersuite that provides integrity >>>> protection to messages. >>>>> >>>>> [Hannes] You are certainly right with this comment. I >>>> changed the text. >>>>> >>>>> Here is the updated document: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>>>> sync-07.txt >>>>> >>>>> 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 ted.ietf@gmail.com Tue Aug 18 12:57:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537CB28C249; Tue, 18 Aug 2009 12:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGNpVZCmnwya; Tue, 18 Aug 2009 12:57:21 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 7E3D83A6E7D; Tue, 18 Aug 2009 12:57:21 -0700 (PDT) Received: by pxi1 with SMTP id 1so2255187pxi.31 for ; Tue, 18 Aug 2009 12:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:message-id :in-reply-to:references:date:to:from:subject:cc:content-type; bh=sQPAPYLKRqOPWYRh/V5zobNCDDn1jxSDwA/MOXua5Y8=; b=id4zu21/xVkyVynP91173xhgzKRnSC/AsdgphwnONIqycXMkOKqXtrpBOwq/4XtrdJ YSdFNOLDKyG9g936/l4fX2+q68STNvd3qAEgYmPZo9jVRAzSzkVx+y1CyDuDcn1ib5JY qMPYkD5eH/v8Phq2s84ZmpWt/SsTKc2V1oVRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:message-id:in-reply-to:references:date:to:from:subject :cc:content-type; b=bL92wvpuL/rQtx+8Ks0wmT+wNCD7vHSRGAJK5u9o4MjBk53FewTlFIO/Lo99xMrDpL 7LI/1IWa2kGIeEGpgr1eBzQd90OI/HEwYkv7a1EZJzkbborjys5idp7cB66HbsP3d1p+ dTfKeml6VEHdFOH0R6cu6m+AE7cxtIaC9BGtk= Received: by 10.115.85.27 with SMTP id n27mr5791323wal.188.1250625445154; Tue, 18 Aug 2009 12:57:25 -0700 (PDT) Received: from ?10.0.1.200? (c-67-188-159-73.hsd1.ca.comcast.net [67.188.159.73]) by mx.google.com with ESMTPS id k21sm13247841waf.59.2009.08.18.12.57.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Aug 2009 12:57:24 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> Date: Tue, 18 Aug 2009 12:57:17 -0700 To: Ray.Bellis@nominet.org.uk From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: 'ecrit' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Please respond to the Premature Disconnect HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 19:57:22 -0000 At 7:49 AM +0200 8/18/09, Ray.Bellis@nominet.org.uk wrote: > > Waiting for the PSAP to get signalling >> on this is a non-starter for me personally, so I see this as >> potentially complicating the code paths for very little gain. > >As I understand it [*] several lives are saved annually and prosecutions succeed because of this functionality in the PSTN. > >In the latter case it's because the PSAP operator has been able to monitor and record evidence of a crime still in progress. Maybe I've misunderstood the course of discussion so far, but it was my understanding the Brian, at least, was not after functionality that allowed the PSAP to continue to monitor a UE after an initial attempt to disconnect was made. The functionality was closer to a fast-reconnect than retaining an open channel. I'd also like to re-point out that using PSTN models for this is not likely to be perfect. If the proposed flow is: User initiates call to PSAP PSAP asks for special treatment of disconnect User agent agrees (Call begins) User initiates disconnect User confirms disconnect using special treatment Call tears down I think we have met what is currently on the table. if it runs User initiates call to PSAP PSAP asks for special treatment of disconnect User agent agrees (Call begins) User initiates disconnect PSAP is informed prior to disconnect (PSAP either controls the disconnect or confirmation must wait) User confirms disconnect Call tears down I think we're back in the realm that requires a lot more thought. If you want a message the goes when the User initiates disconnect but has no effect, I strongly suspect that the confirmation will complete prior to the PSAP operator being able to do or say anything useful, except in cases where the User already recognized that it was a mistake. regards, Ted >Ray > >[*] admittedly hearsay, but I know a man who'd know for sure, but like me and you he's on vacation at the moment. From mlinsner@cisco.com Tue Aug 18 14:13:20 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D693A6B37 for ; Tue, 18 Aug 2009 14:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.342 X-Spam-Level: X-Spam-Status: No, score=-5.342 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbuVV0OeQ4US for ; Tue, 18 Aug 2009 14:13:16 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 408FB3A683E for ; Tue, 18 Aug 2009 14:13:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkEAHe2ikpAZnme/2dsb2JhbACCJy6XF6VpiC2QYAWEGQ X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="scan'208,217";a="54530517" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Aug 2009 21:13:07 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7ILD72d029829; Tue, 18 Aug 2009 17:13:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7ILD7Ub008118; Tue, 18 Aug 2009 21:13:07 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 17:13:07 -0400 Received: from [10.116.195.118] ([10.116.195.118]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 17:13:07 -0400 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 18 Aug 2009 17:13:04 -0400 From: Marc Linsner To: Message-ID: Thread-Topic: [Ecrit] Please respond to the Premature Disconnect HUM Thread-Index: AcogSKyp3kz4HjSpXEq4Vq60o4rQVg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3333460387_1970827" X-OriginalArrivalTime: 18 Aug 2009 21:13:07.0297 (UTC) FILETIME=[AEA08510:01CA2048] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3706; t=1250629987; x=1251493987; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Please=20respond=20to=20the=2 0Premature=20Disconnect=20HUM |Sender:=20 |To:=20; bh=uQaohfIZwvSzvXmFZJ1U0MTa1kC8RIbyoVug4NP0iW8=; b=mVuBordrv4rHGsc83aCs1MwkNXtFLSaaMVXbY2qbmBzUpeaKAUoMS2phEy wsCqFR+oskJcV+Q/zcchPrRJMQ/CPj3gtjBi4mOM5xFh705V+ezrlPkicffX gv0JY8xJmq; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'ecrit' Subject: Re: [Ecrit] Please respond to the Premature Disconnect HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 21:13:20 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3333460387_1970827 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ray, On 8/18/09 1:49 AM, "Ray.Bellis@nominet.org.uk" wrote: >> > Waiting for the PSAP to get signalling >> > on this is a non-starter for me personally, so I see this as >> > potentially complicating the code paths for very little gain. >=20 > As I understand it [*] several lives are saved annually and prosecutions > succeed because of this functionality in the PSTN. >=20 > In the latter case it's because the PSAP operator has been able to monito= r and > record evidence of a crime still in progress. >=20 [ML] I don=B9t understand how this is accomplished if the caller placed the handset on the hookswitch. Obviously, if the caller and call-taker have agreed to allow the PSAP to monitor the situation, that could work for any technology, the caller simply lays the handset down without ending the call= . -Marc- >=20 >=20 > Ray=20 >=20 > [*] admittedly hearsay, but I know a man who'd know for sure, but like me= and > you he's on vacation at the moment. >=20 --B_3333460387_1970827 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Ecrit] Please respond to the Premature Disconnect HUM Ray,


    On 8/18/09 1:49 AM, "Ray.Bellis@no= minet.org.uk" <Ray.Bellis@no= minet.org.uk> wrote:

    > Waiting for the PSAP to get signalling
    > on this is a non-starter for me personally, so I see this as
    > potentially complicating the code paths for very little gain.

    As I understand it [*] s= everal lives are saved annually and prosecutions succeed because of this fun= ctionality in the PSTN.In the latter case it's = because the PSAP operator has been able to monitor and record evidence of a = crime still in progress.

    [ML]  I don’t understand how this is= accomplished if the caller placed the handset on the hookswitch.  &nbs= p;Obviously, if the caller and call-taker have agreed to allow the PSAP to m= onitor the situation,  that could work for any technology, the caller s= imply lays the handset down without ending the call.

    -Marc-


    Ray

    [*] admittedly hearsay, = but I know a man who'd know for sure, but like me and you he's on vacation a= t the moment.

    --B_3333460387_1970827-- From randy@qualcomm.com Tue Aug 18 22:06:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD603A6AF9; Tue, 18 Aug 2009 22:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.871 X-Spam-Level: X-Spam-Status: No, score=-102.871 tagged_above=-999 required=5 tests=[AWL=-1.730, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 PG5nM1vPR6ho; Tue, 18 Aug 2009 22:06:39 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 244063A68F5; Tue, 18 Aug 2009 22:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1250658404; x=1282194404; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20=20<002801ca1f6 5$e1c9fef0$2549a20a@nsnintra.net>=0D=0A=20=0D=0A=20=20=0D=0A=20|References:=20=0D=0A=20<002801ca1f65$e1c9fef0$2549a 20a@nsnintra.net>=0D=0A=20=09=0D=0A=20=20=0D=0A=20<002801ca1f65$e1c9fef0$2 549a20a@nsnintra.net>=0D=0A=20=0D=0A=20=09<002801ca1f65$e1c9fef0$2549a20a@nsnin tra.net>=0D=0A=20=0D =0A=20=0D=0A=20=09<002 801ca1f65$e1c9fef0$2549a20a@nsnintra.net>=0D=0A=20=20=0D=0A=20=0D=0A=20 =09<002801ca1f65$e1c9fef0$2549a20a@nsnintra.net>=0D=0A=20 =09=0D=0A=20=09=20|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-Note:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20Tu e,=2018=20Aug=202009=2022:00:36=20-0700|To:=20Hannes=20Ts chofenig=20,=0D=0A=20=20=20=20 =20=20=20=20"'Marc=20Linsner'"=0D=0A=09,=20"'ecrit'"=20,=0D=0A=20=20=20=20=20 =20=20=20"Reese,=20Theresa=20E"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Ted=20Hardie=20,=20|From:=20Ran dall=20Gellens=20|Subject:=20Re:=20[E crit]=20Please=20respond=20to=20the=20Premature=20Disconn ect=20HUM|CC:=20|MIME-Version:=20 1.0|Content-Type:=20text/html=3B=20charset=3D"us-ascii" |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5713"=3B=20a=3D"22316986"; bh=VSdU1nlzOPklVPh/TJcPbs7sIfaspKjuhkuxxuq728s=; b=mi8tQK1xrtqRt94X41CzgN1Sb/8uvrWhm879fxRZDyXnXeTxJCLLCERX Y2w9L81xevFPEfpiFXF84BssSPB6RB13KuSjaPdwsBFhxh6j3zzFHCcPE +qoZnZdseTH6ZjssVzn+Abuen8TQ3PvV7FQkCwdaO9uQIktvkrxfQl4C5 w=; X-IronPort-AV: E=McAfee;i="5300,2777,5713"; a="22316986" 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; 18 Aug 2009 22:06:28 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7J56SR5031520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2009 22:06:28 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7J56PG7010630 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Aug 2009 22:06:25 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 18 Aug 2009 22:06:25 -0700 Received: from [10.10.2.90] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 18 Aug 2009 22:06:24 -0700 Message-ID: In-Reply-To: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> References: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 18 Aug 2009 22:00:36 -0700 To: Hannes Tschofenig , "'Marc Linsner'" , "'ecrit'" , "Reese, Theresa E" , Ted Hardie , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 Cc: ecrit-bounces@ietf.org Subject: Re: [Ecrit] Please respond to the Premature Disconnect HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 05:06:40 -0000 Re: [Ecrit] Please respond to the Premature Disconnect HUM
    At 9:09 PM +0300 8/17/09, Hannes Tschofenig wrote:
    Do you have feedback regarding the problem statement?

    Yes.  I've sent some proposed revisions.  I intended to, but didn't actually send, comments on your proposed revision, to the effect that the text about PSAP's being signalled in the middle defeated the intent of the earlier statements about special handling by the client.


    Do you think that this is a problem worth solving in ECRIT?

    Depends on the problem statement :-)

    I think it's useful for ecrit to work on this, provided we're working on a problem that doesn't predetermine the solution, and that the solution is helpful.


    At 9:52 PM -0700 8/17/09, Ted Hardie wrote:
    The PSAP can
    *ask* for this capability during a negotiation, but they have to take
    no for an answer and it must default off.  As feedback on Brian's
    recent statement, I think this:

    >It is desirable that the PSAP be aware that the user has attempted to
    > disconnect/reconnect, and it may be useful for the PSAP to be able to
    > influence the behavior of the device.  Some form of signaling for this
    > purpose is desirable, but need not be reliable, since it is advisory.

    doesn't really jibe with where we've been going.  We've been
    talking about a case in which the user is given a cue that
    the disconnect may be premature and is given a mechanism
    to continue to disconnect.  The "double press end" view of
    things, if  you will.  Waiting for the PSAP to get signalling
    on this is a non-starter for me personally, so I see this as
    potentially complicating the code paths for very little gain.

    This is the basic disagreement that we've been struggling with.

    I think that ecrit can agree to work on a solution along the lines of what Ted suggests, and that this solution would be useful in solving the problem that Biran and Guy describe, and that this solution would still allow for further revisions in the future to give the PSAP more information about disconnection attempts.  In other words, optional signalling at call set-up seems a useful way to get a lot of the problem fixed, even if it doesn't go as far as some would prefer.  In still other words, a compromise.


    At 7:49 AM +0200 8/18/09, <Ray.Bellis@nominet.org.uk> wrote:

    > Waiting for the PSAP to get signalling
    > on this is a non-starter for me personally, so I see this as
    > potentially complicating the code paths for very little gain.

    As I understand it [*] several lives are saved annually and prosecutions succeed because of this functionality in the PSTN.

    In the latter case it's because the PSAP operator has been able to monitor and record evidence of a crime still in progress.

    As I understand it, this has been explicitly ruled out by almost everyone who has spoken on the subject.  very explicitly and many times.

    --
    Randall Gellens
    Opinions are personal;    facts are suspect;    I speak for myself only
    -------------- Randomly selected tag: ---------------
    The whole problem with the world is that fools and fanatics are always
    so certain of themselves, but wiser people so full of doubts.
                                                       --Bertrand Russell
    From fmenard@xittel.net Tue Aug 18 22:21:31 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA413A6A24 for ; Tue, 18 Aug 2009 22:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 vdL83+zrMbvU for ; Tue, 18 Aug 2009 22:21:30 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 1C7F73A6A1F for ; Tue, 18 Aug 2009 22:21:30 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MdMd9-0001F1-3a; Tue, 18 Aug 2009 07:13:31 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MdMd7-0005DB-Uf; Tue, 18 Aug 2009 07:13:31 -0400 Message-Id: From: Francois Menard To: br@brianrosen.net In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 18 Aug 2009 07:13:29 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: ecrit Subject: Re: [Ecrit] Problem statement for Premature Disconnect X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 05:21:31 -0000 I thought the consensus for many years is that when engaged into an emergency call, the PSAP would have to be the one sending a BYE and the end-user ATA would never initiate a BYE. f. On 11-Aug-09, at 5:32 PM, wrote: > Brian, > > This looks to be very useful and I'd like to add an extra dimension to > requirements please. > > One of main problems we have in answering emergency calls in UK > PSAPs is > when a caller does not answer or is incoherent at the start of a call > and then clears. The PSAP has not had time to establish whether or > not > there's a genuine emergency or whether the call is accidental or is a > result of a child "playing" with the phone (a particular issue since > we > have three digits the same with 999 as an emergency code!). If the > PSAP > is able to influence or affect the release/ending of the emergency > call > it provides an efficient way of establishing whether or not help is > required. > > This is currently achieved by setting of Last Party Release in C7 > signalling, which means a caller cannot make another call until the > PSAP > is satisfied that an emergency service is not required, usually by > caller confirming (adult finds child playing with phone or adult > realises they have misdialled) - it does not work on ISDN calls > though. > > > Thanks > > John > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: 29 July 2009 14:22 > To: ecrit@ietf.org > Subject: Re: [Ecrit] Problem statement for Premature Disconnect > > There is a small typo in this. > > The ECRIT work group would complete requirements for handling > premature > disconnect. > > Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf > >> Of Rosen, Brian >> Sent: Wednesday, July 29, 2009 5:31 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] Problem statement for Premature Disconnect >> >> I was asked to reword a problem statement on premature disconnect >> that > >> might be acceptable to begin work on, probably a design team on >> requirements. I propose: >> >> In emergency calls, people are stressed. They sometimes try to >> disconnect a call where communication between the caller and the call >> taker has begun, but before the call taker has acquired enough >> information to direct appropriate response. That circumstance is >> known as "premature disconnect". In those circumstances the device >> should behave differently. For example, the device may alert rather >> than disconnect. The behavior of the device would be UI driven, and >> thus not specifiable by the IETF, although advice might be given. >> >> Special behavior is not always desirable. For example, in high call >> volume circumstances, the call may be answered by the PSAP at an IVR, >> in which case no special behavior is desired. The device may not >> implement the specification, or for some reason, it may not be >> available for a particular emergency call. For this reason, some >> form > >> of signaling at the beginning of the call is needed to negotiate >> enabling the special behavior. >> >> It is desirable that the PSAP be aware that the user has attempted to >> disconnect/reconnect, and it may be useful for the PSAP to be able to >> influence the behavior of the device. Some form of signaling for >> this > >> purpose is desirable, but need not be reliable, since it is advisory. >> >> In all circumstances the user must maintain control of his device, >> and > >> it must be possible for the user to take some action to complete a >> disconnect. >> >> The geopriv work group would complete requirements for handling >> premature disconnect. Some of the resulting protocol work may need >> to > >> be accomplished in other RAI work groups. >> _______________________________________________ >> 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 Francois Menard fmenard@xittel.net From hannes.tschofenig@nsn.com Tue Aug 18 22:45:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776A23A6AF9 for ; Tue, 18 Aug 2009 22:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-0.652, 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 Z4GHG7Uu5wmU for ; Tue, 18 Aug 2009 22:45:21 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D613A3A67F7 for ; Tue, 18 Aug 2009 22:45:20 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7J5iOF8007810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Aug 2009 07:44:24 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7J5iMuc031864; Wed, 19 Aug 2009 07:44:24 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 07:44:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 08:46:59 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019A2680@FIESEXC015.nsn-intra.net> In-Reply-To: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DEADLINE FOR ECRIT Rechartering & Milestone Update Thread-Index: AcofaNVmS+J52KuCR+CYKGKdKpDamwBJ2yTA References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Hannes Tschofenig" , "ecrit" X-OriginalArrivalTime: 19 Aug 2009 05:44:22.0449 (UTC) FILETIME=[1A714210:01CA2090] Subject: [Ecrit] DEADLINE FOR ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 05:45:22 -0000 I forgot to indicate a deadline.=20 Let's pick September 2nd.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Hannes Tschofenig >Sent: 17 August, 2009 21:31 >To: 'ecrit' >Subject: [Ecrit] ECRIT Rechartering & Milestone Update > >Hi all,=20 > >please let us know if there is something incorrect or missing=20 >with the proposal for the new charter & milestones.=20 > >Ciao >Hannes & Marc > >---------------- > >Emergency Context Resolution with Internet Technologies (ecrit) > >Description of Working Group: > >In a number of areas, the public switched telephone network=20 >(PSTN) has been configured to recognize an explicitly=20 >specified number (commonly one that is short and easily=20 >memorized) as a call for emergency services. These numbers=20 >(e.g. 911, 112) relate to an emergency service context and=20 >depend on a broad, regional configuration of service contact=20 >methods and a geographically-constrained context of service=20 >delivery. These calls are intended to be delivered to special=20 >call centers equipped to manage emergency response. Successful=20 >delivery of an emergency service call within those systems=20 >requires both an association of the physical location of the=20 >originator with an appropriate emergency service center and=20 >call routing to deliver the call to the center. > >Calls placed using Internet technologies do not use the same=20 >systems to achieve those goals, and the common use of overlay=20 >networks and tunnels (either as VPNs or for mobility) makes=20 >meeting them more challenging. There are, however, Internet=20 >technologies available to describe location and to manage call=20 >routing. This working group will describe when these may be=20 >appropriate and how they may be used. >Explicitly outside the scope of this group is the question of=20 >pre-emption or prioritization of emergency services traffic.=20 >This group is considering emergency services calls which might=20 >be made by any user of the Internet, as opposed to government=20 >or military services that may impose very different=20 >authentication and routing requirements. > >The group will maintain and extend the Location to Service Translation >(LoST) protocol for emergency services related aspects but=20 >also for usage outside the emergency services context.=20 >Additionally, the group is chartered to work on descriptions=20 >and extensions regarding citizen-to-authority services (such=20 >as defining a Resource Priority header for usage with=20 >emergency services).=20 > >While this group anticipates a close working relationship with=20 >groups, such as NENA and ETSI EMTEL, any solution presented=20 >must be useful regardless of jurisdiction, and it must be=20 >possible to use without a single, central authority. Further,=20 >it must be possible for multiple delegations within a=20 >jurisdiction to be handled independently, as call routing for=20 >specific emergency types may be independent. > >This working group cares about privacy and security concerns,=20 >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=20 >Informational RFC=20 > >Done Submit "Security Threats and Requirements for Emergency Call >Marking and Mapping" to the IESG for consideration as an=20 >Informational RFC > >Done Submit "A Uniform Resource Name (URN) for Emergency and Other >Well-Known Services" to the IESG for consideration as a=20 >Standards Track RFC=20 > >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=20 >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 > >Done Submit "Best Current Practice for Communications Services=20 >in support of Emergency Calling" to the IESG for consideration=20 >as a BCP RFC > >Done Submit "Framework for Emergency Calling using Internet=20 >Multimedia" to the IESG for consideration as a Standards Track RFC > >Aug 2009 Submit "Synchronizing Location-to-Service Translation=20 >(LoST) Servers" to the IESG for consideration as a Standards Track RFC > >Sep 2009 Submit "IANA Registering a SIP RPH Namespace for=20 >Local Emergency Communications" to the IESG for consideration=20 >as a Standards Track RFC > >Oct 2009 Submit "LoST ServiceListBoundary Extension" to the=20 >IESG for consideration as an Experimental RFC=20 > >Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as=20 >a Standards Track RFC > >Dec 2009 Submit "Location-to-Service Translation Protocol=20 >(LoST) Extensions" to the IESG for consideration as an=20 >Informational RFC > >Feb 2010 Submit "Using Imprecise Location for Emergency=20 >Context Resolution" to the IESG for consideration as an=20 >Informational RFC > >Mar 2010 Submit "Marking of Calls initiated by Public Safety=20 >Answering Points (PSAPs)" to the IESG for consideration as an=20 >Informational RFC > >Apr 2010 Submit "Emergency Services Architecture Extensions=20 >for Unauthenticated and Unauthorized Devices" to the IESG for=20 >consideration as an Experimental RFC > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Tue Aug 18 23:00:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A943A68D1 for ; Tue, 18 Aug 2009 23:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.836, 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 S6pRWKaWUTMf for ; Tue, 18 Aug 2009 23:00:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6E13E3A67F7 for ; Tue, 18 Aug 2009 23:00:24 -0700 (PDT) Received: (qmail invoked by alias); 19 Aug 2009 05:59:30 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp045) with SMTP; 19 Aug 2009 07:59:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+sc9VMCc2sf5C9oU1kdiStbv3dhPc0zJ9EFaYFap C3uLMoRN+6Hme0 From: "Hannes Tschofenig" To: "'James M. Polk'" , "'ecrit'" References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> <005501ca2023$b819c040$8e01fe0a@nsnintra.net> Date: Wed, 19 Aug 2009 09:02:07 +0300 Message-ID: <006f01ca2092$962cc170$8e01fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcogJo4ytxyKGXkSRs6s75pi+iEUxwAAQIZw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 06:00:26 -0000 Hi James, >>RFC 5031bis refers to this document: >>http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy-00.txt >> >>We discussed the requirements for some time and now there is also a >>document available. > >I knew about this doc, but didn't understand this is being >talked about as a formal "bis" ID (i.e., that it would >obsolete 5031). If that's the case (which I think you just >said it is), then shouldn't the filename change to > > draft-forte-ecrit-5031bis-00.txt Good point. This document actually only updates RFC 5031. It does not replace it. So, we shouldn't really call it -bis. Ciao Hannes From robinsg@huawei.com Tue Aug 18 23:27:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7CC3A684B for ; Tue, 18 Aug 2009 23:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTiBflw3A3J6 for ; Tue, 18 Aug 2009 23:27:51 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 473E63A677D for ; Tue, 18 Aug 2009 23:27:51 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOM00H7O1EOBE@szxga01-in.huawei.com> for ecrit@ietf.org; Wed, 19 Aug 2009 14:16:01 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOM00L4R1EOTV@szxga01-in.huawei.com> for ecrit@ietf.org; Wed, 19 Aug 2009 14:16:00 +0800 (CST) Received: from [10.85.203.7] by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOM008EF1EO0P@szxml04-in.huawei.com> for ecrit@ietf.org; Wed, 19 Aug 2009 14:16:00 +0800 (CST) Date: Wed, 19 Aug 2009 14:15:59 +0800 From: Robins George In-reply-to: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> To: Hannes Tschofenig Message-id: <4A8B989F.20502@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> Cc: 'ecrit' Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 06:27:52 -0000 Hannes, > Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a > Standards Track RFC > > Dec 2009 Submit "Location-to-Service Translation Protocol (LoST) > Extensions" to the IESG for consideration as an Informational RFC > > Did you skip the shelter draft ? http://tools.ietf.org/html/draft-sun-ecrit-shelter-service-02 -- Robins From Hannes.Tschofenig@gmx.net Tue Aug 18 23:28:03 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC2A3A6A1F for ; Tue, 18 Aug 2009 23:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQn+uR4m5C6r for ; Tue, 18 Aug 2009 23:28:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2D7B73A684B for ; Tue, 18 Aug 2009 23:28:02 -0700 (PDT) Received: (qmail invoked by alias); 19 Aug 2009 06:18:27 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp013) with SMTP; 19 Aug 2009 08:18:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18fMvZo7uwfLsToNQrbbU+1dxSX23wjbLayv5I64o uowQroqjojV6AD From: "Hannes Tschofenig" To: "'Andrew Newton'" References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> Date: Wed, 19 Aug 2009 09:21:02 +0300 Message-ID: <007b01ca2095$3bb3de60$8e01fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcogKgBYS5CrHg6+Stertux3aScqMAAaNVlw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 06:28:04 -0000 Hi Andy, >Well... I guess... kinda. > >I'm not sure why it simply wouldn't look like a normal > element complete with the set and the normal >display name. What URI would you set there? The mapping points to the boundary that is covered by a LoST server rather than a PSAP. > >If the intent is to sync the mappings, you shouldn't really >need to change a thing. This is a terminology issue. The document tries to provide the necessary functionality to get the "mapping architecture" to work. It would also be possible for the FG to always collect all the mappings from the LoST servers it controls. Then, the above-mentioned case would not show up. If the intent is for one server to >tell another that it is authoritative for an area, that's not >really syncing so much as plain configuration -- and I'm not >sure you want to do that in a protocol. Why not? Yet another protocol to exchange mappings? > After all, the US >forest guide isn't simply gonna take all service boundaries >from lost.kaernten.example, as kaernten could claim a larger >area than it really is responsible for -- a possible attach >vector at worst, an opportunity for a grand screw up at best. Correct. It was just an example to illustrate what I meant. Austria is obviously too small to justify LoST servers for each state. > >At least that's how this strikes me. Ciao Hannes > >-andy > >On Aug 18, 2009, at 1:11 PM, Hannes Tschofenig wrote: > >> Thanks for the suggestion. The proposal sounds indeed fairly >good (and >> simple). >> >> Here is an example of how this could look like for mapping data used >> by an Austrian Forest Guide (FG). For this example I assumed >that each >> state runs an independent LoST server and the FG would contain >> pointers to these LoST servers. I illustrated two such >mappings below: >> >> > expires="2009-01-01T01:44:33Z" >> lastUpdated="2009-12-01T01:00:00Z" >> source="lost.kaernten.example" >> sourceId="e8b05a41d8d1415b80f2cdbb96ccf109"> >> >> Kaernten LoST Server >> >> urn:service:sos >> > profile="civic"> >> > xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> AT >> Kaernten >> >> >> >> 112 >> >> >> > expires="2009-01-01T01:44:33Z" >> lastUpdated="2009-12-01T01:00:00Z" >> source="lost.wien.example" >> sourceId="e8b05a41d8d1415b80f2cdbb96ccf109"> >> >> LoST Server Wien >> >> urn:service:sos >> > profile="civic"> >> > xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> AT >> Wien >> >> >> >> 112 >> >> >> >> Thoughts? >> >> Ciao >> Hannes >> >> >> >>> -----Original Message----- >>> From: ext Andrew Newton [mailto:andy@hxr.us] >>> Sent: 17 August, 2009 22:27 >>> To: Tschofenig, Hannes (NSN - FI/Espoo) >>> Cc: ext Karl Heinz Wolf; ECRIT >>> Subject: Re: [Ecrit] LoST Sync Draft Update >>> >>> I think you could safely and naturally run the U-NAPTR process >>> against the contents of the element to get what >you need. A >>> LOST URL scheme is not needed, and would have implications on tools >>> that are fed them. >>> >>> -andy >>> >>> On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) >>> wrote: >>> >>>> Hi Karl Heinz, >>>> Hi all, >>>> >>>> Thanks for this question. >>>> >>>> To provide a bit of background to your question let us take an >>>> example provided in >>>> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >>>> >>>> On page 10 an example of mappings stored at a server are outlined: >>>> >>>> country A1 A2 A3 resource or LoST server >>>> US NJ Bergen Leonia sip:psap@leonianj.gov >>>> US NJ Bergen Fort Lee sip:emergency@fortleenj.org >>>> US NJ Bergen Teaneck sip:police@teanecknjgov.org >>>> US NJ Bergen Englewood englewoodnj.gov >>>> >>>> In this case, the first three mappings point to PSAPs (or >>> ESRPs; one >>>> cannot differentiate based on the mapping data). The final >mapping, >>>> however, points to a LoST server. >>>> >>>> So, element of the element accepts only URIs. The >>>> output of the U-NAPTR process (described in Section 4 of >>> http://www.ietf.org/rfc/rfc5222.txt) >>>> leads to a HTTP/HTTPS URI. >>>> >>>> So, the URI that is associated with the boundary is using a >>> HTTP and >>>> HTTPS URL scheme. >>>> The input unfortunatley isn't; it is just a DNS name. >>>> >>>> In earlier versions of the LoST specifications we defined >a new URI >>>> scheme (namely lost://) but later removed it. As such, there is no >>>> LoST URI to put into the element. >>>> >>>> So, do we have a problem here? >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: I have to check what the implementers have implemented here. >>>> >>>>> Hannes, >>>>> >>>>> some time ago I asked you about lost-sync and the pushing of >>>>> coverage regions up a tree. >>>>> Pushing of coverage regions is mentioned in the introduction, but >>>>> all the examples show complete mappings. >>>>> So I wonder if you assume LoST URIs to be placed in the URI >>>>> elements of the mappings to indicate that this is not a >mapping but >>>>> rather a coverage region in the boundary? >>>>> >>>>> cheers >>>>> karl heinz >>>>> >>>>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - >>>>> FI/Espoo) wrote: >>>>>> Hi all, >>>>>> >>>>>> I asked Roger to submit the PROTO writeup for the LoST >sync draft >>>>>> after we got further confirmation from the implementers team. >>>>>> Then, >>>>>> Roger pointed me to the review by Richard and I have to >say that I >>>>>> must have missed it. Here are Richards review comments: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>>>> >>>>>> My response is inline: >>>>>> >>>>>> I reviewed lost-sync-04 in order to update my earlier >>>>> comments on -01. >>>>>> This version is much improved from the previous versions >>> in terms of >>>>>> specificity (although it's still vague in places). It still >>>>> seems to >>>>>> me that there are a few layers of detail missing. Specific >>>>> comments below. >>>>>> --Richard >>>>>> >>>>>> 1. The document describes transactions for requesting and >>> delivering >>>>>> mapping structures, but doesn't describe at all how these >>>>> transactions >>>>>> create a synchronization system. There is clearly some tracking >>>>>> of state needed (especially for "pushMappings"), and the >document >>>>>> is silent on how this state is initially established and then >>>>> maintained. >>>>>> >>>>>> [Hannes] I added text throught the document to address this >>>>>> comments. >>>>>> In particular I point to the need to keep state and also >>> to the fact >>>>>> that the document relies on manual configuration for setting up >>>>>> the >>>>>> "peering" between the two nodes. >>>>>> >>>>>> 2. In a similar vein, it would be helpful for this document to >>>>>> have >>>>>> some discussion of how this synchronization system relates >>> to others >>>>>> that are out there (e.g., rsync). Since the name of the draft is >>>>>> "synchronization", there should be some discussion of how >>>>>> bidirectional sync is handled. >>>>>> >>>>>> [Hannes] We had a discussion about this topic at the >>> interim meeting >>>>>> and "downgraded" the document to an Experimental status to avoid >>>>>> having to Analyse all available replication mechanisms. >>>>>> >>>>>> 3. It seems like there should really be only 3 message types here >>>>>> instead of 4: (1) a "syncRequest" message sent from >destination to >>>>>> source (getMappingsRequest), (2) a "syncUpdate" message sent from >>>>>> source to destination (getMappingsResponse == >>>>>> pushMappingsRequest), >>>>>> and (3) a "syncResult" message sent from destination to source >>>>>> (pushMappingsResponse). There can still be two types of >>>>> transaction, >>>>>> but they're determined by which type of message (syncRequest or >>>>>> syncUpdate) is sent in the HTTP request. >>>>>> >>>>>> [Hannes] We got similar feedback from the implementers. >>>>> However, in a >>>>>> subsequent discussion with them it turned out that this change is >>>>>> rather a matter of style than anything technical. A change in the >>>>>> description along the lines as you suggested (and as they had >>>>>> suggested) as well only impacts the writing style of the >>>>> document and >>>>>> not really the implementation as such. Hence, I left the >>>>> document as is. >>>>>> >>>>>> 4. In a similar vein to 2 and 3, the use of "client" and >>> "server" is >>>>>> confusing. I would suggest using more appropriate names >for these >>>>>> roles like "source" and "destination", along with some text that >>>>>> explains how these roles map to HTTP roles in each type of >>>>> transaction. >>>>>> >>>>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >>> changed the >>>>>> terminology in the document to reflect the source / >>>>> destination terminology. >>>>>> I hope it improved readability. >>>>>> >>>>>> 5. My comment about the security considerations has not been >>>>> addressed. >>>>>> The security considerations section is essentially a >>>>> pointer to LoST, >>>>>> but this protocol is only peripherally related to LoST (at a >>>>> technical >>>>>> level). Since it's about synchronization, I would expect this >>>>>> document to note that the primary risk is the injection of false >>>>>> location information (since the mappings themselves are >>>>> public), which >>>>>> means that the parties should use HTTPS to carry the XML, >>>>> authenticate >>>>>> the source, and use a ciphersuite that provides integrity >>>>> protection to messages. >>>>>> >>>>>> [Hannes] You are certainly right with this comment. I >>>>> changed the text. >>>>>> >>>>>> Here is the updated document: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>>>>> sync-07.txt >>>>>> >>>>>> 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 Hannes.Tschofenig@gmx.net Tue Aug 18 23:47:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E9B3A6AA8 for ; Tue, 18 Aug 2009 23:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.732, 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 0N2ZzFDoaIwh for ; Tue, 18 Aug 2009 23:47:58 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0575E3A694F for ; Tue, 18 Aug 2009 23:47:57 -0700 (PDT) Received: (qmail invoked by alias); 19 Aug 2009 06:20:21 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp020) with SMTP; 19 Aug 2009 08:20:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18d1ucNiPUdZi2rrlvm8oeFiYc45QKVfhxfpSW4pH WPGZJyK+mb5TYh From: "Hannes Tschofenig" To: References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> <4A8B989F.20502@huawei.com> Date: Wed, 19 Aug 2009 09:22:57 +0300 Message-ID: <007c01ca2095$7f55dd30$8e01fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoglIfaAcR6uTWQSwCDy6ZSpN2gngAANd2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A8B989F.20502@huawei.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: 'ecrit' Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 06:47:59 -0000 Nope, I did not. Per discussion some time ago the idea was to change the Service URN allocation policy and to have documents like this to be submitted to the RFC Editor. >-----Original Message----- >From: Robins George [mailto:robinsg@huawei.com] >Sent: 19 August, 2009 09:16 >To: Hannes Tschofenig >Cc: 'ecrit' >Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update > >Hannes, > >> Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a >> Standards Track RFC >> >> Dec 2009 Submit "Location-to-Service Translation Protocol (LoST) >> Extensions" to the IESG for consideration as an Informational RFC >> >> >Did you skip the shelter draft ? >http://tools.ietf.org/html/draft-sun-ecrit-shelter-service-02 > > >-- Robins > > > From robinsg@huawei.com Wed Aug 19 01:55:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D993A6BA7 for ; Wed, 19 Aug 2009 01:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQpFVD-ftAt6 for ; Wed, 19 Aug 2009 01:55:45 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id F16CE3A69A6 for ; Wed, 19 Aug 2009 01:55:44 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOM00H5R8PW55@szxga03-in.huawei.com> for ecrit@ietf.org; Wed, 19 Aug 2009 16:53:56 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOM00KFA8PVOD@szxga03-in.huawei.com> for ecrit@ietf.org; Wed, 19 Aug 2009 16:53:55 +0800 (CST) Received: from [10.85.203.7] by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOM00ETV8PVU8@szxml04-in.huawei.com> for ecrit@ietf.org; Wed, 19 Aug 2009 16:53:55 +0800 (CST) Date: Wed, 19 Aug 2009 16:53:54 +0800 From: Robins George In-reply-to: <007c01ca2095$7f55dd30$8e01fe0a@nsnintra.net> To: Hannes Tschofenig Message-id: <4A8BBDA2.2050701@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net> <4A8B989F.20502@huawei.com> <007c01ca2095$7f55dd30$8e01fe0a@nsnintra.net> Cc: 'ecrit' Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 08:55:45 -0000 Hannes, Thanks for the clarification. I would like to know, when can we submit this draft to RFC Editor ? -- Robins > Nope, I did not. > > Per discussion some time ago the idea was to change the Service URN > allocation policy and to have documents like this to be submitted to the RFC > Editor. > > >> -----Original Message----- >> From: Robins George [mailto:robinsg@huawei.com] >> Sent: 19 August, 2009 09:16 >> To: Hannes Tschofenig >> Cc: 'ecrit' >> Subject: Re: [Ecrit] ECRIT Rechartering& Milestone Update >> >> Hannes, >> >> >>> Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a >>> Standards Track RFC >>> >>> Dec 2009 Submit "Location-to-Service Translation Protocol (LoST) >>> Extensions" to the IESG for consideration as an Informational RFC >>> >>> >>> >> Did you skip the shelter draft ? >> http://tools.ietf.org/html/draft-sun-ecrit-shelter-service-02 >> >> >> -- Robins >> >> >> >> > > From john.elwell@siemens-enterprise.com Wed Aug 19 09:57:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B623A6A48 for ; Wed, 19 Aug 2009 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.682 X-Spam-Level: X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpNCi9unNXjA for ; Wed, 19 Aug 2009 09:57:14 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id C62EA3A698D for ; Wed, 19 Aug 2009 09:57:14 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KOM00762V3I0H@siemenscomms.co.uk> for ecrit@ietf.org; Wed, 19 Aug 2009 17:57:18 +0100 (BST) Date: Wed, 19 Aug 2009 17:57:17 +0100 From: "Elwell, John" To: ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00249B512@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Ecma-International work on emergency calls in enterprise networks Thread-Index: Acog7hwZDo21zJa1SqekFqluS72/Og== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "Theis, Harald \(Harald\)" , John Fenn , "Hammer, Bernard" , "Vautz, Rolf \(Rolf\)" , "Dietz, J.B. \(Jan\)" Subject: [Ecrit] Ecma-International work on emergency calls in enterprise networks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 16:57:15 -0000 As part of its work on enterprise networks under the name Next Generation Corporate Networks (NGCN), including interoperation with NGN, Ecma-International has carried out investigations into emergency calling in enterprise networks, and a near-final draft of the resulting Technical Report is available here: http://www.ecma-international.org/activities/Communications/9th%20draft% 20TRNGCN%20Emergency%20calls.pdf The report draws heavily on the work of ECRIT. Any comments on the draft would be appreciated. We hope to finalise it during the second half of September. John From khwolf1@gmail.com Thu Aug 20 00:09:29 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617D83A6B9B for ; Thu, 20 Aug 2009 00:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKJmENKyk9-M for ; Thu, 20 Aug 2009 00:09:28 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 268653A69F8 for ; Thu, 20 Aug 2009 00:08:52 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so872251fga.18 for ; Thu, 20 Aug 2009 00:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TDTubw9JfXpn0xrJFlz4KLL3z7tlFlqPgPaApNPnenU=; b=sFXQxsAAUrtJs8PTn09bkuQw71RbW9qLBc2K0f8v3XbjGte8TOq2Hk8/Usy+aeo56h VZq8ZK1FMj470n3tISX3kW8QIZGfE1qenxzaIunjNwjj4vu+MEy0eb4JEfcIIrUmeLZL tqcbEqM6QiVWHfF2/a1Y8F+M39+nb+ekoQkmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EhPa2KeyFhP29HJMr5NkTXJKZVllLDiztUdjL7ICOaRG3JfvicgAVniSWGfyxrLLcm 68KidTxWzReitQeaek1YYcD/2/WKXQgAvEgVZfn7hcUN02U22pNPpUMmpD5vB1khUPMl 6rjrWVHTH5WBP5YLpg+h5nYy8yM4gWYYxgQrQ= MIME-Version: 1.0 Received: by 10.86.18.34 with SMTP id 34mr4913005fgr.2.1250752132162; Thu, 20 Aug 2009 00:08:52 -0700 (PDT) In-Reply-To: <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> Date: Thu, 20 Aug 2009 09:08:52 +0200 Message-ID: From: Karl Heinz Wolf To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 07:09:29 -0000 Hannes, this seems to be a possible solution. I would also skip the serviceNumber element in the examples since it is not necessary for the FG to know them - just the coverage region is of interest. In your examples, would the LoST server also be authoritative for possible subservices? karl heinz On Tue, Aug 18, 2009 at 7:11 PM, Hannes Tschofenig wrote: > Thanks for the suggestion. The proposal sounds indeed fairly good (and > simple). > > Here is an example of how this could look like for mapping data used by a= n > Austrian Forest Guide (FG). For this example I assumed that each state ru= ns > an independent LoST server and the FG would contain pointers to these LoS= T > servers. I illustrated two such mappings below: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" > =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" > =A0 =A0 =A0 =A0source=3D"lost.kaernten.example" > =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0Kaernten LoST Server > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0urn:service:sos > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0profile=3D"civic"> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civ= icAddr"> > =A0 =A0 =A0 =A0 =A0 =A0AT > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kaernten > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0112 > =A0 =A0 =A0 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" > =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" > =A0 =A0 =A0 =A0source=3D"lost.wien.example" > =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0LoST Server Wien > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0urn:service:sos > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0profile=3D"civic"> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civ= icAddr"> > =A0 =A0 =A0 =A0 =A0 =A0AT > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wien > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0112 > =A0 =A0 =A0 > > > Thoughts? > > Ciao > Hannes > > > >>-----Original Message----- >>From: ext Andrew Newton [mailto:andy@hxr.us] >>Sent: 17 August, 2009 22:27 >>To: Tschofenig, Hannes (NSN - FI/Espoo) >>Cc: ext Karl Heinz Wolf; ECRIT >>Subject: Re: [Ecrit] LoST Sync Draft Update >> >>I think you could safely and naturally run the U-NAPTR process >>against the contents of the element to get what you >>need. =A0A LOST URL scheme is not needed, and would have >>implications on tools that are fed them. >> >>-andy >> >>On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >>> Hi Karl Heinz, >>> Hi all, >>> >>> Thanks for this question. >>> >>> To provide a bit of background to your question let us take an >>> example provided in >>> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >>> >>> On page 10 an example of mappings stored at a server are outlined: >>> >>> =A0 country =A0 A1 A2 =A0 =A0 =A0 =A0 A3 =A0 =A0 =A0 =A0resource or LoS= T server >>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Leonia =A0 =A0sip:psap@leonianj= .gov >>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Fort Lee =A0sip:emergency@fortl= eenj.org >>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Teaneck =A0 sip:police@teaneckn= jgov.org >>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Englewood englewoodnj.gov >>> >>> In this case, the first three mappings point to PSAPs (or >>ESRPs; one >>> cannot differentiate based on the mapping data). The final mapping, >>> however, points to a LoST server. >>> >>> So, element of the element accepts only URIs. The >>> output of the U-NAPTR process (described in Section 4 of >>http://www.ietf.org/rfc/rfc5222.txt) >>> =A0leads to a HTTP/HTTPS URI. >>> >>> So, the URI that is associated with the boundary is using a >>HTTP and >>> HTTPS URL scheme. >>> The input unfortunatley isn't; it is just a DNS name. >>> >>> In earlier versions of the LoST specifications we defined a new URI >>> scheme (namely lost://) but later removed it. As such, there is no >>> LoST URI to put into the element. >>> >>> So, do we have a problem here? >>> >>> Ciao >>> Hannes >>> >>> PS: I have to check what the implementers have implemented here. >>> >>>> Hannes, >>>> >>>> some time ago I asked you about lost-sync and the pushing of >>>> coverage regions up a tree. >>>> Pushing of coverage regions is mentioned in the introduction, >>>> but all the examples show complete mappings. >>>> So I wonder if you assume LoST URIs to be placed in the URI >>>> elements of the mappings to indicate that this is not a >>>> mapping but rather a coverage region in the boundary? >>>> >>>> cheers >>>> karl heinz >>>> >>>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - >>>> FI/Espoo) wrote: >>>>> Hi all, >>>>> >>>>> I asked Roger to submit the PROTO writeup for the LoST sync draft >>>>> after we got further confirmation from the implementers team. Then, >>>>> Roger pointed me to the review by Richard and I have to say that I >>>>> must have missed it. Here are Richards review comments: >>>>> >>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>>> >>>>> My response is inline: >>>>> >>>>> I reviewed lost-sync-04 in order to update my earlier >>>> comments on -01. >>>>> This version is much improved from the previous versions >>in terms of >>>>> specificity (although it's still vague in places). =A0It still >>>> seems to >>>>> me that there are a few layers of detail missing. =A0Specific >>>> comments below. >>>>> --Richard >>>>> >>>>> 1. The document describes transactions for requesting and >>delivering >>>>> mapping structures, but doesn't describe at all how these >>>> transactions >>>>> create a synchronization system. =A0There is clearly some tracking of >>>>> state needed (especially for "pushMappings"), and the document is >>>>> silent on how this state is initially established and then >>>> maintained. >>>>> >>>>> [Hannes] I added text throught the document to address this >>>>> comments. >>>>> In particular I point to the need to keep state and also >>to the fact >>>>> that the document relies on manual configuration for setting up the >>>>> "peering" between the two nodes. >>>>> >>>>> 2. In a similar vein, it would be helpful for this document to have >>>>> some discussion of how this synchronization system relates >>to others >>>>> that are out there (e.g., rsync). =A0Since the name of the draft is >>>>> "synchronization", there should be some discussion of how >>>>> bidirectional sync is handled. >>>>> >>>>> [Hannes] We had a discussion about this topic at the >>interim meeting >>>>> and "downgraded" the document to an Experimental status to avoid >>>>> having to Analyse all available replication mechanisms. >>>>> >>>>> 3. It seems like there should really be only 3 message types here >>>>> instead of 4: (1) a "syncRequest" message sent from destination to >>>>> source (getMappingsRequest), (2) a "syncUpdate" message sent from >>>>> source to destination (getMappingsResponse =3D=3D pushMappingsRequest= ), >>>>> and (3) a "syncResult" message sent from destination to source >>>>> (pushMappingsResponse). =A0There can still be two types of >>>> transaction, >>>>> but they're determined by which type of message (syncRequest or >>>>> syncUpdate) is sent in the HTTP request. >>>>> >>>>> [Hannes] We got similar feedback from the implementers. >>>> However, in a >>>>> subsequent discussion with them it turned out that this change is >>>>> rather a matter of style than anything technical. A change in the >>>>> description along the lines as you suggested (and as they had >>>>> suggested) as well only impacts the writing style of the >>>> document and >>>>> not really the implementation as such. Hence, I left the >>>> document as is. >>>>> >>>>> 4. In a similar vein to 2 and 3, the use of "client" and >>"server" is >>>>> confusing. =A0I would suggest using more appropriate names for these >>>>> roles like "source" and "destination", along with some text that >>>>> explains how these roles map to HTTP roles in each type of >>>> transaction. >>>>> >>>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >>changed the >>>>> terminology in the document to reflect the source / >>>> destination terminology. >>>>> I hope it improved readability. >>>>> >>>>> 5. My comment about the security considerations has not been >>>> addressed. >>>>> =A0The security considerations section is essentially a >>>> pointer to LoST, >>>>> but this protocol is only peripherally related to LoST (at a >>>> technical >>>>> level). =A0Since it's about synchronization, I would expect this >>>>> document to note that the primary risk is the injection of false >>>>> location information (since the mappings themselves are >>>> public), which >>>>> means that the parties should use HTTPS to carry the XML, >>>> authenticate >>>>> the source, and use a ciphersuite that provides integrity >>>> protection to messages. >>>>> >>>>> [Hannes] You are certainly right with this comment. I >>>> changed the text. >>>>> >>>>> Here is the updated document: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>>>> sync-07.txt >>>>> >>>>> 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 Hannes.Tschofenig@gmx.net Thu Aug 20 00:47:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B562B3A67EF for ; Thu, 20 Aug 2009 00:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLZVL5b05O1Q for ; Thu, 20 Aug 2009 00:47:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0CBA73A6D0C for ; Thu, 20 Aug 2009 00:47:43 -0700 (PDT) Received: (qmail invoked by alias); 20 Aug 2009 07:47:48 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp002) with SMTP; 20 Aug 2009 09:47:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+FB10M01aFu13n65YP6yN/u6Z9MGUA4yJN041HjU Rk5L8K1DcsqKSP From: "Hannes Tschofenig" To: "'Karl Heinz Wolf'" References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> Date: Thu, 20 Aug 2009 10:50:24 +0300 Message-ID: <004501ca216a$e18a07d0$035ca20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcohZRKLvjMAULQmS7Ky18ydpFgZ4gABFQ8w X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 07:47:45 -0000 Hi Karl Heinz,=20 >Hannes, >this seems to be a possible solution. I would also skip the=20 >serviceNumber element in the examples since it is not=20 >necessary for the FG to know them - just the coverage region=20 >is of interest. You are correct that I could omit the element.=20 (In fact I can also omit the element as well instead of having it empty.) >In your examples, would the LoST server also be authoritative=20 >for possible subservices? Your question is whether the "Kaernten" LoST server in the example below would also be hosting entries for urn:service:sos.police etc?=20 Ciao Hannes >karl heinz > >On Tue, Aug 18, 2009 at 7:11 PM, Hannes >Tschofenig wrote: >> Thanks for the suggestion. The proposal sounds indeed fairly=20 >good (and=20 >> simple). >> >> Here is an example of how this could look like for mapping data used=20 >> by an Austrian Forest Guide (FG). For this example I assumed=20 >that each=20 >> state runs an independent LoST server and the FG would contain=20 >> pointers to these LoST servers. I illustrated two such=20 >mappings below: >> >> =A0 =A0 =A0> =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" >> =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" >> =A0 =A0 =A0 =A0source=3D"lost.kaernten.example" >> =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0Kaernten LoST Server >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0urn:service:sos >> =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0 =A0profile=3D"civic"> >> =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0 =A0 = =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> =A0 =A0 =A0 =A0 =A0 =A0AT >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kaernten >> =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0112 >> =A0 =A0 =A0 >> >> =A0 =A0 =A0> =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" >> =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" >> =A0 =A0 =A0 =A0source=3D"lost.wien.example" >> =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0LoST Server Wien >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0urn:service:sos >> =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0 =A0profile=3D"civic"> >> =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0 =A0 = =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> =A0 =A0 =A0 =A0 =A0 =A0AT >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wien >> =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0112 >> =A0 =A0 =A0 >> >> >> Thoughts? >> >> Ciao >> Hannes >> >> >> >>>-----Original Message----- >>>From: ext Andrew Newton [mailto:andy@hxr.us] >>>Sent: 17 August, 2009 22:27 >>>To: Tschofenig, Hannes (NSN - FI/Espoo) >>>Cc: ext Karl Heinz Wolf; ECRIT >>>Subject: Re: [Ecrit] LoST Sync Draft Update >>> >>>I think you could safely and naturally run the U-NAPTR=20 >process against=20 >>>the contents of the element to get what you need. =A0 >A LOST URL=20 >>>scheme is not needed, and would have implications on tools that are=20 >>>fed them. >>> >>>-andy >>> >>>On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN -=20 >FI/Espoo) wrote: >>> >>>> Hi Karl Heinz, >>>> Hi all, >>>> >>>> Thanks for this question. >>>> >>>> To provide a bit of background to your question let us take an=20 >>>> example provided in=20 >>>> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >>>> >>>> On page 10 an example of mappings stored at a server are outlined: >>>> >>>> =A0 country =A0 A1 A2 =A0 =A0 =A0 =A0 A3 =A0 =A0 =A0 =A0resource or = LoST server >>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Leonia =A0 = =A0sip:psap@leonianj.gov >>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Fort Lee = =A0sip:emergency@fortleenj.org >>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Teaneck =A0 = sip:police@teanecknjgov.org >>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Englewood englewoodnj.gov >>>> >>>> In this case, the first three mappings point to PSAPs (or >>>ESRPs; one >>>> cannot differentiate based on the mapping data). The final=20 >mapping,=20 >>>> however, points to a LoST server. >>>> >>>> So, element of the element accepts only URIs. The=20 >>>> output of the U-NAPTR process (described in Section 4 of >>>http://www.ietf.org/rfc/rfc5222.txt) >>>> =A0leads to a HTTP/HTTPS URI. >>>> >>>> So, the URI that is associated with the boundary is using a >>>HTTP and >>>> HTTPS URL scheme. >>>> The input unfortunatley isn't; it is just a DNS name. >>>> >>>> In earlier versions of the LoST specifications we defined=20 >a new URI=20 >>>> scheme (namely lost://) but later removed it. As such, there is no=20 >>>> LoST URI to put into the element. >>>> >>>> So, do we have a problem here? >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: I have to check what the implementers have implemented here. >>>> >>>>> Hannes, >>>>> >>>>> some time ago I asked you about lost-sync and the pushing of=20 >>>>> coverage regions up a tree. >>>>> Pushing of coverage regions is mentioned in the introduction, but=20 >>>>> all the examples show complete mappings. >>>>> So I wonder if you assume LoST URIs to be placed in the URI=20 >>>>> elements of the mappings to indicate that this is not a=20 >mapping but=20 >>>>> rather a coverage region in the boundary? >>>>> >>>>> cheers >>>>> karl heinz >>>>> >>>>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN -=20 >>>>> FI/Espoo) wrote: >>>>>> Hi all, >>>>>> >>>>>> I asked Roger to submit the PROTO writeup for the LoST=20 >sync draft=20 >>>>>> after we got further confirmation from the implementers team.=20 >>>>>> Then, Roger pointed me to the review by Richard and I=20 >have to say=20 >>>>>> that I must have missed it. Here are Richards review comments: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>>>> >>>>>> My response is inline: >>>>>> >>>>>> I reviewed lost-sync-04 in order to update my earlier >>>>> comments on -01. >>>>>> This version is much improved from the previous versions >>>in terms of >>>>>> specificity (although it's still vague in places). =A0It still >>>>> seems to >>>>>> me that there are a few layers of detail missing. =A0Specific >>>>> comments below. >>>>>> --Richard >>>>>> >>>>>> 1. The document describes transactions for requesting and >>>delivering >>>>>> mapping structures, but doesn't describe at all how these >>>>> transactions >>>>>> create a synchronization system. =A0There is clearly some = tracking=20 >>>>>> of state needed (especially for "pushMappings"), and the=20 >document=20 >>>>>> is silent on how this state is initially established and then >>>>> maintained. >>>>>> >>>>>> [Hannes] I added text throught the document to address this=20 >>>>>> comments. >>>>>> In particular I point to the need to keep state and also >>>to the fact >>>>>> that the document relies on manual configuration for setting up=20 >>>>>> the "peering" between the two nodes. >>>>>> >>>>>> 2. In a similar vein, it would be helpful for this document to=20 >>>>>> have some discussion of how this synchronization system relates >>>to others >>>>>> that are out there (e.g., rsync). =A0Since the name of the=20 >draft is=20 >>>>>> "synchronization", there should be some discussion of how=20 >>>>>> bidirectional sync is handled. >>>>>> >>>>>> [Hannes] We had a discussion about this topic at the >>>interim meeting >>>>>> and "downgraded" the document to an Experimental status to avoid=20 >>>>>> having to Analyse all available replication mechanisms. >>>>>> >>>>>> 3. It seems like there should really be only 3 message=20 >types here=20 >>>>>> instead of 4: (1) a "syncRequest" message sent from=20 >destination to=20 >>>>>> source (getMappingsRequest), (2) a "syncUpdate" message=20 >sent from=20 >>>>>> source to destination (getMappingsResponse =3D=3D=20 >>>>>> pushMappingsRequest), and (3) a "syncResult" message sent from=20 >>>>>> destination to source (pushMappingsResponse). =A0There can=20 >still be=20 >>>>>> two types of >>>>> transaction, >>>>>> but they're determined by which type of message (syncRequest or >>>>>> syncUpdate) is sent in the HTTP request. >>>>>> >>>>>> [Hannes] We got similar feedback from the implementers. >>>>> However, in a >>>>>> subsequent discussion with them it turned out that this=20 >change is=20 >>>>>> rather a matter of style than anything technical. A=20 >change in the=20 >>>>>> description along the lines as you suggested (and as they had >>>>>> suggested) as well only impacts the writing style of the >>>>> document and >>>>>> not really the implementation as such. Hence, I left the >>>>> document as is. >>>>>> >>>>>> 4. In a similar vein to 2 and 3, the use of "client" and >>>"server" is >>>>>> confusing. =A0I would suggest using more appropriate names=20 >for these=20 >>>>>> roles like "source" and "destination", along with some text that=20 >>>>>> explains how these roles map to HTTP roles in each type of >>>>> transaction. >>>>>> >>>>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >>>changed the >>>>>> terminology in the document to reflect the source / >>>>> destination terminology. >>>>>> I hope it improved readability. >>>>>> >>>>>> 5. My comment about the security considerations has not been >>>>> addressed. >>>>>> =A0The security considerations section is essentially a >>>>> pointer to LoST, >>>>>> but this protocol is only peripherally related to LoST (at a >>>>> technical >>>>>> level). =A0Since it's about synchronization, I would expect this=20 >>>>>> document to note that the primary risk is the injection of false=20 >>>>>> location information (since the mappings themselves are >>>>> public), which >>>>>> means that the parties should use HTTPS to carry the XML, >>>>> authenticate >>>>>> the source, and use a ciphersuite that provides integrity >>>>> protection to messages. >>>>>> >>>>>> [Hannes] You are certainly right with this comment. I >>>>> changed the text. >>>>>> >>>>>> Here is the updated document: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>>>>> sync-07.txt >>>>>> >>>>>> 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 khwolf1@gmail.com Thu Aug 20 01:08:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B067F3A6CCC for ; Thu, 20 Aug 2009 01:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHkHRPLOVjPH for ; Thu, 20 Aug 2009 01:08:46 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id D1D3B3A697D for ; Thu, 20 Aug 2009 01:08:45 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1140198fgg.18 for ; Thu, 20 Aug 2009 01:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LLfxLxhSg66F4xqKaniR2YdUzd1AGyWoDwrrMuetCKo=; b=nAoCB+6lxDa0MyyCK4I2bvHTbnjLqfHO13ZMg6BWfCUK+EdFH9hP+eLbqkmAIURjNA p0MBF7e2sMHLpidck4XoC3TqVK78hcBUIe3PQWmnraO1nDLh2czBdr8CKg6lNsPg1iH4 5xnvTYU6MtieeFtNK+70BeoxkrghkXO2wObdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e4MyHinpZF59GLPFftba/gu3MVPkmFWFLeW8AbV/qk3BlJ4+L3h7Fsn4/PsuDNoUSu grCysqIBC0K+p+fzL4hy9E+w0hngOc2XzfU5g3iQCJpj/rE1VTWHvHArS/DQ7JzU0vrK lYE3tUu5Ng72eto8EffBvvpeyKz0Me2EqM6KE= MIME-Version: 1.0 Received: by 10.86.226.32 with SMTP id y32mr4876975fgg.77.1250755711268; Thu, 20 Aug 2009 01:08:31 -0700 (PDT) In-Reply-To: <004501ca216a$e18a07d0$035ca20a@nsnintra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> <004501ca216a$e18a07d0$035ca20a@nsnintra.net> Date: Thu, 20 Aug 2009 10:08:31 +0200 Message-ID: From: Karl Heinz Wolf To: ECRIT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 08:08:47 -0000 On Thu, Aug 20, 2009 at 9:50 AM, Hannes Tschofenig wrote: > Hi Karl Heinz, > >>Hannes, >>this seems to be a possible solution. I would also skip the >>serviceNumber element in the examples since it is not >>necessary for the FG to know them - just the coverage region >>is of interest. > > You are correct that I could omit the element. > (In fact I can also omit the element as well instead of having it > empty.) > >>In your examples, would the LoST server also be authoritative >>for possible subservices? > Your question is whether the "Kaernten" LoST server in the example below > would also be hosting entries for urn:service:sos.police etc? yes, that's my question: when a server pushes up a coverage region for urn:service:sos, is he also authoritative for urn:service:sos.police or would he have to push up the same coverage region twice? But theoretically a different server could be responsible for the subservices, couldn't it? karl heinz > > Ciao > Hannes > >>karl heinz >> >>On Tue, Aug 18, 2009 at 7:11 PM, Hannes >>Tschofenig wrote: >>> Thanks for the suggestion. The proposal sounds indeed fairly >>good (and >>> simple). >>> >>> Here is an example of how this could look like for mapping data used >>> by an Austrian Forest Guide (FG). For this example I assumed >>that each >>> state runs an independent LoST server and the FG would contain >>> pointers to these LoST servers. I illustrated two such >>mappings below: >>> >>> =A0 =A0 =A0>> =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" >>> =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" >>> =A0 =A0 =A0 =A0source=3D"lost.kaernten.example" >>> =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> >>> =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0Kaernten LoST Server >>> =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0urn:service:sos >>> =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0profile=3D"civic"> >>> =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:c= ivicAddr"> >>> =A0 =A0 =A0 =A0 =A0 =A0AT >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kaernten >>> =A0 =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0112 >>> =A0 =A0 =A0 >>> >>> =A0 =A0 =A0>> =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" >>> =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" >>> =A0 =A0 =A0 =A0source=3D"lost.wien.example" >>> =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> >>> =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0LoST Server Wien >>> =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0urn:service:sos >>> =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0profile=3D"civic"> >>> =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:c= ivicAddr"> >>> =A0 =A0 =A0 =A0 =A0 =A0AT >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wien >>> =A0 =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0 >>> =A0 =A0 =A0 =A0112 >>> =A0 =A0 =A0 >>> >>> >>> Thoughts? >>> >>> Ciao >>> Hannes >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Andrew Newton [mailto:andy@hxr.us] >>>>Sent: 17 August, 2009 22:27 >>>>To: Tschofenig, Hannes (NSN - FI/Espoo) >>>>Cc: ext Karl Heinz Wolf; ECRIT >>>>Subject: Re: [Ecrit] LoST Sync Draft Update >>>> >>>>I think you could safely and naturally run the U-NAPTR >>process against >>>>the contents of the element to get what you need. >>A LOST URL >>>>scheme is not needed, and would have implications on tools that are >>>>fed them. >>>> >>>>-andy >>>> >>>>On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - >>FI/Espoo) wrote: >>>> >>>>> Hi Karl Heinz, >>>>> Hi all, >>>>> >>>>> Thanks for this question. >>>>> >>>>> To provide a bit of background to your question let us take an >>>>> example provided in >>>>> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >>>>> >>>>> On page 10 an example of mappings stored at a server are outlined: >>>>> >>>>> =A0 country =A0 A1 A2 =A0 =A0 =A0 =A0 A3 =A0 =A0 =A0 =A0resource or L= oST server >>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Leonia =A0 =A0sip:psap@leonia= nj.gov >>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Fort Lee =A0sip:emergency@for= tleenj.org >>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Teaneck =A0 sip:police@teanec= knjgov.org >>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Englewood englewoodnj.gov >>>>> >>>>> In this case, the first three mappings point to PSAPs (or >>>>ESRPs; one >>>>> cannot differentiate based on the mapping data). The final >>mapping, >>>>> however, points to a LoST server. >>>>> >>>>> So, element of the element accepts only URIs. The >>>>> output of the U-NAPTR process (described in Section 4 of >>>>http://www.ietf.org/rfc/rfc5222.txt) >>>>> =A0leads to a HTTP/HTTPS URI. >>>>> >>>>> So, the URI that is associated with the boundary is using a >>>>HTTP and >>>>> HTTPS URL scheme. >>>>> The input unfortunatley isn't; it is just a DNS name. >>>>> >>>>> In earlier versions of the LoST specifications we defined >>a new URI >>>>> scheme (namely lost://) but later removed it. As such, there is no >>>>> LoST URI to put into the element. >>>>> >>>>> So, do we have a problem here? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> PS: I have to check what the implementers have implemented here. >>>>> >>>>>> Hannes, >>>>>> >>>>>> some time ago I asked you about lost-sync and the pushing of >>>>>> coverage regions up a tree. >>>>>> Pushing of coverage regions is mentioned in the introduction, but >>>>>> all the examples show complete mappings. >>>>>> So I wonder if you assume LoST URIs to be placed in the URI >>>>>> elements of the mappings to indicate that this is not a >>mapping but >>>>>> rather a coverage region in the boundary? >>>>>> >>>>>> cheers >>>>>> karl heinz >>>>>> >>>>>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - >>>>>> FI/Espoo) wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I asked Roger to submit the PROTO writeup for the LoST >>sync draft >>>>>>> after we got further confirmation from the implementers team. >>>>>>> Then, Roger pointed me to the review by Richard and I >>have to say >>>>>>> that I must have missed it. Here are Richards review comments: >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>>>>> >>>>>>> My response is inline: >>>>>>> >>>>>>> I reviewed lost-sync-04 in order to update my earlier >>>>>> comments on -01. >>>>>>> This version is much improved from the previous versions >>>>in terms of >>>>>>> specificity (although it's still vague in places). =A0It still >>>>>> seems to >>>>>>> me that there are a few layers of detail missing. =A0Specific >>>>>> comments below. >>>>>>> --Richard >>>>>>> >>>>>>> 1. The document describes transactions for requesting and >>>>delivering >>>>>>> mapping structures, but doesn't describe at all how these >>>>>> transactions >>>>>>> create a synchronization system. =A0There is clearly some tracking >>>>>>> of state needed (especially for "pushMappings"), and the >>document >>>>>>> is silent on how this state is initially established and then >>>>>> maintained. >>>>>>> >>>>>>> [Hannes] I added text throught the document to address this >>>>>>> comments. >>>>>>> In particular I point to the need to keep state and also >>>>to the fact >>>>>>> that the document relies on manual configuration for setting up >>>>>>> the "peering" between the two nodes. >>>>>>> >>>>>>> 2. In a similar vein, it would be helpful for this document to >>>>>>> have some discussion of how this synchronization system relates >>>>to others >>>>>>> that are out there (e.g., rsync). =A0Since the name of the >>draft is >>>>>>> "synchronization", there should be some discussion of how >>>>>>> bidirectional sync is handled. >>>>>>> >>>>>>> [Hannes] We had a discussion about this topic at the >>>>interim meeting >>>>>>> and "downgraded" the document to an Experimental status to avoid >>>>>>> having to Analyse all available replication mechanisms. >>>>>>> >>>>>>> 3. It seems like there should really be only 3 message >>types here >>>>>>> instead of 4: (1) a "syncRequest" message sent from >>destination to >>>>>>> source (getMappingsRequest), (2) a "syncUpdate" message >>sent from >>>>>>> source to destination (getMappingsResponse =3D=3D >>>>>>> pushMappingsRequest), and (3) a "syncResult" message sent from >>>>>>> destination to source (pushMappingsResponse). =A0There can >>still be >>>>>>> two types of >>>>>> transaction, >>>>>>> but they're determined by which type of message (syncRequest or >>>>>>> syncUpdate) is sent in the HTTP request. >>>>>>> >>>>>>> [Hannes] We got similar feedback from the implementers. >>>>>> However, in a >>>>>>> subsequent discussion with them it turned out that this >>change is >>>>>>> rather a matter of style than anything technical. A >>change in the >>>>>>> description along the lines as you suggested (and as they had >>>>>>> suggested) as well only impacts the writing style of the >>>>>> document and >>>>>>> not really the implementation as such. Hence, I left the >>>>>> document as is. >>>>>>> >>>>>>> 4. In a similar vein to 2 and 3, the use of "client" and >>>>"server" is >>>>>>> confusing. =A0I would suggest using more appropriate names >>for these >>>>>>> roles like "source" and "destination", along with some text that >>>>>>> explains how these roles map to HTTP roles in each type of >>>>>> transaction. >>>>>>> >>>>>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >>>>changed the >>>>>>> terminology in the document to reflect the source / >>>>>> destination terminology. >>>>>>> I hope it improved readability. >>>>>>> >>>>>>> 5. My comment about the security considerations has not been >>>>>> addressed. >>>>>>> =A0The security considerations section is essentially a >>>>>> pointer to LoST, >>>>>>> but this protocol is only peripherally related to LoST (at a >>>>>> technical >>>>>>> level). =A0Since it's about synchronization, I would expect this >>>>>>> document to note that the primary risk is the injection of false >>>>>>> location information (since the mappings themselves are >>>>>> public), which >>>>>>> means that the parties should use HTTPS to carry the XML, >>>>>> authenticate >>>>>>> the source, and use a ciphersuite that provides integrity >>>>>> protection to messages. >>>>>>> >>>>>>> [Hannes] You are certainly right with this comment. I >>>>>> changed the text. >>>>>>> >>>>>>> Here is the updated document: >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>>>>>> sync-07.txt >>>>>>> >>>>>>> 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 Hannes.Tschofenig@gmx.net Thu Aug 20 01:59:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9F93A6E93 for ; Thu, 20 Aug 2009 01:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.762 X-Spam-Level: X-Spam-Status: No, score=-0.762 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoxhgJeM4UZr for ; Thu, 20 Aug 2009 01:59:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 465243A6FB4 for ; Thu, 20 Aug 2009 01:59:16 -0700 (PDT) Received: (qmail invoked by alias); 20 Aug 2009 08:59:21 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp063) with SMTP; 20 Aug 2009 10:59:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18SIGA0HN4SeDCVgVIq5ULSKJDA4eRkTTZ/hhdZvi /OnFPQOhQpIqY5 From: "Hannes Tschofenig" To: "'Karl Heinz Wolf'" , "'ECRIT'" References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net><3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net><280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us><006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net><004501ca216a$e18a07d0$035ca20a@nsnintra.net> Date: Thu, 20 Aug 2009 12:01:57 +0300 Message-ID: <005801ca2174$e07a8810$035ca20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcohbXaxdkferyrUR/imRAX03zqO7gABtjmA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 08:59:56 -0000 Hi Karl Heinz, =20 >On Thu, Aug 20, 2009 at 9:50 AM, Hannes >Tschofenig wrote: >> Hi Karl Heinz, >> >>>Hannes, >>>this seems to be a possible solution. I would also skip the=20 >>>serviceNumber element in the examples since it is not necessary for=20 >>>the FG to know them - just the coverage region is of interest. >> >> You are correct that I could omit the element. >> (In fact I can also omit the element as well instead of having=20 >> it >> empty.) >> >>>In your examples, would the LoST server also be authoritative for=20 >>>possible subservices? >> Your question is whether the "Kaernten" LoST server in the example=20 >> below would also be hosting entries for urn:service:sos.police etc? >yes, that's my question: when a server pushes up a coverage=20 >region for urn:service:sos, is he also authoritative for=20 >urn:service:sos.police or would he have to push up the same=20 >coverage region twice? >But theoretically a different server could be responsible for=20 >the subservices, couldn't it? Ok. Your question is addressing the current form of encoding and the semantic of it. When the mapping indicates 'urn:service:sos' then it is only authoritive = for 'urn:service:sos' and not for the sub-services as they might be provided = by other LoST servers. Maybe that's something we should make more clear in = the document. Now, you could argue that one could instead of pushing up 2 mapping = elements (both with the same boundary but with different service URNs) just list = the service URNs within a single boundary. That's true and would be more bandwidth efficient.=20 I don't think we should optimize the bandwidth performance at this point = in time but rather get something out there for folks to play with. I am = sure that there will be lots of other feedback coming so that we have to = revise the document in the future.=20 Ciao Hannes > >karl heinz >> >> Ciao >> Hannes >> >>>karl heinz >>> >>>On Tue, Aug 18, 2009 at 7:11 PM, Hannes=20 >>>Tschofenig wrote: >>>> Thanks for the suggestion. The proposal sounds indeed fairly >>>good (and >>>> simple). >>>> >>>> Here is an example of how this could look like for mapping=20 >data used=20 >>>> by an Austrian Forest Guide (FG). For this example I assumed >>>that each >>>> state runs an independent LoST server and the FG would contain=20 >>>> pointers to these LoST servers. I illustrated two such >>>mappings below: >>>> >>>> =A0 =A0 =A0>>> =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" >>>> =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" >>>> =A0 =A0 =A0 =A0source=3D"lost.kaernten.example" >>>> =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> >>>> =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0 =A0Kaernten LoST Server >>>> =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0urn:service:sos >>>> =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 =A0 =A0profile=3D"civic"> >>>> =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 =A0 =A0 = =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >>>> =A0 =A0 =A0 =A0 =A0 =A0AT >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kaernten >>>> =A0 =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0112 >>>> =A0 =A0 =A0 >>>> >>>> =A0 =A0 =A0>>> =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" >>>> =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" >>>> =A0 =A0 =A0 =A0source=3D"lost.wien.example" >>>> =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> >>>> =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0 =A0LoST Server Wien >>>> =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0urn:service:sos >>>> =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 =A0 =A0profile=3D"civic"> >>>> =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 =A0 =A0 = =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >>>> =A0 =A0 =A0 =A0 =A0 =A0AT >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wien >>>> =A0 =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0 >>>> =A0 =A0 =A0 =A0112 >>>> =A0 =A0 =A0 >>>> >>>> >>>> Thoughts? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Andrew Newton [mailto:andy@hxr.us] >>>>>Sent: 17 August, 2009 22:27 >>>>>To: Tschofenig, Hannes (NSN - FI/Espoo) >>>>>Cc: ext Karl Heinz Wolf; ECRIT >>>>>Subject: Re: [Ecrit] LoST Sync Draft Update >>>>> >>>>>I think you could safely and naturally run the U-NAPTR >>>process against >>>>>the contents of the element to get what you need. >>>A LOST URL >>>>>scheme is not needed, and would have implications on tools=20 >that are=20 >>>>>fed them. >>>>> >>>>>-andy >>>>> >>>>>On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - >>>FI/Espoo) wrote: >>>>> >>>>>> Hi Karl Heinz, >>>>>> Hi all, >>>>>> >>>>>> Thanks for this question. >>>>>> >>>>>> To provide a bit of background to your question let us take an=20 >>>>>> example provided in=20 >>>>>> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >>>>>> >>>>>> On page 10 an example of mappings stored at a server are=20 >outlined: >>>>>> >>>>>> =A0 country =A0 A1 A2 =A0 =A0 =A0 =A0 A3 =A0 =A0 =A0 =A0resource = or LoST server >>>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Leonia =A0 = =A0sip:psap@leonianj.gov >>>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Fort Lee = =A0sip:emergency@fortleenj.org >>>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Teaneck =A0 = sip:police@teanecknjgov.org >>>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Englewood englewoodnj.gov >>>>>> >>>>>> In this case, the first three mappings point to PSAPs (or >>>>>ESRPs; one >>>>>> cannot differentiate based on the mapping data). The final >>>mapping, >>>>>> however, points to a LoST server. >>>>>> >>>>>> So, element of the element accepts only=20 >URIs. The=20 >>>>>> output of the U-NAPTR process (described in Section 4 of >>>>>http://www.ietf.org/rfc/rfc5222.txt) >>>>>> =A0leads to a HTTP/HTTPS URI. >>>>>> >>>>>> So, the URI that is associated with the boundary is using a >>>>>HTTP and >>>>>> HTTPS URL scheme. >>>>>> The input unfortunatley isn't; it is just a DNS name. >>>>>> >>>>>> In earlier versions of the LoST specifications we defined >>>a new URI >>>>>> scheme (namely lost://) but later removed it. As such,=20 >there is no=20 >>>>>> LoST URI to put into the element. >>>>>> >>>>>> So, do we have a problem here? >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> PS: I have to check what the implementers have implemented here. >>>>>> >>>>>>> Hannes, >>>>>>> >>>>>>> some time ago I asked you about lost-sync and the pushing of=20 >>>>>>> coverage regions up a tree. >>>>>>> Pushing of coverage regions is mentioned in the=20 >introduction, but=20 >>>>>>> all the examples show complete mappings. >>>>>>> So I wonder if you assume LoST URIs to be placed in the URI=20 >>>>>>> elements of the mappings to indicate that this is not a >>>mapping but >>>>>>> rather a coverage region in the boundary? >>>>>>> >>>>>>> cheers >>>>>>> karl heinz >>>>>>> >>>>>>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN -=20 >>>>>>> FI/Espoo) wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I asked Roger to submit the PROTO writeup for the LoST >>>sync draft >>>>>>>> after we got further confirmation from the implementers team. >>>>>>>> Then, Roger pointed me to the review by Richard and I >>>have to say >>>>>>>> that I must have missed it. Here are Richards review comments: >>>>>>>> >>>>>>>>=20 >http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>>>>>> >>>>>>>> My response is inline: >>>>>>>> >>>>>>>> I reviewed lost-sync-04 in order to update my earlier >>>>>>> comments on -01. >>>>>>>> This version is much improved from the previous versions >>>>>in terms of >>>>>>>> specificity (although it's still vague in places). =A0It still >>>>>>> seems to >>>>>>>> me that there are a few layers of detail missing. =A0Specific >>>>>>> comments below. >>>>>>>> --Richard >>>>>>>> >>>>>>>> 1. The document describes transactions for requesting and >>>>>delivering >>>>>>>> mapping structures, but doesn't describe at all how these >>>>>>> transactions >>>>>>>> create a synchronization system. =A0There is clearly=20 >some tracking=20 >>>>>>>> of state needed (especially for "pushMappings"), and the >>>document >>>>>>>> is silent on how this state is initially established and then >>>>>>> maintained. >>>>>>>> >>>>>>>> [Hannes] I added text throught the document to address this=20 >>>>>>>> comments. >>>>>>>> In particular I point to the need to keep state and also >>>>>to the fact >>>>>>>> that the document relies on manual configuration for=20 >setting up=20 >>>>>>>> the "peering" between the two nodes. >>>>>>>> >>>>>>>> 2. In a similar vein, it would be helpful for this document to=20 >>>>>>>> have some discussion of how this synchronization system relates >>>>>to others >>>>>>>> that are out there (e.g., rsync). =A0Since the name of the >>>draft is >>>>>>>> "synchronization", there should be some discussion of how=20 >>>>>>>> bidirectional sync is handled. >>>>>>>> >>>>>>>> [Hannes] We had a discussion about this topic at the >>>>>interim meeting >>>>>>>> and "downgraded" the document to an Experimental=20 >status to avoid=20 >>>>>>>> having to Analyse all available replication mechanisms. >>>>>>>> >>>>>>>> 3. It seems like there should really be only 3 message >>>types here >>>>>>>> instead of 4: (1) a "syncRequest" message sent from >>>destination to >>>>>>>> source (getMappingsRequest), (2) a "syncUpdate" message >>>sent from >>>>>>>> source to destination (getMappingsResponse =3D=3D=20 >>>>>>>> pushMappingsRequest), and (3) a "syncResult" message sent from=20 >>>>>>>> destination to source (pushMappingsResponse). =A0There can >>>still be >>>>>>>> two types of >>>>>>> transaction, >>>>>>>> but they're determined by which type of message (syncRequest or >>>>>>>> syncUpdate) is sent in the HTTP request. >>>>>>>> >>>>>>>> [Hannes] We got similar feedback from the implementers. >>>>>>> However, in a >>>>>>>> subsequent discussion with them it turned out that this >>>change is >>>>>>>> rather a matter of style than anything technical. A >>>change in the >>>>>>>> description along the lines as you suggested (and as they had >>>>>>>> suggested) as well only impacts the writing style of the >>>>>>> document and >>>>>>>> not really the implementation as such. Hence, I left the >>>>>>> document as is. >>>>>>>> >>>>>>>> 4. In a similar vein to 2 and 3, the use of "client" and >>>>>"server" is >>>>>>>> confusing. =A0I would suggest using more appropriate names >>>for these >>>>>>>> roles like "source" and "destination", along with some=20 >text that=20 >>>>>>>> explains how these roles map to HTTP roles in each type of >>>>>>> transaction. >>>>>>>> >>>>>>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >>>>>changed the >>>>>>>> terminology in the document to reflect the source / >>>>>>> destination terminology. >>>>>>>> I hope it improved readability. >>>>>>>> >>>>>>>> 5. My comment about the security considerations has not been >>>>>>> addressed. >>>>>>>> =A0The security considerations section is essentially a >>>>>>> pointer to LoST, >>>>>>>> but this protocol is only peripherally related to LoST (at a >>>>>>> technical >>>>>>>> level). =A0Since it's about synchronization, I would expect = this=20 >>>>>>>> document to note that the primary risk is the=20 >injection of false=20 >>>>>>>> location information (since the mappings themselves are >>>>>>> public), which >>>>>>>> means that the parties should use HTTPS to carry the XML, >>>>>>> authenticate >>>>>>>> the source, and use a ciphersuite that provides integrity >>>>>>> protection to messages. >>>>>>>> >>>>>>>> [Hannes] You are certainly right with this comment. I >>>>>>> changed the text. >>>>>>>> >>>>>>>> Here is the updated document: >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>>>>>>> sync-07.txt >>>>>>>> >>>>>>>> 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 khwolf1@gmail.com Thu Aug 20 04:04:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46823A7009 for ; Thu, 20 Aug 2009 04:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdRGYQqaqQ5t for ; Thu, 20 Aug 2009 04:04:55 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 9F2CA3A6FD3 for ; Thu, 20 Aug 2009 04:04:38 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1160423fgg.18 for ; Thu, 20 Aug 2009 04:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YPP487BofM8l78WYEBWcvAzxCbNyHMAZ0ktEtxr9IEQ=; b=PwF6hG18V7fX3fmPiIYurMtKxUUYzn920wgFiWm/3wwtvYO8qfcaMWPk3Tn8o72PkN LW4/e/8fJHm14TNxTz7cLg/97KLf75bHRTFWGb4ifw3RiVN/Vu+f5WZqY4o4/eURiYwm r89ir2KwpwPK9bmFEnjQJ6oS8sZO2mIdZNFvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=goyx2ScVSqlQVCSVwGahgodC3KVyyu2v+LT5lt/bwK1S1sD/5DuIuL9rC9p/Ivv+tq Zxjp8MlTc1cYbwY4Vt/WdoHuyijyS89WokjDW7pmgB0aMyWwEOsA7hDBA1W3osOGJS1D erxTiWl6fV1tW+zNU+LdV+vV92cuh/trmLh3M= MIME-Version: 1.0 Received: by 10.86.169.3 with SMTP id r3mr5047755fge.15.1250766281302; Thu, 20 Aug 2009 04:04:41 -0700 (PDT) In-Reply-To: <005801ca2174$e07a8810$035ca20a@nsnintra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45019415C3@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45019419DE@FIESEXC015.nsn-intra.net> <280E2FDB-4F0B-4E84-828B-10BDAF945043@hxr.us> <006401ca2026$ee5feaf0$8e01fe0a@nsnintra.net> <004501ca216a$e18a07d0$035ca20a@nsnintra.net> <005801ca2174$e07a8810$035ca20a@nsnintra.net> Date: Thu, 20 Aug 2009 13:04:41 +0200 Message-ID: From: Karl Heinz Wolf To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT Subject: Re: [Ecrit] LoST Sync Draft Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 11:04:56 -0000 Hannes, thank you for clarifying this. I was not concerned about bandwidth efficiency but the document doesn't say much about pushing of coverage regions so I thought I should ask. Probably a few words in the document would be a good idea. karl heinz On Thu, Aug 20, 2009 at 11:01 AM, Hannes Tschofenig wrote: > Hi Karl Heinz, > > >>On Thu, Aug 20, 2009 at 9:50 AM, Hannes >>Tschofenig wrote: >>> Hi Karl Heinz, >>> >>>>Hannes, >>>>this seems to be a possible solution. I would also skip the >>>>serviceNumber element in the examples since it is not necessary for >>>>the FG to know them - just the coverage region is of interest. >>> >>> You are correct that I could omit the element. >>> (In fact I can also omit the element as well instead of having >>> it >>> empty.) >>> >>>>In your examples, would the LoST server also be authoritative for >>>>possible subservices? >>> Your question is whether the "Kaernten" LoST server in the example >>> below would also be hosting entries for urn:service:sos.police etc? >>yes, that's my question: when a server pushes up a coverage >>region for urn:service:sos, is he also authoritative for >>urn:service:sos.police or would he have to push up the same >>coverage region twice? >>But theoretically a different server could be responsible for >>the subservices, couldn't it? > > Ok. Your question is addressing the current form of encoding and the > semantic of it. > > When the mapping indicates 'urn:service:sos' then it is only authoritive = for > 'urn:service:sos' and not for the sub-services as they might be provided = by > other LoST servers. Maybe that's something we should make more clear in t= he > document. > > Now, you could argue that one could instead of pushing up 2 mapping eleme= nts > (both with the same boundary but with different service URNs) just list t= he > service URNs within a single boundary. That's true and would be more > bandwidth efficient. > > I don't think we should optimize the bandwidth performance at this point = in > time but rather get something out there for folks to play with. I am sure > that there will be lots of other feedback coming so that we have to revis= e > the document in the future. > > Ciao > Hannes > >> >>karl heinz >>> >>> Ciao >>> Hannes >>> >>>>karl heinz >>>> >>>>On Tue, Aug 18, 2009 at 7:11 PM, Hannes >>>>Tschofenig wrote: >>>>> Thanks for the suggestion. The proposal sounds indeed fairly >>>>good (and >>>>> simple). >>>>> >>>>> Here is an example of how this could look like for mapping >>data used >>>>> by an Austrian Forest Guide (FG). For this example I assumed >>>>that each >>>>> state runs an independent LoST server and the FG would contain >>>>> pointers to these LoST servers. I illustrated two such >>>>mappings below: >>>>> >>>>> =A0 =A0 =A0>>>> =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" >>>>> =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" >>>>> =A0 =A0 =A0 =A0source=3D"lost.kaernten.example" >>>>> =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> >>>>> =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0 =A0Kaernten LoST Server >>>>> =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0urn:service:sos >>>>> =A0 =A0 =A0 =A0>>>> =A0 =A0 =A0 =A0 =A0profile=3D"civic"> >>>>> =A0 =A0 =A0 =A0 =A0>>>> =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10= :civicAddr"> >>>>> =A0 =A0 =A0 =A0 =A0 =A0AT >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kaernten >>>>> =A0 =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0112 >>>>> =A0 =A0 =A0 >>>>> >>>>> =A0 =A0 =A0>>>> =A0 =A0 =A0 =A0expires=3D"2009-01-01T01:44:33Z" >>>>> =A0 =A0 =A0 =A0lastUpdated=3D"2009-12-01T01:00:00Z" >>>>> =A0 =A0 =A0 =A0source=3D"lost.wien.example" >>>>> =A0 =A0 =A0 =A0sourceId=3D"e8b05a41d8d1415b80f2cdbb96ccf109"> >>>>> =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0 =A0LoST Server Wien >>>>> =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0urn:service:sos >>>>> =A0 =A0 =A0 =A0>>>> =A0 =A0 =A0 =A0 =A0profile=3D"civic"> >>>>> =A0 =A0 =A0 =A0 =A0>>>> =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10= :civicAddr"> >>>>> =A0 =A0 =A0 =A0 =A0 =A0AT >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Wien >>>>> =A0 =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0 >>>>> =A0 =A0 =A0 =A0112 >>>>> =A0 =A0 =A0 >>>>> >>>>> >>>>> Thoughts? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: ext Andrew Newton [mailto:andy@hxr.us] >>>>>>Sent: 17 August, 2009 22:27 >>>>>>To: Tschofenig, Hannes (NSN - FI/Espoo) >>>>>>Cc: ext Karl Heinz Wolf; ECRIT >>>>>>Subject: Re: [Ecrit] LoST Sync Draft Update >>>>>> >>>>>>I think you could safely and naturally run the U-NAPTR >>>>process against >>>>>>the contents of the element to get what you need. >>>>A LOST URL >>>>>>scheme is not needed, and would have implications on tools >>that are >>>>>>fed them. >>>>>> >>>>>>-andy >>>>>> >>>>>>On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - >>>>FI/Espoo) wrote: >>>>>> >>>>>>> Hi Karl Heinz, >>>>>>> Hi all, >>>>>>> >>>>>>> Thanks for this question. >>>>>>> >>>>>>> To provide a bit of background to your question let us take an >>>>>>> example provided in >>>>>>> http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt >>>>>>> >>>>>>> On page 10 an example of mappings stored at a server are >>outlined: >>>>>>> >>>>>>> =A0 country =A0 A1 A2 =A0 =A0 =A0 =A0 A3 =A0 =A0 =A0 =A0resource or= LoST server >>>>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Leonia =A0 =A0sip:psap@leon= ianj.gov >>>>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Fort Lee =A0sip:emergency@f= ortleenj.org >>>>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Teaneck =A0 sip:police@tean= ecknjgov.org >>>>>>> =A0 US =A0 =A0 =A0 =A0NJ Bergen =A0 =A0 Englewood englewoodnj.gov >>>>>>> >>>>>>> In this case, the first three mappings point to PSAPs (or >>>>>>ESRPs; one >>>>>>> cannot differentiate based on the mapping data). The final >>>>mapping, >>>>>>> however, points to a LoST server. >>>>>>> >>>>>>> So, element of the element accepts only >>URIs. The >>>>>>> output of the U-NAPTR process (described in Section 4 of >>>>>>http://www.ietf.org/rfc/rfc5222.txt) >>>>>>> =A0leads to a HTTP/HTTPS URI. >>>>>>> >>>>>>> So, the URI that is associated with the boundary is using a >>>>>>HTTP and >>>>>>> HTTPS URL scheme. >>>>>>> The input unfortunatley isn't; it is just a DNS name. >>>>>>> >>>>>>> In earlier versions of the LoST specifications we defined >>>>a new URI >>>>>>> scheme (namely lost://) but later removed it. As such, >>there is no >>>>>>> LoST URI to put into the element. >>>>>>> >>>>>>> So, do we have a problem here? >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> PS: I have to check what the implementers have implemented here. >>>>>>> >>>>>>>> Hannes, >>>>>>>> >>>>>>>> some time ago I asked you about lost-sync and the pushing of >>>>>>>> coverage regions up a tree. >>>>>>>> Pushing of coverage regions is mentioned in the >>introduction, but >>>>>>>> all the examples show complete mappings. >>>>>>>> So I wonder if you assume LoST URIs to be placed in the URI >>>>>>>> elements of the mappings to indicate that this is not a >>>>mapping but >>>>>>>> rather a coverage region in the boundary? >>>>>>>> >>>>>>>> cheers >>>>>>>> karl heinz >>>>>>>> >>>>>>>> On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN - >>>>>>>> FI/Espoo) wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I asked Roger to submit the PROTO writeup for the LoST >>>>sync draft >>>>>>>>> after we got further confirmation from the implementers team. >>>>>>>>> Then, Roger pointed me to the review by Richard and I >>>>have to say >>>>>>>>> that I must have missed it. Here are Richards review comments: >>>>>>>>> >>>>>>>>> >>http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html >>>>>>>>> >>>>>>>>> My response is inline: >>>>>>>>> >>>>>>>>> I reviewed lost-sync-04 in order to update my earlier >>>>>>>> comments on -01. >>>>>>>>> This version is much improved from the previous versions >>>>>>in terms of >>>>>>>>> specificity (although it's still vague in places). =A0It still >>>>>>>> seems to >>>>>>>>> me that there are a few layers of detail missing. =A0Specific >>>>>>>> comments below. >>>>>>>>> --Richard >>>>>>>>> >>>>>>>>> 1. The document describes transactions for requesting and >>>>>>delivering >>>>>>>>> mapping structures, but doesn't describe at all how these >>>>>>>> transactions >>>>>>>>> create a synchronization system. =A0There is clearly >>some tracking >>>>>>>>> of state needed (especially for "pushMappings"), and the >>>>document >>>>>>>>> is silent on how this state is initially established and then >>>>>>>> maintained. >>>>>>>>> >>>>>>>>> [Hannes] I added text throught the document to address this >>>>>>>>> comments. >>>>>>>>> In particular I point to the need to keep state and also >>>>>>to the fact >>>>>>>>> that the document relies on manual configuration for >>setting up >>>>>>>>> the "peering" between the two nodes. >>>>>>>>> >>>>>>>>> 2. In a similar vein, it would be helpful for this document to >>>>>>>>> have some discussion of how this synchronization system relates >>>>>>to others >>>>>>>>> that are out there (e.g., rsync). =A0Since the name of the >>>>draft is >>>>>>>>> "synchronization", there should be some discussion of how >>>>>>>>> bidirectional sync is handled. >>>>>>>>> >>>>>>>>> [Hannes] We had a discussion about this topic at the >>>>>>interim meeting >>>>>>>>> and "downgraded" the document to an Experimental >>status to avoid >>>>>>>>> having to Analyse all available replication mechanisms. >>>>>>>>> >>>>>>>>> 3. It seems like there should really be only 3 message >>>>types here >>>>>>>>> instead of 4: (1) a "syncRequest" message sent from >>>>destination to >>>>>>>>> source (getMappingsRequest), (2) a "syncUpdate" message >>>>sent from >>>>>>>>> source to destination (getMappingsResponse =3D=3D >>>>>>>>> pushMappingsRequest), and (3) a "syncResult" message sent from >>>>>>>>> destination to source (pushMappingsResponse). =A0There can >>>>still be >>>>>>>>> two types of >>>>>>>> transaction, >>>>>>>>> but they're determined by which type of message (syncRequest or >>>>>>>>> syncUpdate) is sent in the HTTP request. >>>>>>>>> >>>>>>>>> [Hannes] We got similar feedback from the implementers. >>>>>>>> However, in a >>>>>>>>> subsequent discussion with them it turned out that this >>>>change is >>>>>>>>> rather a matter of style than anything technical. A >>>>change in the >>>>>>>>> description along the lines as you suggested (and as they had >>>>>>>>> suggested) as well only impacts the writing style of the >>>>>>>> document and >>>>>>>>> not really the implementation as such. Hence, I left the >>>>>>>> document as is. >>>>>>>>> >>>>>>>>> 4. In a similar vein to 2 and 3, the use of "client" and >>>>>>"server" is >>>>>>>>> confusing. =A0I would suggest using more appropriate names >>>>for these >>>>>>>>> roles like "source" and "destination", along with some >>text that >>>>>>>>> explains how these roles map to HTTP roles in each type of >>>>>>>> transaction. >>>>>>>>> >>>>>>>>> [Hannes] I added text regarding the HTTP/HTTPs roles and >>>>>>changed the >>>>>>>>> terminology in the document to reflect the source / >>>>>>>> destination terminology. >>>>>>>>> I hope it improved readability. >>>>>>>>> >>>>>>>>> 5. My comment about the security considerations has not been >>>>>>>> addressed. >>>>>>>>> =A0The security considerations section is essentially a >>>>>>>> pointer to LoST, >>>>>>>>> but this protocol is only peripherally related to LoST (at a >>>>>>>> technical >>>>>>>>> level). =A0Since it's about synchronization, I would expect this >>>>>>>>> document to note that the primary risk is the >>injection of false >>>>>>>>> location information (since the mappings themselves are >>>>>>>> public), which >>>>>>>>> means that the parties should use HTTPS to carry the XML, >>>>>>>> authenticate >>>>>>>>> the source, and use a ciphersuite that provides integrity >>>>>>>> protection to messages. >>>>>>>>> >>>>>>>>> [Hannes] You are certainly right with this comment. I >>>>>>>> changed the text. >>>>>>>>> >>>>>>>>> Here is the updated document: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost- >>>>>>>>> sync-07.txt >>>>>>>>> >>>>>>>>> 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 hannes.tschofenig@nsn.com Thu Aug 20 22:54:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6BE3A6971 for ; Thu, 20 Aug 2009 22:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.213 X-Spam-Level: X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=1.386, 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 eJ2j7+LnOLhj for ; Thu, 20 Aug 2009 22:54:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 928403A69B1 for ; Thu, 20 Aug 2009 22:54:34 -0700 (PDT) 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 n7L5s9HW028175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Aug 2009 07:54:09 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7L5s9G8006419; Fri, 21 Aug 2009 07:54:09 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 07:54:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 08:56:46 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019E0AF1@FIESEXC015.nsn-intra.net> In-Reply-To: <4A8BBDA2.2050701@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Rechartering & Milestone Update Thread-Index: Acogqt1g0leqiLiaREWr3MjwlDON8wAF0vpg References: <003401ca1f68$d6226a80$2549a20a@nsnintra.net><4A8B989F.20502@huawei.com><007c01ca2095$7f55dd30$8e01fe0a@nsnintra.net> <4A8BBDA2.2050701@huawei.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , "Hannes Tschofenig" X-OriginalArrivalTime: 21 Aug 2009 05:54:08.0907 (UTC) FILETIME=[CCD325B0:01CA2223] Cc: ecrit Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 05:54:46 -0000 First, we have to get the charter and the milestones updated. In about 2 weeks I plan to send the charter/milestone proposal (with the feedback from the list incorporated) to the IESG. Then, they will discuss it and other folks will comment on it. That takes a bit of time.=20 Then, we hopefully have the new charter. One of the items is the Service URN update that will allow us to simplify the allocation of new Service URNs. Your document creates such a service URN. At this point in time you can submit your draft to the RFC Editor. Hopefully by that time the Service URN document will be progressed to an RFC and the new policy is in place.=20 The policy currently asks for expert review. Your document will then be sent for expert review (the IESG will appoint an expert reviewer, most likely from this group).=20 After the expert review your document will go through the normal processing steps through the publication process.=20 Ciao Hannes PS: I would appreciate if you could review other working group items as well so that we progress our work faster and consequently your document will go through the pipeline faster as well.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Robins George >Sent: 19 August, 2009 11:54 >To: Hannes Tschofenig >Cc: 'ecrit' >Subject: Re: [Ecrit] ECRIT Rechartering & Milestone Update > >Hannes, > >Thanks for the clarification. >I would like to know, when can we submit this draft to RFC Editor ? > >-- Robins > >> Nope, I did not. >> >> Per discussion some time ago the idea was to change the Service URN=20 >> allocation policy and to have documents like this to be submitted to=20 >> the RFC Editor. >> >> =20 >>> -----Original Message----- >>> From: Robins George [mailto:robinsg@huawei.com] >>> Sent: 19 August, 2009 09:16 >>> To: Hannes Tschofenig >>> Cc: 'ecrit' >>> Subject: Re: [Ecrit] ECRIT Rechartering& Milestone Update >>> >>> Hannes, >>> >>> =20 >>>> Nov 2009 Submit "RFC 5031bis" to the IESG for consideration as a=20 >>>> Standards Track RFC >>>> >>>> Dec 2009 Submit "Location-to-Service Translation Protocol (LoST)=20 >>>> Extensions" to the IESG for consideration as an Informational RFC >>>> >>>> >>>> =20 >>> Did you skip the shelter draft ? >>> http://tools.ietf.org/html/draft-sun-ecrit-shelter-service-02 >>> >>> >>> -- Robins >>> >>> >>> >>> =20 >> >> =20 >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Thu Aug 20 23:36:53 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBE63A6971 for ; Thu, 20 Aug 2009 23:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 04T05jBmmT4t for ; Thu, 20 Aug 2009 23:36:51 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6D18F3A6A5F for ; Thu, 20 Aug 2009 23:36:50 -0700 (PDT) Received: (qmail invoked by alias); 21 Aug 2009 06:36:55 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp066) with SMTP; 21 Aug 2009 08:36:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/lzklaUuvl1hD+w3LwWRlpRmUcM02MICeVjsr7p1 jAjobHOLcazvZt From: "Hannes Tschofenig" To: "'Elwell, John'" , References: <0D5F89FAC29E2C41B98A6A762007F5D00249B512@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 21 Aug 2009 09:39:31 +0300 Message-ID: <008601ca222a$254fad70$035ca20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00249B512@GBNTHT12009MSX.gb002.siemens.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acog7hwZDo21zJa1SqekFqluS72/OgBOdahQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: "'Theis, Harald \(Harald\)'" , 'John Fenn' , "'Hammer, Bernard'" , "'Vautz, Rolf \(Rolf\)'" , "'Dietz, J.B. \(Jan\)'" Subject: Re: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 06:36:53 -0000 Hi John, Thanks for sharing this document with us. Interesting writeup. I browsed through it and it looked pretty good. I will have some comments once I do a detailed review. For now I just wanted to quickly respond to the standardization gaps that are listed in the document: ------ STANDARDISATION GAP 1 (see 6.1.2): There are currently no service URNs defined for use where enterprise-specific emergency services need to be identified separately from public emergency services. ------ First, there is the question whether you really need this. I will have to read through the document in more detail to get an understanding. Let's assume you do need additional service URNs then there are a few ways to get them: * You could define new sub-services for the 'sos' service http://www.ietf.org/rfc/rfc5031.txt Policy: expert review * You could define new to-top level service URNs Since a number of folks in the group wanted to do that we started the discussion around relaxing the policy from 'Standards Action' (as defined in RFC 5031) to 'expert review' (in http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy-00.txt). The rechartering process is currently ongoing. * Finally, you can define your own URNs, as it is done with http://tools.ietf.org/html/draft-rosen-urn-nena-00 The usage scenario in NENA is, however, different. There, folks want to use their own Service URNs within the ESINet. So, it depends on your scenarios. ------ STANDARDISATION GAP 2 (see 6.2.2.2.2): There is no standardised means of conveying information on position relative to access points in SIP. ------ This is a GEOPRIV topic. There was a proposal (http://tools.ietf.org/id/draft-linsner-geopriv-relativeloc-03.txt) or even more than one. If I recall it correctly then the main question by some folks in the GEOPRIV group was whether this is really so useful. I again have to read through your document to figure out what your arguments are. ------ STANDARDISATION GAP 3 (see 6.4.3): There is currently no reliable means of identifying a return call from an ERC. ------ We had chats about this topic in ECRIT for a long time and then finally decided that we should do a writeup of this topic. The group was interested in working on this subject and it is also included in the re-chartering process. Here is the document: http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt Since this work is still at a very early stage we would highly appreciate feedback to make basic design decisions. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Elwell, John >Sent: 19 August, 2009 19:57 >To: ecrit@ietf.org >Cc: Theis, Harald (Harald); John Fenn; Hammer, Bernard; >Vautz,Rolf (Rolf); Dietz, J.B. (Jan) >Subject: [Ecrit] Ecma-International work on emergency calls in >enterprisenetworks > >As part of its work on enterprise networks under the name Next >Generation Corporate Networks (NGCN), including interoperation >with NGN, Ecma-International has carried out investigations >into emergency calling in enterprise networks, and a >near-final draft of the resulting Technical Report is available here: > >http://www.ecma-international.org/activities/Communications/9th >%20draft% >20TRNGCN%20Emergency%20calls.pdf > >The report draws heavily on the work of ECRIT. Any comments on >the draft would be appreciated. We hope to finalise it during >the second half of September. > >John >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From john.elwell@siemens-enterprise.com Fri Aug 21 12:41:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB7F28C203 for ; Fri, 21 Aug 2009 12:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 rcD81wLPlihO for ; Fri, 21 Aug 2009 12:41:02 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 86B193A6922 for ; Fri, 21 Aug 2009 12:41:02 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KOQ0041NS0I9C@siemenscomms.co.uk> for ecrit@ietf.org; Fri, 21 Aug 2009 20:41:06 +0100 (BST) Date: Fri, 21 Aug 2009 20:41:05 +0100 From: "Elwell, John" In-reply-to: <008601ca222a$254fad70$035ca20a@nsnintra.net> To: Hannes Tschofenig , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00249BDF6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks Thread-Index: Acog7hwZDo21zJa1SqekFqluS72/OgBOdahQABaZFnA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00249B512@GBNTHT12009MSX.gb002.siemens.net> <008601ca222a$254fad70$035ca20a@nsnintra.net> Cc: "Theis, Harald \(Harald\)" , John Fenn , "Hammer, Bernard" , "Vautz, Rolf \(Rolf\)" , "Dietz, J.B. \(Jan\)" Subject: Re: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 19:41:08 -0000 Hannes, Thanks for your initial feedback and your willingness to do a more detailed review.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 21 August 2009 07:40 > To: Elwell, John; ecrit@ietf.org > Cc: 'Theis, Harald (Harald)'; 'John Fenn'; Hammer, Bernard;=20 > 'Vautz,Rolf (Rolf)'; 'Dietz, J.B. (Jan)' > Subject: RE: [Ecrit] Ecma-International work on emergency=20 > calls in enterprisenetworks >=20 > Hi John,=20 >=20 > Thanks for sharing this document with us. Interesting writeup.=20 >=20 > I browsed through it and it looked pretty good. I will have=20 > some comments > once I do a detailed review.=20 >=20 > For now I just wanted to quickly respond to the=20 > standardization gaps that > are listed in the document:=20 >=20 > ------ > STANDARDISATION GAP 1 (see 6.1.2): There are currently no service URNs > defined for > use where enterprise-specific emergency services need to be identified > separately from > public emergency services. > ------ >=20 > First, there is the question whether you really need this. I=20 > will have to > read through the document in more detail to get an understanding.=20 [JRE] Certainly there will be enterprise-specific emergency services. In some enterprise networks it might be sufficient to use the existing service URNs, and simply route to the appropriate private emergency response centre rather than to a PSAP, but if there are enterprises where the user may have a choice (e.g., could dial an enterprise emergency code or 112), this would suggest the need for separate URNs. See what you think when you have reviewed the relevant section. We certainly would appreciate wider input to this question. Another question is who will want to register these additional URNs - individual enterprises for their own purposes, particular industries, or simply generic ones registered by Ecma, say. >=20 > Let's assume you do need additional service URNs then there=20 > are a few ways > to get them:=20 >=20 > * You could define new sub-services for the 'sos' service > http://www.ietf.org/rfc/rfc5031.txt > Policy: expert review=20 [JRE] Perhaps appropriate if the new values do not overlap with existing values, e.g., I cannot recall whether there is an existing value for an emergency in an oil refinery or chemical plant. >=20 > * You could define new to-top level service URNs > Since a number of folks in the group wanted to do that we started the > discussion around relaxing the policy from 'Standards Action'=20 > (as defined in > RFC 5031) to 'expert review' (in > http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy- > 00.txt). The > rechartering process is currently ongoing.=20 [JRE] Noted. >=20 > * Finally, you can define your own URNs, as it is done with > http://tools.ietf.org/html/draft-rosen-urn-nena-00 > The usage scenario in NENA is, however, different. There,=20 > folks want to use > their own Service URNs within the ESINet.=20 >=20 > So, it depends on your scenarios.=20 [JRE] I had missed that - I will investigate. >=20 > ------ > STANDARDISATION GAP 2 (see 6.2.2.2.2): There is no=20 > standardised means of > conveying > information on position relative to access points in SIP. > ------ >=20 > This is a GEOPRIV topic. There was a proposal > (http://tools.ietf.org/id/draft-linsner-geopriv-relativeloc-03 > .txt) or even > more than one.=20 >=20 > If I recall it correctly then the main question by some folks=20 > in the GEOPRIV > group was whether this is really so useful. I again have to=20 > read through > your document to figure out what your arguments are.=20 [JRE] Noted. >=20 > ------ > STANDARDISATION GAP 3 (see 6.4.3): There is currently no=20 > reliable means of > identifying > a return call from an ERC. > ------ >=20 > We had chats about this topic in ECRIT for a long time and=20 > then finally > decided that we should do a writeup of this topic. The group=20 > was interested > in working on this subject and it is also included in the=20 > re-chartering > process. Here is the document: > http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt [JRE] Yes, I was aware of that. >=20 > Since this work is still at a very early stage we would=20 > highly appreciate > feedback to make basic design decisions.=20 [JRE] I will investigate. John >=20 > Ciao > Hannes > =20 >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > >On Behalf Of Elwell, John > >Sent: 19 August, 2009 19:57 > >To: ecrit@ietf.org > >Cc: Theis, Harald (Harald); John Fenn; Hammer, Bernard;=20 > >Vautz,Rolf (Rolf); Dietz, J.B. (Jan) > >Subject: [Ecrit] Ecma-International work on emergency calls in=20 > >enterprisenetworks > > > >As part of its work on enterprise networks under the name Next=20 > >Generation Corporate Networks (NGCN), including interoperation=20 > >with NGN, Ecma-International has carried out investigations=20 > >into emergency calling in enterprise networks, and a=20 > >near-final draft of the resulting Technical Report is available here: > > > >http://www.ecma-international.org/activities/Communications/9th > >%20draft% > >20TRNGCN%20Emergency%20calls.pdf > > > >The report draws heavily on the work of ECRIT. Any comments on=20 > >the draft would be appreciated. We hope to finalise it during=20 > >the second half of September. > > > >John > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > >=20 >=20 From hannes.tschofenig@nsn.com Sun Aug 23 09:37:41 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0045B3A6ADC for ; Sun, 23 Aug 2009 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.893 X-Spam-Level: X-Spam-Status: No, score=-4.893 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc4ZsCwPd3tR for ; Sun, 23 Aug 2009 09:37:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3B3423A6A71 for ; Sun, 23 Aug 2009 09:37:38 -0700 (PDT) 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 n7NGbcPU007745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Aug 2009 18:37:38 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7NGbcZY020594; Sun, 23 Aug 2009 18:37:38 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Aug 2009 18:37:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 23 Aug 2009 19:40:16 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019E0F88@FIESEXC015.nsn-intra.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00249BDF6@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks Thread-Index: Acog7hwZDo21zJa1SqekFqluS72/OgBOdahQABaZFnAAM/qO8A== References: <0D5F89FAC29E2C41B98A6A762007F5D00249B512@GBNTHT12009MSX.gb002.siemens.net><008601ca222a$254fad70$035ca20a@nsnintra.net> <0D5F89FAC29E2C41B98A6A762007F5D00249BDF6@GBNTHT12009MSX.gb002.siemens.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Elwell, John" , "Hannes Tschofenig" , X-OriginalArrivalTime: 23 Aug 2009 16:37:38.0097 (UTC) FILETIME=[06858210:01CA2410] Cc: "Theis, Harald \(Harald\)" , John Fenn , "Hammer, Bernard" , "Vautz, Rolf \(Rolf\)" , "Dietz, J.B. \(Jan\)" Subject: Re: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 16:37:41 -0000 Hi John,=20 >Hannes, > >Thanks for your initial feedback and your willingness to do a=20 >more detailed review.=20 > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: 21 August 2009 07:40 >> To: Elwell, John; ecrit@ietf.org >> Cc: 'Theis, Harald (Harald)'; 'John Fenn'; Hammer, Bernard;=20 >> 'Vautz,Rolf (Rolf)'; 'Dietz, J.B. (Jan)' >> Subject: RE: [Ecrit] Ecma-International work on emergency calls in=20 >> enterprisenetworks >>=20 >> Hi John, >>=20 >> Thanks for sharing this document with us. Interesting writeup.=20 >>=20 >> I browsed through it and it looked pretty good. I will have some=20 >> comments once I do a detailed review. >>=20 >> For now I just wanted to quickly respond to the standardization gaps=20 >> that are listed in the document: >>=20 >> ------ >> STANDARDISATION GAP 1 (see 6.1.2): There are currently no=20 >service URNs=20 >> defined for use where enterprise-specific emergency services need to=20 >> be identified separately from public emergency services. >> ------ >>=20 >> First, there is the question whether you really need this. I=20 >will have=20 >> to read through the document in more detail to get an understanding. >[JRE] Certainly there will be enterprise-specific emergency=20 >services. In some enterprise networks it might be sufficient=20 >to use the existing service URNs, and simply route to the=20 >appropriate private emergency response centre rather than to a=20 >PSAP, but if there are enterprises where the user may have a=20 >choice (e.g., could dial an enterprise emergency code or 112),=20 >this would suggest the need for separate URNs. >See what you think when you have reviewed the relevant=20 >section. We certainly would appreciate wider input to this=20 >question. Another question is who will want to register these=20 >additional URNs - individual enterprises for their own=20 >purposes, particular industries, or simply generic ones=20 >registered by Ecma, say. Please note that the usage of enterprise specific emergency services numbers does not require new Service URNs to get registered. It requires additional entries in the LoST database.=20 > >>=20 >> Let's assume you do need additional service URNs then there=20 >are a few=20 >> ways to get them: >>=20 >> * You could define new sub-services for the 'sos' service=20 >> http://www.ietf.org/rfc/rfc5031.txt >> Policy: expert review >[JRE] Perhaps appropriate if the new values do not overlap=20 >with existing values, e.g., I cannot recall whether there is=20 >an existing value for an emergency in an oil refinery or=20 >chemical plant. When you define a new Service URN you would expect a different routing behavior.=20 So, why would you route an emergency call related that happens in an oil refinery or=20 chemical plant differently than another emergency call?=20 We once had a discussion already a related topic when someone suggested that we should define one service URN for calls that involve a murder, another one when they involve a robbery, etc. I believe it would be very difficult for the user to make that differentiation.=20 Please note that the emergency call routing has nothing todo with the way how the dispatch happens. First responders would obviously react differently (but that's a different story) in the above-mentioned cases. > >>=20 >> * You could define new to-top level service URNs Since a number of=20 >> folks in the group wanted to do that we started the=20 >discussion around=20 >> relaxing the policy from 'Standards Action' >> (as defined in >> RFC 5031) to 'expert review' (in >> http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy- >> 00.txt). The >> rechartering process is currently ongoing.=20 >[JRE] Noted. > >>=20 >> * Finally, you can define your own URNs, as it is done with=20 >> http://tools.ietf.org/html/draft-rosen-urn-nena-00 >> The usage scenario in NENA is, however, different. There, folks want=20 >> to use their own Service URNs within the ESINet. >>=20 >> So, it depends on your scenarios.=20 >[JRE] I had missed that - I will investigate. > >>=20 >> ------ >> STANDARDISATION GAP 2 (see 6.2.2.2.2): There is no=20 >standardised means=20 >> of conveying information on position relative to access=20 >points in SIP. >> ------ >>=20 >> This is a GEOPRIV topic. There was a proposal >> (http://tools.ietf.org/id/draft-linsner-geopriv-relativeloc-03 >> .txt) or even >> more than one.=20 >>=20 >> If I recall it correctly then the main question by some folks in the=20 >> GEOPRIV group was whether this is really so useful. I again have to=20 >> read through your document to figure out what your arguments are. >[JRE] Noted. > >>=20 >> ------ >> STANDARDISATION GAP 3 (see 6.4.3): There is currently no reliable=20 >> means of identifying a return call from an ERC. >> ------ >>=20 >> We had chats about this topic in ECRIT for a long time and then=20 >> finally decided that we should do a writeup of this topic. The group=20 >> was interested in working on this subject and it is also included in=20 >> the re-chartering process. Here is the document: >> http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt >[JRE] Yes, I was aware of that. > >>=20 >> Since this work is still at a very early stage we would highly=20 >> appreciate feedback to make basic design decisions. >[JRE] I will investigate. > >John > > More feedback later.=20 Ciao Hannes > >>=20 >> Ciao >> Hannes >> =20 >>=20 >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> >Behalf Of Elwell, John >> >Sent: 19 August, 2009 19:57 >> >To: ecrit@ietf.org >> >Cc: Theis, Harald (Harald); John Fenn; Hammer, Bernard; Vautz,Rolf=20 >> >(Rolf); Dietz, J.B. (Jan) >> >Subject: [Ecrit] Ecma-International work on emergency calls in=20 >> >enterprisenetworks >> > >> >As part of its work on enterprise networks under the name Next=20 >> >Generation Corporate Networks (NGCN), including interoperation with=20 >> >NGN, Ecma-International has carried out investigations into=20 >emergency=20 >> >calling in enterprise networks, and a near-final draft of the=20 >> >resulting Technical Report is available here: >> > >> >http://www.ecma-international.org/activities/Communications/9th >> >%20draft% >> >20TRNGCN%20Emergency%20calls.pdf >> > >> >The report draws heavily on the work of ECRIT. Any comments on the=20 >> >draft would be appreciated. We hope to finalise it during=20 >the second=20 >> >half of September. >> > >> >John >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> > >>=20 >>=20 >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Mon Aug 24 10:53:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09753A6E79 for ; Mon, 24 Aug 2009 10:53:14 -0700 (PDT) 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.169, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHCIsCIIN2Ge for ; Mon, 24 Aug 2009 10:53:13 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 3DC4F3A6BF0 for ; Mon, 24 Aug 2009 10:53:13 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.33]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mfdj5-0004Q2-SA; Mon, 24 Aug 2009 12:53:04 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 24 Aug 2009 13:53:04 -0400 From: Brian Rosen To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Elwell, John" , Hannes Tschofenig , Message-ID: Thread-Topic: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks Thread-Index: Acog7hwZDo21zJa1SqekFqluS72/OgBOdahQABaZFnAAM/qO8ABkXlOJ In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45019E0F88@FIESEXC015.nsn-intra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: "Theis, Harald \(Harald\)" , John Fenn , "Hammer, Bernard" , "Vautz, Rolf \(Rolf\)" , "Dietz, J.B. \(Jan\)" Subject: Re: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 17:53:14 -0000 I believe the way we envisioned things with enterprises boiled down to three things: A) In most jurisdictions, for most enterprises it is a VERY BAD IDEA to send emergency calls to some local responder. In some jurisdictions, for most enterprises, it's illegal. B) Where doing that is the right idea: an airport with its own fire, police and EMS services on site for example, the way we expect it would be done is to have the actual LoST service have the correct entry. This means, for example, that a call from a mobile phone from the airport would get routed correctly. If calls should go somewhere within the enterprise, then ALL calls should go there C) Despite the above two, we know that some enterprises will do the wrong thing. The way to do that is to have a local LoST server with the routing the way the enterprise wants it. Of course, not all services would discover that LoST server, but the ones they really care about would Brian On 8/23/09 12:40 PM, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: > Hi John, > >> Hannes, >> >> Thanks for your initial feedback and your willingness to do a >> more detailed review. >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: 21 August 2009 07:40 >>> To: Elwell, John; ecrit@ietf.org >>> Cc: 'Theis, Harald (Harald)'; 'John Fenn'; Hammer, Bernard; >>> 'Vautz,Rolf (Rolf)'; 'Dietz, J.B. (Jan)' >>> Subject: RE: [Ecrit] Ecma-International work on emergency calls in >>> enterprisenetworks >>> >>> Hi John, >>> >>> Thanks for sharing this document with us. Interesting writeup. >>> >>> I browsed through it and it looked pretty good. I will have some >>> comments once I do a detailed review. >>> >>> For now I just wanted to quickly respond to the standardization gaps >>> that are listed in the document: >>> >>> ------ >>> STANDARDISATION GAP 1 (see 6.1.2): There are currently no >> service URNs >>> defined for use where enterprise-specific emergency services need to >>> be identified separately from public emergency services. >>> ------ >>> >>> First, there is the question whether you really need this. I >> will have >>> to read through the document in more detail to get an understanding. >> [JRE] Certainly there will be enterprise-specific emergency >> services. In some enterprise networks it might be sufficient >> to use the existing service URNs, and simply route to the >> appropriate private emergency response centre rather than to a >> PSAP, but if there are enterprises where the user may have a >> choice (e.g., could dial an enterprise emergency code or 112), >> this would suggest the need for separate URNs. >> See what you think when you have reviewed the relevant >> section. We certainly would appreciate wider input to this >> question. Another question is who will want to register these >> additional URNs - individual enterprises for their own >> purposes, particular industries, or simply generic ones >> registered by Ecma, say. > > Please note that the usage of enterprise specific emergency services > numbers does not require new Service URNs to get registered. It requires > additional entries in the LoST database. > >> >>> >>> Let's assume you do need additional service URNs then there >> are a few >>> ways to get them: >>> >>> * You could define new sub-services for the 'sos' service >>> http://www.ietf.org/rfc/rfc5031.txt >>> Policy: expert review >> [JRE] Perhaps appropriate if the new values do not overlap >> with existing values, e.g., I cannot recall whether there is >> an existing value for an emergency in an oil refinery or >> chemical plant. > > When you define a new Service URN you would expect a different routing > behavior. > So, why would you route an emergency call related that happens in an > oil refinery or > chemical plant differently than another emergency call? > > We once had a discussion already a related topic when someone suggested > that we should define one service URN for calls that involve a murder, > another one when they involve a robbery, etc. I believe it would be > very difficult for the user to make that differentiation. > > Please note that the emergency call routing has nothing todo with the > way how the dispatch happens. First responders would obviously react > differently (but that's a different story) in the above-mentioned cases. > > >> >>> >>> * You could define new to-top level service URNs Since a number of >>> folks in the group wanted to do that we started the >> discussion around >>> relaxing the policy from 'Standards Action' >>> (as defined in >>> RFC 5031) to 'expert review' (in >>> http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy- >>> 00.txt). The >>> rechartering process is currently ongoing. >> [JRE] Noted. >> >>> >>> * Finally, you can define your own URNs, as it is done with >>> http://tools.ietf.org/html/draft-rosen-urn-nena-00 >>> The usage scenario in NENA is, however, different. There, folks want >>> to use their own Service URNs within the ESINet. >>> >>> So, it depends on your scenarios. >> [JRE] I had missed that - I will investigate. >> >>> >>> ------ >>> STANDARDISATION GAP 2 (see 6.2.2.2.2): There is no >> standardised means >>> of conveying information on position relative to access >> points in SIP. >>> ------ >>> >>> This is a GEOPRIV topic. There was a proposal >>> (http://tools.ietf.org/id/draft-linsner-geopriv-relativeloc-03 >>> .txt) or even >>> more than one. >>> >>> If I recall it correctly then the main question by some folks in the >>> GEOPRIV group was whether this is really so useful. I again have to >>> read through your document to figure out what your arguments are. >> [JRE] Noted. >> >>> >>> ------ >>> STANDARDISATION GAP 3 (see 6.4.3): There is currently no reliable >>> means of identifying a return call from an ERC. >>> ------ >>> >>> We had chats about this topic in ECRIT for a long time and then >>> finally decided that we should do a writeup of this topic. The group >>> was interested in working on this subject and it is also included in >>> the re-chartering process. Here is the document: >>> http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt >> [JRE] Yes, I was aware of that. >> >>> >>> Since this work is still at a very early stage we would highly >>> appreciate feedback to make basic design decisions. >> [JRE] I will investigate. >> >> John >> >> > > More feedback later. > > Ciao > Hannes > >> >>> >>> Ciao >>> Hannes >>> >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Elwell, John >>>> Sent: 19 August, 2009 19:57 >>>> To: ecrit@ietf.org >>>> Cc: Theis, Harald (Harald); John Fenn; Hammer, Bernard; Vautz,Rolf >>>> (Rolf); Dietz, J.B. (Jan) >>>> Subject: [Ecrit] Ecma-International work on emergency calls in >>>> enterprisenetworks >>>> >>>> As part of its work on enterprise networks under the name Next >>>> Generation Corporate Networks (NGCN), including interoperation with >>>> NGN, Ecma-International has carried out investigations into >> emergency >>>> calling in enterprise networks, and a near-final draft of the >>>> resulting Technical Report is available here: >>>> >>>> http://www.ecma-international.org/activities/Communications/9th >>>> %20draft% >>>> 20TRNGCN%20Emergency%20calls.pdf >>>> >>>> The report draws heavily on the work of ECRIT. Any comments on the >>>> draft would be appreciated. We hope to finalise it during >> the second >>>> half of September. >>>> >>>> John >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From john.elwell@siemens-enterprise.com Mon Aug 24 20:17:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5DB3A6EB9 for ; Mon, 24 Aug 2009 20:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkOCEYpPFKR5 for ; Mon, 24 Aug 2009 20:17:12 -0700 (PDT) Received: from gbmddmh212asvr.siemens.co.uk (gbmddmh212asvr.siemens.co.uk [212.58.233.141]) by core3.amsl.com (Postfix) with ESMTP id 080203A6875 for ; Mon, 24 Aug 2009 20:17:11 -0700 (PDT) Received: from GBMDDMH214ASVR ([192.168.200.78]) by gbmddmh212asvr.siemens.co.uk (Switch-3.3.0/Switch-3.3.0) with ESMTP id n7P3O2Si017254 for ; Tue, 25 Aug 2009 04:24:02 +0100 Received: from GBNTHDA1206MSX.gb001.siemens.net ([137.223.164.54]) by GBMDDMH214ASVR with InterScan Messaging Security Suite; Tue, 25 Aug 2009 04:15:29 +0100 Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by GBNTHDA1206MSX.gb001.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 04:17:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Aug 2009 04:17:07 +0100 Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D00249BEDD@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45019E0F88@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks Thread-Index: Acog7hwZDo21zJa1SqekFqluS72/OgBOdahQABaZFnAAM/qO8ABY3AOw References: <0D5F89FAC29E2C41B98A6A762007F5D00249B512@GBNTHT12009MSX.gb002.siemens.net><008601ca222a$254fad70$035ca20a@nsnintra.net> <0D5F89FAC29E2C41B98A6A762007F5D00249BDF6@GBNTHT12009MSX.gb002.siemens.net> <3D3C75174CB95F42AD6BCC56E5555B45019E0F88@FIESEXC015.nsn-intra.net> From: "Elwell, John" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "Hannes Tschofenig" , X-OriginalArrivalTime: 25 Aug 2009 03:17:11.0393 (UTC) FILETIME=[89338D10:01CA2532] Cc: "Theis, Harald \(Harald\)" , John Fenn , "Hammer, Bernard" , "Vautz, Rolf \(Rolf\)" , "Dietz, J.B. \(Jan\)" Subject: Re: [Ecrit] Ecma-International work on emergency calls in enterprisenetworks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 03:17:13 -0000 Hannes, Sorry for the anticipated delay in this reaching you, due to travelling. See below.=20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: 23 August 2009 17:40 > To: Elwell, John; Hannes Tschofenig; ecrit@ietf.org > Cc: Theis, Harald (Harald); John Fenn; Hammer, Bernard;=20 > Vautz,Rolf (Rolf); Dietz, J.B. (Jan) > Subject: RE: [Ecrit] Ecma-International work on emergency=20 > calls in enterprisenetworks >=20 > Hi John,=20 >=20 > >Hannes, > > > >Thanks for your initial feedback and your willingness to do a=20 > >more detailed review.=20 > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: 21 August 2009 07:40 > >> To: Elwell, John; ecrit@ietf.org > >> Cc: 'Theis, Harald (Harald)'; 'John Fenn'; Hammer, Bernard;=20 > >> 'Vautz,Rolf (Rolf)'; 'Dietz, J.B. (Jan)' > >> Subject: RE: [Ecrit] Ecma-International work on emergency calls in=20 > >> enterprisenetworks > >>=20 > >> Hi John, > >>=20 > >> Thanks for sharing this document with us. Interesting writeup.=20 > >>=20 > >> I browsed through it and it looked pretty good. I will have some=20 > >> comments once I do a detailed review. > >>=20 > >> For now I just wanted to quickly respond to the=20 > standardization gaps=20 > >> that are listed in the document: > >>=20 > >> ------ > >> STANDARDISATION GAP 1 (see 6.1.2): There are currently no=20 > >service URNs=20 > >> defined for use where enterprise-specific emergency=20 > services need to=20 > >> be identified separately from public emergency services. > >> ------ > >>=20 > >> First, there is the question whether you really need this. I=20 > >will have=20 > >> to read through the document in more detail to get an=20 > understanding. > >[JRE] Certainly there will be enterprise-specific emergency=20 > >services. In some enterprise networks it might be sufficient=20 > >to use the existing service URNs, and simply route to the=20 > >appropriate private emergency response centre rather than to a=20 > >PSAP, but if there are enterprises where the user may have a=20 > >choice (e.g., could dial an enterprise emergency code or 112),=20 > >this would suggest the need for separate URNs. > >See what you think when you have reviewed the relevant=20 > >section. We certainly would appreciate wider input to this=20 > >question. Another question is who will want to register these=20 > >additional URNs - individual enterprises for their own=20 > >purposes, particular industries, or simply generic ones=20 > >registered by Ecma, say. >=20 > Please note that the usage of enterprise specific emergency services > numbers does not require new Service URNs to get registered.=20 > It requires > additional entries in the LoST database.=20 [JRE] Certainly. This would be the way of achieving routing to an enterprise ERC if, for a given emergency service URN in a given location, the enterprise operator requires use of the enterprise ERC rather than the PSAP. What we are talking about with this issue is whether there are different service types that enterprises might require. Personally I am not totally convinced of the need, but some of my colleagues in Ecma thought this would be a strong possibility. >=20 > > > >>=20 > >> Let's assume you do need additional service URNs then there=20 > >are a few=20 > >> ways to get them: > >>=20 > >> * You could define new sub-services for the 'sos' service=20 > >> http://www.ietf.org/rfc/rfc5031.txt > >> Policy: expert review > >[JRE] Perhaps appropriate if the new values do not overlap=20 > >with existing values, e.g., I cannot recall whether there is=20 > >an existing value for an emergency in an oil refinery or=20 > >chemical plant. >=20 > When you define a new Service URN you would expect a different routing > behavior.=20 > So, why would you route an emergency call related that happens in an > oil refinery or=20 > chemical plant differently than another emergency call?=20 >=20 > We once had a discussion already a related topic when someone=20 > suggested > that we should define one service URN for calls that involve a murder, > another one when they involve a robbery, etc. I believe it would be > very difficult for the user to make that differentiation.=20 >=20 > Please note that the emergency call routing has nothing todo with the > way how the dispatch happens. First responders would obviously react > differently (but that's a different story) in the=20 > above-mentioned cases. [JRE] I agree with what you say, but that doesn't really address the point. Suppose a given enterprise has an ERC for dealing with medical emergencies on enterprise premises. We could use the normal service URN for medical emergencies and rely on the LoST query to cause routing to the enterprise ERC. But then there is no way of making a call from the enterprise to the PSAP that deals with medical emergencies. Some contributors to the Ecma work thought this might be needed in some cases. This presumably is based on knowledge of how legacy enterprise networks sometimes are set up for emergency calls, with difference dial strings for accessing private ERC and PSAP. John =20 From James.Winterbottom@andrew.com Thu Aug 27 17:23:33 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62343A6822; Thu, 27 Aug 2009 17:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.207 X-Spam-Level: X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1j2Zjy0daFm; Thu, 27 Aug 2009 17:23:32 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 95AAF3A6BBD; Thu, 27 Aug 2009 17:22:47 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_08_27_19_46_01 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 27 Aug 2009 19:46:00 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 19:22:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2775.AE35B812" Date: Thu, 27 Aug 2009 19:22:51 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Emergency Services Workshop 6 Thread-Index: Aconda2+kZ6iL+wLQ5+3FDLKYaiqEQ== From: "Winterbottom, James" To: , "GEOPRIV" X-OriginalArrivalTime: 28 Aug 2009 00:22:53.0141 (UTC) FILETIME=[AED63050:01CA2775] Subject: [Ecrit] Emergency Services Workshop 6 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 00:23:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2775.AE35B812 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=0D=0A=0D=0A=20=0D=0A=0D=0AThe sixth Emergency Services Workshop wil= l be held in Kuala Lumpur=0D=0AMalaysia the week before the IETF meeting in= Hiroshima.=0D=0A=0D=0AThe dates for the event at the 4th and 5th of Novemb= er.=0D=0A=0D=0A=20=0D=0A=0D=0AMore details on the event can be found here:=0D= =0Ahttp://www.emergency-services-coordination.info/esw6.html=0D=0A=0D=0A =0D= =0A=0D=0AWe expect a registration page to be available early next week and = I will=0D=0Asend an update when registration is fully open.=0D=0A=0D=0A=20=0D= =0A=0D=0APlease keep this event in mind as it is the first of these that we= have=0D=0Abeen able to host in Asia.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D=0A=0D= =0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A------------------------------------------= ------------------------------------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information. =20=0D=0AIf you have received it in= error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA2775.AE35B812 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=
    =0D=0A=0D=0A

    Hi All,=

    =0D=0A=0D=0A

    &nb= sp;

    =0D=0A=0D=0A

    The s= ixth Emergency Services Workshop will be held in Kuala Lumpur Malaysia=0D=0Athe week before the IETF meeting in = Hiroshima.<= /font>

    =0D=0A=0D=0A

    The dates for the even= t at the 4th and 5th=0D=0Aof November.

    =0D=0A=0D=0A

    =  <= /span>

    =0D=0A=0D=0A

    More details on= the event can be found here: http://www.emergency-services-coordination.in= fo/esw6.html

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    We expect a registration page to be available early next=0D= =0Aweek and I will send an update when registration is fully open.

    =0D=0A=0D=0A

     <= /o:p>

    =0D=0A=0D=0A

    Please ke= ep this event in mind as it is the first of these=0D=0Athat we have been ab= le to host in Asia.

    =0D=0A=0D=0A

     =

    =0D=0A=0D=0A

    Cheers

    =0D=0A=0D=0A

    = James

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A=0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A
    =0D=0A

     

    =0D=0A     		=0D=0A

     

    =0D=0A
    =0D= =0A=0D=0A

     

    =0D=0A=0D= =0A

     

    =0D=0A=0D=0A=
    =0D=0A=0D=0A

    = =0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01CA2775.AE35B812-- From g.caron@bell.ca Mon Aug 31 13:09:49 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1242128C518 for ; Mon, 31 Aug 2009 13:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 BVWQTR7R0uRd for ; Mon, 31 Aug 2009 13:09:44 -0700 (PDT) Received: from mail70.messagelabs.com (mail70.messagelabs.com [193.109.255.115]) by core3.amsl.com (Postfix) with ESMTP id 96CB028C527 for ; Mon, 31 Aug 2009 13:09:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-8.tower-70.messagelabs.com!1251749378!112377173!22 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [206.47.0.168] Received: (qmail 5475 invoked from network); 31 Aug 2009 20:09:53 -0000 Received: from srp004371srs (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-8.tower-70.messagelabs.com with RC4-SHA encrypted SMTP; 31 Aug 2009 20:09:53 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.1.358.0; Mon, 31 Aug 2009 16:10:00 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub02-wyn.bell.corp.bce.ca ([142.182.199.50]) with mapi; Mon, 31 Aug 2009 16:09:48 -0400 From: To: , , Date: Mon, 31 Aug 2009 16:09:47 -0400 Thread-Topic: [Ecrit] Please respond to the Premature Disconnect HUM Thread-Index: AcoXhxQtX8f3gqAXCEqhXCTtM2totQH3pMOgAsPWA1A= Message-ID: <0FEAC1C09868B34A982F4FB40254B37C275A0B8EA3@MBX02.bell.corp.bce.ca> References: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> In-Reply-To: <002801ca1f65$e1c9fef0$2549a20a@nsnintra.net> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0FEAC1C09868B34A982F4FB40254B37C275A0B8EA3MBX02bellcorp_" MIME-Version: 1.0 Subject: Re: [Ecrit] Please respond to the Premature Disconnect HUM X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 20:09:49 -0000 --_000_0FEAC1C09868B34A982F4FB40254B37C275A0B8EA3MBX02bellcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Do you think that this is a problem worth solving in ECRIT? YES. Those features are an integral part of some emergency services and sho= uld have an evolution path within the IP domain. In my view, ECRIT is the m= ost appropriate place to initiate such engineering process and possibly imp= rove the features over their PSTN ancestors. Thanks, Guy ________________________________ De : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de H= annes Tschofenig Envoy=E9 : 17 ao=FBt 2009 14:10 =C0 : 'Marc Linsner'; 'ecrit' Objet : [Ecrit] Please respond to the Premature Disconnect HUM FYI: We have not received a lot of feedback (maybe because of the holidays,= maybe because of lack of interest, maybe because of the other discussions)= . So, help us to make a decision... ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: 07 August, 2009 20:47 To: 'ecrit' Subject: [Ecrit] Premature Disconnect At the Stockholm meeting Brian Rosen presented Premature Disconnect (http:/= /www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit= -premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecri= t-premature-disconnect-rqmts-02). After some amount of discussion, we told= Brian to 'go away' and bring back a problem statement vs. a set of require= ments so we could evaluate whether this is something we wanted to work on. = I had hoped we would have time during the meeting for Brian to present the= problem statement, but we ran out of time. Brian sent it to the list on 7/= 29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html). Now for the obvious questions. Do you have feedback regarding the problem statement? Do you think that this is a problem worth solving in ECRIT? Your feedback will determine whether we ask for AD approval to add this wor= k to our charter. Please respond by COB Friday August 14, 2009. Thanks, Marc & Hannes --_000_0FEAC1C09868B34A982F4FB40254B37C275A0B8EA3MBX02bellcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Premature Disconnect

    Hi,

     

    Do you think that this is a problem worth solvi= ng in ECRIT?

     =

    YES. Those featur= es are an integral part of some emergency services and should have an evolution pa= th within the IP domain. In my view, ECRIT is the most appropriate place to initiate such engineering process and possibly improve the features over th= eir PSTN ancestors.

     =

    Thanks,

     =

    Guy

    De : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de Hannes Tschofenig
    Envoy=E9 : 17 ao=FBt 20= 09 14:10
    =C0 : 'Marc Linsner'; '= ecrit'
    Objet : [Ecrit] Please respond to the Premature Disconnect HUM    <= /o:p>

     

    FYI: We have not received a lot of feedback (maybe because of the holidays, maybe because of lack of interest, maybe because of the other discussions). So, help us to make a decision...<= /span>

     

    From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
    Sent: 07 August, 2009 20:47<= br> To: 'ecrit'
    Subject: [Ecrit] Premature Disconnect

    At the Stockholm meeting Brian Rosen presented Prematu= re Disconnect (http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-= rqmts-02).  After some amount of discussion, we told Brian to ‘go away̵= 7; and bring back a problem statement vs. a set of requirements so we could evaluate whether this is something we wanted to work on.  I had hoped = we would have time during the meeting for Brian to present the problem stateme= nt, but we ran out of time. Brian sent it to the list on 7/29/09 (h= ttp://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html).

    Now for the obvious questions.

    Do you have feedback regarding the problem statement?

    Do you think that this is a problem worth solving in ECRIT?

    Your feedback will determine whether we ask for AD approval to add this wor= k to our charter.  Please respond by COB Friday August 14, 2009.

    Thanks,

    Marc & Hannes

    --_000_0FEAC1C09868B34A982F4FB40254B37C275A0B8EA3MBX02bellcorp_--

    -------------------------------------------------------------------= -----------------------------
    =0D=0AThis message is for&n= bsp;the designated recipient only and may
    =0D=0A= contain privileged, proprietary, or otherwise priv= ate information.  
    =0D=0AIf you have recei= ved it in error, please notify the sende= r
    =0D=0Aimmediately and delete the original. &n= bsp;Any unauthorized use of
    =0D=0Athis email is=  prohibited.
    =0D=0A------------------------------------------------= ------------------------------------------------
    =0D=0A[mf2]